A Novel Business Model

Here's a company that gives away their iPhone apps, but sells the underlying source code. Interesting approach, and I'm sure there is a market for good iPhone libraries and source code. The only shortcoming that I see is that there's no way to know how good the underlying code is. This company's apps undoubtedly look nice, but a pretty GUI is no guarantee of well-written code. The underlying code could be stellar, or it could be functional but disorganized and poorly written, and there's really no way to know without shelling out the cash. Unfortunately, the people who can benefit the most from code like this are the ones least able to distinguish between good and bad code.

That creates a bit of a catch-22 for the company. If they show people the code, it's hard to keep people from using it, but buying something sight unseen makes some people (like me) a little nervous. It's like buying a mystery bag, or playing the lottery, neither of which I would ever do.

If I were them, I'd probably try and get some testimonials from some respected developers - get a few people with some know-how to say "yeah, their code is good". I think it would make people more comfortable about shelling out cash to buy source code they can't look at first.

Note: I've heard from someone who has bought one of the source code projects, and the feedback was positive. This person said the code was "well organized" and "clean", though he hadn't had a chance to look at it in detail yet. That's definitely good news for the Tausendstern folks, and for their potential customers. I've decided to purchase the package and take a look for myself - I'll give a report here when I do.

SQLite Adventures

With the release of OS X 10.4 (Tiger), Apple gave us developers something pretty cool called "Core Data". Core Data is an ORM tool based (at least in concept, if not in actual code) on Enterprise Objects Framework (or EOF) which was NeXT's revolutionary tool for persisting object-oriented data to a database: revolutionary, that is, back in 1993.

Now, I don't mean to slight EOF or Core Data in that statement. Both are cool tools, and are vastly superior to embedding SQL calls to a procedural API in your object-oriented code. In 1993, strongly-typed languages ruled the desktop development roost and "web development" was yet to even really exist as a defined form of programming since, for all practical purposes, 1993 was the year the web was born¹.

 C and C++ were the indisputed champions of desktop application development and the arrival of Java two years later would cement the dominance of strongly-typed languages for quite some time. In 1993, weakly-typed languages had been around for a while but, for a number of reasons, were largely considered ill-suited to writing "serious" applications. NeXTStep's use of Objective-C was definitely an odd-man out in terms of desktop application development.

Things have changed quite a lot since 1993, though. Computers have gotten faster, dynamic languages like PERL, Ruby, and Python have become increasingly popular, and even most of the statically typed languages — including C++ — have gained some level of runtime introspection capability.

Probably one of the coolest approaches to object-relational mapping is the ActiveRecord design pattern. A good ActiveRecord implementation requires a dynamic language with robust type introspection which allows the object to dynamically add variables and methods to itself based on the contents of a database table.

But ActiveRecord, as cool as it is, is not ideally suited for desktop development with an embedded database because it is database table-driven. What would be ideal for embedded work is a sort-of "reverse ActiveRecord" where tables are created based on the existing attributes of objects. So, if you added a string variable to your object, it would know to add a varchar column to the table and would also know to save the contents of the variable in that column.  If there is a name for this approach, please let me know it; I've never heard one, but I suspect one exists.

Anyway, I do have a point here, and it has to do with the iPhone and SQLite. I realized yesterday while writing an article proposal on SQLite that Objective-C's dynamic nature would allow this theoretical "reverse ActiveRecord" idea to be implemented and, in fact, that it could probably be encapsulated almost entirely in a single abstract super class. Well, not technically abstract, because Objective-C doesn't support abstract classes, but that's neither here nor there.

Yesterday, I wrote a proof-of-concept version of just such a class. It has methods to create tables, insert, update, and delete data from the database as well as rollback to the last values stored in the database. It's capable of using foreign key relationships for one-to-one associations between objects and cross-reference tables for one-to-many associations represented in Objective-C by the use of arrays and dictionaries.

My code is still very rough around the edges and is definitely not production ready, but I think the concept is sound and with Core Data not being available on the iPhone, I think it's a great approach to avoid having to write tons of custom embedded SQL for each object. In fact, all you do is create a subclass, add instance variables and property declarations and you're done. You don't actually have to write any SQL to handle the persistence and there's even a mechanism to specify indices for your object's table.

I will clean up my code a little bit and put it out there for comments and feedback in the next day or so.

1 - Yes, I know that, in theory the web dates back to 1989 and in implementation dates back to 1990, but CERN announced on April 30, 1993 that the World Wide Web would be free for everyone to use, and that date (in my mind) marks the real beginning of the web as we know it.

Web Services Fun

Well, I got a proof of concept iPhone application working today. It's not ready to show off yet, as it's little more than a command-line application running in an iPhone window, but I was able to authenticate against a Tririga web service, pass in a username and password, then parse the results.

The iPhone does not have support for NSXML, unfortunately, so we're stuck using the procedural libxml api. Using libxml inside of an OO environment is like pulling teeth. It's a great procedural API, but compared to what you can do with a good high-level language, it's just downright ugly. I'm sure the performance is much better than NSXML, but the code it takes to use it is really, really ugly looking.

It took me longer than I expected, but I've now got the hang of using libXML, and have written a few utility functions to make my life easier. I may try wrapping it up into a low-overhead objective-C wrapper. If I do, I'll post the results here.

In the next day or so, I hope to have a full proof-of-concept iPhone app to submit a work request through Tririga.

Still Playing

I started working with the audio toolbox on the iPhone today. This morning, I added sounds to the little dice rolling application I've been writing. I recorded a total of fifteen sounds, five of a single die being rolled, five of two dice being rolled, and five of four dice being rolled. I let my kids roll the dice while I recorded the sounds, which they thought was cool, although they can't understand why I can't put the program on my iPhone. 

Do you hear that, Steve Jobs? You are making my kids sad. Do you really want that on your conscience?  ;) 

Unfortunately, the "Coding How-Tos" on the iPhone web site don't give a full code sample on how to play audio files. They show the command to play a sound, but not how to find and load the file from your application bundle (it may be in the how-tos somewhere, but it wasn't under the section on playing audio). Figuring that out took a little poking around in the documentation and header files (and, of course, a couple of application crashes), but I got it working without too much trouble. 

Boy, it's been a while since I've worked with pointers... I spent way too long working almost exclusively with Java. I don't want to bash Java - I know a lot of people like it, and it's been the basis for a lot of my income over the years - but it just feels so much less elegant than objective-C. 

Since I wrote my first AppleScript Basic program in 1980, I have used literally dozens of different programming and scripting languages, many extensively and as part of my professional life, and I can say that Objective-C and Cocoa (and now Cocoa Touch) are, by far and without a doubt my favorite. They take a little while to understand when you first start using them, but once you get over the "grokking curve" and really start to understand how it all pieces together, coding in objective-C really becomes a pleasurable experience. It's just plain fun. 

In a way, I envy all those people coming to the iPhone from other languages and toolset. They are about to discover something very, very cool if they have the patience to get past the initial obstacles.

An iPhone App

I really hate the chilling effect the NDA is having on the iPhone developer community right now. There is no mailing list where we can talk tech about this, or ask others for feedback, and we have been admonished not to talk about it even on Apple's official Cocoa-dev mailing list, where developers turn to each other for help with coding problems.

I understand, to some extent, why Apple is doing this, but given the fact that any Schmoe can sign up for an ADC free membership and moments later download the SDK, it seems a little overkill. I would fully agree and understand this if, like most pre-release software, the SDK was seeded only to Select and Premiere members of ADC, but since it's not, it's bordering on silly. It's like putting a notice on a bulletin board and then asking people not to talk about it. Except that Apple has a means of enforcing this edict, and it's one smart developers are not going to risk facing, since it will have a pronounced affect on their bottom line.

I may not be able to share the code or write a tutorial about how I did it, but I certainly can show you a screenshot of the little app I hacked out last night. This took me about two hours: a little less than one hour for the code, and a little more than an hour to take the pictures of the dice, crop and resize the photos, and make the icons.