Building Carousel: How we made our networked mobile app feel fast and local

For more on the subject of "optimistic interactions", check out Luke Wroblewski's post from July of last year on getting the Polar app to feel super-responsive: http://www.lukew.com/ff/entry.asp?1759

Super interesting, but for the enterprise software crowd I don't think those lessons be applied 1:1, the complexity of such a solution in enterprise apps will be higher.

Why?

Conflict resolution is costly and if coupled with a delay can be irrevocable. This means you need as much data validation and associated business logic offline in your app to prevent the user from even saving wrong data in the first place.

Some customers will want their users to work disconnected during their whole work day to save on data costs. Again, think global, data plans are not the same between the US and Brazil, for example.

Even if permitted to work online, the work environment the user enters might prevent them from going online. Think hospitals, where mobile phone usage is restricted in certain areas or is simply blocked through an active MRI machine in the vicinity.

The amount of data needed locally will likely be higher than in consumer apps.

A fully offline capable model to ensure maximum independence of connectivity needs a mix of sync mechanisms that should follow their respective business use cases. Conflict resolution and error handling is not exactly simple in such an environment, pervasive logging is key - plus a way to sync down app logs to the online backend. Users can freely fiddle with time/date and locale settings on iOS devices for example, which can wreak havoc on your sync logic - being able to backtrack such events is key when dealing with customer support issues.

I once used a similar trick -- queuing uncomfirmed outgoing edits, and replaying them on top of incoming models -- when working on a web client app (Laszlo Calendar, a browser UI to an iCalendar-backed server). It was an act of desperation: user edits would disappear and reappear, depending on the relative latency of client->server and server->client connections, and trying to add delays was a game of whack-a-mole. Replaying an edit queue onto the incoming model eliminated lots of code and all the bugs.

I tried to write something up about this although looking back half a decade later leaves me even less impressed by my communication skills. Nonetheless, in case it's useful to see some coding details, a (pre-Promises, pre-Harmony, 2008) JavaScript sketch of this is here: http://blog.osteele.com/posts/2008/02/synchronizing-client-m...

This was before Operational Transform, but in retrospect it could be viewed as a simplified subset of that algorithm.

Several times since I've seen clients that try to skip this, sending the edit upstream and then synching to the model that comes back down, which may not reflect the edits. And then add delays which sometimes hide the problem.

The couple of short code fragments in this article suggest that the cross-platform code in this app is in C++. Can anyone inside Dropbox say whether this is correct? And if so, were you able to use any tools to make the JNI glue code less tedious to write for the Android version?

Came across "The Decline of the Mobile Web" here on HN a few days ago:

http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/

Don't optimistic actions prove he's wrong?

Only operations that can be rolled back locally should be done, since you might have to roll them back if the server says something else happened than you thought.

I don't understand. Isn't this what Dropbox Sync API for?

Isn't carousel just a dragnet, which Rice has joined to oversee? I do not believe this is an at all unfair hypothesis, in the light of the Snowden revelations and Rice being a war criminal and all.