Microsoft Windows*8 is the new OS in town, and it’s something of a radical departure from the familiar Windows environment that countless developers and consumers the world over have grown used to. Microsoft is putting its full weight behind the platform’s roll out on PCs, tablets, and, importantly, mobile phones, a relatively new battleground for Windows. The new OS is expected to make a major impact, with its penetration on phones and tablets tipped to grow significantly, bringing it firmly into the race with iOS* and Android*. The explosion of portable Windows 8 devices brings a new set of challenges to app developers as they strive to master the programming environment and ensure the optimum consumer experience across every device, from desktops and laptops, to tablets, Ultrabooks™ devices, and mobile phones.
In 2012, Intel engaged Chaotic Moon, a mobile application development studio based in Austin, Texas, to create a new app for Intel® Software Adrenaline to run on Microsoft Windows 8 devices. Optimized primarily for Intel® architecture and Ultrabook devices, the app lets users access and read Intel® Software Adrenaline magazine content on any Windows* 8 device, and took the team of David Jacobson, Jim Mischel, Mike Walls, and Philip Wheat a total of three months to complete. The resulting application was written (in significant part) in a completely new language for Microsoft Windows client developers, founded on a new runtime, and giving users a completely new way of interacting with their devices.
There are numerous resources available to help developers of apps for Android and iOS, but so far first-person advice for creators of Windows Store apps is more difficult to find. With the aim of making the journey easier for Windows Store app developers, Intel Software Adrenaline magazine caught up with Philip Wheat, Manager of Chaotic Moon’s Lab Division, to find out what lies in store.
Intel Software Adrenaline (ISA): Please tell us about your team’s background in developing mobile apps.
Wheat: Chaotic Moon studios was founded in March 2010 by three great guys hoping to be at the forefront of the adoption of mobile apps and technology. Now, building mobile apps is hardly innovative, but our company is good at it. Three years ago, we were focused specifically on phone apps because at that time, mobile meant Apple iPhone* apps, Microsoft Windows Mobile apps, or a desktop application on a laptop. Today, that world has expanded dramatically, with Microsoft Windows Phone 8, Microsoft Windows 8, Apple iOS, and Android all clamoring for attention in the minds and toolboxes of mobile app developers. We keep our focus on the ever-evolving market and technology, so developing Windows Store applications was the next logical step.
ISA: Can you discuss the terms used in the new environment for developing Windows Store apps?
Wheat: During the development of Microsoft Windows 8, Microsoft used the code name Metro for this new environment. As you might expect, this term caught on with developers, but as release grew nearer the code name was replaced with the final Windows Store app name for the overall environment, both for app developers and end users. While we technical people love code names, app users needed a simple way to differentiate this development runtime from the Win32*/Windows Presentation Foundation (WPF) applications they are used to. And the simplest solution to this question was to describe it as a function of where they will find these types of apps.
I find it easier to think of Windows Store apps as apps that are based around the latest foundational shift in the Windows world. To date there have been basically four shifts (I’m speaking loosely here, I know there are many ways to break out the generations)—DOS, Win32, .Net, and the new Windows runtime. DOS brought us hardware independence (coupled with standard BIOS), Win32 brought the GUI development environment to the forefront, .Net helped free us from buffer overruns and lost memory pointers; and now Windows runtime steps us forward into the world of asynchronous methods, concurrency management, and stateless local applications.
In the current world of networked devices, it is no longer safe for developers to assume they have local access to resources they need, and Windows runtime assists development by ensuring that developers can call on the required data and processing power without worrying about blocking local resources and creating unresponsive applications for the end users. Another benefit of Windows runtime is the ability to write code (and any subsequent edits) once and roll it out on any hardware platform. Windows runtime is not to be confused with Windows RT, the new OS for a limited market of portable devices based on non-Intel® architecture.
ISA: What programming language developments are you seeing,
and how do they impact on the creation of Windows Store apps?
Wheat: JavaScript* is now a first-class language for client development. Industry trends show that JavaScript use has been increasing on servers to provide a common development metaphor between the browser and server, but the Windows Store app environment and Windows runtime extends that commonality to the desktop itself. And with the ability for Windows 8 to provide hardware acceleration for the language, developers will see performance benefits
that were previously unattainable for the language. For example, the Intel Software Adrenaline Windows Store app was written almost entirely in JavaScript and XAML. When working with the Windows 8 application development environment, developers who have JavaScript experience should consider
making it their primary programming language.
That being said, C++ has returned to mainstream application development. In the past, the language’s perceived complexity and the additional work needed to create a user application steered many Windows client developers away. But now the Windows runtime environment assists the C++ syntax to manage and simplify complexity, enabling developers to be as comfortable with the language as they have previously been with Visual Basic* and C#. For Windows Store apps that have extensive or complex algorithm needs or that require high-efficiency back-end processing, C++ may be the language of choice. C/C++ offers more options for taking advantage of the underlying hardware power than any other programming language (with the exception of assembly language, of course).
However, experienced Visual Basic, C#, or F# developers aren’t being left out. Not only can Windows Store apps be developed in different languages, but they can also be developed in different languages inside the same applications. For example, although the Intel Software Adrenaline Windows Store app was written almost entirely in JavaScript, we also used a bit of code that had previously been developed in C#.
ISA: What is important for developers to know about the presentation layers when creating Windows Store apps?
Wheat: On top of Windows runtime is the presentation layer. In Windows Store apps, the user experience is encoded in XAML. Though developers may recognize the term of “XAML” from WPF or Silverlight*, the format itself has changed somewhat—consider it as simple (or as vast) as the transition happening between HTML4 and HTML5. The encoding and formatting remain the same, but the keywords, elements, attributes, and so forth have changed.
Why didn’t Microsoft stick with WPF or Silverlight since those presentation layers have been well optimized over time? The reason is simple—as both XAML and HTML continue to evolve, the idea of an XML presentation layer continued to converge into a standard. And that standard falls very close (if not on top of) the pending HTML5 standard.
In many cases developers can use HTML5 directly, doing many of the same things they do in a browser in their Windows Store app development environment. But, by design, a browser environment is limited for security reasons and to ensure the safety of the generic OS underneath it. Because of the tight integration between the Windows kernel and security system with the Windows runtime/XAML environment, those security checks can be much stronger, allowing the Windows Store app end users more resources and access.
This means that access to localization resources, user data, local caching, and so forth become easier and more secure to use with XAML, while the model remains close enough to HTML5 to ensure cross-utilization of code and the ability to provide light, lower-functionality versions of Windows Store apps that can be run inside of browser environments. This provides the best balance between optimized desktop applications and cross-platform standardized functionality.
ISA: Can you explain “app contracts” in the context of Windows Store apps?
Wheat: App contracts, one of the most interesting features of the new runtime, are interfaces that the Windows Store app registers with Windows 8 to allow easy integration with the operating system. The simplest and most common app contract is “search,” which enables the app to register its search capability with the operating system itself. Then when the app user wants to find an item of data, instead of having to open each application and perform a search, the user simply activates the Windows 8 search charm on the user interface and selects the applications and data types that he or she wants to include in the search. Because the applications themselves have exposed their search interface, the operating system knows how to query each dataset and quickly return the desired results.
ISA: What resources are available to support the development and testing of Windows Store apps?
Wheat: One useful place to go to is the online Intel® Developer Zone (intel.ly/dev4ultrabook), which has an area dedicated to Windows 8 development for Ultrabook devices. You’ll find info, guides, tool downloads, and test code samples to get you started. You can also ask questions directly to the guys at Intel in the forums, which are always welcome.
With regard to testing, in addition to the traditional unit, application, and user experience testing, Microsoft has included a certification test to validate a new Windows Store app before it is submitted to the Windows Store. This certification test ensures that not only does the Windows Store app pass for standard functionality—such as starting up, shutting down, and responding to user input—but that it is also categorized correctly and does not impose unnecessary resource demands. The tests evaluate everything from startup speed, to splash-screen validation, to suspend and resume functionality. About the only things that the automated test can’t check at the moment—although this may change—are exception rollbacks and step-back functionality that might be used with IntelliTrace*.
ISA: What were the primary considerations and challenges encountered when creating the user experience design for the ISA Windows Store app?
Wheat: The user experience of a Windows Store app is a blend of WPF and HTML5. This is a natural merging of the two presentation layers, but it also requires extra effort to blend the two user experience models into a seamless whole. The resulting application must merge both modal desktop interfaces with modeless Web interfaces to ensure the best of both worlds in the final application.
ISA: What challenges arose during the coding of the Windows Store app for Intel, and how did you resolve them?
Wheat: The biggest coding challenge was to ensure that the proper security models and modes were adhered to. With Web applications, almost none of the local resources are available to the developer—everything happens on the server which means things can be slow. With desktop applications, all the local resources are available so applications have access to critical systems components. With the Windows Store app development process, developers must be prepared to walk a careful path between requesting resources for optimum performance and user concerns about excessive security authorization for desktop resources.
Intel® Software Adrenaline App now available on iOS*, Android* platforms, Kindle*, and Windows* 8. Download the app at: software.intel.com/sites/billboard/app
