Carnets de bord

Canappi's Data Binding Framwork allows you get  data from a Web API and effortlessly bind it to your UI.

For instance, getting a Twitter feed and binding it to a table is as simple as that.

The core of the Canappi's binding framework relies on a simple assumption. Good Data is simple to bind, so what we do is to reify data formats to a simple set of rows. Yes, wouldn't the world (of software engineering) be a lot simpler if data was (mostly) flat?

In XML, that would amount to:

<collection>
     <row attr1="value1" attr2="value2">
        <key3>value3</value>
        ... 
     </row>
</collection>

I of course reify elements and attributes in a single dictionary for each row. So the reification algorithm is quite simple, I generally ask for a couple of values in the connection definition: which one is the collection element, which one is the row? I can go arbitrarily deep.

In JSON things are a bit more complex, I found it a bit harder to identify where the "array" is. Here is my reification algorithm, first I identify where the rows are, then I flatten any subdictionary (and I ignore for the most part subarrays):



You know what? the life of the data binder would be a lot simpler if API designers would also support a "mobile friendly" format which in JSON could look like:

{
    "collection": [
        {
            "row": {
                "key1": "value1",
                "key2": "value2"
                ...
            }
        },
        {
            "row": {
                "key1": "value1",
                "key2": "value2"
            }
        },
        ...
    ]
}

What's the point of arbitrarily nested data structures?

So I'd like to share my Algorithm, you can dowload a adaptation of the SBJSONParser on Github.

This is how you use it:

    url = [NSURL URLWithString:endpoint];

    ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url];
    request.requestMethod = @"GET" ; 
	
    [request startSynchronous];
	
    NSString *response = [request responseString];
	
    // Canappi tests for JSONP and removes it first
    // See generated code
    
    id data = nil;

    SBJsonParser *parser = [[SBJsonParser alloc] init];
    //Get a JSON object	
    id parsedData = [parser objectWithString:response error:nil] ;
    
    //First find the array, then flatten the rows, to get an array or simple key/value pairs dictionaries	
    data = [parser flatten:[parser findArrayForElement:@"collection" andRow:@"row" wrapped:NO in:parsedData] forElement:nil]  ;
 

Canappi also provides the ability to "join" two API calls and simply merge both set of rows in the same data structure.

So this post is a plea for API designers to give mobile developers the data structures they need to simplify the data binding process. There is simply no value in doing otherwise, just incidental complexity.

This is possibly a world record: I tried to fit a Canappi app descriptor in a tweet, in less than 140 chars !! and it works. Who can do better? or simpler? Here is the file. You can generate the iOS and Android app here, after registration.

Interface Builder is one of the most amazing software ever written. After 25 years (and hardly anything added to it), it is still relevant and still a GUI designer far ahead of the competion. Just let me know if you know any other piece of software that was designed 25 years ago and is still relevant today, pretty much unchanged.

When I discovered IB in 1990, I was in owe. Not only could you build incredible GUIs effortlessly (at least for the time), but IB was also an Injection Dependency Framework more than a decade ahead of Spring. It forever set the tone of my career, anchoring it in the model-driven world, building software that builts software.

That being said, I built Canappi to address a number of shortcomings which would be expected since IB was never designed to build mobile solutions and to a large extend it shows.

1. Canappi's mdsl describes the entire application in a single file: XIB files have all kinds of granularity and are generally loaded individually at different locations, directly from the code. It makes it quite dificult to have a comprehensive view of the application.

2. Canappi introduces the concept of Layout, as a set of controls, which can be reused across different views: IB does not allow you to reuse groups of controls easily, this has to be dealt in code, not at the view definition time.

3. Canappi offers standard actions (call a number, send an email, navigate to a view, present/dismiss a view...): IB doesn't have any notion of standard actions, in particular navigation actions, so you have to go back in code to implement things that could be easily dealt with at the model level, in the GUI definition

4. Canappi has introduced the concept of stylesheets: IB does not have a simple way to reuse a set of properties across the definition of several controls (TextField, Label, Button...)

5. Canappi's programming model include Web API definitions which can be bound to layout and actions: How many mobile apps need to talk to some kind of Web API? Unfortunately IB, which was build 25 years ago, knows nothing about them. With Canappi you can create a client view of a Web API (Connection), and bind operations to individual layouts, including tables and actions. Canappi generates the code to assemble the Web API request, parse the response (XML or JSON) and bind it to the controls of a View.

6. Canappi's can easily specify the layout of a table: When you drag and drop a table in a XIB file, you get, a table. You have no way to declaratively define what the table row is made of.

7. Canappi defines the whole wiring of an application, from Splash screen to Menu to every aspect of Navigation (navigation bar, navigation actions, dialogs...): Apple recently added Storyboards, but that mechanism doesn't scale very well if you application is more than a few views.

8. Canappi makes the process of designing Universal Binary easy, you can define both the iPhone and iPad layouts. Each layout is independent of each other which allows you to define different navigation schemes as well (of course the remainder of the definitions are shared between the two: connections, styles, ...): IB knows nothing about different form factors running the same application. Again, 25 years ago, this was not a common usage pattern.

9. Canappi has a much richer palette of controls: Graph (Core-Plot), Gallery, RadioButtons (yes IB doesn't have radio buttons for iOS), Button Triggered Pickers and Date Pickers, Video Player, ...

10. With Canappi you can use Interface Builder to create Android layouts. We convert Interface Builder files into mdsl, which can be used to generate both iOS and Android applications.

Canappi's mdsl is also a textual language which you can easily version, compare and merge, even create libraries of resuable application definition. IB on the other hand is a graphical tool which is ideal to position controls on a view, but far less than ideal to manage an entire application.

In fact, mdsl, Canappi's programming model, is so complete today that you can now write entire applications from it, something that is impossible to do with Interface Builder. This app was built with 700 lines of mdsl and less than 50 lines of custom code.

Data services are often an essential part of mobile solutions. It can be pretty tedious to manage a data access layer (say written in PHP) and a database schema (say MySQL).

Over the past few months, we have built a number of prototypes and a fairly large scale project that is about to go in production using MongoDB hosted by MongoLab.

What we noticed is that all we had to do was to create a collection for each entity and everything else would happen in mdsl. I must admit this was a nice side effect of mdsl, not necessarily something that I had designed for, I was simply exploring what you could do with MongoDB. Of course, this works well for CRUD operations since there is no data access layer per se, but still, it seems to fit lots of mobile solutions like a glove. The freedom of not having a rigid schema and the ability to add attributes and rows by hand as needed makes a big difference when you are building a solution: all the boiler plate code that keeps the client, data access layer and schema goes away. I cannot emphasize enough how easy and fast developing a connected a mobile solution becomes.

Here is a typical mdsl connection definition to a MongoDB database:

The first operation fetches the entire collection of patients (of course not very realistic). The createPatient operation POSTs a new patient to the patients’s collection. The JSON body is constructed  automatically by the generated code within a “row” element as shown on the right.
Canappi’s knows readily how to create, read, update or delete these types of record.

The third operation, getPatientByEmail, implements a very simple query, using MongoDB query language and assuming the row element name is “row”. Here is what the resulting json document looks like in MongoDB, using the MongoLab console:

Here is how a join between two collections can be defined, assuming an event has a foreign key, itemid that points to an item detail document:

That's it !