11–20 of 31 posts
That first load time was pretty long, though (like 4 seconds). Felt as if it checked online or loaded too many things.
All the offline-first apps I've built have felt magically fast to load. It really is an incredible experience. I think its likely something to do with parsing/loading the initial view state that is taking a bit. Thats a pretty complicated widget so likely has to load libraries to handle it.
It conveniently doesn't mention the hardest part: conflicts. If you just drop a conflicting edit then it's a stretch to call your app "offline". Yes, it "works" but who wants to use an application to at drops you edits?
Conflicts themselves are not hard: Keep a directed acyclic graph of immutable records. Changes to a record point to the parent/prior record. Two users update the same record, now you have a tree. The challenge is interpreting what that tree structure should mean. If you can, let a user decide how to resolve the conflict. - User logs in, they have a “conflict inbox” of things that need to be resolved. - Two coworkers…
1. Do you store the tree structure for every table in your app? If you have 20 tables that could be edited offline, do you re-implement it for each table, or try to have a generic implementation? 2. Do you design all your tables around the tree structure, or do you just store it in addition to your "normal" tables? 3. Every piece of code that modifies one of these tables need to do it via the tree structure - if you update your tables directly from any place it could effectively cause conflicts. 4. Do you build separate UI to resolve conflicts for every table? 5. Do you query and cache the tree structure on the device, or does it have to be online to resolve conflicts? 6. Do you expose the tree structure via external APIs, or keep it internal?
I find that "last-write-wins" is sufficient for a large percentage of cases, and much simpler to implement. Or in some cases, just doing conflict detection is sufficient (notify the user that the data has changed between loading and saving, and they need to re-apply their edits).
If you do need conflict resolution on a large scale (many different tables), I'd recommend using data structures designed for that. CRDTs is one example - while it is typically used for automatic conflict resolution, it often stores enough data to allow manual resolution if desired.
It conveniently doesn't mention the hardest part: conflicts. If you just drop a conflicting edit then it's a stretch to call your app "offline". Yes, it "works" but who wants to use an application to at drops you edits?
It conveniently doesn't mention the hardest part: conflicts. If you just drop a conflicting edit then it's a stretch to call your app "offline". Yes, it "works" but who wants to use an application to at drops you edits?
Beyond that, you get into complex territory but maybe we've all been overthinking the problem space.
It conveniently doesn't mention the hardest part: conflicts. If you just drop a conflicting edit then it's a stretch to call your app "offline". Yes, it "works" but who wants to use an application to at drops you edits?
Conflict resolution and the inability to come to a business decision on what to do has stopped offline-first support in a couple apps I've done. Its a really messy conversation to have, especially with people that aren't used to sweating the details. You can't just handwave away the complexity!
One of my biggest gripes with the Spotify app is the poor offline support, at least in my experience on Android. I have the bulk of my library downloaded for offline listening, so when I have a spotty network connection like when I'm on the Subway, I'd expect that I can still easily access at least my downloaded songs. Not the case. Spotify, it seems, won't use its local cache until it's thoroughly convinced you're offline, which may take several minutes of waiting for requests to time out. Once Spotify is convinced I'm offline, my downloaded songs will then finally load normally.
My guess is that instead of doing it the way the Kinopio does - by reading from the local cache before fetching the remote data - Spotify does it the other way around.
Anyway, nicely done!
Earlier quoted context omitted.
Conflict resolution and the inability to come to a business decision on what to do has stopped offline-first support in a couple apps I've done. Its a really messy conversation to have, especially with people that aren't used to sweating the details. You can't just handwave away the complexity!
I've seen business software, where money can be lost, just handwave and silently dropping conflicts (because "it doesn't really happen that often!")
I may at an earlier part of my career, when I knew far less about building robust software, have stumbled into such an experience.
It's really cool to see offline support done well. It can be very frustrating when it's done poorly, or not offered at all. One of my biggest gripes with the Spotify app is the poor offline support, at least in my experience on Android. I have the bulk of my library downloaded for offline listening, so when I have a spotty network connection like when I'm on the Subway, I'd expect that I can still easily access at le…
It conveniently doesn't mention the hardest part: conflicts. If you just drop a conflicting edit then it's a stretch to call your app "offline". Yes, it "works" but who wants to use an application to at drops you edits?
Earlier quoted context omitted.
Conflict resolution and the inability to come to a business decision on what to do has stopped offline-first support in a couple apps I've done. Its a really messy conversation to have, especially with people that aren't used to sweating the details. You can't just handwave away the complexity!
I've seen business software, where money can be lost, just handwave and silently dropping conflicts (because "it doesn't really happen that often!")
Proceeds to do millions of transactions a day.