WP7 v Android: Dev ‘fluff’ stuff
While I’ve outlined some of the programmatic differences between WP7 and Android, there is often a lot more to it than that – how easy is it to get the environment up and running? How easy is it to learn?
Getting the SDK/Tools up and going
WP7′s SDK can be found through developer.windowsphone.com portal (download is on the standard Microsoft downloads, but developer portal is the easiest way to grab it), you grab the 69kb web bootstrapper, which then downloads up to 339.8MB, installs the various tools and you’re right to go – from Visual Studio or Blend, you can go File –> New Project –> Select Windows Phone.
Android’s SDK is found on the developer.android.com portal, grab the appropriate version for your operation system, make sure Java 5 or 6 is installed, then once you’ve unzipped the SDK, you’ll need to run SDK Setup, which lets you choose and download which version of the SDK you’d like. Android is relatively fragmented, so you need to download the SDK for the lowest version of the API you’d like to target – that is, if you want to run on Android 1.6 and above, download 1.6 (version 4 of the API) and then you can target that/make virtual machine with 1.6 on it.
By default, the SDK Setup tool will query https://dl-ssl.google.com/android/repository/repository.xml for the latest information, but that has never worked for me on a variety of machines. You’ll need to go into the Settings for SDK Setup and tick ‘force https://… sources to be fetched using http://…’
Once you’ve got the SDK up and running, you may as well create a Virtual Device, unless you plan to do all your debugging on a device.
Finally, you’ll need to setup your IDE of choice – Eclipse has a plugin from Google with its own set of hopes to jump through, IntelliJ IDEA Ultimate ships with Android support, and NetBeans has an unofficial/unsupported plugin. And finally, now you can start a new Android project.
Winner: WP7 – set and forget, done. Android you have to earn it.
Included SDK/Tools
I should stress this is about the free SDK/Tools included, not any third party purchased tools.
WP7 includes
- Visual Studio 2010 Express for Windows Phone
- Expression Blend 4 Express for Windows Phone
- XNA
- WP7 Emulator
You cannot, however, select what components you want although thankfully its smart enough to figure out that if you’ve got VS2010 Standard or above to not install another copy of VS.
Android includes
- SDK Tools
- Dalvik Debug Monitor
- Draw 9 Patch
- Android Emulator
- Android Emulator manager which lets you create different VM configurations (storage/screen res/etc)
- SDK version downloader/manager (download more versions
- Eclipse Plugin
While at first glance you would be forgiven for thinking WP7 is superior as it includes a full IDE and a UI designer, there are a few caveats. The Android Dalvik Debug monitor can attach to either a VM/Emulator or a real device – meaning you get full file access/exploration, full debugger output, device querying, radio querying, ability to take screenshots from the device and more. While these tools don’t trump Visual Studio in most, having no way to query a physical (or emulated) device for WP7 or to take a screenshot is going to be very frustrating.
Not this is based on Windows Mobile/CE experience rather than WP7 experience – why? I have a Windows Mobile device, but I do not/cannot get a WP7 device just yet, unless a Microsoftie wants to donate one of the 90,000 or so Microsoft are giving away to employees.
Winner: Not clear (leans towards WP7)
Emulator/Virtual Machine

Hands down, WP7 emulator is faster. I timed my first WP7 app from cold boot to being in my application…. 7.5 seconds. That’s insanely fast. It is, however, showing it’s beta-ness. I’ve managed to crash it – which just meant it closed, no restarting, it doesn’t respond to keyboard input – which means you have to use the onscreen keyboard using your mouse.
There doesn’t seem to be a way to start up the WP7 emulator without using Visual Studio or Blend, but I may just be missing something (why would you want to do this? Well, you might want to test the horrible browser on WP7 to make sure it works with your site). This is a downside but it is fairly easy to work around considering how fast VS2010 and the emulator boot.

The Android VM is sloooow. Even on my quad core system, it 32 seconds for the OS to boot, let alone deploy and start up my app. And it’s relatively buggy too – icon’s are supposed to scale with the resolution of the VM but more often than not on my WVGA VM it doesn’t scale leaving the UI stretched or overly spaced.
On the plus side, crashing the Android VM results in the virtual device rebooting itself inside the VM instead of just closing, it also responds to full (physical) keyboard input, and has a wider variety of installed apps to interact/test with.
Winner: Not clear (leans towards Android, seriously, lack of keyboard input on WP7 bites)
Documentation
"Back in the day" JavaDocs were all the rage, but that was a long time ago. Android’s documentation is barely more than JavaDocs for Java and Android API’s available. While there are some examples, they’re not entirely useful or beyond basic "Hello World" given the complexity that Android has.
Google has Android Docs?!?!?!?! I thought those were templates for future use
Ive been working with the SDK since it has been out and the one thing i have learned is reading those docs is about as useful as trying to light a fire with a squirt gun. Its easier to go onto the github and rip apart their source to see the truth
Those are two tweets in response to when I said the Android docs weren’t that good.
On the flip side, MSDN has come a long way in terms of visual and cross browser appeal in the last few years. In general, the MSDN docs are detailed enough and generally contain a sample in C#/VB/XAML.
Winner: WP7, and by a big margin. MSDN rocks my socks.
Winner?
Again, there are no winners here – both have their positive and negative elements. I’d compare debugging but that’s a little unfair until I’ve got a WP7 device to compare against.
WP7 is easiest to get going, and has better documents, but some of the tools are lacking and the VM is a little frustrating.
Android is daunting to get going and you’re better off reading other people’s code/Android’s source code than reading the Android docs
(I’m happy to have devices donated to compare…Microsoft, same goes for you HP/Palm on WebOS, or Apple if they want to send me a Mac Mini+iPhone)
Comments
5 Comments
Trackbacks / Pingbacks
-
[...] This post was mentioned on Twitter by Paul Jenkins, Bugra Ayan. Bugra Ayan said: WP7 v Android: Dev ‘fluff’ stuff: While I’ve outlined some of the programmatic differences between WP7 and Android… http://bit.ly/94NbAW [...]

You are not quite fair with Android, on the “Included SDK/Tools” you said WP7 wins (yes, I know “leans towards WP7″). But you did not even talk about eclipse ! Yes, eclipse is not shiped with the “bundle” but it is on free&open on eclipse.org. Eclipse has strong points like great live debug including hybrid application (not sure VS ex got this).
About “Emulator/Virtual Machine” section, you did not compare the emulated feature available. One are are for instance service emulation (simulate GPS, proximity, phone, orientation, phone call, SMS, etc).
Documentation section is realy a matter of taste, personally I preffer the “javadoc” style and add forum+blog articles on howto.
At the end, you did not noticed that the Dev platform is limited to WinVista and Win7 on WP7 SDK, where as it is quite broad on the Android SDK : WinXXX, Mac, Linux. This is a key problem for people like enterprise developer that are stuck with XP SP2+ :(
Eclipse, imho, is best not to talk about. In an hour of android dev, it will crash up to sixteen times. The debug experience is awkward at best (and thats comparing to intellij, not vs). It might be free, but is probably the biggest problem i have with android dev.
The emulator features of both i barely touched on, not because i dont care but because i dont know through lack of using it. For example, wp7 does have hw kb input if you toggle it (documented in xna…wtf?)
As for being windows only, i dont use the others, so it doesnt phase me (this IS my blog after all ;)) however no xp i was not aware of
“Eclipse, imho, is best not to talk about.”…. so, well if there are issues/problems you think about, you should definitivelly talk about them in the article so people can either debate or solve them. I am not an eclipse fan too as an “JBuilder oldtimer” I tend to preffer IntelliJ or Netbeans, but the mass of plugin there make it still a reference (for the best and the worse). So, not reviewing it about a Java related product with specific plugin is like not reviewing VS when taking about the Redmon’s latest GUI API :P BTW, crash 16times in an hour, hummm … did you install “armagaedon plugin” or what ;-)
Cheers & Rgs,
TM
You may have noticed that this *isn’t* a review of IDE’s though – I’m not directly comparing and pitting them against each other. Like all software, liking an IDE can come down to personal taste. I *personally* don’t like Eclipse’ debug experience, layout, colour scheme, menus, and even the general UI toolkit. Yes, I know Eclipse is pretty configurable and I could change it, but thats a lot of effort just to begin using the code side!
FWIW, I’ve tried Eclipse, NetBeans and IntelliJ for Android dev, and IntelliJ is by far the best overall experience (from actual coding to debugging), but it still has some ‘wtfs’ compared to VS. For example, if I’ve got a method ‘HelloWorld’, and start typing ‘Hellow’, IntelliJ isn’t smart enough to figure out I wanted ‘HelloWorld’ because of the case difference, and will present me with a *blank* auto-complete box!
As for the crashes – JDK, JRE, Eclipse (tried latest three versions) and the Android plugin were the only Java things installed. Okay, I lied, I had the TeamCity tray notifier/TeamCity build agent running on my machine as well, which all works perfectly. I’m guessing that it was the Android plugin causing the crashes, which leaves me… in a position of being unable to compare the IDE without stabbing small kittens in frustration.