Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The building blocks of offline support

pketh.org

Post reply on HN
Print view View original

21–30 of 31 posts

Re: The building blocks of offline support

#21

Post by JamesSwift »

woodrowbarlow wrote: post #19
tussa wrote: post #3

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?

if you can encode your state in CRDTs, there are no conflicts to resolve.

Thats only solving the conflicts at a technical level. The hard problem to solve is what conflict-resolution means at a business level. The even harder problem to solve is auditing and coming up with an appropriate answer for _every single entity in the system_.

For most products, there isnt a one-size-fits-all answer to how to handle conflicts.

Re: The building blocks of offline support

#22

Post by JamesSwift »

paxys wrote: post #18
jamestanderson wrote: post #16

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…

Yeah, the only way to get Spotify to work well offline is to manually set your phone to airplane mode. Otherwise it will endlessly try and fetch everything over the internet despite it being fully cached.

I ran into this all the time when trying to listen while mowing my lawn and going into/out-of wifi range. Very frustrating UX.

Re: The building blocks of offline support

#23

Post by pketh »

JamesSwift wrote: post #22
paxys wrote: post #18

Earlier quoted context omitted.

Yeah, the only way to get Spotify to work well offline is to manually set your phone to airplane mode. Otherwise it will endlessly try and fetch everything over the internet despite it being fully cached.

I ran into this all the time when trying to listen while mowing my lawn and going into/out-of wifi range. Very frustrating UX.

lately, I've been using zotify to download album mp3s from spotify and listen to them in doppler for mac/ios. It's been amazing to not have to use spotify to use spotify

Re: The building blocks of offline support

#24

Post by pketh »

JamesSwift wrote: post #13
tussa wrote: post #3

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!

perfect is the enemy of the good, and perfect can be iterated towards as demand scenarios increase

Re: The building blocks of offline support

#25

Post by pketh »

JamesSwift wrote: post #11
jiehong wrote: post #6

That first load time was pretty long, though (like 4 seconds). Felt as if it checked online or loaded too many things.

As someone who has built offline-first, I noticed that as well : D 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's an issue with the ios app only that i'll be investigating (the loading screen is mostly idling during that time). If you load the kinopio website in safari while offline (the app is just a thin wrapper over the site), then it is indeed magically fast

Re: The building blocks of offline support

#26

Post by gerdemb »

halfcat wrote: post #4
tussa wrote: post #3

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…

I created an experimental Swift package that implemented this architecture using SQLite.

https://github.com/gerdemb/SQLiteChangesetSync

As you noted, detecting conflicts is easy, but handling them is not.

Re: The building blocks of offline support

#27

Post by gerdemb »

matharmin wrote: post #12
halfcat wrote: post #4

Earlier quoted context omitted.

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…

Conceptually that's not hard, but in practice an approach like that can significantly increase the complexity of the app: 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 you…

I wrote a Swift library to experiment with this architecture using SQLite.

https://github.com/gerdemb/SQLiteChangesetSync

The library works at the database-level and stores databases modifications as binary change sets in a separate table that models a graph similar to a git repository. Capturing modifications is as simple as wrapping the transaction with a handler provided by the library. The graph of database modifications is stored locally on each device, but can easily by synced with an online repository.

The library detects conflicts, and provides a handler to the application for conflict resolution.

Re: The building blocks of offline support

#28

Post by latentcall »

jamestanderson wrote: post #16

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…

I thought Spotify used to have an “offline mode” toggle in the settings a long time ago. Is that no longer the case?

Re: The building blocks of offline support

#29

Post by JamesSwift »

emacsen wrote: post #14
tussa wrote: post #3

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?

I used to think this a lot, but then I find products that do exactly this and work reliably most of the time by simply asking you "Local Version" or "Server Version". This is what Steam does, what Nextcloud does, what PS5 does, and probably others. It's a naive approach but it seems to work well enough. Beyond that, you get into complex territory but maybe we've all been overthinking the problem space.

It only works for certain classes of products. A game has decidedly few copies (will just be your own saves across multiple devices), and is already serializing in a singular high-level format. When you have business software that is used my multiple people, and has multiple different 'kinds' of things that are being reconciled (at varying levels of granularity), it gets really messy and really hard to hit the sweet spot.

Re: The building blocks of offline support

#30

Post by jamestanderson »

latentcall wrote: post #28
jamestanderson wrote: post #16

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…

I thought Spotify used to have an “offline mode” toggle in the settings a long time ago. Is that no longer the case?

Huh, I never knew about this! It looks like it's still around. I'll try that next time. Thanks for the tip!
Post reply on HN