We are building a real-time chat app using Firestore. We need to handle a situation when Internet connection is absent. Basic message sending code looks like this
let newMsgRef = database.document(“/users/\(userId)/messages/\(docId)“)
newMsgRef.setData(payload) { err in
if let error = err {
// handle error
} else {
// handle OK
}
}
When device is connected, everything is working OK. When device is not connected, the callback is not called, and we don't get the error status.
When device goes back online, the record appears in the database and callback triggers, however this solution is not acceptable for us, because in the meantime application could have been terminated and then we will never get the callback and be able to set the status of the message as sent.
We thought that disabling offline persistence (which is on by default) would make it trigger the failure callback immediately, but unexpectedly - it does not.
We also tried to add a timeout after which the send operation would be considered failed, but there is no way to cancel message delivery when the device is back online, as Firestore uses its queue, and that causes more confusion because message is delivered on receiver’s side, while I can’t handle that on sender’s side.
If we could decrease the timeout - it could be a good solution - we would quickly get a success/failure state, but Firebase doesn’t provide such a setting.
A built-in offline cache could be another option, I could treat all writes as successful and rely on Firestore sync mechanism, but if the application was terminated during the offline, message is not delivered.
Ultimately we need a consistent feedback mechanism which would trigger a callback, or provide a way to monitor the message in the queue etc. - so we know for sure that the message has or has not been sent, and when that happened.
The completion callbacks for Firestore are only called when the data has been written (or rejected) on the server. There is no callback for when there is no network connection, as this is considered a normal condition for the Firestore SDK.
Your best option is to detect whether there is a network connection in another way, and then update your UI accordingly. Some relevant search results:
Check for internet connection with Swift
How to check for an active Internet connection on iOS or macOS?
Check for internet connection availability in Swift
As an alternatively, you can check use Firestore's built-in metadata to determine whether messages have been delivered. As shown in the documentation on events for local changes:
Retrieved documents have a metadata.hasPendingWrites property that indicates whether the document has local changes that haven't been written to the backend yet. You can use this property to determine the source of events received by your snapshot listener:
db.collection("cities").document("SF")
.addSnapshotListener { documentSnapshot, error in
guard let document = documentSnapshot else {
print("Error fetching document: \(error!)")
return
}
let source = document.metadata.hasPendingWrites ? "Local" : "Server"
print("\(source) data: \(document.data() ?? [:])")
}
With this you can also show the message correctly in the UI
Related
I am listening to .info/connected to figure out if my device is online or not. If it is online it adds a child with the device id to the database.
_firebaseDatabase.reference().child('.info/connected').onValue.listen((event) {
if (event.snapshot.value == true) {
setDeviceOnline(userUid: uid, deviceUid: deviceUid)
}
});
I am using the onDisconnect callback on Firebase Realtime Database to remove this device id when the corresponding client disconnects.
Future<void> setDeviceOnline({String userUid, String deviceUid}) async {
DatabaseReference currentDeviceConnection = _firebaseDatabase.reference().child('users/$userUid/connections').push();
// Add this device to my connections list
await currentDeviceConnection.set(deviceUid);
// When I disconnect, remove this device
currentDeviceConnection.onDisconnect().remove();
}
Now:
When the client explicitly disconnects, the onDisconnect fires and removes the device id from the db.
When I turn on airplane mode the onDisconnect fires after a short timeout and removes the device id from the db.
When I turn on airplane mode and turn it back off before this timeout happens, the onDisconnect fires immediately when the client reconnects. Like it tells the db "I was offline"
The problem with point 3 is when the clients reconnects, onDisconnect fires and removes the present id from the database and due to the .info/connected listener which shows event.snapshot.value == true again, it immediately adds a new child with the device id to the database.
I think this works as intended. So I don't think this is a bug. But is there a way to prevent removing the child and adding a new one if there is still a corresponding child present in the db?
Once the server detects that the original connection is gone (either on its own, or because the client tells it about it), it executes the onDisconnect handler that you set for that connection.
There is no way to prevent the removal of the previous connection node.
But since a new connection is established, your setDeviceOnline should generate a new currentDeviceConnection connect ID again. In fact, that is precisely why the presence system in the Firebase documentation generates a new ID each time it reconnects. Is that not happening for you?
I am wanting to use Firestore to retrieve user info and other data linked to that user once they have logged in via firebase auth. On the home page of the app I use .onAppear{ pulluserData() }. I understand that Firestore functions are asynchronous so how can I wait for this data to be pulled before displaying it to the user on the home screen?
Here is my function to check the database:
func checkDatabase() async {
//Function that will check the database. Will be good to add a listener eventually
if self.pullUserData{
await dbm.readUser(userID: "VSWAq7QCw3dbGYwMdtClbbANGVe2")
}
}
and the actual database function:
func readUser(userID: String)async{
//Function that will be used to read user info from the database
let userRef = database.collection("users")
do{
let doc = try await userRef.document(userID).getDocument().data()
print("The doc is: ")
print(doc as Any)
}
catch {
}
}
There are a number of ways to do this but the two most common ways are to (1) use a launch screen to indicate a loading state that disappears to a view identical to the launch screen (to continue the appearance of loading) that is only removed when the database returns (i.e. Twitter); (2) load the user right into the app and allow them to move freely while either indicating that data is loading or displaying cached data.
Remember that Firestore maintains a local cache on the device which means that data will be available immediately when the app launches. This data may be out of sync with the server but it will update as soon as the app establishes a connection with Firestore, which is usually instant. What I would recommend is launching the user right into the app without the use of a loading screen and relying on the cached data to get the UI up as fast as possible.
And if we're only talking about user-specific data (data that is specific to the user that the user has full control over) then that data will only change when the user changes it, which would have been the last time they used the app, which means that the locally-cached data on their device (assuming they use only one device) will always reflect the state of the server (in theory, anyway). And if it doesn't then it doesn't; the fresh data will update instantly anyway.
You may then wonder what happens if the user launches the app without connection. In that case, the cached data is displayed and the user is almost none the wiser. And because Firestore is offline capable, the user can freely edit their data and it will write to the server when connection eventually establishes.
I have an actions project built and working. I'm trying to handle some error scenarios where it is failing. I need some help there.
I have a scenario where the webhook call throws a proper JSON formatted error response as shown below but which couldn't not be read at google end. Not sure if that is google actions limitation. Because of this issue I couldn't trigger a webhook handler back to my server to end the open conversation smoothly.
{
“responseJson”: {
“error”: {
“message”: “Transaction cancelled: maximum execution time exceeded”,
“detail”: “Transaction cancelled: ****”
},
“status”: “failure”
}
}
In the Error & status handling of actions scenes I dont see any system intent other than Cancel to handle any such error scenarios, I don't see any other relevant system intents too.
In simple words, I'm trying to catch a bad response and trigger back a webhook call to end the conversation at server side.
Could someone suggest a way to deal with this issue?
I am trying to check for errors while the app is trying to connect to the firebase-realtime-database.
My main concern is when the user fires up the app for the first time, but with no internet connection. I create the ref to the database and try to observe a single event, but the console log starts to throw error messages and none of them is captured by my code.
//------- variable declaration
var ref:DatabaseReference?
//------- inside de method
ref = Database.database().reference(withPath: "myPath")
ref?.observeSingleEvent(of: .value, with: { (snapshot) in
//I cannot even fire up the observer, so I never get here
}){(error) in
//no error is captured here also
}
Even if I comment or delete the observeSingleEvent I can see the errors getting thrown in the console, but I would like to capture them.
Does anyone know how to do that?
Thanks in advance
It is not an "error" to be offline at the time of a query. The SDK will continue trying to make the request for as along as your app is running and your code has an observer attached at that location.
If you want to detect the connection state, you can attach an observer at /.info/connected to get a callback that indicates the current state of the connection. Note that this information might be out of date, as a stalled connection doesn't immediately become fully disconnected until after a while.
I am developing one application using easyrtc tool with wavemaker tool.For a new user easy rtc provides automatically created easyrtc id.
In the chat window the random id are shown..i want to replace these ids with applications username..
I have find one solution where we have to set easyrtc.setUsername("") in client js file before calling easyrtc.connect function..
But this not solves the problem...
any help would be appriciated
Now, you can do it easyer, use this function:
easyrtc.idToName(easyrtcid)
Their is no easy way to solve this. However, it is possible using a mixture of server-side and client-side events to pass/receive user metadata when connected/disconnected. Here is a simple way to achieve this:
When a client connects to the server send user metadata via sendServerMessage on the connected event listener via client-side library. The server then receives the message from the client and stores the metadata about the user with that particular easyrtcid in a central location (ex. redis). The message sent to the server can be a json object with user metadata in a structured format. See details on connecting and sending a message to the server here: easyRTC Client-Side Documentation
When a client disconnects from the server remove their information from the data store using the onDisconnect event on the server side. This event provides a connectionObj which includes the easyrtcid of the user who disconnected. Use this identifier to remove the user from the datastore. You could also call generateRoomList() on the connectionObj to remove the user by easyrtcid and room from your datastore. You can read about the connection object here: connectionObj easyRTC documentation
Here is some example code of how to do this:
// Client-Side Javascript Code (Step 1)
easyrtc.connect('easyrtc.appname', function(easyrtcid){
// When we are connected we tell the server who we are by sending a message
// with our user metadata. This way we can store it so other users can
// access it.
easyrtc.sendServerMessage('newConnection', {name: 'John Smith'},
function(type, data){
// Message Was Successfully Sent to Server and a response was received
// with a the data available in the (data) variable.
}, function(code, message) {
// Something went wrong with sending the message... To be safe you
// could disconnect the client so you don't end up with an orphaned
// user with no metadata.
}
}, function(code, message) {
// Unable to connect! Notify the user something went wrong...
}
Here is how things would work on the server-side (node.js)
// Server-Side Javascript Code (Step 2)
easyrtc.events.on('disconnect', function(connectionObj, next){
connectionObj.generateRoomList(function(err, rooms){
for (room in rooms) {
// Remove the client from any data storage by room if needed
// Use "room" for room identifier and connectionObj.getEasyrtcid() to
// get the easyrtcid for the disconnected user.
}
});
// Send all other message types to the default handler. DO NOT SKIP THIS!
// If this is not in place then no other handlers will be called for the
// event. The client-side occupancy changed event depends on this.
easyrtc.events.emitDefault("disconnect", connectionObj, next);
});
Redis is a great way to keep track of the users connected if using rooms. You can use an hash style object with the first key being the room and each sub key/value being the users easyrtcid with a JSON hash of the metadata stored as it's value. It would have to be serialized to a string FYI and de-serialized on the lookup but this is simple using Javascript using the JSON.stringify and JSON.parse methods.
To detect occupancy changes in your application you could add a event listener to the easyrtc.setRoomOccupantListener method on the client-side and then when this event is fired send another message to the server to get all the users connected to it from the datastore.You would have to listen for a separate message on the server-side and return the users in the store deserialized back to the client. However, depending on your application this may or may not be needed.