I'm facing a weird issue using Parse's Local Datastore.
I have a Cloud function declared in backend that returns a list of ParseUsers, which can returns my current User.
The problem is when the function returns my User in the list, local currentUser gets overrided by the server data, resulting in a lost of information (i.e. authData).
Reading documentation from Parse I found this:
There are a couple of side effects of enabling the local datastore
that you should be aware of. When enabled, there will only be one
instance of any given ParseObject. For example, imagine you have an
instance of the "GameScore" class with an objectId of "xWMyZ4YEGZ",
and then you issue a ParseQuery for all instances of "GameScore" with
that objectId. The result will be the same instance of the object you
already have in memory.
I think this may be causing the problem.
Have you got any idea how to prevent this behaviour?
Thanks you in advance.
Well I finally found that this is due to a know Bug: https://developers.facebook.com/bugs/898928300168631/?search_id
Related
I have a REST API containing a JSON Array of JSON Objects.
On the first launch of the Android application, the data is consumed through retrofit and stored using a Room database.
My question is: what do I do on the second launch? Do I systematically call and consume the API after each launch? Or is there a better way of handling this?
Thanks in advance
You don't have to consume the API call if you stored that data already, what you can do is defining a timestamp variable inside your model class, and put any time value (you can add days or months) that should determine whether your app should fetch the data or not, if the time does't pass yet you can get the data from your local database, android documentation recommend using NetworkBoundResource to handle this case, check it out it will help you a lot.
My problem is with how Firestore offline mechanism works (or i don't understand it). Specific issue is that data is firstly synced from cache instead from online if network is available. It's quite easy to reproduce this:
In your firestore database, change data type of one of your variables to the wrong type. For example if we have document "Person" which contains variable "name" which is type String, change type to number and put 1 as value.
Your application will now crash, because Firestore SDK tries to parse data from that specific "Person" variable "name" int as String.
Now fix this issue on Firestore database and set "name" back as String and set value "test name".
Now open application (with network available).
The problem that i'm seeing in my own application is that the data is firstly taken directly from cache, and in cache, that "Person" variable "name" is still written as int (number on firestore) and the application crashes before it can take updated value from online, even though I have active network connection and I fixed data type directly on Firestore database.
The only solution to prevent crash in this situation is for user to clear app storage/cache and go into application again. Is this reproducable issue for other users as well? Is this intended behaviour?
If there is more explanation needed please write in comments.
This is the expected behavior. You should use some combination of strategies to prevent problems due to bad data:
Obviously, verify that all writes contain the types you expect. Use security rules to validate those types on the server.
Always assume that Firestore can give you unexpected data when you read a document. Before assuming that a type is what you think, actually check the type of that to make sure your assumption is correct.
Clearing cache should not be your production-worthy solution. Take steps to make sure that only good data goes in, and that only good data gets processed on the way out.
I am making an app that will let user keep notes - simple text entries. I want to persist these to the backend and Parse.com seems to make it easy. While going over their documentation, I came across this:
There are a couple of side effects of enabling the local datastore
that you should be aware of. When enabled, there will only be one
instance of any given ParseObject. For example, imagine you have an
instance of the "GameScore" class with an objectId of "xWMyZ4YEGZ",
and then you issue a ParseQuery for all instances of "GameScore" with
that objectId. The result will be the same instance of the object you
already have in memory.
Say that my class is called NoteEntry. Since the user will create a number of notes, there will be a lot of NoteEntrys. Does the side effect mean that only a single NoteEntry can ever exist in the database?
and
Another side effect is that the current user and current installation
will be stored in the local datastore, so you can persist unsaved
changes to these objects between runs of your app using the methods
below.
I don't even know what that means. What is it saying?
Doc: https://www.parse.com/docs/android_guide#localdatastore
No, that's not the side effect. You can still be dealing with lots of Parse objects, it just means that there will be only one copy of each different object. If you had a NoteEntry object in variable x and later query and that same object is returned, it will be equal to the object in x and not a separate copy of the object.
I am developing in iOS with Parse. My app required offline operation, so I had developed my own solution. However, Parse's introduction of the LocalDataStore obviates the need for my own solution. Since this is not released in iOS yet, I can only rely on documentation to prepare for this. I asked these questions on the Parse forum a week ago and the questions have been completely ignored by Parse. Can anyone answer these via experience with the Android version?
1) Objects pointed to by pointers and PFRelations will be pinned along with the pinned object. (That's correct, right?) Will PFFiles be pinned along with the object? Will the file data be locally available?
2) When a pinned object is modified, you have to SaveEventually it to push the changes to the Server, right? Does a Save on a pinned object save locally? Or does it do an "on-line" save?
3) When changes occur elsewhere to a pinned object, how do those changes get propagated to the pinned object in the LocalDataStore? Does the programmer have to explicit fetch the changes, or will it happen automatically?
4) Does the concept of logging in apply to the LDS? Do the ACLs operate in the LDS? Or does the local code have access to all objects in the LDS?
-Bob
I can give a basic answer from the Android side, but keep in mind the details may change as the Parse.com iOS version of LDS is released. My answers below come direct from the API docs are are bolded where I quote directly.
Let's go point by point:
1) Objects pointed to by pointers and PFRelations will be pinned along with the pinned object. (That's correct, right?) Will PFFiles be pinned along with the object? Will the file data be locally available?
Yes. From the Android docs: "Pinning a ParseObject is recursive, just like saving, so any objects that are pointed to by the one you are pinning will also be pinned."
2) When a pinned object is modified, you have to SaveEventually it to push the changes to the Server, right? Does a Save on a pinned object save locally? Or does it do an "on-line" save?
Again, from the Android docs this appears to be Yes. "Once you've saved some changes locally, there are a few different ways you can save those changes back to Parse over the network. The easiest way to do this is with saveEventually. When you call saveEventually on a ParseObject, it will be pinned until it can be saved. The SDK will make sure to save the object the next time the network is available."
3) When changes occur elsewhere to a pinned object, how do those changes get propagated to the pinned object in the LocalDataStore? Does the programmer have to explicit fetch the changes, or will it happen automatically?
The Android docs are pretty quiet about this process, but it's a safe bet you will have to query the server to synchronize the local datastore, the same way you do now when you have a local instance of an object after a query. That's all all the local data store is - a very persistent version of queried data.
4) Does the concept of logging in apply to the LDS? Do the ACLs operate in the LDS? Or does the local code have access to all objects in the LDS?
Logging in still applies, as does ACLs, as far as I can tell. The object permissions are still required for the local data. I haven't confirmed this with a test project in Eclipse, but the docs allude to this being the case.
A final note: The CEO of Parse, Ilya Sukhar, weighed in on the Google Group 3 days ago saying the iOS LDS is definitely on it's way. Here's hoping it's soon!
In the Parse android docs it says that by default, related ParsePbjects are not fetched, implying that there is a setting that will fetch them. It later says that they cannot be fetched without a call to fetchIfNeeded. Which is it? I definitely need to fetch the related ParseObject and would prefer to do so without having to make multiple requests. Is that possible?
By default, when fetching an object, related ParseObjects are not fetched. These objects' values cannot be retrieved until they have been fetched like so:
In the ParseQuery you are using to get the original object, you can use the include(key) method to tell it to also fetch the related object. This works for pointers and arrays of pointers.
No They Can't. I am also facing the similar problem. SO if you have two table and one table is having reference key from second table, then there is no such query where we can find relative data.
Its Sad. I wonder why they don't provide such a useful thing.