4. Windows Phone 8 Developer Platform
XAML Apps Direct3D Apps
In-App
XAML Maps Geolocation Sensors Direct3D
Purchase
HTML XML Threading Touch Speech XAudio2
Your apps Phone
Features
Push Camera Video Proximity
Media
Foundation
Your way Calendar Wallet Contacts Core Types VoIP STL
Multitasking Live Tiles Memory Async Enterprise CRT
C# and VB C#, VB, and C++ C++
File system, Networking, Graphics, Media
Core Operating System
5. shared core
Full WinRT
11,000 members
Windows Phone Runtime
2,800 shared members
600 new members
8. Model-View-ViewModel
Windows 8 Windows Phone 8
public class Product public class Product
{ {
public int Id { get; set; } public int Id { get; set; }
[DataMember(Name = "text")] [DataMember(Name = "text")]
public string Text { get; set; } public string Text { get; set; }
[DataMember(Name = "complete")] [DataMember(Name = "complete")]
public bool Complete { get; set; } public bool Complete { get; set; }
} }
21. Different Form Factors Require Different UX
Windows Phone 8 Windows 8
Screen Size Screen Size
800x480 1024x768
1280x720 2,560x1,440
1280x768 everything
in between
22. Different Form Factors Require Different UX
Windows Phone 8 Windows 8
Orientation Orientation
Portrait Portrait
Landscape Landscape
Snapped
33. Windows 8 / Windows Phone 8 Apps Are a Perfect Match
• Mix and match techniques
• Share Models, Helpers, Services, ViewModels
• Linked files
• Portable Class Libraries
• Using #if conditionals for small code differences
• Using Extension methods to bridge implementation differences
• Async-await model for HttpWebResponse/Request
• Focus on the user experience that works for the form factor
33 Microsoft confidential 12/5/2012
34. Some WP7 Love
WP7 can do Async/Await!
Install-Package Microsoft.Bcl.Async
PCLs can add this package too!
34 Microsoft confidential 12/5/2012
Welcome to Cross Development for Windows 8 and Windows Phone 8. In the next hour we’re going to go over the best practices, tips and tricks for developing applications that will delight users across devices powered by both Windows 8 and Windows Phone 8.
All in all out of 11,000 full WinRT members, Windows Phone Runtime shares 2800 of them and adds 600 specifically for phones. And these commonalties will only increase with future releases.
Right off the bat, we can see we have a similar structure. App.xaml handles our resource management, App.xaml.cs handles launching and suspension methods, the MainPage.xaml page contains the UI and has been set to the initial screen on startup.The big difference between these two projects is that the Windows Phone 8 version has been prepared to make localization a little easier.But the bulk of the functionality that we want to look at is in the MainPage.xaml.cs
But no! Because we’re going to add the files as links into our Windows Phone 8 project. We just right click in our project, add an existing item and make sure that we “Add as Link” instead of a simple “Add”. This way when we change the file, all the changes will be implemented in both application and we won’t be stuck going back and forth copying code between our apps.
And we can see our linked classes in our Windows Phone 8 application. Perfect. Nice, healthy shared code between both projects.
The thread-handling dispatchers are different on Windows Phone and Windows 8. In windows 8, we use an element of the UI Core while in Windows Phone, we have a dispatcher that has been assigned to our app deployment. So, if you’re anything like me, you say “well it was worth a shot, time to give up”.
No, of course not. If we have a situation where there are small difference in code compatibilities, we can use compiler conditional statements to separate the incompatible lines. In the case of Windows 8 development we would say #if NETFX_CORE and for Windows Phone we have the slightly more obvious #if WINDOWS_PHONE. We should consider using this implementation when there are small differences, this isn’t a catch-all approach. If we over use it, we can make our code unreadable, unmaintainable and just plain ugly. But it is perfect for situations where you require a specific namespace for your app (for example the Windows.UI.Xaml namespace which exists in Windows 8 but not in Windows Phone) or if there are small method differences.
So let’s just take the XAML that we used for our Windows Phone UI and move it over to our Windows 8 project and…
Huh. We may wonder what went wrong here. The answer is “nothing”. The XAML is acting just the way it is supposed to act. It compiles, it runs, everything from the default styling to the user interactions all work. However, let’s take one step back and talk about the most important element of cross development between Windows 8 and Windows Phone 8.
We need to keep in mind we’re looking at two very different form factors. Windows Phone runs at 3 resolutions, on phone screens from 3.5 inches to 4.8 inches. Windows 8 runs on screen resolutions to 1024x768 to 2,560 x 1,440 although this is by no means a limit. Windows 8 powers 10 inch tablets and 82 in screens that take up the entire wall.
The same goes for orientation. Windows Phone supports portrait and landscape mode, but Windows 8 supports Portrait, landscape and the third-screen snapped mode. Each of these modes requires consideration in design, spacing, an interaction.
To aid in these considerations, Windows 8 and Windows Phone 8 have unique controls that have been designed with their particular form factors in mind. Some of the specialized controls for Windows 8 include GridView: (groupable) tile array. Also possible to dynamically size items in the grid. The GridView comes with built in styles for input and selectionSemanticZoom: Allows for quick jump through large lists of grid itemsFlipView: Browsing view optimised for touch to pane left-right through sequential items.
To aid in these considerations, Windows 8 and Windows Phone 8 have unique controls that have been designed with their particular form factors in mind. Some of the specialized controls for Windows 8 include GridView: (groupable) tile array. Also possible to dynamically size items in the grid. The GridView comes with built in styles for input and selectionSemanticZoom: Allows for quick jump through large lists of grid itemsFlipView: Browsing view optimised for touch to pane left-right through sequential items.
On the Windows Phone side of things, we have controls customized to a phone experience. The Panorama control is designed to give users a sort of “landing” space where they can get a feel for the content of the application explore that content in an open interactive environment.
New to Windows Phone 8 is the LongListSelector control. This is the recommended control for list-based UI’s, replacing the ListBox. It is optimized for scrolling speed, but also implements a “group selection” interface so that the user can move quickly between grouped items in a very long list. Here we can see that group selection applied to an alphabetical list, but you could define a set of groups and then use the group selection to navigate between them.
So what does this mean practically? It means that when we’re thinking about how we’re going to design our two applications, we should consider making use of the customized UI features of either Windows 8 or Windows Phone 8. For example, the semantic zoom control lets us see groups of items at a high level and then drill into them until we select one. That behaviour is similar in many ways to what the pivot control does. We should consider using the Pivot for the Phone and the SemanticZoom for Windows 8.
And when we select an item? Windows 8 has a very powerful paradigm of horizontal scrolling, but it’s a paradigm that doesn’t make sense in the context of a phone. So instead of mimicking the horizontal scrolling UI we see in Windows 8, we should translate that into a vertical scrolling UI that fits the phone more appropriately.
And if we have a long list of grouped items in Windows Phone 8, we might want to consider implementing them as a GridView in Windows 8. We just need to keep in mind that this is less about mimicking
So you can see our ball moves around just fine on both platforms using the same code. But remember how we can save the game and recall it later on another device? Let’s try doing that. We have to add a name for our app and, well, this is on a phone and I hate having to do all that typing so I think we should add a simple web service that can go out and get some suggestions for us while we type.
