0

So my goal is to get rid of these bugs completely. I am in a dilemma where each decision leads to a bug.

The first thing I can do that eventually becomes an issue is use a String-interpolated collection path in all my query functions like so:

func getEventName() {
    listener = db.collection("school_users/\(user?.uid)/events").order(by: "time_created", descending: true).addSnapshotListener(includeMetadataChanges: true) { (querySnapshot, error) in
        if let error = error {
            print("There was an error fetching the data: \(error)")
        } else {
            self.events = querySnapshot!.documents.map { document in
                return EventName(eventName: (document.get("event_name") as! String))
            }
            self.tableView.reloadData()
        } 
    }
}

The thing with this is, when I run the app on the simulator, I am restricted from pressing buttons and then sometimes I can press them and then sometimes they get restricted again. This bug is so confusing because it makes no sense where it springs from.

The other issue is I can use a Constants value in all the query functions in my collections path.

static let schoolCollectionName = "school_users/\(user?.uid)/events"

This is nested in a Firebase struct within the Constants struct. In order to keep Xcode from giving errors I create a let users = Auth.auth().currentUser variable outside the Constants struct. The issue with this value is that when I put that in all of my query functions collection paths, all the buttons are accessible and selectable all the time, but when a user logs out and I log in as a new user, the previous user's data shows up in the new user's tableview.

It would obviously make more sense to use the Constants value because you prevent typos in the future, but I can't figure out how to get rid of the bug where the old user's data shows up in the new user's tableview. Thanks in advance.

dsonawave
  • 137
  • 2
  • 12

1 Answers1

2

The user id should definitely not be a constant. What it sounds like is that right now, you have no reliable way to change users -- your setup probably depends on which user is logged in at app startup, since that's where your variable gets set.

I would do something more like this:

func getEventName() {
    guard let user = Auth.auth().currentUser else {
       //handle the fact that you don't have a user here -- don't go on to the next query
       return
    }
    listener = db.collection("school_users/\(user.uid)/events").order(by: "time_created", descending: true).addSnapshotListener(includeMetadataChanges: true) { (querySnapshot, error) in

Note that now, user.uid in the interpolated path doesn't have the ? for optionally unwrapping it (which Xcode is giving you a warning for right now). It will also guarantee that the correct query is always made with the currently-logged-in user.

Regarding being able to press the buttons, that sounds like an unrelated issue. You could run your app in Instruments and check the Time Profiler to see if you have long-running tasks that are gumming up the main/UI thread.

jnpdx
  • 45,847
  • 6
  • 64
  • 94
  • See that's the thing, that is my Firestore path, if I get rid of the optional, the function will not work. The document ID is literally `Optional("UserUIDHere")`. The only reliable way I change users is logging in and logging out. I don't know if the guard statement would be a reasonable addition, when the user logs in, it shows the correct user's email, but displays the wrong user's data. This is similar to [my last question that you answered](https://stackoverflow.com/questions/66513571/is-this-firestore-closure-causing-a-memory-leak) where it's the right user but displays wrong data. @jnpdx – dsonawave Mar 09 '21 at 03:56
  • The thing with the other question is that there was a `authStateListener` closure that coincidentally provided a `user` parameter that I could use in my query path instead of the other `actualuser` variable I declared. In this case, I don't think it would make sense to add another `authStateListener` in this tableViewController cause I feel it would just cause even more bugs down the line. @jnpdx – dsonawave Mar 09 '21 at 04:00
  • Hmm -- making the document ID "Optional()" etc is probably not a good idea. If this isn't a production app yet, I'd change that. If you're stuck with it, I'd hard code that into your string rather than relying on swift to do it (and living with the Xcode error) – jnpdx Mar 09 '21 at 04:06
  • I agree -- don't add another authStateListener – jnpdx Mar 09 '21 at 04:06
  • I did try changing it last night, but then I got a bad access error and I had to go through all my code just to change things back again. I'll try it again tonight. The buttons act buggy and get restricted on the simulator but perfectly fine on my physical device, I'll take a look at the Instruments and Time Profiler. @jnpdx – dsonawave Mar 09 '21 at 04:10
  • Just revitalized my whole project with the guard statements this morning. Works great. Thanks again Floyd Mayweather. @jnpdx – dsonawave Mar 09 '21 at 14:31