ParseObject implements Parcelable

[wanclem]

I think ParseObject needs to implement Serializable.In a scenario where a developer is building a long list of ParseObject items that are pulled from the internet and displayed on a list view,if serialized it could help mimick offline content on the occasion where the user has no connectivity.That is,the previously serialized list items could be deserialized and populated on the list view when there is no connectivity on the phone.I tried subclassing ParseObject to get this effect but the Problem is that Subclassing ParseObject is forcing me to use a Zero-Argument Constructor and a predefined className which leaves me with the question "What if I want to provide classNames dynamically without predefining with @ParseClassName annotation as done by ParseObject?." Please help.

[grantland]

First off, Parcelable is more efficient than Serializable for passing objects through Intents, so use that when possible. I'll rename this issue as such.

Secondly, we're planning on converting ParseObject to implement Parcelable at some point, but it's a bit more complicated that you might think:

1. Do we parcel just server data or server data and dirty changes?

   Right now we're planning on passing both server data and dirty changes. Once object.revert() lands in Publicize ParseObject.revert() and revert(key) #112, you'll be able to clear dirty changes and have access the server data.

2. What do we do if there are multiple operation sets in the object's queue like we're in the middle of saving an object?

   The best option might be to consider the previous operations as failed and roll forward the changes into one operation set. This will mean that the unparceled object might have some dirty changes that will be persisted on the server and additional calls to save() will execute them again. Doing so will be fine for idempotent operations, but might cause some issues with increment(key) and decrement(key). We can issue a logcat warning when parceling an object with in progress operations to alert them of these possible inconsistencies.

3. What do we do if the object has been deleted?

   This seems like a super rare case and might be fine doing nothing. The only side-affect of doing nothing will mean that the unparceled object will incorrectly return false from isDirty().

4. What do we do if the object is currently being deleted?

   Follow (2) and assume the delete() has failed and warn in logcat. Same repercussions as (3).

5. What do we do for in progress saveEventually() or deleteEventually()?

   Follow (2) and assume the eventually calls failed and warn in logcat. Same repercussions as (2) as well.

6. Is it ok that the unparceled object will be the same instance when LDS is enabled?

   This seems fine and probably a better scenario since in progress calls to save(), delete(), saveEventually(), and deleteEventually() will notify the instance, although there's no way to subscribe to these changes. Will probably warn in logcat with in progress calls as well. If the process dies we'll get a new object instance with the operation set queue squashed, similar to (2) even if the operations complete since there's no way to update the originating Intent.

It'd also be great to hear developer's feedback on this since it'll be a huge change and has a lot of nuances so we can be sure we're going in the right direction with this feature.

[rustanacexd]

So a quick question. how do we pass a parse object if we cant implement serializable nor parcelable. assuming I don't want to convert into a pojo. ie: extending ParseObject

[grantland]

If you want to use ParseObject data to inflate the UI in a new Activity, we recommend passing specific fields that you need for UI through the Bundle and inflating your UI with that data.

If you want to modify a ParseObject in a new Activity, we recommend passing the className and objectId through the Bundle and creating a pointer in the new Activity using ParseObject.createWithoutData(className, objectId).

[sbagadi]

I think the method is ParseObject.createWithoutData(className, objectId) because ParseObject.create(className) only takes one argument.

[grantland]

@sbagadi Oops, thanks! I've updated my comment.

[natario1]

@grantland any updates on this?