Editor’s Note: This was re-blogged with permission from IRL Gaming.
If you’ve spent any time building data driven applications on the Titanium Appcelerator platform you’ve probably had to deal with SQLite.
SQL databases (and particularly SQLite) are a great solution, but they can become a real pain when you’re prototyping or rapidly iterating the design of your application. Maintaining complicated databases schemas, figuring out indexes, and writing ugly embedded SQL queries can really slow down the pace your team works at and make your code difficult to maintain.
During the development of Zombie Hood this became a major issue for us as a team. SQLite proved to be unsuitable for a number of reasons:
- It was slow and difficult to constantly modify, re-index and deploy a new schema every time we changed the application or added a new feature
- Migrating data between versions of the app became very difficult
- Our data wasn’t secure – users with jail broken phones could basically change whatever they wanted whenever they wanted (and they did)
- Moving data between our MongoDB driven API and our SQLite driven application was clunky and error prone
After version 1.2 of the app went live it became clear that SQLite was a bad fit for us. After researching better solutions we finally decided to build our own NoSQL data management solution. It works great, we love it, and now it’s available on the Open Mobile Marketplace for iOS developers.
Checkout this screencast to see the module in action:
If you’re comfortable working with JSON, and you’ve had a quick look at MongoDB then you’re already up to speed on how this module works. We designed the system from the ground up to be:
- Secure – all data committed to and read from disk is signed so that it can’t be tampered with by users
- File Based – we didn’t want to run a server on the handset, so all data committed to storage is encoded as JSON and stored in flat files. This also means that all your data is portable
- MongoDB Compatible – we constantly shift data between our API and the user’s handset so JSONDB generates unique BSON Object Ids and MongoDate objects in accordance with the specification.
- Flexible – JSONDB had to allow us to combine query expressions, conditional expressions and mutation expressions in any order. We also implemented the DBRef spec to allow references to objects between collections along with dynamic object reference resolution.
- Single Context – single execution context apps are the only way to go in Appcelerator, so while JSONDB isn’t thread safe it runs in the same execution context as the app. This makes it lightning fast to perform queries and updates.
- Simple – we wanted to get rid of ugly SQL queries and make everything object based, very similar to the way MongoDBqueries work
- Geo-spatial Query Support – we needed to be able to perform geo-spatial queries on our data-set on the handset
So, let’s imagine an application where the user can add contacts to an address book, along with cartesian coordinates so that the records can be displayed on a map. A contact record might have a nickname, a full name, an email address, a phone number, and an address. We’ll also include some cartesian coordinates.
We could create a contacts collection and add a record as follows:
This creates a new contacts collection (or loads an existing one), creates a new record and commits it to storage. You would plug this into your contact management GUI so users can add contacts. Let’s imagine that your user has added a couple of hundred contacts to their collection and want to search through them to find John Smith based on his name:
This will return the first object with a name property matching “smith” ordered by creation date from oldest to newest. This is a pretty simple example, so what if the user wanted to retrieve a list of all contacts near them within a 1km radius ordered by nickname alphabetically?
Another example might be the user wanting to update all of John Smith’s records to set the phone number to 9090909 if the records were added less than a week ago:
Finally, if the user wanted to remove all records from their contact list that didn’t have phone numbers:
These are really just a few very simple examples of just how powerful this module is. If you’d like to know more check out theproduct page on the Open Mobile Marketplace or drop us a line at firstname.lastname@example.org.