Building Carousel: How we made our networked mobile app feel fast and local(tech.dropbox.com)
tech.dropbox.com
Building Carousel: How we made our networked mobile app feel fast and local
https://tech.dropbox.com/2014/04/building-carousel-part-i-how-we-made-our-networked-mobile-app-feel-fast-and-local/
8 comments
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.
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.
There are some general purpose algorithms for conflict detection and management. Google CRDT or watch my Strangeloop talk about the data structures used by Apache CouchDB and Couchbase Lite. http://www.infoq.com/presentations/sync-mobile-data
Yes, I think any moderately complete CRUD-style app is going to fall down with this approach, sadly. Even if you duplicate all of the logic that the server implements to validate data, then that doesn't guarantee there won't be some kind of invalid interaction with a related record that only got changed on the server while you were offline.
Inevitably there needs to be some kind of review screen to let the user adjust their edit in the above scenario and that makes the whole user experience a little clunky.
I agree with the overall point of the OP though, given how flaky a mobile connection can be, this is by far the best approach if it suits the app.
Inevitably there needs to be some kind of review screen to let the user adjust their edit in the above scenario and that makes the whole user experience a little clunky.
I agree with the overall point of the OP though, given how flaky a mobile connection can be, this is by far the best approach if it suits the app.
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.
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?
The short answer is yes, we use a fair amount of C++, and yes, we've eliminated writing the JNI code for developers on the team. We're planning on writing more about both of these topics in a future blog post and we're interested in sharing our tools with the community, though it will take some work to make them less specific to our code base.
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?
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.
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.
As little as this site enjoys political interference with technology and progress, I think this is an unfortunate issue that a lot of people should hesitate over when considering continual use of Dropbox and its related products. I'd love to switch, but then... I'd also like something as easy as Dropbox for sharing photos and keeping light backups.
I think it's bizarre that people went a-lynching over Eich, a man who a decade ago voted against gay rights... But nobody cares that a woman who actively destroyed rights for all over the last decade now has steer over an organisation who hold your data.