I have an application that reads data from a JSON file and displays the locations for the records it’s reading in a map. Fairly standard fare and all works well. Well, it worked on an iPhone, but on an iPad the application would crash after loading a few hundred records. I thought there might be something wrong with the names of the locations that I was loading. These would be the titles for the annotations, so having established that a particular record was giving trouble I just disregarded it and moved on. Then I got a new data set and the problem went away. At least the problem with that record went away, but now a different record caused a problem, and again only on the iPad. I just buried my head in the sand. I’m not worried about the app running on an iPad so it’s not a major problem.

Except then I got a new iPhone, still an iPhone 4, so exactly the same model as the old one. And now the application crashes on the new iPhone just like it did on the iPad, but it doesn’t crash on the old iPhone. And now I am worried, because if it works on some iPhones and not on others that’s not a good thing. So I looked at the differences between the two iPhones. Aha! The new one runs iOS 4.3.1 and the old one runs 4.1. And the iPad runs 4.3.1 too, so that’s interesting.

But there has to be a root cause, because by ignoring some data records I could get the problem to stop happening. So this time I looked closer at the data and found the problem. The latitude and longitude are included in my data and these are a number of degrees. These range from -360 to +360 and have 5 or 6 decimal places. Except the bad records, which had been badly entered into the data file and had no decimal point, so they read as 3 million degrees or something.

Earlier versions of iOS would probably replace the bad values with zero, while 4.3 and later would crash. In fact the crash was very low down in the OS, it would make my app so it would not run again, I’d have to reboot the device.

I changed my app so it replaced these erroneous coordinates with zeroes and now my app runs perfectly. OK there are some annotations placed at the north pole, but that’s a data issue and nothing to do with my app. I just need to get the data cleaned up.

There are some lessons here: Never trust the data. Never ignore an error, and test for every type of hardware.

 

This is probably an obvious one. but it’s possible to shorten your OpenID URL. Use your URL shortener of choice. Assuming you’re using TinyURL, type your OpenID, which might be something like http://myopenid.com/itsmereally and generate a TinyUrl for it (the TinyURL would look something like http://tinyurl.com/ABC123). When entering your OpenId in a web-site you can now type the shortened URL. OK in this example it doesn’t gain you much, but if you have your own domain and have tied your OpenID to that you would have an OpenID like http://openid.mydomain.com/itsmereally, which can benefit from shortening

 

I’ve been experimenting for a while integrating OpenID (Wikipedia) with an iOS application. The iOS application uses a split view controller, though that shouldn’t matter.

I started by registering with MyOpenId. In fact I did this a week or so ago. I’ve linked my OpenID with a few other sites that I use (StackOverflow, Toodledo etc). OpenID is an implementation of a decentralized authentication mechanism, which means users of my application would be able to authenticate using their OpenID credentials rather than needing to have special credentials for my application.

MyOpenId is partnered with Janrain, whose product Janrain Engage allows you to integrate OpenID with various application platforms. I registered with Janrain – using their Basic package, since I’m just trialling the mechanism for now. My Janrain registration is tied to my OpenID. I registered a new application there too, which has an application Id that I will use from my iApp. Janrain produce an Objective C library that I cloned from github.

It was a simple task to clone the github repository and include it in my application. I then modified my AppDelegate header to include the JREngage header and added a function that would make an authentication call:


JREngage *jrEngage = [JREngage jrEngageWithAppId:@"abcdefghijklmnopqrst"
andTokenUrl:nil
delegate:self];
[jrEngage setCustomInterfaceDefaults:customInterface];
[jrEngage showAuthenticationDialog];

I linked this code to a login button. I also provided the necessary JREngageDelegate functions, specifically jrAuthenticationDidSucceedForUser.

The application now starts up with a blank screen, and the user must select Login. In the login action function I make a call to the jrEngage library. This pops up a dialog and asks for an OpenID provider. I select MyOpenID and type my OpenID. I’m then redirected to the MyOpenID page and asked to type in my MyOpenID password. The result of this is sent back to the jrAuthenticationDidSucceedForUser function in my application. Here I verify that the user information that MyOpenID have sent back corresponds to a user who’s allowed to use my application, and I render my applications UI. To check the OpenId matches one of my users, I’d maintain a list of users for my system and the OpenId for each one. I can visualise how I’d set up new users; I’d take the OpenId information returned by MyOpenID (this contains an email address and an OpenID); I’d ask the user to sign up for my application, and send a validation email – maybe it would contain a secret code that they’d have to type into my app. I would not be holding any passwords, since I’d be authenticating people based on their OpenID credentials

© 2011 Derek Knight's Blog Suffusion theme by Sayontan Sinha