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! ^_~

Everyone is incorporating social into their web applications, to the point where there is so much noise created by the new startups. The few that do emerge as being widely used can provide inspiration for the mobile. We can take aspects from the successes, remix them, and apply them to other settings. Notable here, as part of my ongoing interests in mobile UE, is the importance of mobile search. When we’re out and about we may want to find out that quick snippet of information nagging you on a train. Or maybe you want to find out the best restaurant in an unfamiliar area. These are typical use scenarios that are immediately obvious. If we turned the latter example on its head, and describe a use scenario where people want to find better restaurants in a familiar environment, the situation becomes more difficult. No longer would users be content with a simple average “star rating” given by other visitors to the restaurant. How about finding the best steak amongst the local chinese take-aways? (Believe me, people love these wok-fried steaks.) How about the best place for a quick desert, that offers a comfortable local atmosphere?

Whoever provides a solution that lets you quickly assess the surrounding areas for recommendations based on relevant filters based on social context, specific culinary preferences, time of day, and dynamically changing qualities of restaurants that in the past can only come from word of mouth are sure to make a few bucks. Maybe we can take inspiration from (social) web 2.0 and bring this into (social) mobile 2.0.

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

This is an interaction model that I believe will pave the way to more usable automatic, mobile location disclosure interfaces. If access were controlled by allowed-lists, the interactions required to select who can see what, and when, is multi-faceted, which causes a whole load of problems, including users perceiving the system to be more complex, therefore abandoning use altogether.

Under this model, when users want to blur their exact location, they simply create a larger bounding box around their current location. Who cares if people know you’re ‘somewhere’ in the city? During times when you feel more social, you simply reduce the size of the box. If your buddies know you well enough, they should be able to infer where you’re likely to be even if they don’t know your exact location. Then, the good ol’ phone call comes in and the system becomes a context-setter and conversation starter…

Link to poster’s paper.

My 4th Ph.D. progress report is up – check it out in the documents/papers section. The report itself shouldn’t be that interesting to most of you, but please look at the interface mockups and get back to me with any comments (shown below). I’ll be implementing these soon so wouldn’t mind some feedback.

Three interface designs, to be implemented and compared in the first experiments. Absolute, spatial, map-based, allows deception and disclosure ’blurriness’ radius (top); distance-based, doesn’t allow deception but privacy alleviation through ambiguity (middle); spatial, distorted distances, allows deception and disclosure ’blurriness’ radius (bottom).

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!

No, I’m not talking about Navizon for iPhone, which uses cell triangulation methods to detect (rough) location and WiFi triangulation for greater accuracy in built-up areas for paying customers. This is locoGPS – a real GPS module attached to the iPhone communicating through some hacked interfaces. Only thing is, it looks a bit tacky, even the rendered prototype. Shouldn’t they build a wire in there so that it doesn’t have to rigidly protrude from the proprietry apple socket?

Or maybe we can wait till February, when apple will hopefully release a new firmware version that includes a not-so-cripped Bluetooth stack, with a developer SDK. They just have to! Combined with the accelerometer, unlimited data plan and an open API, this could be so ideal for my research (a few of my friends have iPhones).

Demo:

Click here to view the embedded video.

Source

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/