My first Windows 8 application: A wrap up

By Justin James

Takeaway: If you’re serious about Windows 8 development, read these pointers, find out what might trip you up more than anything else, and learn what to consider in terms of testing.

I have wrapped up with my initial Windows 8 Metro applications. I spoke with some of the folks at Microsoft (notably Joe Stegman, a program manager with Microsoft overseeing WPF and XAML), and we got to the root of the performance problems I had with my Windows 8 Metro apps. It turns out my code was running right into a bug that Microsoft has fixed in its internal builds. Along the way, the Microsoft folks gave me useful advice and pointers for Windows 8 Metro applications, and that is the information that I will share today.

The first thing they suggested was to limit the data being pulled down in the first place (which is easy enough to do with the OData protocol). Some approaches they put forth are:

• Use a curated set of results.
• Limit the initial data pull to, say, 20 results, with a “See more” link or button that loads more results.
• Limit the initial data pull, and tap into the scrolling events to load more results.

All of these are definitely possible, and none of them are that much work.

This entire situation highlights to me that coming from a WinForms environment to Metro requiresa lot more than just learning new libraries and widget properties — it involves learning an entirely new approach to application design. This will trip up developers more than anything else.

In WinForms (or WebForms), the “right” approach to this kind of application is to use a DataGrid bound to some data source and set the needed properties around paging, and it is done. With Metro, it doesn’t quite work that way. A DataGrid depends on a relatively rigid screen layout and presents a ton of tiny pieces of data and small controls. That works just dandy on a desktop machine, but it falls apart when touch control comes into play. In addition, many Metro devices (particularly tablets and similar devices) may be resource constrained… bandwidth, CPU, and memory may all be at a premium. Dropping a few hundred megs of data into memory and then letting the system kind of sort it all out is a disaster for a tablet or potentially mobile user. Before you take the route of, “well, tablets might be mighty capable,” remember that it looks like Windows Phone 8 will be a phone version of Windows 8, not an updated version of Windows Phone 7 (WP7); this means you should expect your applications to work even on phones with their very limited resources. You can expect that Windows 8 RT will appear on some pretty low-end equipment to compete with the Android tablets.

If you want to write Metro apps, you need to look to the kinds of techniques that mobile developers are using. In the example application I wrote, these are the kinds of things that I would need to do to make it a top-flight Metro application:

• Emphasize search and “quick jump” techniques (like having a list of letters of the alphabet, and selecting one shows all items starting with that letter) for rapid navigation.
• De-emphasize scrolling and paging as much as possible; remember, scrolling through long lists with finger flicks is “painful” at best.
• Make the data on any list screen show a minimal number of fields, and show only enough data for the user to decide if they need to see a details page.
• Ensure that any jumping back and forth between details and listings returns the list view to its precise layout and condition.
• Make the details page set up so that it truncates text to fit all fields into one screen with no scrolling, and offer “See more” options to expand them to full text.
• Do not load any data until requested (to minimize bandwidth usage).
• Cache data locally, so that repeated visits do not re-download data and increase bandwidth usage.

This is a pretty intensive list of things that are substantially different from the WinForms (or even the WPF) world that most developers would be transitioning from, and this kind of mindset cannot be taught — it has to be internalized by making mistakes, experimenting, and doing a lot of hands-on work.

I have gotten a leg-up by working with WP7. Something I learned while working with WP7 is that the tools are deceptive; things that look good and work well in the emulator are often a disaster on a phone, and things that are hard to use in the emulator can very often be great on a phone. I am positive that the same thing will happen with Windows 8 Metro applications when you compare the on-screen experience with a keyboard and mouse to the on-screen experience with a touchscreen.

This is why it is so critical for developers to get a hold of and work with touch devices. Right now, there are a few options out there:

• Use an existing “slate” or “convertible” PC and install Windows 8 on it.
• Use a system like Splashtop that allows access to a Windows 8 VM from an iPad.
• Set up RDP to a Windows 8 VM and access it from a touch device (including any tablet already on the market).
• Get into the various programs from vendors to get early access to Windows 8 on new tablet hardware.

The first three options are the easiest, with different costs associated with them. The last option will give the most accurate representation of what the Windows 8 experience will be like on actual, shipping devices.

Conclusion

If you are serious about Windows 8 development, you need to be testing on some sort of touch-enabled device, and if possible, test in various conditions mimicking Wi-Fi and cellular data connections. It’s the only way to ensure that your applications feel and work right for desktop users, as well as for tablet and other mobile and touch users.