I recently got assigned to take a look at Windows Phone development for an upcoming project at work. I regret that I didn't start blogging about this from day one since it would have been an interesting account of how it is to come as an Android developer to the Windows Phone platform. Anyway, here's a quick summary of the first week with WP:
Language
My first reaction to Windows Phone and C# was actually a lot more positive than I had anticipated it would be. The C# syntax is not at all weird (unless you start messing with lambda expressions). It feels like a mix between Java and ActionScript, both of which I'm very comfortable.
Android vs Windows Phone
1-1
IDE
The standard Visual Studio Express IDE was a disappointment with a lot of features lacking compared to Eclipse. I'm aware of the fact that a lot of the shortcomings will go away once I get Visual Studio Professional and
ReSharper, but that comes at a price of almost €800...
Android vs Windows Phone
2-1
User Interface
Another positive experience was the way Windows Phone user interfaces are created. Windows Phone UIs can be created using XAML files where components are arranged in nested tags just like on Android. Each XAML has what is called a code-behind C# file that initializes the view by parsing the XAML. From the code-behind C# file you get immediate access to the components on the view (you don't even have to do findViewById). And to add a big cherry on top you also have the possibility to add data bindings between the XAML and an underlying data context.
This way of defining the UI and the ability to use data bindings has led to the de-facto Windows Phone standard of separating view and logic into a pattern called MVVM (Mode View ViewModel). The idea is that the View (XAML + code-behind) is wired to a ViewModel using databindings and the ViewModel is the one responsible for providing the view with data to show from the model. This means that you'll have a ViewModel without any references to UI components and UI code, thus making it testable.
I wouldn't say that the Windows Phone way of defining and working with views and UI components is better than Android, but it sure has it's advantages. On the other hand does Android handle styling better (by a small margin though) and Android has some very nice features for working with shape drawables that I haven't seen on Windows Phone.
Android vs Windows Phone
3-2
Logging
Logging on Windows Phone is done using Debug.WriteLine() calls, similar to the Log.d() call on Android. If you want anything more fancy and wrap this into a framework with the ability to send logs to different targets, set log level filtering and things like that you probably go for SLF4J on Android. When you want to do the same on Windows Phone there's a few frameworks to chose from and the one I tested the most was
NLog.
Unfortunately NLog wasn't as painless to work with as SLF4J. NLog has a lot of targets to chose from out of the box, but not one for the Debug.WriteLine. NLog can log to the console, but that only works on the emulator (and only after a
registry hack). I tried to use one of the network targets to send logs to a separate log reader (for instance Apache Chainsaw) but it proved damn near impossible to get it to work. I ended up scrapping NLog and instead wrote my own wrapper for Debug.WriteLine with log levels and parameterized log messages (i.e. logger.debug("some output p1: {} p2: {} p3: {}", "param1", 2, parameterThreeObject)
Android vs Windows Phone
4-2
JSON
Json parsing on Windows Phone is as painless as on Android. On Android you either chose Gson or Jackson and similar functionality on Windows Phone is provided by Json.NET. There's also native Json parsing, but Json.NET is more feature-complete than the native functions.
Android vs Windows Phone
5-3
REST
Making network calls on Windows Phone is a really painless business. There's a simple WebClient with methods for doing asynchronous calls to not hang the UI and there is the more advanced HttpWebRequest. So far it seems like there's little need to use anything other than the WebClient. I did however also have a look at a framework called
RestSharp and it handles automatic deserialization of XML and JSON (using Json.NET), supports GET, POST, PUT, DELETE, handles authentication and file uploads.
Android vs Windows Phone
5-4
Dependency Injection
I've come to fall in love with the concept of dependency injection/inversion of control and I've become really familiar with the way it's done on Android using Guice/RoboGuice. One of the first things I did when I started with Windows Phone was to try and find a Guice equivalent. The product that in my opinion best fills the role on Windows Phone is
Ninject. Ninject supports several different ways of setting up the bindings, it has several different injection patterns, it supports providers and everything else you can do with Guice.
Android vs Windows Phone
6-5
Persistence
I have not had a chance to explore this enough yet, but I did try the IsolatedStorageSettings which is a persistent key-value pair map available only to your own app. It works in a similar way to the SharedPreferences on Android, but it handles any kind of values, even complex objects can be persisted. I haven't had a chance to try the file and database APIs yet, so I can't really judge those.
Android vs Windows Phone
6-5
Testing on a device
This was a real disappointment, but not really a surprise. I have gotten so used to the openness of the Android platform that I came to expect that I would be able to test my code straight away on the Nokia Lumia 800 phone we bought. Alas, you need a Live-ID (not a big deal), an AppHub account, a Zune installation and you need to unlock your phone for developer testing. Getting a Live-ID is not so different from signing up for a Google Account, it is what identifies you across the somewhat sprawling set of Microsoft products. Getting an AppHub account is a matter of signing up for an annual $99 subscription and if you are registering as a company waiting a few days until GeoTrust has verified your account. GeoTrust, seriously? Why on earth is this required at all and why is this process handed over to a third party? Zune is unfortunately unavoidable and it seems like unnecessary software for me as a developer to have to install on my machine.
Android vs Windows Phone
7-5
Summary
Working with Windows Phone was not at all as bad as I had expected it to be. I have been positively surprised by a lot of the things I've seen so far and I do hope that my initial positive experience will stick when I really get my hands dirty in the weeks to come.
