Testing CoreData Migration is usually my last step before submitting to the AppStore. Typically I label my last successful released version in Mercurial, then when I’m ready to submit again I pull that source code into a different directory and run it in the debugger. This creates my old sqlite database. Then I can run the new code and make sure the migration is successful.
I ran into an issue yesterday though with my latest release where I didn’t have the right version labeled in Mercurial… so I wasn’t sure how to get a copy of the old sqlite database. After an admittedly lazy tweet, @ideal1st put me on the right track – “Download a datastore from your device, pop in simulator and run mapping model on it“. But I wasn’t quite sure how to get at the Application directory. A quick Google search later I found iPhone Backup Extractor. From there it was easy…
1. Download the existing app from the app store and run it
2. Take a backup in iTunes
3. Use iPhone Backup Extractor to grab the Documents and Library directories of my app which has my sqlite database file
4. Run the new code in the iPhone Simulator
5. Navigate to the Documents directory of the app in the simulator and replace its contents from what was in the backup
6. Run the new code again and verify the migration
Glad I did too. I had an issue where an attribute was getting an invalid type, but a quick look with SQLite Database Browser helped clear that up.
Hopefully that helps someone else. I’d love to hear better suggestions as well!
When I started writing Objective-C I had been in the C# world for years. The mantra that Exceptions are Exceptional was new to me. But after 2 years of Objective-C, the idea of writing @catch anywhere freaked me out.
C# developers get this wrong… a lot….
My favorite example that I ran into once while debugging another developers code…
This was in a commercially released product. Pardon the pun but that’s unexceptable.
But everything has its place. And since going back to helping architect and develop a C# webservice platform, we’ve molded a pattern which uses custom exceptions to handle bad things that we know might happen but allowing other exceptions to bubble all the way up to the “this shit is broken – fix it” level.
The platform uses the basic three tier approach – data level/logic level/webservice. The idea is that if any client developer using the webservice sees a 500 error from the webservice tier, then something we never expected happened in the logic or data tier and it’s a serious bug. Top priority fix. Pretty basic idea right?
In our code design we concentrated objects that will be used across multiple applications – be they service applications, web applications or even unit test projects – into their own library. We then added our our subclass of System.Exception. Now anywhere in the solution we know if the exception was something we created and should handle accordingly, or if its a bigger problem.
On top of that we added our own error code to our exceptions and documented what each of them means. They’re segmented into ranges just like Http Status codes and returned to anyone using the webservice in the headers of the response along with a detailed error message. You can run Firebug and see exactly why your request failed.
This approach also gave us the ability to correctly set the http status code to something a client application can understand. I’ve run into so many webservices that return HTTP STATUS 200 OK with an html body that says “400″. If you’re doing this, you suck.
With our approach we have a central place on each endpoint that returns the appropriate http status code with an error code the client developers program can recognize and provide the appropriate user feedback, along with a useful trace message the savvy developer can use to figure out what’s wrong.
It’s an “everybody wins” goal platform architects should strive for. It also saves on the technical questions as well.
We already have numerous developers building on our platform with minimal technical questions to our platform developers since its all relatively self explanatory. And as someone who would rather write code than answer questions… that’s pretty awesome.
Jazz vs rock…
Sounds come in the same tones
But never the same beat
Rock is structured
Life thrives on structure
Life diversifies in chaos
And that’s why I love Apple!
I hand my phone to the guy and tell him that the pictures it takes now are really blurry. I know its because the back is scratched to hell but I played dumb. He looks at the back and says “the back of your phone is scratched to hell, that’s why. I’ll replace that for you.” After gathering my info he disappears in the back for 5 minutes then comes back out and hands me my phone with a brand new glass back and my receipt for $0.00.
Lets see if you notice the difference…
Last week I had two people ask me for help with their Apple products (iPhone and an iPod Touch). Both were afraid to reach out to Apple Support because people told them it would cost a lot of money.
My iPhone 4 use to take amazing pictures. The pictures it takes now are horrible. I have an appointment at the Genius Bar tomorrow. Granted I have Apple Care on my iPhone 4, but I bet my experience is awesome… because it always is.
I’ve had iPods, iPhones, iPod Touches – even faulty video cards embedded in the motherboard of my Mac Book Pro – all replaced… for free… I walk out with a brand new piece of hardware that’s *exactly* the same software-wise as the one I walked in with… for free…
It’s not really free – you do pay the price upfront – but for the support experience? It’s worth it!
I’ll post tomorrow about how my appointment goes.
I’m looking forward to it. Not dreading it.