Towards the end of last year, I realized I was about to bump up against the ”use it or lose it” vacation policy at work which basically means I either had to take about two weeks of paid vacation or forfeit the vacation. Since I hadn’t planned the time off I immediately became worried about what to do with all that idle time especially since if left to my own devices I’d play 80 straight hours of Modern Warfare 3 without pause.

To make sure the time was productively used I decided to write a mobile app as a learning exercise about the world of mobile development since I’ve read so much about it and part of my day job is building APIs for developers of mobile apps.  I ended up enjoying the experience so much I added an extra week of vacation and wrote two apps for Windows Phone. I’d originally planned to write one app for Windows Phone then port it to iOS or Android but gave up on that due to time constraints after some investigation of both.

I learned a bunch about mobile development from this exercise and a few friends have asked me to share of my thoughts on mobile development in general and building for Windows Phone using Microsoft platforms in particular. If you are already a mobile developer then some of this is old hat to you but I did find a bunch of what I learned to be counterintuitive and fairly eye opening so you might too.

Thoughts on Building Mobile Apps on Any Platform

This section is filled with items I believe are generally applicable if building iOS, Android or Windows Phone apps. These are mostly things I discovered as part of my original plan to write one app for all three platforms.

1. A consistent hardware ecosystem is a force multiplier

   After realizing the only options for doing iPhone development on Windows was the Dragon Fire SDK which only supports games, I focused on learning as much as I could about Android development options. The Xamarin guys have MonoTouch which sounded very appealing to me as a way to leverage C# skills across Android and Windows Phone until I saw the $400 price tag. :)

   One of the things I noticed upon downloading the Android SDK as compared to installing the Windows Phone SDK is that the Android one came with a bunch of emulators and SDKs for various specific devices. As I started development on my apps, there were many times I was thankful for the consistent set of hardware specifications for Windows Phone. Knowing that the resolution was always going to be WVGA and so if something looked good in the emulator then it would look good on my device and those of my beta testers not only gave piece of mind but made UX development a breeze.

   Comparing this to an ecosystem like Android where the diversity of hardware devices with varying screen resolutions have made developers effectively throw up their hands as in this article quoted by Jeffrey Zeldman

   If … you have built your mobile site using fixed widths (believing that you’ve designed to suit the most ‘popular’ screen size), or are planning to serve specific sites to specific devices based on detection of screen size, Android’s settings should serve to reconfirm how counterproductive a practice this can be. Designing to fixed screen sizes is in fact never a good idea…there is just too much variation, even amongst ‘popular’ devices. Alternatively, attempting to track, calculate, and adjust layout dimensions dynamically to suit user-configured settings or serendipitous conditions is just asking for trouble.

   Basically, you’re just screwed if you think you can build a UI that will work on all Android devices. This is clearly not the case if you target Windows Phone or iOS development. This information combined with my experiences building for Windows Phone convinced me that it is more likely I’ll buy a Mac and start iOS development than it is that I’d ever do Android development.

2. No-name Web Hosting vs. name brands like Amazon Web Services and Windows Azure

   One of my apps had a web service requirement and I initially spent some time investigating both Windows Azure and Amazon Web Services. Since this was a vacation side project I didn’t want expenses to get out of hand so I was fairly price sensitive. Once I discovered AWS charged less for Linux servers I spent a day or two getting my Linux chops up to speed given I hadn’t used it much since my the early 2000s. This is where I found out about yum and discovered the interesting paradox that discovering and installing software on modern Linux distros is simultaneously much easier and much harder than doing so on Windows 7. Anyway, that’s a discussion for another day.

   I soon realized I had been penny wise and pound foolish when focusing on the cost of Linux hosting when it turns out what breaks the bank is database hosting. Amazon charges about $0.11 an hour ($80 a month) for RDS hosting at the low end. Windows Azure seemed to charge around the same ballpark when I looked two months ago but it seems they’ve revamped their pricing site since I did my investigation.

   Once I realized database hosting would be the big deciding factor in cost. It made it easier for me to stick with the familiar and go with instead of as a LAMP  server stack. If I had stuck with LAMP , I could have gone with a provider like Blue Host to get the entire web platform + database stack for less than $10 with perks like free credits for Google ads thrown in. With the WISC stack, hosters like Discount ASP and Webhost 4 Life charge in the ballpark of $15 which is about $10 if you swap out SQL Server for MySQL.

   These prices were more my speed. I was quite surprised that even though all the blogs talk about AWS and Azure, it made the most sense for my bootstrapped apps to start with a vanilla web host and pay up to ten times less for service than using one of the name brand cloud computing services. Paying almost ~$100 a month for services with elastic scaling properties may make sense if my apps stick around and become super successful but not at the start.

   Another nice side effect of going with a web hosting provider is the reduced complexity from going with a cloud services provider. Anyone who's gone through the AWS getting started guides after coming from vanilla web hosting knows what I mean.

3. Facebook advertising beats search ads for multiple app categories

   As mentioned above, one of the perks of some of the vanilla hosting providers is that they throw in free credits for ads on Google AdSense/Adwords and Facebook ads as part of the bundle. I got to experiment with buying ads on both platforms and I came away very impressed with what Facebook has built as an advertising platform.

   I remember reading a few years ago that MySpace had taught us social networks are bad for advertisers. Things are very different in today’s world. With search ads, I can choose to show ads alongside results when people search for a term that is relevant to my app. With Facebook ads, I get to narrowly target demographics based on detailed profile attributes such as Georgia Tech alumni living in New York who have expressed an interest in DC or Marvel comics. The latter seems absurd at first until you think about an app like Instagram.

   No one is searching for "best photo sharing app for the iphone" on Google and even if you are one of the few people who has, there aren’t a lot of you. On the other hand, at launch the creators of Instagram could go to Facebook and say we'd like to show ads to people who have liked or use an and who also have shown an affiliation for photo sharing apps or sites like Flickr, Camera+, etc then craft specific pitches for those demographics. I don’t know about you but I know which sounds like it would be more effective and relevant.

   This also reminded me that I'd actually clicked on more ads on Facebook than I've ever clicked on search ads.

4. Lot's of unfilled niches still exist

   I remember being in college back in the day, flipping through my copy of Yahoo! Internet Life and thinking that we were oversaturated with websites and all the good ideas were already taken. This was before YouTube, Flickr, SkyDrive, Facebook or Twitter. Silly me. 

   The same can be said about mobile apps today. I hear a lot about there being 500,000 apps in the Apple app store and the same number being in Android Market. To some this may seem overwhelming but there are clearly still niches that are massively underserved on those platforms and especially on Windows Phone which just hit 50,000 apps.

   There are a lot of big and small problems in people's lives that can be addressed by bringing the power of the web to the devices in their pockets in a tailored way. The one thing I was most surprised by is how many apps haven't been written that you'd expect to exist just from extrapolating what we have on the Web and the offline world today. I don't just mean geeky things like a non-propeller head way to share bookmarks from my desktop to my phone and vice versa without emailing myself but instead applications that would enrich the lives of millions of regular people out there that they'd be gladly willing to pay $1 for (less than the price of most brands of bubble gum these days).

   If you are a developer, don't be intimidated by the size of the market nor be attracted to the stories of the folks who've won the lottery by gambling on being in the right place at the right time with the right gimmick (fart apps, sex position guides and yet another photo sharing app). There are a lot of problems that can be solved or pleasant ways to pass the time on a mobile device that haven’t yet been built. Look around at your own life and talk to your non-technical friends about their days. There is lots of inspiration out there if you just look for it.

5. Look for Platforms that Favor User Experience over Developer Experience

   One of the topics I’ve wanted to write about in this blog is how my generation of software developers who came of age with the writings of Richard Stallman and Eric Raymond’s The Cathedral and the Bazaar with its focus on building software with a focus on making the developers who use the software happy collides with the philosophy of software developers who have come of age in the era of Steve Jobs and what Dave Winer has called The Un-Internet where focusing on providing a controlled experience which is smoother for end users leads to developers being treated as second fiddle. 

   As a developer, having to submit my app to some app store to get it certified when I could publish on the web as soon as I was done checking in the code to my local github repository is something I chafe against. When working on my Windows Phone apps, I submitted one to be certified and found prominent typos a few hours later. However there was nothing I could do but wait for five business days for my app to be approved after which I could submit the updated version to be certified which would take another week in calendar days. Or so I thought. 

   My initial app submission was rejected for failing a test case around proper handling of lack of network connectivity. I had cut some corners in my testing when it came to testing network availability support once I discovered NetworkInterface.GetIsNetworkAvailable() always returns true in the emulator which meant I had to actually test that process on my phone. I never got around to it by telling myself no one actually expects a network connected app to work if they don’t have connectivity.

   The Windows Phone marketplace rejected my app because it turns out it crashes if you lose network connectivity. I was actually pretty impressed that someone at Microsoft is tasked with making sure any app a user installs from the store doesn't crash for common edge cases. Then I thought about the fact that my wife, my 3 year old son, and my non-technical friends all use mobile apps and it is great that this level of base set of quality expectations are being built into the platform. Now when I think back to Joe Hewitt famously quitting the Apple App store and compare it to the scam of the week culture that plagues the Android marketplace, I know which model I prefer as a user and a developer. It’s the respect for the end user experience I see coming out of Cupertino and Redmond.

   This respect for end users ends up working for developers which is why there really is no surprise that iOS devs make 6 time smore than their Android counterparts because users are more likely to spend money on apps on iOS.

Thoughts on Microsoft-Specific Development

In addition to the general thoughts there were some things specific to either Windows Phone or WISC development I thought were worth sharing as well. Most of these were things I found on the extremely excellent Stack Overflow, a site which cannot be praised enough.

1. Free developer tools ecosystem around Microsoft technology is mature and surprisingly awesome

   As a .NET developer I’ve been socialized into thinking that Microsoft tools are the realm of paying an arm and a leg for tools while people building on Open Source tools get great tools for free. When I was thinking about building my apps on Linux I actually got started using Python for a web crawler that was intended to be part of my app as well as for my web services. When I was looking at Python I played around with web.py and wrote the first version of my crawler using Beautiful Soup.

   As I moved on the .NET I worried I’d be stuck for such excellent free tooling but that was not the case. I found similar and in some cases better functionality for what I was looking for in Json.NET and the HTML Agility Pack. Besides a surprising amount of high quality, free libraries for .NET development, it was the free tools for working with SQL Server that sent me over the top. Once I grabbed SQL Complete, an autocomplete/Intellisense tool for SQL Server, I felt my development life was complete. Then I found ELMAH. Fatality…I’m dead and in developer heaven.

2. Building RESTful web services that emit JSON wasn't an expected scenario from Microsoft dev tools teams?

   As part of my day job, I'm responsible for Live Connect which among other things provides a set of RESTful JSON-based APIs for accessing data in SkyDrive, Hotmail and Windows Live Messenger. So it isn't surprising that when I wanted to build a web service for one of my side projects I'd want to do the same. This is where things broke down.

   The last time I looked at web services development on the WISC the way to build web services was to use Windows Communication Foundation (WCF). So I decided to take a look at that and found out that the product doesn’t really support JSON-based web services out of the box but I could grab something called the WCF Web API off of CodePlex. Given the project seemed less mature than the others I’d gotten off of CodePlex I decided to look at ASP.NET and see what I could get there since it needs to enable JSON-based REST APIs as part of its much touted JQuery support. When I got to the ASP.NET getting started page, I was greeted with the statement that ASP.NET enables building 3 patterns of websites and I should choose my install based on what I wanted. Given that I didn't want to build an actual website not a web service I didn't pick any of them

   Since I was short on time (after all, this was my vacation) I went back to what I was familiar with and used ASP.NET web services with HTTP GET & POST enabled. I’m not sure what the takeaway is here since I clearly built my solution using a hacky mechanism and not a recommended approach yet it is surprising to me that what seems like such a mainline scenario isn’t supported in a clear out-of-the-box manner by Microsoft’s dev tools.

3. Embrace the Back Button on Windows Phone

   One of the things I struggled with the most as part of Windows Phone development was dealing with the application lifecycle. The problem is that at any point the user can jump out of your app and the operating system will put your app in either a dormant state where data is still stored in memory or tombstone your app in which case it is killed and state your app cares about is preserved.

   One of the ways I eventually learned to thing about this the right way was to aggressively use the back button while testing my app. This led to finding all sorts of interesting problems and solutions such as how to deal with a login screen when the user clicks back and that a lot of logic I thought should be in the constructor of a page really should be in the OnNavigatedTo method (and don’t forget to de-register some of those event handlers in your OnNavigatedFrom event handler).

I could probably write more on this but this post has gotten longer than I planned and I need to take my son to daycare & get ready for work. I’ll try to be a more diligent blogger this year depending on whether the above doesn’t make too many people unhappy.

Happy New Year.

Now Playing: Kanye West - Devil In A New Dress (featuring Rick Ross)