When using childByAutoId, something really strange happens. Instead of getting a unique id, I get the following key every time:
-------------------0
I know keys are generated with client side timestamps, so I tried running my code through the iOS simulator and an actual device, same result though.
I don't do anything interesting in my code, but here it is for reference:
func sendRandomMessage() {
let firebaseRootRef = Firebase(url:firebaseRootUrl)
let newMessageRef = firebaseRootRef.childByAutoId()
println(newMessageRef.key)
}
I'm using Firebase 2.3.0
There was a bug in the Firebase SDK for iOS 2.3.0 that caused this problem.
It has been fixed in 2.3.1. See https://www.firebase.com/docs/ios/changelog.html
Related
When I started working with parse live query I knew from the beginning it would be a challenge. Seeing that there were muiple ways to create a live query. When I had the set up the server early on, the bit of code I used to listen for updates looked like this:
let liveQueryClientMessage = ParseLiveQuery.Client()
qMessages.whereKey("toUser", equalTo: (PFUser.current()?.objectId!)! as String)
messageSubscription = liveQueryClientMessage.subscribe(qMessage).handle(Event.created){ _, message in
//prepare a local notification alert
print("object updated")
}
This however, no longer seems to function properly. So I looked at the parse live query docs to see if there was a working example and found that this gets the server to "Create new client: " with this code:
let qMessages = PFQuery(className: "Messages")
qMessages.whereKey("toUser", equalTo: (PFUser.current()?.objectId!)! as String)
let subscription = Client.shared.subscribe(qMessages)
subscription.handle(Event.updated){ query, event in
print("object updated")
}
But I am unable to get the print message to display... Am I missing something? I'm using the latest version of parselivequery I believe:
pod 'ParseLiveQuery'
UPDATE1: So I tried to rebuild the server and the issue still seems to persist. I'll try and make use of a parse query and see if its the filter...
UPDATE2: I rolled back the version of the podfile just in case it was an issue with just grabbing the lastest master branch. No fix yet...
The solution to fixing this issue was related to where everything was defined. Refer to the awnser to this stackoverflow question: Parse Cloud - LiveQueries - iOS Client doesn't work There's sufficient explanation there too.
I tried googling this problem but it seems like everyone has the opposite problem where the app runs on simulator but not their device. I've been struggling a LOT all week with firebase asynchronous calls returning null and linked the issue to persistence being enabled. All my problems go away if I disable persistence, but I want it enabled. I learned recently about synchronous issues with the different listeners/persistence and have been struggling with firebase returning outdated/nil values for a while.
Simulator was working just a week or two ago and I'm not sure what's changed. I've tried messing with / switching out .observeSingleEvent for .observe and still crashes at this code:
let synced = ref.child("profiles").child((FIRAuth.auth()?.currentUser?.uid)!).child("level")
synced.observeSingleEvent(of: FIRDataEventType.value, with: { (snapshot) in
print(snapshot)
print(snapshot.ref)
if (snapshot.value as! String == "One") {
........//CRASH
With the message:
Could not cast value of type 'NSNull' (0x10b7cf8c8) to 'NSString' (0x10a9dfc40).
When I try to print snapshot, it shows me an empty snapshot. But when I print the ref, the link works and takes me to the right place in my db (where I can see the data exists)
Any ideas how to fix/get around this without disabling persistence? Or more importantly I guess, should I care that it doesn't work in simulator if it works on a device? Will this matter for app store approval / affect future users?
If you'd like to see for yourself that this is an issue of firebase getting a nil/outdated value when the reference exists, here is what I see when I follow the printed ref link
The error seems fairly explicit: there is no value, so you can't convert it to a string.
synced.observeSingleEvent(of: FIRDataEventType.value, with: { (snapshot) in
if (snapshot.exists()) {
if (snapshot.value as! String == "One") {
........//CRASH
I've migrated my iOS parse SDK from the old Parse SDK to the version released to support a Parse stack hosted on my own infrastructure.
I have my project set up with SocketIO and decided it would be more efficient to append new Parse Objects sent from the server to my iOS apps model instead of making a new network request whenever the model changed, therefore I needed to instanciate a Parse object with an existing object ID.
To do that I used the following code snippet:
let appendError = PFObject(withoutDataWithClassName: "MachineError", objectId: id)
appendError.setValue(errorCode, forKey: "errorCode")
appendError.setValue(errorMessage, forKey: "errorMessage")
appendError.setValue(newDate, forKey: "createDate")
appendError.setValue(serial, forKey: "serialNumber")
appendError.setValue(status, forKey: "status")
appendError.setValue(false, forKey: "completed")
This code used to work fine when I was running xcode v7.1 but since this-morning when I upgraded to xcode 7.3, I was presented with an error that withoutDataWithClassName was not a valid parameter, it offered me outDataWithClassName as an alternative but the naming of that parameter did not sound as declarative as the previous. I did some reading through the PFObject documentation for iOS, but I could not find any details depicting what outDataWithClassName actually does.
I can only assume that it may be a typo on behalf of the Parse team, but I may be wrong. Could anyone here confirm whether withoutDataWithClassName is equivalent to outDataWithClassName?
Looks like it was a mistake related to automatic Objective-C to Swift conversion. It was reported as in issue in the repo, and a fix was committed 3 days ago.
In short, outDataWithClassName will do the same thing as withoutDataWithClassName for now, but since the current method name is rather uninformative, I would recommend updating Parse soon to get the fix.
I'm using a Parse Cloud function to get a list of movies. This was all working very well till today. The app crashes and I can't seem to fix it.
Weird (and highly problematic) thing is that it did work yesterday and the days before. (This app is in production in the App store)
This is the function causing the error:
PFCloud.callFunctionInBackground(function, withParameters: parameters) { (movies, error) -> Void in
if error != nil { return block(success: false, movies: []) }
PFObject.pinAllInBackground(movies as! [PFObject])
let foundMovies = ParseMovie.arrayFromPFObjects(movies as! [PFObject])
return block(success: true, movies: foundMovies)
}
If I comment the 4 lines inside the block, it still crashes. If I comment the entire function, it doesn't. So it seems as soon as I call "PFCloud.callFunction" the app crashes.
Any idea what can go wrong? The Parse cloud function does work, because calling it with the parse rest API gives me the movies as expected.
Any help is appreciated, thanks!
Ok, got it. Apparently I'm using an old version of the Parse SDK (1.5) and since today, this version is not working anymore.. I'm not using pods so I was not aware of this out-dated version. A bit disappointed, but probably my fault?
I'm doing a .or query which in every platform works fine except in iOS.
As soon it reaches the line where it does the .or, it crashes with:
System.Collections.Generic.List> doesn't implement interface System.Collections.Generic.IEnumerable>
Assertion: should not be reached at mini-trampolines.c:183
Here's the code:
var isChallenger = ParseObject.GetQuery("Match")
.WhereEqualTo("Challenger",fb.loggedUser);
var isChallenged = ParseObject.GetQuery("Match")
.WhereEqualTo("Challenged",fb.loggedUser);
ParseQuery<ParseObject> query = isChallenger.Or (isChallenged); // Crashes here.
I'm doing it just like in the docs, not sure what's wrong.
Any help would be much appreciated!
Thanks,
Pablo
I think this is a bug I reported here: https://developers.facebook.com/bugs/750897958275392/
Except, I only saw this bug when using ParseQuery. The workaround I used is to use ParseQuery only, but I see you're already doing that. Is the code you posted exactly the same as the code you're actually using?