When Firebase RemoteConfig fetch is invoked, the closure gets called asynchronously when the data is available. After the initial result is returned, does the closure keep listening for changes or de we have to call fetch again?
I am afraid there is no listener for further changes.
If you want to listen to changes in real time you need to propagate the change through some notification mechanism: Firebase provides an official guide on this.
Related
In my app I have set observers for childAdded, childDeleted and childModified on the Firebase database nodes of interest to keep track of them and modify my CoreData device database accordingly. I just realised that if a childDeleted or childModified happens when a device is not online, it won't get notified of those events when it goes online again. As it is the normal expected behaviour as understood, I thought of a workaround as so: when I trigger deletion an entry on Firebase node, I will create an entry of the respective "deleted" node. So a childAdded event will be triggered when device gets back online and perform the logic that is now performed by the childDeleted observer. This way I won't observe any childDeleted events.
So my question is: am I misusing Firebase observers ,and childDeleted should be communicated anyway when the device gets back online, or this kind of situation is actually the way it is supposed to work? What kind of solutions did you implement in this situation?
The Firebase Realtime Database synchronizes the state of the data on the server with any connected clients. Whenever a client (re)connects, Firebase makes sure that client has the current state of the data. As you've discovered Firebase explicitly does not synchronize state changes.
If you want to synchronize state changes, you should store precisely those state changes in the database. Because then those changes becomes the data that Firebase synchronizes.
So your solution is fine, and is in fact the idiomatic way to handle this requirement.
I want to send updates to a database from the background every now and then with an app that I am building (for HealthKit things like user's steps taken, heart rate, etc.). I believe I can do this using background fetch. However, from everything I have read on background fetch, it seems like it is mainly just used to grab data for the app so it can display correctly when the user opens it next. Is it reasonable (or recommended) to use background fetch to send data to a database? Thanks.
Depends on what you want to send.
Location services for example have their own background capability with events that you should listen on. In their delegate methods you can send that data to your API.
Background fetch is as the name says rather used for randomly receiving custom data while the app is in background. There is no fixed schedule when the callback gets called. So you might actually either send the same data many times because they did not get updated, or not enough times that you miss some updates (unless you keep them in a database locally)
Lets say I want current user to observe when theres a childAdded to the friendRequest node so they can see if they are the recipient. If there are zero friend requests, when observer is called from client, will observer still be listening when a friend request comes through at a later time? If not, does this mean I need to have some arbitrary placeholder value to assure the node exists, when client attempts to observe?
You can most definitely observe/listen to a location that has no data. Your observer/listener will still be called when data arrives there.
This is behavior you can pretty easily test for yourself by writing the observer code in your app, and making a quick change in the Firebase Realtime Database console that would trigger your observer.
I want to just update location to server in app terminated state.
I found one great example for getting location, when app is closed.
here
but what my problem is after getting location, somehow webservice not called. any help would be great.
or any specific way for calling webservice in app termination state?
Once you get location updates in terminated state, you should call your web service in a single block.
Try to move all your code that is required to perform the web service action. Like, preparing data for web service, URLSession code and handling response, and everything to this single block. If you have data to be taken from any global instance, you need to prepare them again in this block, as they are not available in app memory.
You should not refer any other class in that block. They are not available for execution during terminated state.
Hope this helps :)
I use HKObserverQuery and background delivery in my iOS application. In the updateHandler of HKObserverQuery I execute a query (HKAnchoredObjectQuery) and send results to the remote server via https. But on a slow connection (EDGE for example) and with big amount of data (steps for example) data sending may take up to one minute.
From the documentation to HKObserverQueryCompletionHandler:
When HealthKit wakes your app, it calls the update handler on any observer queries that match the new data. This block is passed to the update handler. You must call this block as soon as you are done processing the incoming data. Calling this block tells HealthKit that you have successfully received the background data. If you do not call this block, HealthKit continues to attempt to launch your app using a back off algorithm. If your app fails to respond three times, HealthKit assumes that your app cannot receive data, and stops sending you background updates.
So my question is: How much time do I have to call HKObserverQueryCompletionHandler before my app is assumed by HealthKit as "hanged"?
Or should I call HKObserverQueryCompletionHandler immediately and run a new long-running background task for https request instead?
You should definitely start a separate background task to perform the transfer of data to your server and call the HKObserverQueryCompletionHandler as soon as possible. The documentation gives no indication as how long you can wait before calling the handler so the safest thing to do is call it as soon as possible.
I posted a similar question about confusion around use of HKObserverQueryCompletionHandler here, but there haven't been any updates.