A couple of weeks ago I was on the iDeveloperLive podcast speaking about AVFoundation. The actual conversation veered way from the nodes I’d made in advance and from what I had intended to cover so I thought it was worth publishing the notes which you can find below.
This post has moved to my new blog at http://swwritings.com/post/2011-08-12-lion-and-xib-internal-inconsistencies.
This post has moved to my new blog at http://swwritings.com/post/2011-08-12-xcode-developer-tools-group.
This post has moved to my new blog at http://swwritings.com/post/2011-08-12-backups-xcode-build-files.
I’ve just returned home from NSConference, a conference for Mac and iOS developers. Rather than recapping what actually went on (and Alex Blewitt has posted some excellent notes about day 1, day 2 and day 3 on his blog) I thought I’d offer some general comments and opinions which may help waverers decide if they want to go in the future.
Of the four data storage formats which Core Data on OS X supports some developers may use two: XML and SQLite. XML can be great when you are developing your application and want to have a look at what Core Data is storing whilst SQLite is more memory friendly and is generally used in shipping applications (the XML format is easy to read in a text editor but more memory hungry because it loads all of the data into memory). Note: After initially publishing this post I received some feedback on Twitter about the perils of using an XML data store. This is covered in a section at the end of this post.
If the initial development was done using the XML store the developer will at some point throw away the existing test data and reconfigure the NSPersistentStoreCoordinator to use SQLite and then stick with that format. Whilst third-party tools exist which allow you to examine the data in the SQLite data store it easy to toggle between XML and SQLite using Core Data itself. This not only allows you to examine the data easily but it also means that when you transition from XML to SQLite you need not lose any data, possibly important if you have alpha or even beta testers using your application.
One thing I mentioned in my original post about only buying eBook versions of reference books was that I was getting a Kindle so that I could read eBooks in the bath and that if I dropped it then it would be far less costly than dunking an iPad. Several recommendations and suggestions were made about how to keep my Kindle dry if the worst did happen, a popular one being to use a ziplock bag as propsed by Jeff Bezos. However a more interesting suggestion was one to buy an Aquapac.
I’m only going to buy electronic versions of reference books from now on and will attempt to migrate my existing library of development titles to eBooks too.
So why is this actually a challenge? The simple answer is that I love paper books; everything from the smell of a brand new book through to the beauty of a full bookcase and physically holding and working through a book is a wonderful thing. Conversely I’ve never got on with eBooks and have always struggled to read them across a myriad of devices ranging from a Psion 5 through to a current Mac. However, in theory, reference books lend themselves to an electronic format. They can be searched and annotated quickly and easily and are electronic books have no intrinsic size or weight of their own. I can take a whole library of eBooks to a coffee shop or away on a trip without a second thought.
Earlier today I saw a discussion on Twitter (summarised by Jonathan ‘Wolf’ Rentzsch on his blog) about a book called Programming with Quartz: 2D and PDF Graphics in Mac OS X. Having recently written some code related to 2D drawing and having struggled through some aspects of it I decided to buy a copy. However I also noticed that the book has over 700 pages and since I already have shelves of programming books and since they are getting pretty full I thought it was time to try something different.
Devices and Formats
A lot of technical book publishers make eBook versions of their publications available as PDFs. Some also support ePub book and of course there is the proprietary format used by Amazon’s Kindle.
I already own an iPad which gives me several options for managing and reading eBooks. iBooks and Stanza can be used with ePub files and PDFs whilst applications such as GoodReader and iAnnotate allow you to add annotations too. Amazon’s Kindle app obviously allows you to read Kindle eBooks. This pretty much covers all the bases and, initially at least, I’m going to use iBooks and the Kindle app.
On the Desktop and laptop I can read PDFs in Preview and use Kindle app for Mac for Kindle files. ePub files can be opened in Stanza for OS X but, to be honest, I found this a pretty poor experience. Fingers crossed that iBooks makes it over to OS X one day.
The Kindle apps take care of their own files once you’ve purchased them and you can download and store your eBooks on your approved devices from within the Kindle application on each device. One feature I really like with the Kindle is Whispersync which not only syncs your current location in an eBook across devices but it also syncs any bookmarks and notes and highlights you’ve added.
For PDFs and ePub files which are viewed in iBooks I’ll store the original files in the Books section of iTunes. The only real down-side to this is that double-clicking on a book in the Books section of iTunes does nothing. I’ve therefore created a small AppleScript [download] which will open a PDF or ePub file for me. I’ll be using FastScripts to access it.
There is still one problem for me. I love reading in the bath and often find that when I hit a coding problem a soak and a read of related material often helps me to clarify my thoughts. However there’s no way I’d use my iPad when I’m in the bath so, whilst it’s still an expensive slip if it happens, I’ve ordered a Kindle too. The Kindle also has the advantage over the iPad in that it is lighter, something I find puts me off doing a lot of reading on the iPad. I’ll report back on how I get on with it.