Building Carousel: How we made our networked mobile app feel fast and local
1–10 of 18 posts
Re: Building Carousel: How we made our networked mobile app feel fast and local
#2For 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
Re: Building Carousel: How we made our networked mobile app feel fast and local
#3For 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
Awesome man, thanks!
Re: Building Carousel: How we made our networked mobile app feel fast and local
#4The 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?
Re: Building Carousel: How we made our networked mobile app feel fast and local
#5I don't understand. Isn't this what Dropbox Sync API for?
Re: Building Carousel: How we made our networked mobile app feel fast and local
#6The 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.
Re: Building Carousel: How we made our networked mobile app feel fast and local
#7Super 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.
Re: Building Carousel: How we made our networked mobile app feel fast and local
#8I don't understand. Isn't this what Dropbox Sync API for?
Not in the least. The app does not sync so much as browse--I have many more times photos than my phone can even hold.
Re: Building Carousel: How we made our networked mobile app feel fast and local
#9Super 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…
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
Re: Building Carousel: How we made our networked mobile app feel fast and local
#10I 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.