Mobile

The Android FamilySoftware fragmentation is a common concern for Android developers. Right now, supporting all versions down to Android 2.2 (Froyo) will make your application available to 93.5% of Google Play users. However, doing so also means you miss out on APIs that were released in the last 2 years.In this post I'll talk about this problem in detail, and highlight a few libraries available that help you develop an Android 2.2 application without limiting yourself to old APIs.

Yow! Brisbane 2011

I recently had the pleasure of attending the Brisbane Yow! Conference.  This was a great conference with talks to interest developers across many languages platforms and experience.This blog is a summary of the more interesting talks that I attended and my thoughts on them.

Getting started with the development of location-based services on Android is relatively easy thanks to the well documented location API. However, getting more serious shows there is still much uncharted territory. One such area concerns the accuracy of real-life location data, which I have recently taken a close look at. In short, location data can be far more accurate than Google's conservative estimates - at least with the phone that I used.

Swipe ConferenceOf the many excellent sessions at this week's Swipe Conference, the one titled "Build Better Cocoa Apps Using Game Mechanics" by Paris Buttfield-Addison was unique in its topic. In it, Paris outlined how gamification is currently viewed as something that can be quickly slapped onto an existing product in order to increase its appeal, whereas in reality, successful gamification requires carefully thought-out integration, for when done correctly it should form a core part of your app's user experience.
We’ve all heard developers say it: “I’m a terrible drawer” or “I’ve got no design skills”. Perhaps we’re even guilty of saying it ourselves - I know I am. But after attending this year’s Swipe Conference I now subscribe to the opinion that this is no longer acceptable. We are all responsible for the design of the app we are building; developer, designer, tester, or producer: every member of the team is accountable for helping shape the app’s design and interactions.
Yesterday was the last day of Swipe Conference so I thought I would take this time to reiterate one of the points I took from the first presentation by Josh Clark.  Josh covered quite a few topics and if you haven't already you should check out his book Tapworthy: Designing Great iPhone Apps.In short:
  • Gestures can be brilliant … if the context they are used in feels natural
  • If you're using gestures make sure your users will find them
  • If you don't think your users will figure out your gestures easily, don't overload your users with lots of help hints all at once; instead, let them "unlock" them over time, like a reward for using your app
  • Downside though is that there is no consensus on what a 3 finger swipe gesture might do. Every iOS app that uses this gestures decides it for themselves.
It was obvious from the way Josh presents that he has so much passion for touch / gesture based devices. What I personally took away from his presentation was that gestures can be awesome shortcuts within your app. In a lot of cases gestures are a natural progression with how we interact with real world items.
Shine was recently involved with helping a client bring an outsourced mobile web site in-house. The site was essentially a guide for browsing business and event information for cinemas, restaurants and bars in your area. Bringing this web site in-house was mainly an exercise in re-writing the outsourced instance as a component to the client’s own internally developed NodeJS/Express app server (currently used to serve their main - non-mobile - web site).The NetBiscuits platform was used to handle all the device specific porting which allowed the development effort to focus almost entirely on business logic and backend data processing. The combined learning curve of NetBiscuit’s own markup language with Shine’s Jazz template system was simple enough to make the presentation layer development a breeze. This blog will talk about the process involved in developing for NetBiscuits and some of the problems and solutions encountered on the way.
When I first started learning Objective-C and the iOS SDK 2.x a few years ago, one thing that I constantly struggled to get my head around was Interface Builder.  More specifically, why should I use it and how it could possibly benefit my iOS development - given that I could code a UI programmatically, and know exactly how it all worked? A colleague of mine even wrote a blog entry that mirrored my exact feelings towards Interface Builder back then.Well over the past 6-12 months my attitude towards Interface Builder has changed. There are two reasons for this. Firstly, it's now nicely integrated into XCode 4. Prior to that, who wanted to have 2 different apps running (XCode and Interface Builder) with popup windows spamming your desktop? That was a deal-breaker for me. Secondly, I'm now a more experienced developer. After using Interface Builder on a couple of projects, I am confident to say I am now more efficient as a developer when using Interface Builder. However, that wasn't always the case, which leads me to my key message here:
If you're new to iOS development, don't touch Interface Builder until you are capable of building UIs programatically.