I started at Microsoft working on the now defunct Surface Music Kit. One of the first things I realized was that I didn’t know anything about app development on the Microsoft platform (MVVM, XAML, and all that goodness). So I built Greenly. Below is a high-level overview of various parts of the development process that I found interesting.

Reverse Engineering a Private API with Charles

First things first, I needed to understand the app’s data source. Because Leafly doesn’t have a documented API, this isn’t quite as simple as usual… But it’s still not too difficult since its just a standard HTTP REST API (a quite good one at that).

To reverse engineer the API, I configured my android device to route all traffic through Charles. After this, I exercised the officially Leafly app and tried out all its features to get a complete trace of the endpoints and functionality the web API provided.

I really enjoyed using Charles for this work because of its awesome structure view and ease-of-use, but the free program Fiddler should also work.

Key 3rd-Party Components

The entire Greenly codebase is around 5000 lines of C# and 1500 lines of XAML — thanks in large part to the excellent 3rd-party components the app relies on.

I made use of RadDataBoundListBox, RadTransitionControl, RadSlideView, RadRating, RadPaginationControl, RadChart, RadCustomHubTile, RadUniformGrid, and their InteractionEffectManager. The only pages not using any telerik controls are the Settings and About pages.

If you are developing for Windows Phone, I highly recommend using Telerik’s controls (or another vendors) unless you want to spend a lot of time writing custom UserControls — the default controls leave a lot to be desired. At the time of writing, using open source components entirely is not a viable option for most apps.

MVVM Light is a fantastic library that got my app started on the right foot with dependency injection, sugar syntax for raising PropertyChanged events, and an easy pattern to get design time data working. Let me tell you, Blend is great and with MVVM Light it becomes more useful than ever!

Using Json2CSharp, I was able to generate C# ViewModel classes from Leafly’s JSON responses that I could directly bind to in XAML.

Using PortableRest, I could write a single portable client wrapper around the Leafly API that could theoretically be used in any other .NET app.

PortableRest would then parse the JSON responses using Json.NET and directly populate my generated ViewModels with no additional work or parsing logic.

Excluding the generated code, my API wrapper ended up being < 200 lines of code!

I pulled in this dependency for one reason — its Map extensions. These extensions allowed me to data-bind my stores as map pushpins which is surprisingly not a feature of the Maps control.

Initially, I rolled my own UserControl for the slide-out menu, but ran into performance problems on my Lumia 1520 (surprisingly, not on the 520). Luckily, I discovered SlideView which did the job perfectly and is also open source allowing me to learn a bit about writing high performance XAML controls.

Development Techniques

Real Devices

I developed and tested the app on a Lumia 520 and Lumia 1520 which helped me detect performance regressions as soon as they appeared. Testing in the emulator did not expose the performance issues. At just $30 on Amazon, there’s no reason you shouldn’t have a 520 in your arsenal.

Profiling Tools

I made heavy use of the built-in profiling tools to detect XAML controls that were hurting performance and detect when work was mistakenly being done on the UI thread.

Telemetry

I implemented Flurry Analytics to get detailed crash reports from consenting users and for particularly hard to triage bugs I added telemetry to specific code-paths for even more information. Using Flurry, I was able to drive crash counts down quickly after launch.

Blend

Thanks to MVVMLight, for the first time I was able to take advantage of Blend which greatly sped up my iterations on the UI. Seeing your changes live in Blend is much faster than rebuilding and redeploying to the emulator or your device.

Architecture Decisions

Greenly.Core and Greenly.WP8

The app was split into two projects.

Greenly.Core contained my API wrapper and my ViewModels and was implemented as a Portable Class Library so it could theoretically be used in a Windows 8 Modern App.

Greenly.WP8 was a standard Silverlight 8 app that took a dependency on Greenly.Core and implemented all the View logic.

Single Page App

The Windows Phone platform’s Page Navigation model provides a lot of benefits such as simplifying deep-linking, managing its own internal backstack and caching, and handling transitions but it also feels slow and makes it impossible to build an app with an omni-present slide out panel.

Greenly uses a single page with a SlideView that contains the side navigation and a RadTransitionControl. Each “page” in the app is its own UserControl and when navigating, I simply new up a “page” UserControl, bind its ViewModel, and set the RadTransitionControl’s Content to the new control.

Centralized Error Handling

Almost all error handling in the app is located centrally at the App.xaml.cs layer where I can handle exceptions and show global message dialogs, log telemetry, or even ignore exceptions. Moving all the error handling to a central place greatly simplified my ability to “do the right thing” when things went wrong.

Measures of Success

The app is a raving success by Windows Phone standards. At the time of writing: