0

Any design advice regarding how one handles local updates by a user with updates from Firebase? There are two (2) areas I'm interested in understanding. Perhaps assume the application is a shared todo list or shared chat area perhaps:

Q1 - Local updates by user - Is the general concept to (a) make update immediately locally & update firebase at the same time, then separately to this (b) received an "firebase updated" event (which all users sharing the todolist or chat would received) whereby you effectively update that record you just changed again?

Q2 - Delta Updates versus Full Updates - Would one normally get the current list from firebase, and then subscribe to updates only? (as opposed to pulling down full list each time something changes). In this case how does one know when the local app may need to do a full refresh of all items in the firebase list? e.g. scenarios: a) in the case the mobile devices goes out of contact then back into internet contact, can we assume that firebase would buffer the updates and you would get them all?
b) in the case the app goes into background - same as a) above?

Overall I guess I'd be interested in the pseudo-code around how these should best be handled in terms of the approach in the mobile app design...

Greg
  • 31,898
  • 75
  • 232
  • 424
  • a) No. There's no reason to do this, just update Firebase and let the event you receive update the UI. This would apply to all users including the current one. *there are edge cases where this may not be best practice b) You initially pull down the 'full list' (or filtered based on a query) then use childAdded, childChanged and childRemoved to watch for specific events to update the apps local data. Firebase offers offline support. b) Yes. No pseudo code needed. Go through the getting started guides and you'll find a wealth of info - also, we don't know you platform (hint: add a tag). – Jay Nov 30 '17 at 20:24
  • thanks @jay - I'm using react-native and one of the main npm libraries (react-native-firebase) - it uses/wraps the firebase "web" interface I believe...but it exposes the same calls so I think my question is relatively generic to firebase. It does support offline too, however I admit I'd need to dig in here re how this works under the bonnet, or affects the way you would address the questions I raised.. – Greg Nov 30 '17 at 23:59
  • PS @Jay when you mention "firebase offers offline support" - were you saying effectively there is no reason to do anything specific re the case the mobile app goes into background/comes back? So overall just at app start up get full list and from then on only need diffs effectively right? (just double checking) – Greg Dec 01 '17 at 00:02
  • Offline support means on a mobile app, iOS, Android etc if there is a disconnect the app will store/cache data locally temporarily and then syncs on reconnect . The idea is to provide a transparent user experience whether off or online. Do you have to do anything special? It depends on your use case. For example, if it's a game app or chat app, when a user goes offline your app could notify the user they are offline. On the other hand, if it's a single user To Do list - there would be very little to do. There are docs for Offline Capabilities on the Firebase website for several platforms. – Jay Dec 01 '17 at 14:48
  • thanks - I'll do some testing to prove things to myself - I hadn't realized that in fact you will get updates from the local cache itself (if my reading of the offline capabilities of Cloud FIrestore are correct) when disconnected. So this kind of answers a lot of questions. – Greg Dec 01 '17 at 20:25

0 Answers0