Using this architecture in the context of an ecommerce app
fabiopicchi opened this issue · 2 comments
Thank you for the great talk! I found the architecture very solid for the presented use cases and for this sample project. This architecture and the one presented by Virgil Dobjanschi at Google I/O 2010 are very enlightening and I reckon that using such constructs I could solve a lot of the crashes that happen today on my app.
However, the application I work on relies a lot on fresh data. We need to present the actual price of a product to the user and it can't be wrong (keeping this data in sync is already a pain and we have a lot of users complaining about divergencies). I went to study how other ecommerce apps work and even how Google Play works and they all get absolutely useless with no network.
I have been thinking and, maybe, this architecture may be useful for user generated content such as marking a product as favourite or viewing previous orders. However, I would like to hear your opinion on the subject. Do you think that there is any benefit from caching data in an app that requires up to date information? (Another use I can think of is avoiding boring serialization and deserialization of data on orientation change).
Sorry I just saw this.
The act locally - sync globally architecture described in this demo is not suitable for information critical parts of an application.
For instance, if you are a banking app, you cannot tell the user that they sent the money and later on send it on the background. You have to block the user until you have a resolution (because it is money :) ).
In your case, I think it depends on what the PM wants. If you cannot show a price to the user in case it might be wrong, yes you cannot use this architecture. On the other hand, I think you can find a middle ground solution here where
a) You don't show cached prices if it is older than X hours.
b) In the list you show the cached price. When user click on the item and goes to the purchase page you update the price. Until it is updated, the buy button is not enabled. (and there is some UI clue that the price is being updated, maybe replace it with a circular loading icon)
If the update price query fails:
-> you show and error, let the user retry the update (purchase button is still disabled)
If you updated the price and it is the same, seamless perfect UX.
If you updated the price and it is different, show a notification etc to the user to clarify them that price has changed.
Keep in mind that when user goes to a product pages and hits back (I assume most of the time) they always win since they are never blocked.
There are many e-commerce sites doing this even on the web (orbitz comes to mind).
If your product manager OK with this, I think it makes sense.
Also, you can still cache the rest of the data that is unlikely to change. And may be show the product with a loading icon over the price until price is refreshed.
Hope this was helpful.
Thank you, it was very helpful! I will try this mixed solution you proposed and post the results. Great answer :)