Feature/pffile

[mhupman]

WIP - Implementation for #7

[mhupman]

While trying to add some proper unit tests for the PFFile functionality I ran into some prickly issues that I'm having trouble resolving...

In addition to being uploaded to S3, the contents of a PFFile are transparently cached on disk when the Parse SDK's save method (and its ilk) is invoked. That could be an issue in itself since it might cause us to not properly test the async behavior of the network request. However, a more pressing problem is that subsequent calls to getData and friends are raising the following exception:

/Users/mhupman/repo/Parse-RACExtensions/Parse-RACExtensionsTests/PFFileRACSpec.m:0: error: -[PFFileRACSpecSpec downloading_should_download] : NSInternalInconsistencyException: This file is not ready to be fetched.
  Call Stack:
    0   CoreFoundation                      0x00b1d5e4 __exceptionPreprocess + 180
    1   libobjc.A.dylib                     0x007958b6 objc_exception_throw + 44
    2   CoreFoundation                      0x00b1d3bb +[NSException raise:format:] + 139
    3   Parse-RACExtensionsTests            0x060d529b -[PFFile assertAwaitingFetchOrFetching] + 83
    4   Parse-RACExtensionsTests            0x060d668d -[PFFile getDataAsync:] + 35
    5   Parse-RACExtensionsTests            0x060d6616 -[PFFile getDataInBackgroundWithBlock:progressBlock:] + 41
    ...snip...

My guess is that since I'm attempting to fetch a file that was just saved from the same device, it fails the [PFFile assertAwaitingFetchOrFetching] check inside the Parse SDK. Inspecting isDataAvailable and isDirty support the assumption that the Parse SDK thinks the file is fully downloaded and doesn't need fetching.

A solution to this problem would be to find a way to obtain a handle to a PFFile that represents a valid remote resource but has not already been downloaded and cached locally. But...

• PFFile doesn't expose a way to create a valid PFFile pointer (w/o data) from an existing PFFile instance. Something like [PFFile fileWithIdentifer:(NSString*)guid] would be ideal.
• The Parse SDK doesn't provide a mechanism to clear cached file data. You can find the on-disk cache via NSCachesDirectory, but deleting it has no effect on isDataAvailable.
• Specific to the unit tests, I can't think of any way to "clean up" the Parse account after the test, like the PFObjectRACSpec does. PFFile doesn't have a delete method, and Parse documentation says you cannot delete a PFFile that isn't attached to a PFObject ( https://parse.com/docs/ios_guide#files-progress/iOS).

Thoughts?

[kastiglione]

@mhupman – I sent you a message out of band, did you get it?

[mhupman]

I did not - where did you send it? I went ahead and added my email address to my public profile.

[kastiglione]

Cool, I'll send you an email right now.

[a2]

What's the state of this PR? Coming soon?

[mhupman]

@a2 I meant to get someone to review but it fell off of my radar. If you, @jondwillis or @MattCBowman want to give it a once over that would be appreciated. I believe its working as intended, but the unit-tests are prickly (as you can see from the thread above) and I haven't had the chance to use it in a real-world project.

[kastiglione]

oh hai

EDIT: I'll get involved in this asap, I'll give an update by Monday or Tuesday :sparkling_heart:

[kastiglione]

@mhupman Can you temporarily hold off on merging this. I still hope to have more details next week.

[mhupman]

Sure thing!

[kastiglione]

Still no update, but I haven't forgotten and will see if I can get an update soon.

[kastiglione]

@mhupman Things are progressing now, and I'm cautiously optimistic I can review and get the ball really rolling the end of next week. If not then the week after. I haven't looked too closely, but the testing approach looks like a pretty good solution.

[kastiglione]

@mhupman Thanks for your contributions. Given the news that Parse is being shut down, I'm going to close this.

[gfosco]

The reports of our death have been greatly exaggerated. https://github.com/ParsePlatform/parse-server

[kastiglione]

@gfosco Thanks! Apologies for making it appear that I was closing this solely because of Parse transitioning away from a commercial support.

This project hasn't been in active development for some time now, and probably not in active use either. The Parse SDKs have seen many updates, and ReactiveCocoa is now on version 4 and uses Swift. All of these combined led me to the conclusion that it would be best to officially stop this project.