Building apps with common code for windows 8 and windows phone 8 (WP8)
•Als PPTX, PDF herunterladen•
1 gefällt mir•672 views
Windows 8 and WP8 share a lot of commonalities and are heading towards a unified code framework. Still, creating an App that will target both platforms is challenging. In this session we will discuss the commonalities and differences between the platforms, patterns and techniques that will help creating portable code between them.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (18)
Andere mochten auch
Andere mochten auch (7)
Ähnlich wie Building apps with common code for windows 8 and windows phone 8 (WP8)
Ähnlich wie Building apps with common code for windows 8 and windows phone 8 (WP8) (20)
Mehr von Tamir Dresher
Mehr von Tamir Dresher (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Building apps with common code for windows 8 and windows phone 8 (WP8)
- 1. Building Apps with common code for Windows 8 and WP8 Tamir Dresher Senior Software Architect Nov 26, 2013
- 2. About Me • • • • Software architect, consultant and instructor Technology addict .NET and Native Windows Programming http://www.TamirDresher.com.
- 3. One step towards convergence - UX • • • • • Tiles Touch interface AppBar Navigation Similar XAML Controls
- 4. One step towards convergence - Code • Common native API – DirectX, WinSock, CRT, STL and more • WinRT - Infrastructure, common type system, standard programming model. Projected C#, VB, C++ and JavaScript • Shared .NET engine
- 5. Life is not perfect • There are still parts that doesn’t exist in the other platform – System.Threading.Tasks.Parallel, PLINQ etc. – System.Collections.Concurrent namespace • There are Things that exist but with differences – Dispatcher • There are things that exist but just don’t work
- 6. WinRT under different platforms Networking Proximity In-App Purchase Sensors Location File System Core app model Threading http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff626516(v=vs.105).aspx
- 7. Demo
- 8. Common Code between platforms • There are Basically 3 techniques – Link Files – Portable Class Library (PCL) – Dependency Injection
- 9. Add as Link • Using the same file in multiple projects, without copying the file to each project. • Shared • Not Shared
- 10. Add as Link • Changes in one immediately reflects in the other • Compilation can change due to Conditionals
- 11. Demo
- 12. Add as Link – When To Use • Application logic that is shared but is not portable – each platform has its nuance • Code that is written in WinRT API. • User controls with no platform dependencies (NOT XAML) – You can use conditional compilation in your code-behind class
- 13. Portable Class Library (PCL) • Portable Class Libraries support a subset of .NET assemblies that target the platforms you choose. • One code -> one project -> one binary for all platforms • Unsupported in VS2012 Express edition
- 14. Portable Class Library (PCL) • • • • Supports managed code only Doesn’t use conditional compilation related to platform Doesn’t use WinRT API Isn't relevant to UI constructs - XAML code isn’t portable
- 16. Demo
- 17. Portable Class Library – When To Use • Shared Managed Code that deals with Logic • Code that doesn’t depends on specific platform API
- 18. How To Deal with Non-Portable Code • Using the Adapter Pattern PCL ISomeService WP8 Win8 ServiceAdapterWP8 ServiceAdapterWin8 3rdPartyWP8 3rdPartyWin8
- 19. Sharing UI Code • Separate UI from app logic
- 20. Summary • • • • • Separate UI from app logic Share your logic in PCL Use Linked Files when necessary (WinRT) Abstract your dependencies and use DI We are on the path for convergence but there is still a long way to go
- 21. Presenter contact details c: +972-52-4772946 e: tamirdr@codevalue.net b: TamirDresher.com w: www.codevalue.net
Hinweis der Redaktion
- UI Consistency
- UI Consistency
- The set of Windows Runtime API not supported on Windows Phone 8. The API surface area of Windows Runtime is very large, with over 11,000 members. We’ve adopted a subset for Windows Phone 8 that allows you to build compelling phone scenarios. Area 1 in the diagram above represents the APIs that are not available on Windows Phone 8.The set of Windows Runtime API adopted for Windows Phone 8. This is represented by area 2 in the above diagram and consists of approximately 2,800 members. For some types, we have not implemented certain members. For others we have added additional members to support phone-only features. In both cases, these differences are noted in the API reference documentation.We’ve added key APIs needed to build great apps for the phone. These are represented by area 3 in the diagram and total about 600 members. For example, we have brand-new APIs for speech synthesis and recognition, VOIP, and other features. Creating these as Windows Runtime style APIs means you can use them regardless of the programming language you use for your app.
- Code that is written in WinRT API. Windows Phone 8 has adopted a subset of Windows Runtime App logic common to both apps, but not portable. In Windows Phone 8 and Windows 8, a lot of infrastructure code, or code that interacts with the operating system or external data sources, can be written using Windows Runtime API. Because Windows Phone 8 has adopted a subset of Windows Runtime, it’s possible to write code that uses this functionality once, and then share it across your apps. For example, both platforms have the same Windows Runtime API for networking, sensors, location, in-app purchase, and proximity. There’s significant overlap in these API on both platforms. This code can’t be placed in a Portable Class Library because it’s not portable. The .NET Framework portable libraries don’t support Windows Runtime. Instead, you can isolate the use of these APIs to classes in your app and share as linked code files in both your Windows Phone 8 and Windows Store app. If you’re using the free, Express versions of Visual Studio, you won’t be able to create Portable Class Libraries. In this case, you should use this code sharing technique to share your app logic. For example, apps that have been built using the Model-View-ViewModel (MVVM) pattern could share the model and viewmodel of you app.User controls with no platform dependencies. Windows Phone 8 and Windows 8 both enable you to create rich user experiences using XAML. They implement this layer differently and have also defined the API in different namespaces. However, this divergence is not insurmountable. In fact, a lot of the functionality, types, and members are named the same between the platforms, and behave the same way. Although the overriding guidance is to build the best user experience as possible for each platform, there may be cases when you can extract elements of your UI that are common to both, write it once, and share with both apps. It isn’t possible to conditionally compile XAML, so the UI that’s defined in a shared user control must be platform independent. You can use conditional compilation in your code-behind class of the user control, so this offers some flexibility.
- Doesn’t use Windows Runtime APIs Windows Runtime APIs aren’t portable and can’t be used in a Portable Class Library. There is overlap in the Windows Runtime APIs that are supported on Windows Phone 8 and Windows 8. However, binary compatibility is not supported. Your code has to be compiled for each platform and therefore isn’t suitable for a Portable Class Library. Here too you should abstract the use of Windows Runtime APIs into classes or objects that aren’t shared in a Portable Class Library.Isn't relevant to UI constructs - Although XAML for both platforms looks the same (even same names) this code isn’t portable