PFGeopoint, PFFile not converted

[Eke]

When Update,Create or other events are received PFObject is not generated correctly.

Instead of

<PFGeoPoint: 0x1360a4490, latitude: 42.722461, longitude: 45.792475>

I got this assigned to my PFUser subclass location property:

{
    "__type" = GeoPoint;
    latitude = "42.72246132158908";
    longitude = "45.79247540719969";
}

Same happens with PFUser avatar property and all PFObjects, PFPointers and etc

In ClientPrivate.swift i added

if value is Dictionary<String,AnyObject>{
   let objectType = value.valueForKeyPath("__type") as? String;
   let lat = value.valueForKeyPath("latitude") as? Double;
   let lng = value.valueForKeyPath("longitude") as? Double;
   if(key == "location" && objectType == "GeoPoint"){
       let geoPoint:PFGeoPoint = PFGeoPoint.init(latitude: lat!, longitude: lng!)
           parseObject[key] = geoPoint;
       }
   }
}

After this change GeoPoint is assigned to PFUser subclass as needed, but i am not very familiar with swift and don't think my solution is good, any ideas @nlutsenko @richardjrossiii ?

[richardjrossiii]

We need to make the encoding logic from PFDecoder in the main Parse SDK (https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/blob/master/Parse/Internal/PFDecoder.m) accessible to the LiveQuery client at some point in the near future. I'll start bike shedding with @nlutsenko about potential APIs and ways to expose this behavior.

[Eke]

@richardjrossiii sounds good, thanks

[noobs2ninjas]

Unfortunately NSDates are also affected when subscribing. This is the case at least when using them in "greaterThan:" or "lessThan" conditions. This results in a _NSTaggedDate which is the result of a Dictionary taking ownership. It results in a json error during subscription.

I looked at trying to import PFEncoder myself. Unfortunately, this means you'll have several other classes that will also have to get made public. Instead I took some of the logic of comparing classes when enumerating through dictionaries and found out how to convert the same way PFEncoder does but taking a Dictionary as the argument...and done in swift.

Not sure if you guys would be interested in the code, but I have it if you think you would use it.

[richardjrossiii]

@noobs2ninjas send a PR! We're always excited about potential improvements, especially those written in swift!

[noobs2ninjas]

Had a few questions. Kinda new to this contributor stuff on github. I mainly use version control for work as a part of a small team.

I could use a little help testing the encoder. The pod install was giving me fits. Also, I saw no unit test I could run. I pushed a commit to my branch here https://github.com/noobs2ninjas/ParseLiveQuery-iOS-OSX.

Also, I see the class QueryEncoder however I don't see it used anywhere so I wasn't sure if thats where an encoder was intended to go. I might add I don't think using dictionary is the best way to encode queries although its kinda cool how its being used get the conditions and state we may be able to get some things done with that same method...just not encoding. Dictionary just does some weird stuff to NS data types such as NSDate -> NSTaggedDate. Anyway, I just added it to operation. Is that what you guys where expecting?

Ill open another ticket for this but on a related note I am working on turning Client.shared into a singleton that initializes and connects itself. I was thinking of doing that same but creating a private encoder and decoder singleton classes that get called whenever they are needed.

[richardjrossiii]

@noobs2ninjas AFAIK, NSTaggedDate is an implementation detail, built in top of Tagged Pointers. It's still a full NSDate implementation, just not an objective-c object.

We're probably not going to merge these changes right now, but they help put us on the right track. Most likely, we're going to open up the APIs on PFObject itself, and allow you to construct a PFObject from its REST representation.

QueryEncoder.swift, as its an extension on dictionary that adds an initializer to Dictionary, so it is in fact used here. We should also open up the proper JSON representation of queries in the main SDK.

Client.shared should already be a auto-initializing thread-safe singleton (connection is intentionally delayed until you explicitly subscribe a subscription), just with the added benefit of being able to reset it (unit tests, for example). It would be the same as making an objective-c property null_resettable, essentially.

[noobs2ninjas]

I didnt know that NSTaggedDate was still a full NSDate...I just read that it occurs when put inside of a Dictionary.

Either way. It still needs to get converted. Not converting it will produce this error during serialization.

Invalid type in JSON write (__NSTaggedDate)

During inspection of the data created by the dictionary found by the following we get.

▿ 2 elements
▿ [0] : 2 elements
- .0 : "className"
- .1 : appointments
▿ [1] : 2 elements
- .0 : "where"
▿ .1 : 1 elements
▿ [0] : 2 elements
- .0 : appointment_date
▿ .1 : 2 elements
▿ [0] : 2 elements
- .0 : $gt
- .1 : 2016-03-31 05:00:00 +0000
▿ [1] : 2 elements
- .0 : $lt
- .1 : 2016-04-01 05:00:00 +0000

This means its sending

"$lt" : "2016-04-01 05:00:00 +0000"

This is not correct. It should be something like this.

"$lt" : ["__type" : "date", "iso" : "2016-04-01 05:00:00 +0000"]

So even if the NSDate or NSTaggedDate was being serialized...it still wouldnt work when it hit the server.

I created an issue for the singleton issue. Maybe you or someone else can help me out there to see what Im doing wrong.

Additionally I might add that getting access to PFObject wont fix your encode issues during subscribe. You need to get access to something in PFQuery that lets you get the encoded request.

[noobs2ninjas]

Just wanted to add that I am actually planning on using this in a project in order to keep from having to write a ton of SocketIO stuff. So, Im actually going to create a few tests that test every data type possible. If you are interested I will let you know my findings(and solutions when they come) for both encoding and decoding. Otherwise Ill keep the code to myself. Either way, I gotta get this working properly. Sooner rather than later.

[Eke]

Hello @richardjrossiii @nlutsenko, are there any news about this issue? i am planing to use LiveQuery in real product, at this moment we are using Firebase for live events (pain... 😄 ) and i want to completely use Parse for everything, so can i hope to achieve this in near future?

[chadpav]

+1 this enhancement/issue.

[AmbroiseCollon]

+1 for pointer constraints

Is it blocking on parse server side or on iOS ?

[mmowris]

@Eke any progress on this? Also want to use livquery w/ pointer objs :/

[alecsechechel]

@noobs2ninjas Hi
Have you any solutions for use NSDate and CGPoint in conditions for Live Query?

[ZacharyKhan]

+1 on this

[flovilmart]

It's in progress

[francesco79]

+1
since I think querying by date (range) is a very common use case!
A solution to this bug would be very appreciated.
Is there a (rough) estimate when to expect this? There is a branch called "fix-object-decoding" - is it related to this topic?

[dstarke]

I'm having problems with dates not showing up correctly in the objects I get back in my subscription handlers, and it looks like that problem is related to the discussion here. I'm also curious about the "fix-object-decoding" branch, which looks like it might be intended to fix that issue. What are the open issues with that branch? Is there anything I can do to get that work completed?

Update: I checked out that branch and it does appear to fix my issue with dates and other Parse objects not showing up correctly in the subscription handlers. My questions about open issues and what I can do to accelerate this still stand.

[flovilmart]

@dstarke great that it fixes for you. This branch is released now. Not sure what else stands there to fix. Let me know. Perhaps we could open a master of all issues for all encoding/decoding and fix them once and for all (with proper regression tests).