Category: iPhone Development

What I’m doing on my iPhone development project(s)

Today’s Discovery

If you have a Core Data data model with one Entity, say “AircraftCategory” that has a “to-many” Relationship to another, say “AircraftClass”, you can access the AircraftClass objects for an AircraftCategory using an NSMutableSet. But if you Fetch an NSMutableArray of AircraftCategory, and are doing a “fast enumeration” through the AircraftCategory objects, and you happen to remove one of the AircraftClass items from the current AircraftCategory object using one of the generated accessors, the fast enumeration will see that as a modification of the NSMutableArray of AircraftCategory and throw an exception. This is in contrast to Java where you would only get an exception if you were to add or remove things from the actual Collection that you were iterating, and not from calling setter methods on the objects in the Collection.

So instead of removing the AircraftClass from the AircraftCategory, I discovered that what I have to do is remove it from Core Data directly, using
[managedObjectContext deleteObject:aircraftClass];

I haven’t tried it yet, but I wonder if this wouldn’t happen if I assigned the fetch results to an NSArray instead of an NSMutableArray?

Why I find Objective C a hard language to learn

Lots of methods get an NSIndexPath as the argument, and all the sample code that I’ve seen gets the current row out of the indexPath object using [indexPath row]. Sometimes they get the section number using [indexPath section]. Ok, that seems simple enough. Now look at the documentation for this class, which is what you see if you use the XCode research assistant to show you the documents:

NSIndexPath Class Reference.

I cannot for the life of me see any way to extract the information that you get the current row using “row” out of that document. It’s not there. No, instead you have to figure out that UIKit has added some methods to NSIndexPath, and find ‘row” and “section” in a different document called “NSIndexPath UIKit Additions”. Isn’t that intuitive?

iPhone app

I haven’t written much about my iPhone app, but now that I have some time on my hands, I’ve put some more time into it.

I’ve been watching the Stanford iPhone course on iTunes U. They had a couple of successful iPhone app developers come in to give lectures, which were very useful. One of the things that stuck with me was an insistence that you prototype the user interface. They recommended sketches, but my sketches are horrible so I decided to try Photoshop. I grabbed this Photoshop template which is really great except it’s missing some important UI elements, like the symbol that looks like a “Do Not Enter” sign that iPhone apps use to indicate “delete this element”. In spite of that, I managed to mock up some screens, get some feedback, try running through a few scenarios, etc. You can see my current iteration on my gallery. Keep in mind that I don’t think I’ve got the correct fonts or font colours for the standard iPhone UI, but I mostly did it for looking at layout and program flow.

As well as that, I was working out the data storage, including the SQLite tables and stuff. I was trying to figure out how to get the lazy load the data and only keep what I need in memory. That’s when I started reading about the 3.0 software and the Core Data API. It seemed like exactly what I need, so I paid my registration fee and downloaded 3.0 to see if it will be as useful as it appears. One unfortunate side-effect – all the code I’ve typed in from the iPhone book I’ve been working through has tons of “setText is deprecated” warnings. Oh well.

iPhone progress

Things aren’t going as fast as I’d like. I finished the Apple “The Objective-C Programming Language 2.0” and “iPhone Application Programming Guide” documents. I’m about half way through Phone Human Interface Guidelines” (which I read at lunch) and also “Beginning iPhone Development”, which I read at home because I need to work through the examples.

I have a mental picture of what screens I need and what controls they’ll have on them, so I’m wondering if I shouldn’t just go into Interface Builder and build the screens. That might at least give me something to show off.

Is it just me, or is Objective-C a weird language? I find it annoying that I have to declare a variable and then give the exact same declaration in the @property statement, for instance.

More requirements

Some more utterly blue-sky long term goals for the app. Some of them depend entirely on what the phone can do, and I don’t know if it can or not yet.

  • Attach a photo from the library as an icon for the aircraft. Maybe for locations as well, and/or a link to the Maps application. Link people (other crew and passengers) to Contact app, so you can display a picture, and even look up a phone number to call them to go flying!
  • Import from google docs – or a server to do it if the phone can’t. Or maybe direct import from a SQLite database through iTunes? Don’t know – just need a way to get hundreds of records from a previous log book like AvLogBook.
  • Carry forward totals from previous log books.
  • Checkpoint and export – everything before a certain date is exported and deleted, and running totals (ie carry forward) updated.