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)
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.
