search

eladb / Parse-NSCoding

iOS library for serializing Parse objects
MIT License
69 stars 25 forks source link

Fix the problem caused by read-only properties #17

Closed npahucki closed 5 years ago

npahucki commented 10 years ago

See https://github.com/eladb/Parse-NSCoding/issues/16 for description of what I am trying to fix here.

npahucki commented 10 years ago

BTW: just included in this pull request: A fix for a bug where trying to get the Data from PFFile that was restored from cache would crash the app.

Apparently when you stopped saving all the ivars (which caused a different type of crash) you threw out the baby with the bathwater. We must save the state and previousState variables otherwise parse thinks you just created the PFFile and have not saved it, so it fails with "This file is not ready to be fetched" when you try to load it.

npahucki commented 10 years ago

Pardon, the mess, I reverted the changes to PFFile. I realized that I still had an OLDER version of Parse.framework and that a newer version had been pulled in as a dependency of Parse-NSCoding. The older version had some state variables in PFFile that needed to be saved, but it appears in the newer version these variables are gone, making my changes to PFFile+NSCoding unneeded for the latest version of the Parse SDK. The original commit is unaffected and is still needed.

joeyvlin commented 10 years ago

Hi @npahucki, could explain a bit more about why having an older version of Parse.framework required you to save all the ivars but not with the new one? I have a fairly new Parse.framework and am seeing the "This file is not ready to be fetched" issue. I really need some help resolving this. I would get fetching for the file data and this would randomly happen, maybe once every 40 times.

npahucki commented 10 years ago

@joeyvlin I explained pretty clearly why the error was happening in my original comments. I don't think it has anything to do with the problem that you describe as the failure mode was 100% in this case. The only thoughts I have on your issue is that perhaps in some code branch, you are forgetting to upload the PFFile to Parse before trying to use the PFFile or you are somehow getting race conditions perhaps due to the way that you are using threading. If you haven't already, make sure you are using the latest version of Parse, as "fairly new" doesn't mean latest.

Hope that helps some.

npahucki commented 10 years ago

Fixes to make compatible with Parse 1.4.x.

Summary: 1) Remove categories for classes that now have native NSCoding support. 2) Fix a crash condition when the data for PFFile is nil. The new version of the Parse API throws an exception if you call [PFFile fileWithName:name data:data] where data is nil (which is the case if a file has not been downloaded). 3) Increase the version number and Parse dependency version.

pronebird commented 10 years ago

Tremendous work @npahucki. I am switching to your branch, will test it. I don't use files but at least I can test PFObject and PFACL.

pronebird commented 10 years ago

@npahucki so far so good.

Not your edit apparently, but would be nice to move the following:

//Re-declare timestamp properties as read-write
@property (nonatomic, retain, readwrite) NSDate* updatedAt;
@property (nonatomic, retain, readwrite) NSDate* createdAt;

somewhere in implementation file of PFObject+NSCoding category so the rest of app would still see this as originally readonly.

pronebird commented 10 years ago

Another thing I noticed, there is now ivar called "estimatedData", I don't think it was in earlier SDKs. It seems to be used as "the latest value" of object after all pending operations finished. When we restore object from archive, it's filled with NSNull values. I am not sure if there is any side effect to that or shall we fill it with current data too...

pronebird commented 10 years ago

@eladb I know you do not actively maintain this library anymore, but can we make this release happen? This PR fairly covers a transition to Parse 1.4.