Seeking Serendipity

Not finding much to match this error message from Google, I am posting this:

I had cause to generate a new version of a CoreData model (xcdatamodel -> xcdatamodeld) and although I was able to happy rely on the automatic model migration when on device, it repeatedly crashed on simulator. The message was:

2010-08-27 16:44:12.566 WildObsLookout[47240:207] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Bad model.  For entity 'WildObsSearchHistory' superentity 'Account' does not think I am a subentity'

Crazy thing was … I didn’t have any such entity, all mine were prefixed with WildObs.

Turns out this code (not sure where I grabbed it from) was being over zealous on simulator:

NSMutableSet *allBundles = [[[NSMutableSet alloc] init] autorelease];

[allBundles addObjectsFromArray: [NSBundle allBundles]];

[allBundles addObjectsFromArray: [NSBundle allFrameworks]];

managedObjectModel = [[NSManagedObjectModel mergedModelFromBundles:[allBundles allObjects]] retain];

The fix was to only load the models I wanted and hand merge them:

NSString *modelPath = [[[NSBundle mainBundle] bundlePath] stringByAppendingPathComponent:@"WildObs.momd"];

NSManagedObjectModel *model = [[NSManagedObjectModel alloc] initWithContentsOfURL:[NSURL fileURLWithPath:modelPath]];

There is no doubt a better way to load only my *.mom files w/o picking each one individually, but I’ll look for that when I get to version #3. I hope this helps somebody.

This is an add-on to Dave’s posting on ._ (dot underscore) files and CodeSign errors (see http://shortpath.blogspot.com/2009/07/codesign-error-and-fbconnect-library.html.) My problem was different, but started with repeated:

“The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate.”

Note: I wasn’t able to compress the file using find (I suspected coincidentally, although now I don’t believe it. I got that common error of a few K instead of the expected Megabytes) so I was forced to use command line zip. Normally after a few tries the compress works and gives a good result, but this time it didn’t.

I’ve been shipping these binaries (from these configuration files w/o change) for a while now. I did the usual; exit/restarted XCode, double checked the project settings and active target settings, reviewed the Build Results log, even flushed XCode caches and (God, it felt like Windows) doing a machine reboot. Nothing helped. Google searches told me that Application Loader might give some useful error messages.

I started using the “Application Loader” and got the message:

” a sealed resource is missing or invalid codesign_wrapper-0.7.3: failed to execute codesign(1)”

Anyway, trying everything I could for a couple of hours and after reading Dave’s posting, I ended up doing a clean SVN checkout to a new location, deleting all .svn subdirectories (find . -name \.svn -exec rm -rf {} \; -print) and attempting again. This time things worked fine.

Note: I could easily compress using find’s “compress file” and didn’t need to manually zip. Further I was able to use iTunes Connect and not need Application Loader.

As others have said, this was very frustrating, and I hope this helps save others this pain.

I am a Brit. I came to the USA a decent while ago, lured by the adventure of something new (okay and skiing/apres-ski in Killington, Vermont one year when the snow was good.) I’d gone from smallish country town boy to living in London, to traveling around Europe, working in Asia/Africa and living in Hong Kong. Why not see what the USA had to offer?

Computing has been good to me, I’ve traveled far & wide through it, and I got hired to work on financial data distribution for Wall St (networks, multicast messaging, etc.) 

After a few years on the east coast my wife (then girlfriend) brought me out to Colorado and I instantly fell in love with the mountains. We moved here shortly afterwards. We’ve mountain biked, skied, snow boarded, snow shoed, hiked, backpacked, camped and enjoyed Colorado significantly. The climate is amazing, the scenery inspiring, and the potential for adventures endless. 

I live “in the mountains” in a small community up Coal Creek Canyon (technically a Golden address, but my county it Boulder. I am up/behind the Flatirons.) It took folks a while to get used to me (I was harder to understand when I got here, I spoke too quickly for most) but at the end of the day “folk are folk”, and folk here are good. They might not be townies (a freer spirit in many ways) but that is part of why I love this community.

Being on the fire department for over a decade I’ve helped/connected with many neighbours. I’ve stood shoulder to shoulder with impressive fire-fighters, and seen some things I never expected to. Running the community website I get to learn about topics folks care about, and the great efforts they are making. All good. I may still speak funny, but I feel part of this community.

I’ve lived here a while now, but I still get a kick out of every day. The two foot of snow we just had in a day, the Turkey/Elk that cause traffic jams, the mountains that inspire. Driving on the wrong side of the road (most of the time.) 

Boulder is a wonderful city; with a university culture of learning, a gentle approach to the planet and an appreciation for it’s glorious surroundings. A quick jaunt down flagstaff and I can get culture, play time, good food & entertainment. If needed, Denver is not so far away. Boulder is a great balance; small enough and yet big enough. 

For this Brit, Colorado is my “big skies” and Boulder is my home base for that.

Links:

• Coal Creek: http://www.coalcreek.com
• Coal Creek FD: http://coalcreekcanyonfd.org
• Elk/Turkeys: http://wildobs.com

Here are a some of bugs/things I found after the application had been released to adhoc (beta) users. All good reasons to spend as much time in this phase as possible/neccessary:

1) I failed to ‘retain’ a property that happened to be the one locating the website. It seemed to work at start-up but (for many people, any people who had not gone into Settings to make edits which somehow made a difference) it did not after that. In short, the application failed to connect back to http://wildobs.com. Big bad bug.

2) My ‘pretty’ (ok pretty w/o quotes, they are nice nature shots) splash screen was a copy of my about page; aspens with some text over it. I knew what it said, and it looked fine to me. To new users, they couldn’t read the text in time and were left confused.

3) I believed that code in applicationDidFinishLaunching: would be called before viewDidLoad: on any views. *wrong*. Views loaded from the MainWindow.xib (and for a tab layout that can be a few) get loaded simultaneously (perhaps even before.) I started getting reports of random crashes in initialization code. I ended up moving all my initialization code (properties, databases, application-wide data) into a singleton (see Apple site for instructions on how to create one of these) to protect this. Cost me a few hours of re-work and global search/replace but now I know it I’ll design future apps this way.

4) viewWillAppear: does not get called on views loaded from NIB directly into view; i.e. it only get called when another view goes away to reveal this. Important ‘cos I’d tried to fix (3) with some of this, hoping viewWillAppear: would happen after applicationDidFinishLaunching:.

5) I was using <BACK navigations as a “cancel” when they are truly just a “back”. I removed buttons (like ’save’ and ‘done’) simplifying and making more correct against  the HIG, no doubt. Less is more.

6) If you don’t retain the CLLocationManager (keep a reference in your own code, e.g. as application data) you’ll probably not get updates from it. Doh, kinda obvious but it happened. Testing on an iPod Touch (long story), and using the simulator, really doesn’t help navigate the complexities of receiving location information. Sure, they code is there, but you need the stream of data. [For example, I never expected to have to ask the location manager to stop trying after it reported failure to get a location. A never ending supply of pop-ups was not what I had hoped to present to the user.]

7) Numerous small bugs based on my account/test data being more well troden than others, and sometime environmental (divice) differences. Other users had empty WildObs lists, or fewer lists, or any number of different sets of data. Those differences caused different code path.

8] My initial release would not even install due to issues documented here: http://neukadye.com/blog/2009/02/19/installing-adhoc-beta-iphone-applications-via-itunes-on-microsoft-windows/

9) Data stored in an sqlite3 database was getting corrupted (cross-wired.) I learned to use sqlite3_clear_bindings as well as sqlite3_reset on statements I planned to re-use. See this: http://www.sqlite.org/c3ref/clear_bindings.html.

10) Much as the installation/start-up experience is increasingly minuscule over the lifetime of an application, it is critical for that first impression. For an application like WildObsObserver (that needs an account, then downloads data and images before it can be used) there is a lot going on at this installation time. Simplify, simplify, simplify. Spend as much time here as you can…

Not only did the adhoc testing uncover bugs and issues, but it *far more importantly* it revealed how others saw the application I’d built. Seemingly small issues that I’d grown oblivious to could be big issues to new users. Things I was sure were obvious to users, were not.

I cannot thank the users enough for how they progressed this application.

Yesterday I started a simple application and decides to utilize FMDB wrappers sqlite3. Why?

• sqlite3 function calls are low level C, and binding between Object-C types and these C function calls is a little cumbersome and ugly (converting to/from UTF8 string and such.)
• The more code, the more clutter/change for bugs & maintenance headache. Less is more.
• I found myself effectively cut-n-pasting sqlite3 calls (init statement, bind args, call, reset statement) and as such it was crying out for a wrapper.

Here are some useful links for FMDB:

• The developer’s blog posting: http://gusmueller.com/blog/archives/2008/03/fmdb_for_iphone.html
• All the Flying Meat code (FMDB plus others) http://code.google.com/p/flycode/
• Where to get the code: http://flycode.googlecode.com/svn/trunk/fmdb/src/

I couldn’t find a pre-built library, or a project to build a library, so I ended up checking out the source from SVN and inserting the few classes into an FMDB group under my classes. The file to not include (’cos it holds a main) is fmdb.m. This is good sample code/documentation.

BTW: Don’t forget to add the “Other Linker Flags” setting -lsqlite3 to bring in sqlite3.

Based on my brief experience with it, here is my initial review:

Pros:

• I like how simple it is to use, a nice Objective-C wrapper to sqlite3’s C API.
• I like the simple the interface to create/bind statements & result sets.
• I cannot believe there is significant performance overhead in this simple wrapper. (Yes, one access columns via name not position, but that is minor & developer friendly.)

Cons:

• Not sure how thread-safe it is. Code like [db do_something]; if ([db hadError] ) seems risky for anything but the simplest application. Maybe on iPhone this is not a problem, but feels wrong.
• What I really want is an “ActiveRecord” like implementation. Not fat/bloated, just simple binding of objects (using introspection, whatever) to/from database rows. I needed to add this on top and (as such) didn’t gain much from using FMDB verses sqlite3.

Things I’d like to know:

• I wish I knew how to get the last index (the auto-incremented primary key) of the last insert.

Summary:

I’ll keep using this for this application, and will keep an eye out to see if it develops, but I’ll also keep an eye out for other wrappers also. It seems there are a bunch of Objective-C wrappers to sqlite3, I need to see if some are iPhone friendly:

http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers

Since the web page I used to give out for this seems to have gone away, here is the information:

A (unique) device identifier is required (by Apple) to allow adhoc (or beta) testing of applications; the developer builds the version of the application provisioned for a given set of identifiers. This is mechanism is how Apple allow developers to release an application to a small (<=100) set of users before going through App Store submission.

The mechanism for getting the 40 character hexadecimal device identifier is somewhat obtuse.

• Connect your device to iTunes
• Select the device, and view it’s “Summary” information (the first tab)
• Click on the “Serial Number:” label to see it change to “Device Identifier:” Note: This is the obtuse part … it is the “Serial Number:” label you click on. No visual indication is given that this is possible, you just have to know (hence this posting.)
• To copy-n-paste the device identifier double click it (it will not show as selected) and CMD-C to copy and CMD-V to paste into (say) an e-mail.

Serial Number Mode

Device Identifier mode

Note: I have been told…

• This does not work whilst iTunes is downloading content.

Note: If you are a developer and you have XCode/Organizer you have a far easier way to get the device identifier.

I attended iPhoneDevCampCO #3 on Saturday, and was pleased to see a bunch of new as well as old faces. Joe Pezillo (aka Metafy), Danny Newman, Kendall Gelner, and bunch of other good folk.

Many folks were there to learn about iPhone Development, some to learn about iPhone Developer marketing (how to promote one’s app), and some to meet developers. As with many of these meet-ups the energy/enthusiasm was high, and the hopes for what iPhone Development will lead to … higher.

Before index titles

After index titles

For me, once again, the best part was meeting other folks and watching them work/seeing their work. Watching Bruce’s walk though on sqlite3 (from his Bible App) I learn about UITableView index titles (the contacts-like A-Z index down the right side.) Sure I’d read the class documentation, and reviewed the samples, but seeing another developer do it quickly helped me learn this simple capability. Nice free side-effect. The serendipitous aspect of such camps/meet-ups is an important benefit for independent developer solopreneurs.

Before I’d left the event I was able to get a generic set of utility classes built into my WildObs Observer application for all list views, with alphabetic and date indexes. I’d gone with the hope to find “ways to polish a functional app” and this definitely fits that category.

I wasn’t able to access Twitter during most of the event (I half wondered if Danny had blocked the DNS entry for productivity benefits so I wasn’t able to share as much as normal. Also, having been doing iPhone Development full time for a while now, less was shiny and new. Perhaps the most important thing to share is the attendees themselves. Any attendees wanting to share Twitter accounts, perhaps tweet using #iphonedevcamp.

I wish I could’ve stayed longer and had more of a general question and answer session. I would have really benefited for a group discussion around this view issue I’d like insights into. As time goes on I think we need to branch off iPhone newbie presentations at the DevCamp and separate our more group working sessions.

Thanks again to the organizers of this event.

First a shout out to the blog posting I followed when I was performing this for the first time:

Craig Hockenberry, Beta Testing on iPhone 2.0
http://furbo.org/2008/08/06/beta-testing-on-iphone-20/

Then some additions/re-emphasis:

#1When Craig Hockenberry says:

Now that you have setup the entitlements, you’ll want to create a new configuration for your beta builds. I found it easiest to make a copy of my existing App Store distribution configuration and change the code signing setup:

1. Make sure that you new beta configuration is the Active Configuration. Xcode has some problems if you try to modify Code Signing parameters on a configuration that is not active.
2. Use Project > Project Settings to open the build settings. Change the “Code Signing Provisioning Profile” to be “Any iPhone OS Device” and then select the name of the provisioning profile you chose in the Program Portal. If you don’t see the name listed, make sure that the .mobileprovision file is located in ~/Library/MobileDevice/Provisioning Profiles and that the “Code Signing Identity” is set to “iPhone Distribution”.
3. Use Project > Edit Active Target to open the target settings. Change the “Code Signing Entitlements” to be “dist.plist”.
4. Clean the build and you should then be able to build a beta release.

Xcode can get confused when changing provisioning and other code signing settings, so don’t be afraid to quit and restart to get things synced up.

follow these instructions to the letter. Especially on step #3 use Project > Edit Active Target and NOT Project > Project Settings … or you’ll find yourself shipping a development version of your supposedly adhoc (beta) build. When Craig says Xcode gets confused that is right, it might display that you’ve set these settings for the project at your new target’s “level” (i.e. for it only) but the build doesn’t seem to work that way. So (1) set the adhoc build as the currently active target then (2) edit that active target.

Tip: When you’ve done your build look inside the build directory at the embedded.mobileprovision to ensure it is your distribution one, and not your development one.

#2When Craig says:

Xcode can get confused when changing provisioning and other code signing settings, so don’t be afraid to quit and restart to get things synced up.

I had to. Organizer was complaining about the provisioning file, and (sorry) but I don’t recall the error message it gave. Something about the provisioning profile not having an associated certificate or something. I did an online search and received lots of complex ideas for solving it, and in the end a simple exit/restart of xcode was what did the trick.

#3To install the adhoc application on Windows:

Initially none of my beta testes could get this working. They could install the provisioning file by dragging it over the applications pane on iTunes, but never received a “+” (plus) for ‘ok to drop’ sign when they dragged the WildObsObserver.app folder (unzipped from WildObsObserver.app.zip) over the same place.

It turns out that inside the WildObsObserver.app folder was another WildObsObserver.app folder (parallel to an underscore Mac directory) and dragging that folder works. Some quirk of ZIP on Mac verses ZIP on PC? Whatever, that inner folder is the one you want.

Tip: I’ve found that the finder option to ‘compress “WildObsObserver.app”‘ option occasionally generates a corrupted (and way too small) zip file. Ensure the ZIP file size is within the ballpark of the original application.

#4 I’ve found that adhoc applications seem to get a generic logo when shown in iTunes, yet the real logo shows when the application is installed. I’m told that this is not a problem when deployed via the app store, so ought be a cosmetic issue to ignore. [Let me know if you know otherwise, please.]

Good luck beta testing your iPhone applications…

I recently switched to a Mac platform (for pleasure) and started developing on it, and even more recently started iPhone application development. I’d never seen (or heard of) xcode, cocoa, and those things. I’ve found the experience at times trivially easy (e.g. download/run/launch a sample in seconds, then learn from it’s code. Awesome) and sometimes frustratingly painful. Knowing what I know now, and wanting to help others avoid some of my mistakes, I’m planning a few simple postings.

Here are some tips I have for the newbie starting out:

• Do bookmark and visit/re-visit the iPhone Dev Center. It is the place to start.
• Do spend time on the Apple getting started videos, even though they do only scratch the surface. You need to get into the mindset that is iPhone before you start developing, and these videos help.
• Find screencasts and/or  people to watch. I learned more useful tips (configurations, tool, keyboard shortcuts) by watching Kendall & Joe develop at iPhone Dev Camp, than I did from documents (however well written.)
• Download and run/learn from the Apple Samples on the iPhone Dev Center. They are great. Not every one gives you perfect real-world examples but they help enormously.
  • UICatalog — examples of useful controls/transitions. Invaluable.
  • SQLiteBooks — sqlite, for those who want hand on DB examples. A bit bloated (with dehydration) but a solid. That said, I hear there are abstraction layers now.
  • GLPaint — good ’shake’ detection, and sound effects.
  • I could go on, I’ve downloaded 20 or more. Thank you Apple Developers.
• Pick your style of application (e.g. utility one pager, tab based) carefully because what it sets up for you (including MainWindow.nib) is not fun to re-work. If you decide to change consider starting a fresh app and bringing in your existing code. [I went from non-tabbed to tabbed and got cranky w/ Interface Builder in the wasted hours that ensued.] This advice is good for Interface Builder editing also, especially when adding tabs i.e. delete and start a fresh tab don’t hack one.
• Become comfortable with Interface Builder. Let me repeat that, no  increase it … conquer Interface Builder. It is your best friend, so long as yo don’t allow it to become your nemesis. My bad days were often spent ‘cos I hadn’t. It can be awkward at times so learn it’s quirks, and learn how to work happily with it. This excellent tutorial helped me: iPhone Interface Builder Tutorial.
• Find other developers. Watch them, develop along side them, learn by osmosis. When your app is crashing (and it will) talk it through with somebody else (including your dog) it’ll likely help.

Some random comments:

• Take time to learn Objective-C. It is C with more, and not C. It is C++ with less, and not C++. It is it’s own beastie. I’ve come to like it (I am glad it now it has @properties) but it isn’t like other languages and needs you to convert to it’s way of thinking.
• Learn the rules for when to release an object. Learn retain/autorelease/release & be comfortable with them … before you do too much. You don’t want to be chasing memory leaks/memory corruptions. [My simple understanding of autorelease is that the object is released once that events stack unwinds to the top, and the thread goes back to a waiting state. Meaning it is there for a brief period, so if you need to stash something on a longer lived class (e.g. a view) remember to use retain & release in the view destructor. @property (retain) is your friend here.
• You can (and usually do) have properties of the same name as the variable. Using self.x calls a property (and will do automatic release/retains for you if requested) whereas x calls the variable, and does not. Big difference.
• Put a global breakpoint on objc_exception_throw, it'll give you a view of the stack before the crash occurs (i.e. as exception is being thrown) which is helpful for debugging.
• Learn OPTION/COMMAND/UP ARROW to go from the implementation (.m) to the declaration (.h).
• Visit the online class documentation when you work, it is well done.
• Utilize completion via ESC, it helps you learn the available methods (messages you can send).
• Create a view (controller) in Interface Builder, create the view controller classes, then immediately go back set the File owner as this class (COMMAND 4) and then (as immediately) set the view outlet on the file owner to point to the view. See the above tutorial. Forgetting to do this causes confusing crashes when you use the loaded view/view controller.
• Never create two .NIB files with the same name in different groups. I did (by accident, one was empty) and I suffered with random crashes (in some cases the empty one would load.) Ugh, that cost a day or more & was miserably to debug.
• Start simply, stick to UI classes, avoid things like threads until you've made good progress on the UI. I didn't, and had random crashes for a long time until I removed that code. Background threads can wait, leverage the existing Threads/Run Loops the I provides (e.g. your main loop.) KISS.
• Go look at the UICatalog sample (run it) when you are designing your views.
• Avoid UIButton and use the Apple build in icons/buttons and UIToolbar. Much nicer effect.
• Create a Default.png splash screen for your app by taking a screen shot with Organizer once it is running. [I created my about page as a Model view, with no buttons but touch to hide, so I could screen shot it.]
• When testing “shake” add a sound effect so you know it is occurring (even if your code does not show it yet.) Otherwise, like me, you might inadvertently try to hard and launch the device across the desk. Ouch.
• Don’t ever (by mental slip) unplug the cable to the iPhone when you are installing an application, or (if you are unlucky, like me) you’ll have to spend the next period wiping it, restoring backups, and other non-fun stuff.
• Do spend a lot of time on the Apple site (and Apple forums) but don’t forget to Google, and visit sites like Stack Overflow. More and more helpful content is coming out.

So, if you avoid the traps/pitfalls, have fun.

Please feel free to let me know if there are glaring mistakes in this. Remember, I am a newbie at this.

Here is what I am having fun developing…

WildObs Observer iPhone Application

This evening I attended the TechStars first HackSpace. Thanks to the kind folks at TechStars for hosting, and Gnip for feeding.

I saw a lot of computers and some studious activity, but wasn’t sure how much coding was achieved. Some corners seemed heads down, but with roughly 50 people in the room the easier opportunity was for socializing.

I chatted with a few folks I’d met before (e.g. at iPhone Dev Camp) and then met some new ones. What I found fascinating was their ideas, their apps, their sites. What they were doing was more than just interesting to me, it helped me fit my thoughts (and a few feelings) into place. Others with hopes for a site, intentions for an app or plug-in. Progress, lessons learned, challenges. Having fun and serious business. Being amongst others in similar situations was powerfully ‘right’. I learned more than I suspect I realized.

I had a great evening with wonderful people & am grateful for the event.

But, I couldn’t easily walk the whole room and check out what was occurring (I’m not the party crasher @penguin is ;-)) and hence I didn’t learn from everybody in the room. I didn’t learn all the projects, and maybe I missed some ones I’d have stopped and coded for. I didn’t know who was looking for help (if anybody) and who was offering help. What I’d like to see for the next one is this:

• A consistent Twitter hashtag for the next event (#hackspaceboulder was too long, some used #hacknite, some #hacknight but both lacked location.) Perhaps propose a short unique tag with the announcement.
• Folks to post (tweet/blog/whatever) their intention to attend, but also mention their project and their needs/wants. e.g. Anybody interested (or experienced with) OAUTH for Rails want to blah, blah…
• Folks to post their learnings (the serendipitous insights that spring from the conversations.) During and afterwards.

Again, great event, thanks…