I have a project with firebase set up, and I have a function set up similarly to the sample from firebase, but the firebase document updates #Published vars in my observable object:
func getDataFromSession(env: GlobalEnvironmentObject) {
db.collection("sessions").document("firstSession")
.addSnapshotListener { documentSnapshot, error in
guard let document = documentSnapshot else {
print("Error fetching document: \(error!)")
return
}
guard let data = document.data() else {
print("Document data was empty.")
return
}
print("Current data: \(data)")
env.data1 = data[data1]
// env.data1 is the #Published bar data1
}
}
and I'm calling this function in my swiftui view :
var body: some View {
let fbConnection = FirebaseConnectionHandler(env: env)
fbConnection.getDataFromSession()
When I run my app, my debug window is executing the print("Current data: (data)") line at lightning speed despite the fact that no values in the observable object/global environment have change. I was under the impression that the snapshot listener will only perform a read when data changes, and the swiftui views will only update when #Published properties change and so fare neither are happening (so it shouldn't be reading like crazy). And I'm not sure if it's performing a ton of reads in a row or if that output is normal (obv I only want it to read when there is a change in my document)...
What the heck am I doing wrong? How do I prevent the mega reads and have it so the data only reads when it is updated?
Welcome to Stackoverflow. Relax, you and the SDK are doing it nothing wrong. The very first read you are experiencing is due to the initial state of your data.
See the doc View changes between snapshots :
https://firebase.google.com/docs/firestore/query-data/listen#view_changes_between_snapshots
Important: The first query snapshot contains added events for all
existing documents that match the query. This is because you're
getting a set of changes that bring your query snapshot current with
the initial state of the query. This allows you, for instance, to
directly populate your UI from the changes you receive in the first
query snapshot, without needing to add special logic for handling the
initial state.
The initial state can come from the server directly, or from a local
cache. If there is state available in a local cache, the query
snapshot will be initially populated with the cached data, then
updated with the server's data when the client has caught up with the
server's state.
Ok, so I figured it out...if you are updating observable objects from firebase, put the listener object in your view (under "var body: some View {")...
Then, take any of the views in your struct (HStack, ZStack, etc) and add a .onAppear modifier, and call the function the updates your firebase from there...
Turns out the view keeps updating, but .onAppear will kick off the refreshing once...
So, it turns out when I was writing my data to Firestore, all my data was being written to the same document. And, after searching the web, i learned that, when it comes to listeners in firestore, it is an all or nothing thing. So, my entire document was being called and updated, which triggered updates elsewhere, that would call and trigger, etc etc etc.
To fix, I took the document and split it into two documents, where one app can read to one but only write to the other, and the other app did vice versa (read to the other, write to the other). This way, the listener calls changes on a per document level and avoids the looping...
Related
I am testing my app where I have included a tableview that shows items from a Firebase Realtime database.
Every time I create a new object from the app to Firebase, the tableview updates and include the new added object.
But I have detected that sometimes it doesn't maintain the items updated.
For example, if I add a new item from inside the app, it is automically included in the tableView.
If another user creates a new item from inside his app, it is also included and updated in both apps.
But I have detected that not all items are included in the tableview and if I edit an item directly in the firebase console,the app doesn't update inmediatelly the item in the tableview.
Here is the code I am using to populate the tableview:
databaseRef.child(codigo_chat).queryOrderedByKey().observe(.childAdded, with: { (snapshot) in
if let valueDictionary = snapshot.value as? [AnyHashable:String]
{
let texto_mensaje = valueDictionary["mensaje"]
let codigo_chat = valueDictionary["codigo_chat"]
let datetime = valueDictionary["datetime"]
let emisor = valueDictionary["emisor"]
let receptor = valueDictionary["receptor"]
self.mensajesSorted.insert(MisMensajes(codigo_chat: codigo_chat!, datetime: datetime!,emisor: emisor!, mensaje: texto_mensaje!, receptor: receptor! ), at: 0)
self.chatTV.reloadData()
}
})
Right now you're only observing the .childAdded event, which (as its name implies) only fires when a child is added to the location (and initially for all existing children).
If you also want to get called when a child is modified, you should also observe the .childChanged event. In that callback you can then update the existing UI for that child.
In the save vein there are two more events you may want to respond to:
.childRemoved, which is fired when a child is removed from the database, and you'll want to remove it from the UI.
.childMoved, which is fired when the child is moved to a different location in the query results, and which typically goes hand-in-hand with a .childChanged event. In your .childMoved code, you'll usually move the UI element for the child to its new location.
Also see the Firebase documentation on listening for child events.
You need to call reloadData in the main queue.
DispatchQueue.main.async {
self.chatTV.reloadData()
}
I'm currently building a chat app and when I click on a user, it takes me to the chat log controller. Here I call a function fetchChatMessages() in viewdidload() that essentially fetches the conversation from firestore. Problem is, whenever I go to the previous controller and open the chat again, it again fetches the messages.
Not sure if it's fetching from cache or from the server itself. But I did write a print statement under the firestore fetch code that prints every time.
Now I'm new to swift so my question is, in other chat apps, you can see that messages seemed to be fetched just once from the server and after that you add a listener and update the collection view to display the new messages. In my case, it seems like everything is fetched over and over again. Even though I have added a listener and followed a highly acclaimed tutorial.
Also, I added a scroll to bottom code whenever messages are fetched, so every time a new message is fetched, the controller automatically scrolls to the bottom. But this happens every time I open the chat. I was trying to fix this bug where the controller keeps scrolling every time the view appears which made me wonder, am I contacting firebase again and again when the controller is opened?
override func viewDidLoad() {
super.viewDidLoad()
fetchCurrentUser()
fetchMessages()
setupLoadView()
}
//MARK: Fetch Messages
var listener: ListenerRegistration?
fileprivate func fetchMessages(){
print("Fetching Messages")
guard let cUid = Auth.auth().currentUser?.uid else {return}
let query = Firestore.firestore().collection("matches").document(cUid).collection(connect.uid).order(by: "Timestamp")
listener = query.addSnapshotListener { (querySnapshot, error) in
if let error = error{
print("There was an error fetching messages", error.localizedDescription)
return
}
querySnapshot?.documentChanges.forEach({ (change) in
if change.type == .added{
let dictionary = change.document.data()
self.items.append(.init(dictionary: dictionary))
print("FIRESTORE HAS BEEN CONTACTED FETCHING MESSAGES")
}
})
self.collectionView.reloadData()
self.collectionView.scrollToItem(at: [0, self.items.count - 1], at: .bottom, animated: true)
print("Fetched messages")
}
}
//MARK: View Disappears
override func viewWillDisappear(_ animated: Bool) {
super.viewWillDisappear(animated)
if isMovingFromParent{
listener?.remove()
}
}
I want the controller to remember its state. Like if I scroll the messages, exit the controller and enter it again, it stays at the scrolled position like in whatsapp.
The problem here is that your controller gets deallocated every time you leave the screen, because you probably push the controller on to the stack and pop it afterwards, this will erase all of the internal state of the controller. This behavior is indeed intended (viewDidLoad is called once the screen is loaded). You can solve this problem in several ways. An easy one would be to introduce a singleton service (a service which is shared across the app) which holds the state of the controller, so every time the controller is created it will ask the service for its state. Keep in mind this is not a very good solution, but it should be sufficient as starting point. If you need an example I will edit my answer accordingly later on.
I cannot give you a definite answer on this, because it really depends on what features the app and the server support, in the end I would have some kind of database service and chat services (these should not be accessed over the singleton pattern, but rather via dependency injection). The chat service would define some kind of policy when the data should be fetched, which means the controller should not be aware of this. The chat service would then store the messages via the database layer in some persistent store like user defaults, realm or core data for each chat. Every time the user enters an already fetched chat the chat service will check if persisted data is available if not it will fetch it from the server.
Every firebase client example I see in Swift seems to oversimplify properly loading data from Firebase, and I've now looked through all the docs and a ton of code. I do admit that my application may be a bit of an edge case.
I have a situation where every time a view controller is loaded, I want to auto-post a message to the room "hey im here!" and additionally load what's on the server by a typical observation call.
I would think the flow would be:
1. View controller loads
2. Auto-post to room
3. Observe childAdded
Obviously the calls are asynchronous so there's no guarantee the order of things happening. I tried to simplify things by using a complete handler to wait for the autopost to come back but that loads the auto-posted message twice into my tableview.
AutoPoster.sayHi(self.host) { (error) in
let messageQuery = self.messageRef.queryLimited(toLast:25).queryOrdered(byChild: "sentAt")
self.newMessageRefHandle = messageQuery.observe(.childAdded, with: { (snapshot) in
if let dict = snapshot.value as? [String: AnyObject] {
DispatchQueue.main.async {
let m = Message(dict, key: snapshot.key)
if m.mediaType == "text" {
self.messages.append(m)
}
self.collectionView.reloadData()
}
}
})
}
Worth noting that this seems very inefficient for an initial load. I fixed that by using a trick with a timer that will basically only allow the collection view to reload maximum every .25s and will restart the timer every time new data comes in. A bit hacky but I guess the benefits of firebase justify the hack.
I've also tried to observe the value event once for an initial load and then only after that observe childAdded but I think that has issues as well since childAdded is called regardless.
While I'm tempted to post code for all of the loading methods I have tried (and happy to update the question with it), I'd rather not debug what seems to not be working and instead have someone help outline the recommended flow for a situation like this. Again, the goal is simply to auto-post to the room that I joined in the conversation, then load the initial data (my auto-post should be the most recent message), and then listen for incoming new messages.
Instead of
self.newMessageRefHandle = messageQuery.observe(.childAdded, with: { (snapshot) in
try replacing with
let childref = FIRDatabase.database().reference().child("ChildName")
childref.queryOrdered(byChild:"subChildName").observe(.value, with: { snapshot in
Both on simulator and my real device, an array of strings is saved upon app termination. When I restart the app and fetchRequest for my persisted data (either from a viewDidLoad or a manual button action), I get an empty array on the first try. It isn't until the second time I fetchRequest that I finally get my data.
The funny thing is that there doesn't seem to be a time discrepancy involved in this issue. I tried setting various timeouts before trying to fetch the second time. It doesn't matter whether I wait 10 seconds to a minute -- or even immediately after the first fetch; the data is only fetched on the second try.
I'm having to use this code to fetch my data:
var results = try self.context.fetch(fetchRequest) as! [NSManagedObject]
while (results.isEmpty) {
results = try self.context.fetch(fetchRequest) as! [NSManagedObject]
}
return results
For my sanity's sake, here's a checklist:
I'm initializing the Core Data Stack using boilerplate code from Apple: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/InitializingtheCoreDataStack.html#//apple_ref/doc/uid/TP40001075-CH4-SW1
I'm putting my single DataController instance in a static variable at the top of my class private static let context: NSManagedObjectContext = DataController().managedObjectContext
I'm successfully saving my context and can retrieve the items without any issue in a single session; but upon trying to fetch on the first try in a subsequent session, I get back an empty array (and there lies the issue).
Note** I forgot to mention that I'm building a framework. I am using CoreData with the framework's bundle identifier and using the model contained in the framework, so I want to avoid having to use logic outside of the framework (other than initalizing the framework in the appDelegate).
The Core Data stack should be initialized in applicationDidFinishLaunchingWithOptions located in appDelegate.swift because the psc is added after you're trying to fetch your data.
That boilerplate code from Apple includes:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)) {
/* ... */
do {
try psc.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: storeURL, options: nil)
} catch {
fatalError("Error migrating store: \(error)")
}
}
The saved data isn't available until the addPersistentStoreWithType call finishes, and that's happening asynchronously on a different queue. It'll finish at some point but your code above is executing before that happens. What you're seeing isn't surprising-- you're basically looping until the async call finishes.
You need to somehow delay your fetch until the persistent store has been loaded. There are a couple of possibilities:
Do something sort of like what you're already doing. I'd prefer to look at the persistent store coordinator's persistentStores property to see if any stores have been loaded rather than repeatedly trying to fetch.
Post a notification after the persistent store is loaded, and do your fetch when the notification happens.
As the title mentioned, I get local data with keepSynced(true) and have to go out and back into the view to get the latest (fresh) data.
i have the following setup:
var baseRef: FIRDatabaseReference!
in viewDidLoad:
baseRef = FIRDatabase.database().reference()
baseRef.child("Posts").keepSynced(true)
then in viewWillAppear:
baseRef.child("Posts").queryOrderedByChild("sortTimestamp").observeSingleEventOfType(.Value, withBlock: { snapshot in //etc
I get local data, according to this post the data should be fresh as I keepSynced before I attach an observer:
https://groups.google.com/forum/#!searchin/firebase-talk/keepSynced/firebase-talk/SK9WVZvkHsU/HVjxtnv5JoYJ
"keepSynced will work fine both with disk persistence enabled and with it disabled. It immediately fetches the data for the location/query where you enable it, before you attach a listener"
However, as mentioned, I have to trigger this again, by going out and in of the viewController(almost like a refresh), to get fresh data
I did try the normal observeEventType(.Value as well as .ChildAdded, but with the pagination system I use observeSingleEventOfType works better except for the issues above
Not sure what I am missing, any suggestions are much appreciated.