Creating applications for Windows Phone is a delightful experience. Although the current market status might not ratify such statement. It’s an open opportunity to leverage the knowledge on Microsoft technologies you might have or an easier learning curve for those who are new to programming in general.
With new development platforms, the easiest way to learn about them and start building a solid foundation is finding clear examples and exercises that walks you through them and shows you the path to follow. This post will introduce the basic concepts of the platforms that Windows Phone has to offer and in separate posts an implementation exercise will be presented for each of them. At the end you will have an idea which one might seem more compatible with what you want to achieve.
The initial development platform that Windows Phone introduced was based on Silverlight. A technology that came out of Windows Presentation Foundation [WPF] as an alternative for Web applications. Providing a plug-in execution experience in the browser similar to local applications running in the system. As mobile development trends grow; the plug-in approach in browsers started to be questioned in favor of HTML5. This technology platform found its path to evolve into Windows Phone 7 as a new way to create fluid application experiences distancing itself from the previous releases of Windows Mobile.
Creating a Silverlight application consist of describing the user interface elements in a definition language named XAML and defining the classes and methods that inject the functionality in code-behind files.
XAML uses tags the same way as XML or HTML, making it easier and familiar for Web developers to make the transition. A tag defines an instance of an object that might have a visual representation or not. Each tag can be accompanied by a list of attributes that define the instance’s properties. These attributes could be expressed in-line with the tag or in separate blocks contained by that instance.
<!-- in-line --> <Button Content="Hello WP" /> <!-- in a block --> <Button> <Button.Content> <Image Source="/images/win.png" /> </Button.Content> </Button>
The code-behind files can be created using C# or Visual Basic for most of the cases. They can also be combined with Visual C++ to create what is called a hybrid application interacting with Direct3D and other gaming frameworks which require performance advantages only possible with native code. The code-behind classes inherit from a base class named PhoneApplicationPage that lives in the Microsoft.Phone.Controls namespace. This base class enables fundamental services such as: navigation, page orientation, data binding, etc. into every page creating the views of the phone application. But plain classes performing specialized functionality can also exist independently from XAML UI.
As with Silverlight in the browser, many programming techniques can be applied when creating Phone applications. Model-View-ViewModel (MVVM) being one of them. Although, you need to be careful not to add too much processing layers into the application because that could hinder its reliability when running in a low-cost device.
The same way as in the browser scenario, a Silverlight application for Phone is built into a .xap file; which is a compressed file containing the application’s main assembly (.dll) as well as its assets, metadata and third-party assemblies referenced on it. When deployed, the application runs in-process hosted in a sandboxed environment offered by a process called TaskHost.exe.
In Windows Phone 8.1 a new version of Silverlight was introduced. With a wider access to the Windows Runtime API. Applications created on Silverlight 8.1 run in a different execution context or host process called AgHost.exe allowing access to an extended set of API classes and services from the system.
Windows Runtime XAML
Windows Runtime XAML is the platform introduced in Windows 8 to create Modern Apps. With the active efforts of Microsoft to converge the development platforms on Windows this platform arrived to Windows Phone 8.1. Allowing the creation of Universal Applications that can run on Windows and Windows Phone. Sharing a significant amount of code (around 90%) with some specific changes to adapt to the different form factors.
As the name implies, this platform is also based on XAML and if not looked closer it is hard to distinguish its code from Silverlight. One particular difference is the base class used for the code-behind pages, for Windows Runtime is it Page that lives in the Windows.UI.Xaml.Controls namespace. In general most of the Phone Silverlight classes live in the namespace Microsoft.Phone, while in Windows Runtime they are in the Windows.* namespaces. This given the code convergence that exists between the two operating systems.
The convergence of the platforms is not yet fully complete. At this point there are things that can only be accomplished in Silverlight that can’t be achieve with Windows Runtime XAML, and vice-versa. But towards the future the expansion of the Windows Runtime in the Phone is going to grow. For new projects the safest bet is to develop them using WinRT XAML. But if you have an existing application on Silverlight you need to balance things up to determine the impact of transitioning it.
On the execution side the differences are quite significant. Applications created on WinRT XAML are packaged on .appx files. As with Silverlight this package is also a compressed file format that contains the main application assembly (.exe) plus its assets, metadata and third-party referenced assemblies. The application assembly is an out-of-process server that lives on its own but stills runs sandboxed protecting the stability of the operating system from malicious code or application errors.
As with Silverlight the languages you can use to create applications in this platform are C# and Visual Basic. But now you can use Visual C++ on its own to code native applications combined with XAML. This provides a tremendous advantage for game developers and advanced applications that rely on performance elements like Photo and Audio manipulations where C++ is a better fit.
As with a web page that is executed or interpreted in a browser, WWA apps run hosted by a process named WWAHost.exe which bring some restrictions in terms of functionality, such as: not being able to open pop-ups or messages boxes with the alert function, prevents them from resizing windows, and other security aspects that blocks code injection and applications to execute malicious code. Think of this particular changes as what happens when you execute the same web site in a different browser, each browser has its own level of supported features.
WWA apps are packaged in an .appx file the same way as with Windows Runtime XAML apps, although the contents are completely different, in this case the package contains the same source files plus some additional configuration files. For this reason the execution context prevents code from being injected from external sources into the application.
In future separate posts an example of each of these platforms will be presented to complete the introduction and get you initiated into Windows Phone development.