When writing an application to work offline and online is it best to write it once to work offline and the online mode will work the same as offline?
For example lets see we have a typical shopping cart example. A shopping cart contains items and a customer.
When the shopping cart is loaded, should I cache all the items + customers in local storage and use that data cache for both online and offline and update the cache as needed? What are some best practices when developing an offline/online hybrid web application?
Writing a web-app to work in an online/offline mode is really very much like writing any “normal” server-driven web app, with the exception that you have a data access layer (DAL) that sits between your app and the data living on either the server (on-line mode) or the browser’s data(offline mode).
Depending on the application and it’s needs, you can run in one of 2 modes: a.) A cache-and-try-your-best mode or b.) a load-everything-and-check-for-updates mode.
Each of these two modes has some good and some bad parts, and you can definitely have different parts of your application that lean one way or the other.
Cache-and-try-your-best mode
For this mode, the DAL caches data from the server into the browser’s data stores as it accesses data during it’s normal course of operation. Once in offline mode, the DAL tries it’s best to meet users’ requests, but it only has the cached data to work from and so some operations may not be able to be completed (or at least not right away). On the up-side, there is minimal start-up time waiting for data to load, but on the down side, every action requires a server hit (if connected) and that data has to be cached. The app also has to fail gracefully for any operation it can’t complete due to incomplete data.
Load-everything-and-check-for-updates mode
In this case, the DAL loads all of the data the app needs into the browser when the app starts. If the app has already been loaded, then all of the data has to be updated to make sure the cache isn’t stale. In the up-side, the user doesn’t have to wait very long to do things ever, since everything is a local operation, but on the down-side, if there is a lot of data, the start-up time could be rather long.
In either case you have to battle stale cache issues, and issues persisting off-line operations to the server. This means that on start-up, and probably also periodically while the app is running, you will need to sync back to the server to keep your cached data fresh, and to share any local-only state that you may have with the server so that the rest of the world sees the updates from that instance of the application.
Persisting operations back to the server that occurred while the app was in offline mode can be particularly tricky when the data involved with that operation changes between updates of the app. For example, if a cached bank balance is out-of-date and indicates much more money than the “true” state reflected by the server, a user could overdraw the account without knowing it. This is an extreme example, but this sort of operational collision detection needs to be in place for handling updates that may run into each other.
In general, if you have an app that could be both on- and off-line, write the app so that the app itself doesn’t need to care. A lower-level data layer abstracts away all of the problems, and your app only needs to know how to deal with not being able to get information it wants (which any good app, on- or offline, should do).
For a shopping cart, you likely (or hopefully?) have WAY more products than any individual customer is likely to put in their cart. Loading all of them into everyone’s browser is almost certainly a HUGE waste of bandwidth and would cause such a delay for your users that the massive bandwidth cost and lost sales (due to slow response times) would quickly sink any business. Load the products into the browser data as-needed, and if you want to, you could load other products that “other users also bought” that are associated with the items actually in the cart.