oDataiOS is a clean and simple oData library for the iOS platform! Finally, something to replace the existing huge monolithic OData4ObjC. The main driving force for this programming effort was the need for a futures / promise asynchronous programming-model to integrate with my TrackAttack app.
TrackAttack, like many operating systems, does not (by default) separate the thread which executes all GUI events, and a thread which executes all the code you write. Simply, if you are interacting with the GUI (say, updating a text-field), you must not only execute that on the main (GUI) thread, but also must do it quickly since you don’t want to block or slow-down any other necessary GUI events. Thus, all potentially-blocking work must be off-loaded onto other threads.
All of this is basic “App Programming 101” knowledge, so tackling the problem isn’t anything new. What’s new is the use of “promises & futures“: a simple but incredibly powerful solution, blowing all of my previous multi-threading programming experiences out of the water. The idea is pretty simple: you tell some sort of management object that you would like to execute several tasks (sometimes as simple as several functions), which may or may not have some inter-dependancies, and to pass on the results to a specific function you want. Essentially it’s a dispatching service, with the subtle twist that you only get what you need when you need it! Thus, you can dispatch work from the main thread, allowing the GUI to continue its work, and only when your dispatched work is completely done, will it intercept the GUI thread and insert new data.
Usually, spawning new threads and transmitting data between them has been a huge hassle, especially in native languages where there is nearly no true functional-language support (so kiss closures and lambdas farewell). Doing so with Objective-C is simplified, but locks are still required, which can lead to some horrible debugging sessions.
In the end, I was able to solve my problem (which was grouping up several blocking data-query calls for the oData interface) by mixing the powerful code-block execution manager in Apple’s Obj-C Foundation framework (named “NSOperationQueue“) and writing a high-level dispatch manager class.
The end-result is the first-draft release of oDataiOS! Currently it implements all of the basic interfacing methods for an oData server, but also allows you to do blocking and non-blocking (async.) calls. Though I’m still working on implementing a mode to allow dependency checking (currently, all commands are executed, even if there is parts of data never accessed). Since this is also a first-draft, quite a bit of the code is changing, but community feedback is always appreciated. My next big task I’d like to work on is inserting some more formal unit-tests, since there is a huge variety of tests that must be done to verify data consistency. Type-checking in oData is slightly inconsistent, since some oData services that run on top of a MSSQL database may have the same type-name, but different encodings. Regardless, the code is pretty flexible, and easy to read, so changing the code for one preference over another is a quick-fix.
On a final note, many developers who come from a strictly imperative programming language background may not understand how this is different from just launching your own threads and waiting for the threads to finish. In-fact, they are quite similar! The differences that make promises / futures powerful is that it is a clean and self-contained method of receiving the resulting data (no need to lock-down threads to copy data over, since it is implemented internally), and you never have to check for completion: you’ve already provided the code-block to execute upon completion, so you’re good-to-go!