Comments (18)
It's in progress
from parselivequery-ios-osx.
+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?
from parselivequery-ios-osx.
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.
from parselivequery-ios-osx.
@richardjrossiii sounds good, thanks
from parselivequery-ios-osx.
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.
from parselivequery-ios-osx.
@noobs2ninjas send a PR! We're always excited about potential improvements, especially those written in swift!
from parselivequery-ios-osx.
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.
from parselivequery-ios-osx.
@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.
from parselivequery-ios-osx.
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.
from parselivequery-ios-osx.
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.
from parselivequery-ios-osx.
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?
from parselivequery-ios-osx.
+1 this enhancement/issue.
from parselivequery-ios-osx.
+1 for pointer constraints
Is it blocking on parse server side or on iOS ?
from parselivequery-ios-osx.
@Eke any progress on this? Also want to use livquery w/ pointer objs :/
from parselivequery-ios-osx.
@noobs2ninjas Hi
Have you any solutions for use NSDate and CGPoint in conditions for Live Query?
from parselivequery-ios-osx.
+1 on this
from parselivequery-ios-osx.
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.
from parselivequery-ios-osx.
@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).
from parselivequery-ios-osx.
Related Issues (20)
- Subscription handler failing on array of subscriptions HOT 4
- Change query for subscription? HOT 1
- What about using Apple's Network framework instead of Starscream? HOT 3
- Subscription for PFUser current user - Swift
- ParseLiveQuery: WebSocket did disconnect with error: nil HOT 5
- Issue with nested PFQuery in a OR query HOT 1
- Xcode 12 beta 6 / iOS 14 incompatibility HOT 10
- Receiver type 'PFLiveQueryEvent' for instance message is a forward declaration (Xcode 12 Beta 6 / Objective-C project) HOT 6
- Could not build Objective-C module 'ParseLiveQuery' HOT 4
- ParseLiveQuery v2.7.2 not pushed into Cocoapods HOT 1
- Please update Starscream dependency up to '~> 3.1.1' how it was before in your `v2.7.0` release.
- Podfile update needed HOT 2
- LiveQuery interrupted by external operation on the table it monitors on HOT 3
- LiveQuery doesn't repsond to networking changes HOT 5
- Add release automation HOT 1
- Please add SPM Support HOT 5
- ParseLiveQuery: Received ping but we don't handle it... HOT 7
- ParseLiveQuery: Received ping but we don't handle it... HOT 1
- Merge as module with main SDK HOT 8
- Emitted Events from WebSocket pings not forwarded to Subscription Handler HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from parselivequery-ios-osx.