If, like me, you always wondered what sizeToFit: should be used for, I recommend you read this. Cheers Jérémy.

Cocoa Touch

The SDK is not all bad. Cocoa Touch is of course, awesome. It gives you plenty of freedom while constraining you in all the right places so you don’t end up with an unusable app. Most developers can’t do UI (look at some J2ME apps and you’ll know what I mean), but most iPhone apps are quite usable. Love the IB tool once you get your head round what it’s actually doing under the scenes. The widgets are customisable enough and using NSFetchedResultsController with a table is an efficient way to bind data to a table. UITouch events are simple to understand and the way messages cascade through view controllers via their subviews is great to work with.

Music Player Framework:

This is an unacceptable interface to the iPod library simply because it’s so inflexible and querying the library using MPMediaQuery and MPMediaPredicates is so inefficient and slow.

For example when you’re searching tracks by various properties you can only do either “exact match” or “contains”. There is no way  of doing a “word begins” search like the iPod does. This would speed up some queries significantly. Furthermore, there is no efficient way to get a list of Artists, Albums, Playlists etc. You’d imagine you could just do something like NSArray *artists = [[MPMusicPlayerController iPodMusicPlayer] artists] that returns a list of artist strings but actually you have to do something really silly. You have to do a query on the whole media library and tell the Music Player Framework to group tracks into collections. These collections can be representative of your grouping criteria – which in this case would be artist. There’s lots of heavy lifting going on here as we have to retrieve all the tracks on the collection – and on my iPhone 3G with around 2GB of songs this takes more than a few seconds.

To get around this problem you can cache the music library, but although there is a mechanism for detecting an iTunes sync while your app is running, there is no way to find out exactly what has changed. There is an API call to get the last modified date of the library, but this time also includes any updates to the library metadata – e.g. track play count, which makes this useless for detecting collection changes. Apple, please do something about this!

Core Data

I started using this because I thought it would be an easy and efficient way to query a large data set with basic math in the predicates (e.g. abs(r-%f) < .28 AND abs(g-%f) < .28 AND abs(b-%f) < .28) but even though the underlying store is SQLite I realise there are so many limitations. If I wanted to fetch 50 random items, I can’t do that. I can only sort by attribute name (e.g. title descending). That’s not very helpful… I might have to go back to the drawing board and use NSMutableDictionaries instead.

Maybe its time to wipe all preconceptions of programming that I’ve learnt from web development and start getting used to the Client API way of doing things. Lots of ups and downs but we’ll get there.

Thanks for reading

Working on an iPhone app! The image gives it away for those who knows me or knew me well enough. Keep your eyes peeled for a preview version! ^_~

This probably works with a Macbook Pro too, and with Feature Pack 1.

I’ve been programming with the W910i recently. Theoretically, it should be a great phone to work with. Plenty of optional APIs included, has a J2ME accessible accelerometer, BUT, Bluetooth keeps failing randomly with the following error message (in console output, testing in Java Developer mode using Sony Ericsson Device Explorer/Connection Proxy):

[Java/OJEX] bt.core[Util.raiseBluetoothConnectionException] FAILED_NOINFO

I’m using a separate thread that keeps making a serial profile connection (BTSPP://) to a GPS device that outputs in NMEA-0183 format. During random times (sometimes 20 secs, sometimes 5 mins) the thread locks up and any attempt to access it locks up that thread too. It must be to do with some of the bugs listed here – even after updating my firmware using the auto update within the device it’s not fixed. There seems to be no fix available anywhere!

I’m going to do a more simpler test later to see if it’s my code, but I doubt it will make any difference.

This is just a warning for those fellow developers out there tearing their hair out. For now, I’m sticking with Nokia phones and my Sparkfun accelerometer… Just need to re-solder that power connection!

Here’s how it goes for the poor developers who want maximum market penetration with their app, but are locked-down by carriers. To get your program verified by the “official” verification system – Java Verified, you need to pay an independent testing lab. For each bug fix release, you need to pay them to re-test. Your Java Me application can get around the security dialogs once it’s verified, but as soon as you want to release new versions you can understand that costs build up. Read more about the signing process here.

Bedroom developers, and freeware developers need to start charging to maintain useful applications – not an ideal way to encourage innovation is it?. Google chose to not bother signing their Google Maps for mobile application, as a testament to how bad the whole process is. I can understand that you need to go through a complicated process to allow application developers to access your personal information and phone numbers, but what about bluetooth access? How much harm can be done? Even so, what about giving users the choice to silence all future security dialogs with a “remember my decision” option?

Alas, when the restricted APIs are used in research in the UK it isn’t so bad – we don’t have operators like Cingular here. On the Nokia and Sony Ericsson phones I have tested the security dialogs only appear when you start the program. For the purposes of my experiments, I can just tell users to pick “allow” every time, and the problem is solved. I don’t really need to sign my applications.

More reading and good summary here: How Midlet Signing is Killing J2ME/