Yesterday I gave my views on the apps and services I use most often on my iPhone and compared them to what the N900 had to offer, the iPhone won 3-1, but a lot of the comparisons were a draw.
So today I’m going to tell you what I think of the hardware & the OS. I’ll point out right now that I’m comparing the N900 to MY iPhone, which is a 3G, and not the newer 3Gs
In the box are the usual wires, some headphones, a wall wart charger and a USB lead. I was dissapointed that the N900 didn’t use a standard mini USB cable like so many other devices do, it means you are tied to their peripherals much like you are with Apple’s. The box also contains an AV lead which you can plug into a TV and play your media through, very nice.
In terms of looks, the iPhone wins hands down, it’s more polished, their apps all share the same UI and follow (in the main) the Apple guidelines. The N900 UI doesn’t look as polished and many of the apps handle similar tasks in different ways.
In terms of size, the iPhone is about half as thick, 10mm longer and the same width, but they weigh the same as far as I can tell. The screen on the iPhone is slightly larger and when you’re using your fingers it’s capacative screens is much more responsive than the N900, but you can use a stylus on the N900 for much finer control.
Call quality and making calls on both devices is very easy, and the N900 has excellent audio quality, but it has dropped 2 calls in the 3 days I’ve been using it.
The Maemo OS has one massive advantage over Apple’s iPhone OS, it’s free and open source. I can download tools and develop apps for it, just like the iPhone, but I have the choice of 3 languages and 2 GUI toolkits. The latter is what causes the inconsistency in part, but the next version of Maemo will switch to use Qt as it’s toolkit. Another barrier to entry for iPhone dev is that you need to fork out $99 a year to be able to run your apps on an actual device.
I’m trying to write a better Twitter client for the iPhone, but how far I’ll get in the 2 weeks before the phone goes back, I don’t know. Development on OSX has to be done using the provided VM image, which has a 800×600 resolution and runs like a dog on older Apple hardware. I’m hopefull that developing PyQt apps will be easier though, one demo suggests you can deploy to the device just by copying the source over, which will be a great improvment.
Apple also put another wall in between the developer and getting their apps out, and this is either a good thing, or a bad thing, depending on how you look at it. It’s a good thing as it can act as a quality filter (however low they set the bar) or it’s a bad thing because it means they can refuse any app they fancy, or make an eReader have an adult rating because you can use it to read The Karma Sutra.
With the N900 anyone can upload apps to Nokia’s Ovi, which has the same quality gates as the App Store, or you can install stuff via a normal debian package, as a company you can even create your own repository and people can add it to their phones. The Ovi store is where developers can sell their apps, and like Apple, Nokia take a 30% cut of what you sell it for (minus costs) and have a €50 fee to join the store.
The documentation for Maemo is also very good, with plenty of examples, an easy to follow introduction, but these are focused on C or C++, but Meego.com has some basic tutorials for Qt. MeeGo is what the next version of Meamo will be called, after it’s merger with Intel’s Moblin.
So with all these things in it’s favour the N900 is ideally positioned to explode, but there’s 1 thing standing in it’s way … adoption. Developers won’t write apps for it unless they can see they could make some money, and people won’t buy the phone unless they can see the apps they want available for it. Just look at all the apps that were available when the App Store launched, Nokia can’t rely on a build it and they will come strategy, they need to work with developers of all kinds to build the kind of apps people expect to see when they buy the phone. Offer developers the hardware & the support they need to build their apps and not just rely on creating a website and releasing the phone, “Build it and they will come” doesn’t apply unfortunatly.
So, out of the 2 phones, I think the N900 wins, it’s dev tools, better hardware spec and open source nature just beat the iPhone. If I was a new user looking at the 2 devices I’d probably go for the N900.
Last week I was getting quite pissed of with the amount of time my iPhone is taking to wake up from sleep mode, which means I miss quite a few calls because I can’t slide the answer slider!
So this week I took delivery of the new Nokia N900 for a 2 week trial, and here are my inital impressions.
I’ve drawn up a list of all the stuff I use my iPhone for to see how the N900 compares…
- Web Browsing
- Music
- Google Reader
- Maps
- Calendar
- Foursqaure/Gowala
- EBook reader
Web Browsing
The web browser that comes with the N900 is very slick, just as good as the Safari based one that comes on the iPhone, it uses the Gecko rendering engine which is the same one that firefox uses, so it’s probably safe to assume that anything that looks good in Firefox will look the same on the N900.
Verdict: A draw
None of the native twitter apps I tried are very good. Maeku doesn’t let you view @ replies or direct messages and kept telling me I had exceeded my rate limit when other apps worked fine.
Verdict: iPhone Wins
Google Reader
A side effect of the browser being so good is that some services don’t recognise it as a mobile browser, so won’t let you browse their mobile site. The Google Mobile suite of apps being a prime example. Visit http://m/google.com/reader (or any of the mobile sites) and you get redirected to http://www.google.com/mobile/more/ and as yet I havn’t found a workaround.
I tried to use the full site, but displayed on such a small screen, it doesn’t work very well.
Verdict: iPhone wins
Maps
The N900 uses Nokia’s Ovi for it’s mapping, and they look lovely, the N900 comes with a built in compas which lets the maps rotate as you move which is really nice, it helps so much with orientation. I was trying to find a building in Sheffield and the rotating maps made it much easier to work out where I was going. Admitidly, I only have a 3G iphone, not the newer 3Gs which also has the magnetometer.
Having said that, the directions are for driving only and the satalite view is much more detailed on the iPhone.
Verdict: In this limited test, the N900 won.
Calendar
There are many posts about people struggling to get their phone synced to Google for contacts and calendar, but I had no problems when I followed these instructions
Verdict: A Draw
FourSquare/Gowalla
Ok, so these 2 are pretty frivolous, but I’m using them quite a lot at the moment, so I’ll include them here. There are no native apps at the moment, but they both have mobile versions of the site.
Gowalla causes a javascript error at the moment, so I can’t use the rest of the site and the Foursquare mobile site doesn’t seem to use GPS at all, I have to enter it manually.
Verdict: Harsh because it’s not the N900’s fault, but the iPhone wins
eBook Reader
I havn’t had chance to use the ebook reader yet.
Round 1
So at the end of the first post, the iPhone is ahead on apps, but that’s not really a suprise to anyone is it. Part 2 will compare the device & OS itself, and I expect a much closer contest.
In the last post, I looked at moving all your data from one app to another, and today I’m going to go through using Django’s unit test extensions to test the app. This post also covers using signals to validate models that arn’t created from a form. You should of course also unit test the methods on your models outside of the views they’re called from, but there’s nothing special there, and there’s a whole bunch of blog posts that cover them.
The main aim of whos-playing.com is to make organising 5-a-side matches easy, so it’s main features are all around players saying they can or can’t make the game. A player can say they’ll play, but then change their mind, they can only play in matches for teams they are a member of, and they can only say THEY will play, not anyone else, the exception to this being the team organiser, he can add or remove any player. Lets look at the various things we might want to test.
Continue reading
I’ve written a Django app to help people who organise social 5 a side games, (yeah, I know I said it was dead, but I left it up and it started to get a few users, it’s still not a success, but it is being used). It was the first “large” scale Django app I’d attempted and so it’s got a lot of things wrong with it, for starters I didn’t really see where I could split the project up into seperate Django apps, but I understand that a lot better now, so as I add new features I’m also splitting the project out into seperate apps. This blog post covers how I do it, and hopefully you’ll find it usefull.
I’m making a start from this post on Stackoverflow.
I’m already using south for migrations, so it makes sense to use that for refactoring too. If you havn’t already, install it and convert your app over.
Everything I created originally was under an app called, ‘sheets’, and now I want to split the parts of this that control creating and playing matches into a seperate app, which I’m going to call it ‘match’, don’t forget to add it to your INSTALLED_APPS
./manage.py startapp match
Now move the models over to your new models.py file, you’ll have to add a related_name parameter to some of your models if you’re using Postgres because south will try and create a relation with the same name as the existing models relation.
stuart-grimshaws-macbook:teamsheet stuartgrimshaw$ ./manage.py startmigration match --initial Error: One or more models did not validate: sheets.match: Accessor for field 'location' clashes with related field 'Location.match_set'. Add a related_name argument to the definition for 'location'. sheets.matchplayers: Accessor for field 'player' clashes with related field 'User.matchplayers_set'. Add a related_name argument to the definition for 'player'. sheets.sides: Accessor for field 'player' clashes with related field 'User.sides_set'. Add a related_name argument to the definition for 'player'. sheets.sides: Accessor for field 'side' clashes with related field 'SideNames.sides_set'. Add a related_name argument to the definition for 'side'. match.match: Accessor for field 'location' clashes with related field 'Location.match_set'. Add a related_name argument to the definition for 'location'. match.matchplayers: Accessor for field 'player' clashes with related field 'User.matchplayers_set'. Add a related_name argument to the definition for 'player'. match.sides: Accessor for field 'player' clashes with related field 'User.sides_set'. Add a related_name argument to the definition for 'player'. match.sides: Accessor for field 'side' clashes with related field 'SideNames.sides_set'. Add a related_name argument to the definition for 'side'.
Don’t be tempted to dive right into your new migration and add your code to migrate data from the old models to the new ones, South recommends that you do a data migration in 3 steps, which makes sense when you consider that doing it in 1 big step might have it’s shortcomings.
The startmigration –initial command created the first migration, this simply created the tables in your database. Run migrate to make these alterations:
./manage.py migrate
Next, you need to create the migration that actually moves the data from one set of files to another:
./manage.py startmigration match sheets-to-match-data
The migration in the example on Stackoverflow is actually a lot more complicated than ours, we simply need to rename the database tables, like this:
def forwards(self, orm):
db.rename_table('sheets_match', 'match_match')
db.rename_table('sheets_matchplayers', 'match_matchplayers')
db.rename_table('sheets_sides', 'match_sides')
def backwards(self, orm):
db.rename_table('match_match', 'sheets_match')
db.rename_table('match_matchplayers', 'sides_matchplayers')
db.rename_table('match_sides', 'sides_sides')
So, that’s the data migrated over, now we need to migrate any views to the new app, just identify and copy them, one of the mistakes I made in the original attempt actually helps me out here, I created a seperate urls.py for some sections, that was my first clue I was doing something wrong.
After copying this file over to the new apps urls.py, it’s time to take the views it mentions and copy them to the new apps views file, once you’re happy that they’re working, you can delete them from the old views file too.
How do you know they’re working? Well, you have been using Django’s unit tests havn’t you? No? Well that’s another post then.
Stubblog 