writing my first windows phone 8 app

At some point yesterday, I submitted for approval my first ever Windows Phone app. It also happened to be my first ever Windows Phone 8 app, since I never got around to developing any apps for the previous version of the operating system. I figured I’d type some thoughts down on my experience as a developer who has worked pretty extensively with .NET technology before. I’ll try to keep things from getting too technical but I cannot make any promises.


#1: Same Old Technology

When I first had a desire to develop a mobile app, my target platform was obviously the iPhone since it was the largest and most successful app market that existed at the time (and possibly still but I’ve stopped following iOS closely). I went ahead and bought a Mac Mini since I needed an OS X machine to be able to write the appropriate code. I then sniffed around Objective C and figured I needed a guided experience so I went ahead and bought an e-book. I may have even read 2-3 chapters of that book.

The problem became apparent very quickly. I hated Objective C. I hated it with a passion. The syntax makes no sense to me–which I’m sure would change once I got used to it–but I could not imagine a world where I wanted to be used to Objective C. The code just looked ugly. Which is a weird thing to say. But it did. It did not feel structured and logical like C-like syntaxes, despite being a subset of C. Weird. In my opinion, Objective C looked just how OOP syntaxes should not look.

Anyhow, developing my WP8 app, I did not have to learn any crazy new technologies. I already have a firm grasp of C# and that was all I needed for the modeling aspects of my app. C# is almost syntactically identical to Java, so that’s a whole bunch of developers there that shouldn’t need to learn a new skillset. The UI language is something I did have to learn, but having used Silverlight and WPF in the past, this wasn’t a massive leap for me. I’ve had to handcode Cocoa UI in the past and let me say I easily prefer XAML-land. Everything makes sense to me and the MVVM pattern flows effortlessly.

#2: Developing Metro apps is easy

The thing I like most about Windows Phone is the design of the apps. Several developers (particularly cross-platform ones) choose to ignore the beautiful design language and develop cluttery navigational systems. I decided to stick with Metro and it was abundantly easy to do so. There’s lots of boilerplate code to get you started and once I installed the Windows Phone 8 toolkit, I had access to all the controls that MS use on their native apps. Using my pre-existing MVVM knowledge, I was able to get going very quickly. After deploying my app to my device and the emulator, I noticed that MS handled a lot of things seamlessly. One particular shoutout is the persistence of view models. My original code had me recalculating stuff every time a page was loaded with the intention of caching it manually sometime in the future (kinda like in ASP.NET land). I instead found that if I just added a flag to see if I had been to that page before, I could take advantage of view models being cached automatically. This is probably already the case with WPF, but I didn’t realize it and it made me happy.

#3: Haven’t yet done it, but I can see how easy it would be to replicate stuff into a Windows RT/WPF app

I haven’t done this yet, but I do have plans to write a cross-platform WP8/Windows 8/Windows RT app at some point. Given that the all three targets use so much shared technology, it seems that porting across platform really will be a matter of adding the appropriate #if and #endifs and writing the UI layer. This also leads itself to more modular code since I have to keep in mind to separate my modeling layers from my view layers. This can further be expanded to WPF and even ASP.NET which means a developer could go from one code-base to writing apps for: WP8, WP7.5, WinRT, .NET 4.5 and ASP.NET! This makes me seriously excited as I think about app ideas that can leverage all these different platforms.


#1: Getting a fully-capable dev machine

Unfortunately, WP8 development also has several shortfalls, the greatest of which is finding a dev machine capable of developing apps on. This search was ultimately futile from the perspective of finding a machine that was able to both run the emulator and deploy to my device. Of all the machines I work with (and I work with several), only my home-built desktop was able to support the hardware virtualization that allowed the emulators to run. Sure, the emulators run really well, but it makes no sense to me why you would make the barrier to entry so large for a fledgling mobile OS. I can easily see independent developers willing to give WP8 development a spin only to realize that they need to buy a brand new Windows 8 64-bit computer with the appropriate new processor architecture to be able to use an emulator.

Once I found a computer able to run the emulator (which happened to be the desktop I had built from scratch 3 or so years ago), I quickly found out that it was not able to talk to my phone via USB. This may be an issue with my USB controller but I do use several USB devices without event so this was still annoying to me. I ended up having to install Windows 8 on my personal laptop and dual boot it to have a device which could deploy to my phone. So now I have a weird workflow where I develop on my desktop and test things out via emulator before checking it in to TFS and then pulling down a copy of the code on my laptop, building it and deploying it to my 920. Not something I would recommend.

#2: Silverlight-based target is still generations behind .NET 4.5

While I mentioned that the technology is similar to standard .NET development for Windows Phone, sadly it is still a couple of generations behind the current .NET release. Libraries and keywords that I have become accustomed to in my day-to-day development are suddenly no longer available. Routed commands are something I missed, in particular, because it cramped my MVVM style. I had to write my own ICommand classes and I will have to do that for all the apps I develop. Uncool.

#3: Developer support and documentation is paltry

End-user documentation from MSDN is horrible. I cannot recall finding a single piece of code that helped me on the Windows Phone documentation section. Most of my queries get answered by a Google search, a StackOverflow question or just get worked around. Microsoft’s .NET documentation is very good with lots of examples of how to do things. They definitely need better code samples and not just a high-level journey through workflows. The most immediate thing that comes to mind is programmatically generating dynamic live tiles. MS has a huge page describing the tile technology–in English. They frequently reference dynamic tiles and doing things programmatically–but never provide a code sample! Craziness.

That’s it for now. I’ll put a link up to my app once it gets approved.