In this case, they detect online/offline state in a web browser mostly for the purpose of communicating that state to the user so they can tell what is going on.
The web app keeps track of network state. If a network request times out, the state is set to offline. Then it polls every 10 seconds to see when the network comes back online.
This approach seems alright for a webapp, but in a mobile app I think we’d avoid polio every 10 seconds to see if the app is online. Perhaps poll on the next natural network request instead, or trigger on events such as view-will-appear or return-to-foreground.
Great overview of building an app that works offline first as a means to a great user experience.
The offline-first approach is not the universal solution to every problem you will experience with unreliable network connectivity – it heavily depends on your app’s requirements. It’s more like a design approach that lets you focus on what really matters to your end user: a robust app with a great user experience.
A technical pet peeve of mine, this post does a nice job articulating why “manager” classes in software design can be a problem. To me, a “manager” class is like saying, “this class does some stuff” and the stuff has no boundary. But what does this class do? What is it’s purpose? It might be a sign of an unfocused and unsustainable design.
Or as the post says:
Managers can be a symptom of poorly-defined responsibilities. When you think about it, the word “Manager” means nothing. In object oriented programming,everyclass is a manager. Cocoa Touch could haveUIApplicationManager,UIViewManager, and even a humbleNSStringManager.
Runs through Caches vs. Databases and when each is a better fit. Basically, databases are better for a finite set of data that you can save “all” of, perhaps a game of personal database. Caches are better for something that is too big / complex / dynamic to save “all” of, e.g. social media, web, etc.
Also covers the idea of using a queue (or EveneBus) for offline tasks and mixing strategies.
Matt Diephouse with a good article that starts out looking back at the Protocol-Oriented Programming in Swift session from WWDC 2015 (Was that really 2015? It feels much more recent than that!) and then takes us through a different way to write some of the same code from that session.