WinMoPho vs Android from a dev point of view
I’m a PC and I’m a big fan of WPF, so it could be assumed that I like Silverlight and therefore WinMoPhone 7. Well, the truth is I love WPF but think that Silverlight is more like WPF vPainful, and I use Android which has some fantastic hardware and is available now unlike the mythical Windows Mobile 7.
It wasn’t until the recent spat of previews coming out from places like Engadget that I was even vaguely interested in WinMoPho – seeing the simplified design of Metro on AMOLED screens looks fantastic. Some would say it lacks depth and is a bland design. In many ways I agree but as Microsoft have rather strict requirements for WinMoPho devices including OLED as a minimum (no LCD!) I’m beginning to see the beauty in it when compared to the reasonably complex (visually) Android particularly when out in the sun.
From a dev point of view, there are strengths and shortcomings for both systems, and I’m not entirely sure who is the clear winner, if there can be one.
IDEs and tools
Dev tools
Okay, so an IDE is never required, but I like to be productive and don’t memorise every namespace. Android is Java based, so naturally the top choice for IDEs are all Java based as well – the three I’ve tried are Eclipse, Netbeans and IntelliJ. Personally I think IntelliJ is the best, although it’s not free if you want to do Android development. These run on *Nix, OSX or Windows, giving you greater flexibility in your development. Eclipse is as close to the ‘official’ IDE as it gets – Google provide the plugin for it – but there is no IDE directly from Google. This is good in that you can use whatever you are comfortable in, but bad because the general tooling is pretty below par.
WinMoPho has Visual Studio 2010 Express for Windows Phone. It’s a mouthful, but personally I think its justified as its just that much better than the offerings for Android. VS10 Express is free (or you can use the professional versions of Visual Studio), but only runs on Windows which may hinder some. While it is an incredibly complex piece of software, it is also incredibly powerful.
The debugging is just.. well.. better on VS. And IntelliSense works. Eclipse’s auto-complete names all the arguments arg0, arg1 .. argN, I could never get NetBean’s debugging to actually debug and IntelliJ is case sensitive – it won’t pickup Hello for helloWorld.
Design/UI tools
The WinMoPho Developer tools “ship” with an Express version of Expression Blend (Express Expression Blend… another nice name) which will only let you do WinMoPho development. This is free, and will remain free. Eventually it’ll install into regular (non-free) versions of Blend. Blend is, without a doubt, awesome. I won’t bore you with lots of details, but it is a designery app for designing your applications UI. How designery? Blend 4 can directly import Photoshop (PSD) or Illustrator (AI) files – AI goes straight to XAML/Vectors, and PSD will try to map text layers up to Textboxes, rectangles, etc – your layer structure keeps intact!
In contrast, Android has no UI editing program, but there is an editor for Eclipse. Sadly, the editor is absolute balls – you can’t drag controls around, you can’t resize, etc. The closest to something useful is the unofficial DroidDraw java applet. I think DroidDraw is mostly limited by the poor layout system that Android has.
Multitasking
Android has it, WinMoPho doesn’t. I think it is rather stupid of Microsoft given the current mobile climate, but whatever. Android apps have multitasking built into them, even the default Google applications use the same API’s – no hidden secrets or limitations that other OS’s have/have had. There are just a few caveats to be aware of
- your application could be terminated at any time if its not in the foreground, if the device start running low on memory
- every time the user switches back to your application (even after it is killed), the view is recreated as it was in the onCreate method of your Activity unless you override onResume as well.
- Your application should always go back to the previous Activity it was on when they left – Android handles this automatically.
- You can explicitly run in the background so that Android doesn’t kill off your application if you use Services or BroadcastRecievers – think music playing app, IM, etc.
Sharing, Intents and Navigation
One thing thing that WinMoPho completely lacks is one of the greatest strong points of Android – the ability to share data between applications, but without having to specifically target an application. For example, if you take a photo then press share, any application that has registered the correct intent for sharing will appear in a list – email, a variety of Twitter clients, Flickr, Facebook, whatever, so long as its registered, it can handle it.
In Android, you register an Intent with the OS to replace pretty much anything that matches that – such as the Homescreen. That’s right, things as basic/essential as the homescreen can be replaced – how awesome is that?
<activity android:name=".AlbumListActivity"
android:theme="@android:style/Theme.NoTitleBar"
android:screenOrientation="portrait"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
In MahTunes I’ve registered the AlbumListActivity to hook up to the “Launcher” activity – this just means it’ll appear in the “app tray”, and that it should launch this activity first. Intents are registered via the AndroidManifest.xml that every Android app needs.
Navigation
Navigation in Android is through Intents whether it is between applications or inside a single application.
Intent playbackIntent = new Intent(getApplicationContext(), PlaybackActivity.class);
Track t = (Track)tadapter.getItem(arg2);
playbackIntent.putExtra("trackId", t.ID);
startActivityForResult(playbackIntent, 0);
This example is also from MahTunes, inside the track selection dialog, it creates a new Intent to target the PlaybackActivity class and loads it up with some primitive data – you can only pass along primitive types, no objects.
If you’re querying another application, the Intent constructor parameters would look like
Intent intent = new Intent("com.google.zxing.client.android.SCAN");
At the other end, inside PlaybackActivity’s onCreate, it can query the intent “bundle”
long trackId = getIntent().getLongExtra("trackId", -1);
There is one downside – moving from screen to screen inside your own application in Android feels more like a collection of “activities” rather than a proper application, as you pass data around from one to another. There is the (optional) Application class to extend which acts as a global wrapper around them.
WinMoPho navigation around an application isn’t much different. It treats everything as a “page”, so you use Uris to navigate around. This has the same problem of not being able to send complex datatypes to the new page all that easily. That being said, the “application” class isn’t optional, so you’ll always have that container.
NavigationService.Navigate(new Uri("Details.xaml", UriKind.Relative));
Data binding
Android doesn’t have data binding, it’s as simple as that. You can set X to Y, but you’re essentially just setting X to be an instance of Y – when Y updates, X doesn’t. Yes this is framework magic. Data binding and data templating are the two greatest things about WPF and Silverlight.
And this leads into the next point, Lists. Lists are hard, okay? Well, okay, I’m lying, lists aren’t hard at all on most UI frameworks but this is one of the greatest downfalls of Android programming. Unless you want a very basic list of just a string-per-line, Android requires you to create a custom ListAdapter which I’ve written about before. There are a whole stack of performance issues and enhancements you need to do to each and every one of your adapters – it’s just a messy and repetitive process.
Silverlight? myListBox.ItemSource = MyList; Done. That won’t automagically setup your UI to be bound the way you want it (in fact it’ll just give you a .ToString() of each object per line), but you don’t have to write any custom code to adapt a list to your ListBox.
List example

This is a screenshot taken from the Android Dalvik Debug Monitor (part of the Android SDK) of MahTunes running on my Milestone. You’ll notice there are issues with text-wrapping and originally there were issues with some items stretching further than others. Ignoring the rounded corners on both the background item and on the album art and ignoring the custom font, how do you do this in Android and in WinMoPho?
Android
AlbumListActivity.java (snippet from where the Activity sets the current view)
AlbumAdapter albumadapter = new AlbumAdapter(this, Albums); ListView lvMyListView = (ListView)findViewById(R.id.ListViewAlbums); lvMyListView.setAdapter(albumadapter );
AlbumAdapter.java
package mahapps.MahTunes;
import android.content.Context;
import android.graphics.Typeface;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.*;
import java.util.*;
public class AlbumAdapter extends BaseAdapter
{
private List<Album> elements;
private Context c;
public AlbumAdapter(Context c, List<Album> Albums) {
this.elements = Albums;
this.c = c;
}
public int getCount() {
return elements.size();
}
public Object getItem(int position) {
return elements.get(position);
}
public long getItemId(int id) {
return id;
}
public void Remove(int id)
{
notifyDataSetChanged();
}
public View getView(int position, View convertView, ViewGroup parent)
{
LinearLayout rowLayout;
Album t = elements.get(position);
if (convertView == null)
{
rowLayout = (LinearLayout)LayoutInflater.from(c).inflate(R.layout.albumitemview, parent, false);
TextView tv = (TextView)rowLayout.findViewById(R.id.txtName);
tv.setText(t.getName());
tv = (TextView)rowLayout.findViewById(R.id.txtArtist);
tv.setText(t.getArtist());
ImageView iv = (ImageView)rowLayout.findViewById(R.id.imgAlbumArt);
iv.setImageBitmap(t.getAlbumArt());
} else {
rowLayout = (LinearLayout)convertView;
TextView tv = (TextView)rowLayout.findViewById(R.id.txtName);
tv.setText(t.getName());
tv = (TextView)rowLayout.findViewById(R.id.txtArtist);
tv.setText(t.getArtist());
ImageView iv = (ImageView)rowLayout.findViewById(R.id.imgAlbumArt);
iv.setImageBitmap(t.getAlbumArt());
}
return rowLayout;
}
}
AlbumListView.xml
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:orientation="vertical">
<ListView android:id="@+id/ListViewAlbums" android:layout_width="fill_parent" android:layout_height="wrap_content" />
</LinearLayout>
AlbumItemView.xml
<LinearLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:orientation="horizontal"
android:gravity="fill_horizontal">
<ImageView android:id="@+id/imgAlbumArt" />
<LinearLayout
android:layout_width="wrap_content"
android:layout_height="fill_parent"
android:orientation="vertical">
<TextView
android:id="@+id/txtName"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:singleLine="false" />
<TextView
android:id="@+id/txtArtist"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:singleLine="false" />
</LinearLayout>
</LinearLayout>
WinMoPho
C#/Codebehind (snippet where the list is bound to the list of Albums)
lstMyList.ItemsSource = myListOfAlbums;
XAML/UI
<ListBox x:Name="lstMyList">
<ListBox.ItemTemplate>
<DataTemplate>
<StackPanel Orientation="Horizontal">
<Image/>
<StackPanel>
<TextBlock TextWrapping="Wrap" Text="TextBlock"/>
<TextBlock TextWrapping="Wrap" Text="TextBlock"/>
</StackPanel>
</StackPanel>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
There are better ways to write the XAML than this, but this is the easiest way to demonstrate it.
Android has a tonne more code, a tonne more markup (and trust me, its needed), and it still doesn’t function 100% of the way it should and you’d have to rewrite a lot of that code if you wanted to do another list of tracks instead of albums. On Android if you add to the list, you have to make sure you notify the adapter so it can update whereas its automatic on WinMoPho.
Images
If you’re getting images on Android from anywhere but local storage, you’re going to have some fun times there – by that I mean images from the internet.
Android
Part of the issue is when do you download the image? In this example I was setting it in the custom ListAdapter, but this of course creates a very slow loading of the list – you need to spin this off to a different thread.
ImageView imgAvatar = (ImageView) rowLayout.findViewById(R.id.imgAvatar);
URL aURL = null;
URLConnection con = null;
try {
aURL = new URL(t.Avatar);
con = aURL.openConnection();
con.connect();
InputStream is = null;
is = con.getInputStream();
BufferedInputStream bis = new BufferedInputStream(is);
Bitmap bm = BitmapFactory.decodeStream(bis);
imgAvatar.setImageBitmap(bm);
is.close();
bis.close();
} catch (MalformedURLException e) { }
catch (IOException e) { }
catch (IOException e) { }
Silverlight
There are several ways to set images – you can set the Source on an Image in XAML to the Uri, you can databind the Image’s Source in XAML to a property on the object you’re binding (can be a BitmapSource, String or Uri) or you can set it in code like Android. However, most of the time the first two options are what you’ll do, and the framework automatically takes care of loading it asynchronously. It really is that simple – its hard to stress how easy it is compared to Android.
One clever thing Android does do around images, however, is the Nine-Patch image. A NinePatch is like the name suggests, an image that can be divided into 9 sections, where the “inner” (5 if you were looking at it from a numberpad) section can be stretched for content. The editor for this is included in the Android SDK, although isn’t very friendly to use.

Persistence and Storage
WinMoPho will not give you direct access to the file system nor will it ship with (apparently its there, just not accessible) SQL CE. The only way you can store on the device is using IsolatedStorage, a concept brought over from the “desktop” version of Silverlight. That being said, Alex Yakhnin has created a LINQ Data Provider for Isolated Storage which works wonderfully by serialising objects to JSON, then storing in IsolatedStorage, which is incredibly easy to consume.
public static class Storage
{
private static ObjectStore datastore = new ObjectStore("MahBlogMobile");
public static ObjectContext Context = new ObjectContext("MahBlogMobile");
public static void StoreAccounts(IEnumerable<Account> account)
{
datastore.Persist<Account>(account);
}
}
Android by contrasts lets you write to the file system and comes bundled with SQLite. While it (seems?) to lack ORM’s like LINQ, it’s flexible enough to let you decide how you want to do it.
public int InsertProduct(Product P)
{
SQLiteDatabase db = mOpenHelper.getReadableDatabase();
db.execSQL("INSERT INTO Products ('Barcode', 'Name') VALUES ('"+P.barcode+"','"+P.name+"');");
int id = 0;
Cursor c = db.rawQuery("SELECT ID FROM Products WHERE Barcode='"+P.barcode+"' AND Name='"+P.name+"'", null);
if (c.moveToFirst())
{
id = c.getInt(c.getColumnIndex("ID"));
}
db.close();
return id;
}
Device Resolution/Size Handling
WinMoPho will launch with WVGA (800×480) support only with HVGA (480×320) coming later on the track and only on phones (so no 10″ tablets), while Android supports FWVGA, WVGA, HVGA, FWVGA, QVGA, FWQVGA, WQVGA and various phone screen sizes and formats as well as tablets and portable media players. As such, Android has a harder time supporting all those devices, but has some clever ways to support these.
When you create a new project in any of the Android-compatible IDE’s, you’ll have a /res folder with /drawable, /drawable-hdpi, /drawable-ldpi and /drawable-mdpi inside of it. The idea is that you put your special version of your images into each folder and Android will be smart enough to know when to use each resource – ie, for your icon.png, you make it 72×72 for hdpi but mdpi is 48×48. You must declare in the manifest what screens you support, otherwise there is a good chance it’ll default to the wrong one.
While it’s great there is that level of support, the biggest issue is that the magic is based on density. According to Google, medium density is 320×480 on 3″ to 3.5″ screen OR 480×800/480×854 on 4.8″ to 5.8″ screens. Does this mean that a 5″ tablet is going to use a 48x48px icon instead of a 72x72px icon?
From a code point of view, getting the correct resource in said folders is performed in a similar magical way – R.drawable.icon refers to the correct density without having to figure that out yourself. That being said, you can do that
float scale = this.getResources().getDisplayMetrics().density; Bitmap bdRounded = BitmapHelpers.getRoundedCornerBitmap(artwork, (int)(15 *scale), (int)(320 *scale), (int)(320 *scale));
In this instance, scale would return 1.0 on a low density screen and 1.5 on a high density screen.
What will WinMoPho require? At this stage it’s unclear what Microsoft are planning, but because Silverlight is a vector based layout system, many applications may not require changes as vectors scale rather nicely.
Winner?
I don’t think there is a clear winner – for some people Java is going to be more natural but for others its going to grate against everything they know. I think I personally need to more Android dev before I chalk it up to ‘not for me’.
WP7 clearly has some great things going for it – the .NET stack goes from web, desktop, phone, Xbox360, and various mono implementations. Android on the other hand has the flexibility that no other mobile OS offers and a very passionate developer base, with a user base starting to challenge the almighty iPhone juggernaut.

[...] This post was mentioned on Twitter by NickHodge, vkoser, Jonas Follesø, Rob Relyea, Danijel Stulic and others. Danijel Stulic said: RT @follesoe: RT @aeoth: New blog post: WinMoPho 7 vs Android from dev point of view http://is.gd/dAx4d [...]