I think I’ve finally settled on the architecture that makes the most sense for data collection types of applications for the iPhone. I just do them in HTML and use the webkit control everywhere.
Of course I need access to sqlite and so I’ve found I can add new subclasses of NSURLProtocol to provide handlers to access different parts the local machine’s resources.
The first and most useful one I did works with urls of the format sqlite://database/table?a=&b=&c= where a,b, and c are field names. If this is used with a form that has its method set to POST, then a table that can hold all those fields are created and an insert statement is generated to save the record. The response is a JSON dictionary of the resulting record (done to provide the generated primary key back as well as any set default values).
If it is used with a form whose method is set to GET, then all the mentioned fields are fetched, and the ones that have values are used as filters. The response is again a JSON array of dictionaries. This makes a quickie search form easy, however I also look for a field named sql and if that is present, I just execute that as the query instead. Sometimes only SQL will do.
If the form method is DELETE, then the matching records are deleted. Since responses are JSON, using jquery is a no-brainer.
The entire NSURLProtocol subclass is about two pages of code and works with RAILS style form serialization naming conventions to allow saving/retrieval of hierarchies. It also uses ActiveRecord naming conventions and requires a primary key field of id on each table. The primary key is generated as a guid.
Works great. Dead simple. Don’t even need a server. I will be exploring this architecture more.