A Developers Journey in The World of Microsoft Apps

As the primary developer working on Active911 for Windows, it is my pleasure to be writing my first blog post to share my experiences on the subject! Windows has been around for a long time now and even the Windows Phone has been around since late 2010. It wasn’t until the release of Windows 8 that writing apps for Windows devices became more feasible because it was the first operating system to include an online store similar to Apple’s App Store. But with this new marketplace for apps came a brand new framework for building apps, one which was not backwards compatible with older versions of Windows.

It would seem that Windows is in somewhat of a fragmented state right now when it comes to applications and frameworks. One of the most misunderstood issues I have encountered is the expectation that Desktop Apps run on a desktop environment, tablet apps run on a tablet environment, and phone apps run on a phone enviroment. This is sometimes the case, but not always. Windows tablets are essentially windows desktops and both the desktops and the tablets are capable of running traditional Windows 7 style applications and Windows Store applications. To complicate the matters even more, there is a version of Windows called RT that is compiled for ARM processors only. Without digressing into the difference between ARM processors and the type of processor that is commonly found in desktop computers, it should be sufficient to mention that apps compiled for one processor architecture are not cross compatible with the other.

Where does this leave us? Well, we know that what we want is a set of Windows applications that encompass all platforms: Windows destops, tablets, and phones. Under normal circumstances, this would be three different projects each targeting the specific device, but there are some tools to assist us.

wingraph

Windows Project Diagram

  • Active911 Windows Solution
    • Windows Universal Project
      • Windows Phone 8.1
      • Windows Store (Tablet) App
      • Shared Universal Code
    • Windows Desktop Project
    • Backend Library

 

There will be a Universal project containing tablet and phone projects with all common code shared in a sub project, a Desktop project, and a Backend Library project in order to share code among all the apps. The reason we have chosen this structure is because we want to have as much code as possible be shared between each platform. This is key if we are to maintain all apps and expidite features equally among them. In short, our goal is to only have to write something once, and then all three apps will have that new functionality.

This project structure does not overcome all of our obstacles, however. There are two incompatible frameworks in this project. Windows Desktop uses the .NET 4.5 framework while tablet and phone use the .NET Core framework. And even with both phone and tablet sharing a framework, we still run into incompatible layers with the Bing Maps control for example. Microsoft provides one Map Control for phone and another for tablets. A way to overcome this is to create one control for our apps to use that will wrap the other two controls.

Precompiler directives can be used to run the correct code for each platform.

For Example:

#if WINDOWS_DESKTOP
// Here we have Desktop specific code
#elif WINDOWS_MOBILE
// Here we have tablet and phone specific code
#endif

Now we can include code tailored towards each incompatible framework in one file without issue. Much of this kind of code will be in the backend library and the Backend Library targets the desktop framework. This means that the Universal Project cannot reference the Backend Library. But we do not want to have multiple copies of these files to keep in sync, so we symlink the Backend Library’s files into both the phone and tablet projects.

At this point I should have been in a good place to start writing all of the logic which all the apps will use, but unfortunately, this was not the case. Usually when you write code for a project, there are libraries that you can leverage to do some of the common or standardized task. In my case I needed a database library and an XMPP library that would work across all platforms. After due diligence, I found that nothing existed that could fit our needs and we decided to build our own.

SQLite is a great light weight database for apps and it was the natural choice moving forward, but there was not a good implementation that would work across all our Windows devices. First step was to wrap a library around the SQLite DLL (Dynamicly Linked Library) that would allow all the apps the same ability to use a database. This, to my surprise, was much easier than the XMPP library.

XMPP is a standard protocol much like all well known protocols that all end in a ‘P’ like HTTP, SMTP, or FTP. XMPP is the Extensible Messaging and Presence Protocol designed for instant messaging. We use this for all real time communication between all devices in an agency. I was surprised enough when there wasn’t a free or open source library that I could use on all platforms, but there isn’t even a good library that is reasonably priced. So, after a couple months of pouring through the RFC specifications, I built a custom XMPP library for us to use that is extreamly fast and lightweight.

With the project structure and the two libraries that we needed for the project to share code across multiple platforms, there was a great deal of work that needed to be done before I could even start writing the Active911 Windows Apps. Here is the good news: Now that all of this has been handled, once code is written to handle something for one device, that same code will work the same way across the other devices! The only device specific work that will need done for each platform consists of the user interface, push notifications, and GPS functionality. This means that it will be as easy as it possibly can be for us to maintain and update all of the Windows apps moving forward.