Wednesday, November 26, 2008

jTribe has released the forth iPhone app

We were pretty busy over last couple of weeks to release some iPhone apps. We are happy with the progress and the fact that met all our timelines and milestones (thanks to trac).

After the second app in the AppStore the process has been much smoother. Building and submitting a new iPhone app is now so easy compared to the painful experience of the first app. We actually ate our own dog food following Our top five tips for iPhone and Android developers.

Currently we got two apps in the navigation category and two in the entertainment and lifestyle category.

The most popular app is still Firepin Trip Tracker , the free GPS tracking app.

Our first paid app is PinPoint, a simple location sharing app. We spend most of the time making the email formatting look nice. This was a major challenge because the email app on the iPhone required us to go the extra mile to embed images.

The other two apps are in the entertainment category and we developed them originally to test the consumer behaviour in the AppStore. We learned the most astonishing things about consumer behaviour worth to put in a separate blog entry soon.

Ok, this was brief update around our latest iPhone development activities.

Other things that happend at jTtribe this week were the fact that our Android app statistics came back (Daniel, you should write about that).

And we worked on the Application Definition Statement of our next iPhone/Android app. I am so excited to write about it soon.

Sunday, November 23, 2008

JSON and RESTful web services on the iPhone

We use JSON on the iPhone to access RESTful services on the Internet.

JSON seems to be the dominant and easiest way to use web services over the Internet. 
We used it in our native iPhone app (PinPoint) to integrate with Googles Geo Location APIs. Fortunately, Google supports JSON and XML. I have chosen to use JSON over XML for no particular reason other then "want to play".
 
What kind of app do you have?
  1. A web-based  app that runs on Safari
  2. A native iPhone app that uses Objective-C and Cocoa.
Both flavours of JSON-iPhone integration are covered in this blog entry.

1. A web-based  app that runs on Safari
JSON form web apps based on WebKit / Dashcode

The first iPhone JSON integration I did was for a web app that I developed with Dashcode. The app required only the list of trips from our Rails app. No associations or nested objects were required. The JSON response was an array of simple objects. This list was displayed as a typical table view and tapping an item opened the detailed view without making another http request. 
This exercise was surprisingly simple because I could deal with well-known technology (JavaScript, HTMP, CSS, DOM, AJAX).


2. A native iPhone app that uses Objective-C and Cocoa.
JSON using Objective-C / Cocoa / XCode

I have to admit this is not as nice as for the web app using WebKit/Javascript. Not really a surprise since JSON is actually a serialiseed JavaScript object and no mapping is required.

Using JSON in Objective-C / Cocoa is less natural. The Objective-C / JSON framework I used does return the JSON structure mainly as a NSDictionary and NSArray.

If you are using the JSON framework with the iPhone SDK 2.2 then check out this article.

I used JSON to get Geocoding data from Google. The Google JSON API was actually not documented at the time I developed my app, which made it a bit more exciting. The JSON structure that is returned by Google is a mix of nested objects and arrays. I would say that the Google Geo location API returns a pretty complex but well structured data structure.

The JSON framework  for Objective-C does all the hard work of mapping the JSON structure into Cocoa data structures (NSDictionary and NSArray). Now that the data is in Objective-C object my code needed to access the parts I am interested in. The code needs to be aware of the returned JSON structure and that is where I feel things become a bit hardcoded. I needed to access parts of the NSDictionary objects that where pretty nested and had to traverse the tree through pretty long statements.

Show me the code:
Here is a simple example that shows how I get the JSON data for a reverse geo coding call to Google. The exampled will get the address string from the JSON structure.

NSString *jsonRep    = [[NSString alloc]        
      initWithData:data 
encoding:NSUTF8StringEncoding];  
NSLog(@"Got this form JSON");
NSLog(jsonRep);
NSDictionary *dir = [jsonRep JSONValue];
NSArray *arrPlacemarks = [dir valueForKey:@"Placemark"];
NSDictionary *dirPlacemark0 = [arrPlacemarks objectAtIndex:0];
NSString *address = [dirPlacemark0 valueForKey:@"address"];
NSLog(address);

The code to get the more granular part out of the Geo location  JSON string is not that simple but in principle the same approach.  
1. You need to know where the particulare information resided in the JSON strucutre.
2. Navigate the structure to the particular NSDirectory or NSArray and get it.

What could break:
As soon as Google changes their API I am sure my app will break. The above approach will not survive any serious schema changes. As soon as Google changes the nesting of objets in their JSON response I will need to modify my code. 

Tuesday, November 18, 2008

How Apple rejected our iPhone app

Last week I submitted our second iPhone app called PinPoint. After 5 days Apple came back  with a rejection.

Apple did find that the app did not comply to the iPhone Human Interface Guidelines. The app uses a standard "Action" button for an action which is not its intended purpose.

(This is the "standard" Action button provided by Apple)

So this means that Apple is actually reviewing the apps seriously. 

Yes, I did read and understand the purpose of the standards "Action" button. The "Action" button is to be used to open an action sheet that allows users to take an application-specific action. 

I have currently only one application action (open the email app) but I am planning to have more in the future (twitter, text/sms). I decided to use the "standard" action button and I also decided to not display an action sheet with one action to choose from. Seriously, it's not really a choice if you have only one thing to select from. In the next release I would offer more than one application using the same standards action button and the subsequent action sheet. (Wrong!) 

The solution for now is that I got rid of the the Apple "standard" button. I have added my own button that displays an email icon. Great, this way Apple cannot complain about violating the Human Interface Guidelines. I am not convinced that this helps the end-user in the long run because developers are encouraged to come up with their "custom" icons to avoid non-compliance with Apple guidelines. 

Anyway, after initial annoyance and self-criticism I accepted that this stuff happens. The fix and re-submission took me only 30 minutes and I hope I don't have to wait another 5 days.

What have I learned?
  1. If in doubt do not use standard buttons (especially the ambiguous action button)
  2. Cater for rejection in your development time table
  3. It's good to know that Apple takes reviewing the app seriously

Friday, November 14, 2008

iPhone development for Rails and Web 2.0 developers

Interestingly, many of the new iPhone developers seem to come from a Rails / Web 2.0 background. I am one of those guys who did Rails projects and now is sitting in front of XCode doing iPhone development.

I really like developing in Rails and appreciate it's simplicity and elegance. So here I am, I went through the process of morphing from Ruby on Rails to Objective-C/Cocoa.

Are there any techniques and skills I could transfer from Rails to iPhone development?
  1. Model-View-Controller (MVC) pattern
    MVC is the key pattern in COCOA. So, great there is one thing you would understand already when playing around with iPhone development.
  2. Asynchronous UI on iPhone / AJAX on web 2.0
    AJAX-based web apps are great. If you have used AJAX and tried to understand the structure of how AJAX is used to make web 2.0 apps simple then you will be in a good position to make it "simple on the outside and complex on the inside". Cocoa on the iPhone can get information asynchronously from any web source. Check out NSURLRequest in asynchronous mode.
  3. Database on iPhone
    There is SQLite support on the iPhone. Great if you are planning to build a self-contained app that needs to manage some data locally on the iPhone. I have found that I have less need for a database on the iPhone. The way we build our iPhone applications are mostly using the User Preferences locally on the iPhone to persist any UI state. The heavy lifting in terms of Data Storage is done on Rails-based applications and I integrate both through RESTful APIs. If you need SQLite in your iPhone app then you might want to look into Schema Migration support for the SQLite library FMDB
  4. RESTful
    I like to keep the iPhone app lean and this is why I make good use of REST. The iPhone app is my REST client and our Rails applications offers the RESRful APIs. We integrate both through the RESTful APIs using a JSON framework for the iPhone. Actually, in some cases we use a simple POT (Plain Old Text) approach to transfer simple atomic text data from the Rails application and database to the iPhone front-end. This approach has proven as highly successful due to it's simplicity. (I hope I can find some time to post some receipes soon)
  5. Metaprogramming on the iPhone?
    If you have used Metaprogramming in Ruby before you will have some benefits when you work with Objective-C/COCOA but I haven't seen as much use of it. Objective-C does support dynamic typing and you can send any object any message and decide during runtime what to do with it. You will come across a method called respondsToSelector that can check whether an object can respond to a particular method call. I am just starting to realise what can be done in Objective-C in terms of Metaprogramming. Not a much as in Ruby but better than C++.
  6. Test-Driven-Development (TDD) or Behavior-Driven-Development (BDD):
    Sorry, not a lot of support on the iPhone for TDD or BDD. Unit testing and RSpec are not available. Considering how many Rails developers are also playing around with the iPhone SDK I am certain that there will be tools soon that will support TDD/BDD for the iPhone. So, how do you do proper testing? I will need to dedicate a separate blog entry to that topic. Stay tuned. (There are some tools that let you use Ruby to run test and migrations for iPhone code.)
  7. Delegation Pattern:
    I found the Delegation Pattern the most powerful pattern for iPhone development. Delegates are used everywhere in the Cocoa framework. I started to use it heavily to realise notifications between different controllers via protocols. Take some time to get comfortable with it. It will make things so much easier when you develop a more complex iPhone app. Check the Apple Developer Documentation. Check out this nicely written article abut the different ways of listening, observing and notifying in Cocoa
I hope I can find some time to post some of the architecture decisions we made along the way as we developed some pretty complex iPhone apps with various integration points.

Thursday, November 6, 2008

Releasing an iPhone app to the AppStore - Dillema

The rush on the AppStore is on. More than 5,500 app are already in the AppStore. iPhone developers are in a race to get their app in before some one else releases a similar one.

So far I heard everyone saying "You need to be the first one to releases a new app".
I am not sure about that any more. Maybe it's better to be a fast follower?

The Dilemma :
1. Let someone else get the credit first
2. Let someone else get it wrong first

Obviously each iPhone developer fears scenario #1 (Someone else is getting the credit first).
But to get credit and good reviews the app needs to be "really" awesome. A app that is kind of half-baked wont get you any credit but will put you in scenario #2 (get it wrong first).

So what to do? We at jTribe decided to stick to some key principles about releasing an iPhone app and not to focus on the Dilemma mentioned above:

Our top three iPhone application release principles:
  1. Don't release in a rush.
  2. Let the app mature.
    Keep a development version of the app on your iPhone for a couple of days without using it. Then use it and you will see the flaws of your app straight away. Fix the flaws and maybe go through another maturity cycle.
  3. Stick to your original app design.
    The longer I spend in developing an app the more I get carried away and invent new features. Adding more features along the way is great fun and I usually learn heaps about the iPhone SDK. However, more feature usually remove me from my original app design goals. As hard as it is, I found myself actually removing feature before the app is submitted to the Apple AppStore.

Saturday, November 1, 2008

Must read reviews of Android and iPhone

Here are two blog entries I found very useful.

An Android G1 review looking at many facets of the phone:

An here is good review of the iPhone and its SDK: