Showing posts with label Development. Show all posts
Showing posts with label Development. Show all posts

Wednesday, July 7, 2010

iPhone AdHoc Provisioning Tip

Has anyone experienced problems with AdHoc provisioning on iPhone SDK 4?
I had a problem that took me while to overcome. Each time I dragged my app into iTunes I got a message saying:
"A provisioning profile named embedded.mobileprovision already exists on this computer. Do you want to replace it?"
I had a perfectly working setup to create AdHoc distributions of iPhone apps. What has changed?
The only difference was that I created a new Target within the same project. Luckily, I had one target that still worked as AdHoc built. I could boil it down to a missing property in info.plist of the new target.
Adding LSRequiresIPhoneOS and setting it to true did the trick.
If you have a similar problem please check out also this blog entry.

Tuesday, June 22, 2010

Different behaviour in iOS4 for NSError and NSURLConnection

After running some of our apps now on iOS4 we were surprised that there were much more crashes. This little code section is what caused the crashes:

NSURLRequest *request=[NSURLRequest requestWithURL:[NSURL URLWithString:requestStr]
cachePolicy:NSURLRequestUseProtocolCachePolicy
timeoutInterval:10.0];
NSURLResponse *response;
NSError *error;
NSData *responseData = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error];
if(error) {
NSLog(@"error: %@", [error localizedDescription]);
}

After hours of debugging we could narrow it down to the line of code that initialises the NSError. Setting it to nil did remove the crash. So make sure your code looks like this:

NSError *error = nil;

We are currently investigating more issues we have with code that ran perfectly fine in 3.x and now starts crashing with iOS4. The above line fixed approximately 80% of our problems.

Good luck making your apps ready for iOS4.

Thursday, January 7, 2010

iPhone apps re-invent Magazines and News Papers

Paper Magazines and News Papers started to discover the iPhone as a platform to distribute their content. There is a new trend towards custom iPhone apps that complement the paper issue of magazines.

A magazine on an iPhone creates new revenue streams and is an easy door opener into a demographic of users that uses their iPhone for everything lifestyle.

It has already started
Here are two great examples of Magazine that have been converted into iPhone app. Vogue's online version style.com is available as an iPhone app.GQ has just recently released a colourful iPhone app too. Interestingly the sales of GQ will be counting towards their total sales. So paper version and iPhone app count equally. That's very important for advertisers.

An earlier review of the Top Magazine iPhone apps in May 2009 shows some other good examples including Wired, Epicurious, Elle, Spin.com, OK Magazine, Car and Driver, FHM, People Magazine.

A Packaged Solution for the Media and Publishing Industry
We realise that many media companies and publishers are looking for solutions that could rapidly produce high quality iPhone apps.



At jTribe we worked hard developing a platform for iPhone Magazines and News. Our jellymo for Media and Publishing offering makes development of custom branded iPhone apps affordable and fast. The news and magazine apps allow to present constantly fresh content in a branded iPhone app with social elements and even in-app purchase of content.

Tuesday, July 14, 2009

iPhone Universal Remote app for HAL unveiled

Remote controlling everything in your house from your iPhone is the dream right? Well yesterday we unveiled an app that brings us a step closer to a universal remote for the iPhone. At the CEDIA expo in Sydney we unveiled an iPhone app that lets you control devices like Foxtel, DVD, TV and tuners throughout the house. It integrates with some new hardware (HAL) from OzHifi which handles the routing and amplification of audio and video.

The iPhone app starts up and shows a overview of all the rooms (or zones) configured in your house and lets you control basic functions such as power, volume and mute. Clicking the info button for each zone takes you to a remote control for the device that is currently playing in that room. The screenshot below shows a Foxtel remote being used but the user could also select another source such as a DVD player or tuner and a different remote would appear. You can also link zones together to have the same thing playing in multiple rooms (party!), again all controlled from the iPhone.

The hardware will start shipping late this year so look out for even more features from the iPhone app before then.

Friday, April 24, 2009

Shoutmob goes ahead!


In March the management team at jTribe was away to plan our future activities. The session was pretty much 3 guys away and drinking wine in the country side.

One of the things we decided at jTribe was that we want to progress with shoutmob. Shoutmob is our offering for developers to support any mobile app with service-side building blocks and services like high-score persistence, push-messages to the app and app error submission back to the developer.

jTribe is currenly beta testing heavily and we use shoutmob in all our apps for iPhone and Android. I love it and cannot wait to open it up to the public soon.

Thursday, February 5, 2009

ShoutMob Beta now open for iPhone and Android developers

We have been busy creating a new service for iPhone developers and Android developers. The Beta of ShoutMob has launched yesterday. iPhone and Android app developers can sign up now and receive a $20 early sign-up credit. The Beta is limited and will be closing as soon as we got enough beta developers - so be quick. 

We tried to think about a way to reward early adopters who sign up now. As a result developers signing up for ShoutMob Beta will receive two things:
1. $20 a credit so they can get started as soon as shoutmob goes public
2. $5 referral credit, so they get rewarded for spreading the word

We hope that early adopters will get enough credits to be able to use ShoutMob for free for a long, long time.

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

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.

Tuesday, October 28, 2008

Our top five tips for iPhone and Android developers

Apple and Google have changed the way applications are distributed to mobile devices. 

We have released FirePin on AppStore and Android Marketplace and want to share our experience.

The Apple AppStore gave Mac developers a great opportunity to get their applications out there and some did really, really well. Now Google does the same thing with its Android Marketplace. Both storefronts give developers relatively easy access to a large user base. But there are differences in terms of ease of development and distribution.

Our top five:
  1. Start early when dealing with Apple
  2. Android development is faster than iPhone development
  3. iPhone users are different to Android users
  4. Don't expect sophisticated reports
  5. Keep it simple
1. Start early when dealing with Apple
First you have to sign-up for the iPhone Developer Program for a joining fee. In our case it took actually weeks to get it all approved. This might have to do with Apple checking actually the details of our company and the fact that we are an Australian company. I could imagine that the process is faster for a US company. 

If you plan to let people pay for your application then there is some additional forms to be filled out. Especially if you are non-US developer (we are in Australia) there are some additional TAX -related forms you nee to fill out and some need to be send in as paper copies. So you better kick that process off early.

You should allow about 5 days for Apple to review your application. Every update takes another 3-5 days to review.  Apple really reviews an app before it goes into the AppStore. They do not just let the app sit there for a week and then press a button to release it, no, they actually test the app. So you got your application through what I would almost call "user acceptance test" which is performed free of charge by Apple staff. Which is nice. If you have been involved in larger projects you might know that "user acceptance testing" takes time. Which sucks.

Here is a good description Oliver Breidenbach on how to get a EIN from the IRS that is required for non-US developers who want to sell their app. 

Publishing on the Android Marketplace is sooo easy. The developer is trusted to publish "good" applications and therefore there is no review process. The app just goes live and the users can start downloading. Google obviously relies on the "wisdom of the crowd" to promote good quality applications based on user feedback. It looks like Android users are more willing to leave a feedback than iPhone users.

2. Android development is faster than iPhone development
Even though I use a Mac for all my software development I haven't actually developed with the Apple SDK or the Cocoa framework. Apple's SDK is actually not as bad as I thought. After a while I got really in touch with XCode and find it actually simpler than Eclipse. One thing that decreased my productivity was Objective-C which was completely offset by the good quality sample code provided by Apple. The iPhone Simulator works well but not for location-based applications (see previous blog entry). Unfortunately, the community of Objective -C programmers is much smaller than, lets say, Java or Ruby. Finding information on the web was harder than it needs to be.

On Android we had the same application up and running in a fraction of time. The reason is "openness" of the Android platform and the large community of developers. The emulator comes with a number of development tools that make automated testing pretty easy for location-based apps. You can replay a KML file. Very nice.

3. iPhone users are different to Android users
Our app is only since 1 day on the Android Marketplace, but we can already see that the review and feedback from Android users is completely different to what we got in the AppStore. Even for the same application. (More info will be blogged soon)

4. Don't expect sophisticated reports
Analytics suck for both, AppStore and Android Marketplace.

5. Keep it simple
So you are a mobile application developer now. There is a lot of new stuff you have to deal with.  Best you keep your application as simple as possible. We found that users like simplicity in mobile phone applications. Our app is very simple and we actually spend much time to make it so simple. Other apps in the same category are overloaded with features and users give up early. We see that users come back and use an application when it is simple.

Monday, October 20, 2008

The top iPhone thing we don't like

The best relationships are the love-hate relationships. They keep things interesting and spicy. No, I am not talking about my personal relationships - I am talking about my relationship with my iPhone 3G.

One day I love the iPhone for its stylish and innovative appearance and user friendliness. Next day I hate the iPhone 3G for it's restrictiveness and for treating me like a child.

When I am in the "hate my iPhone" stage I usually go to http://pleasefixtheiphone.com/ and click on features I miss most. That has some therapeutic effect.

What is missing for location-based developers?

As an iPhone developer you experience a whole new dimension of iPhone love-hate. The device is actually really great but what about the tools to develop iPhone applications? The iPhone SDK and the Simulator?
When we started developing our first iPhone application we thought it would be easier - I mean it's Apple - right. Surely, the Apple SDK developers must figured out a way of simulating the GPS function in the Simulator. Wrong! In fact Apple did not think that one through.

The Simulator simply does a bad job in location-based app development support. The only thing the Simulator does is that CoreLocation returns always the same Location (the infinite loop in Cupertino). That functionality is enough for simple applications that want to determine your "current location". However, that is of limited use for a tracking application where locations "change".

How to test the "real" GPS behaviour?

So, you really cannot test the "real" GPS function in the Simulator. The way we tested it was to install the app on my iPhone. Then I would leave the building with the iPhone in my hand and run around the block to capture some locations. Does not sound too bad? It was bad! To produce a thoroughly tested application we had to spend the majority of the development time testing with the real iPhone device.

How could GPS testing be simpler?

There should be a way to play back a set of Geo-locations in the Simulator. This is actually not too hard but was probably not one of Apples top priorities at the time. Hopefully Apple will release such a playback tool with the next version of the Simulator or iPhone SDK.

Android is ahead

In the Android SDK there is a way to play back a KML files. That is nice. This function saves the location-based application developer days of testing. If only this would be available for the iPhone.

Hey, at least I am staying fit with all that running around outdoors with my iPhone. ;-)