1

I have a custom subclass of PFObject which keeps track of a large video file on the device. I want to make sure that if i delete the PFObject the videoFile is also deleted.

For now if have override all variants of the delete method, but that seem wrong. Is there a central way to add a behavior when an object is deleted?

otusweb
  • 1,638
  • 1
  • 19
  • 30
  • Could you please clarify the question. Is the video file stored on Parse or is it only local? There are `beforeDelete` and `afterDelete` cloud code hooks that you can put on a class to handle any sort of additional cleanup operations you may need – Russell Nov 03 '15 at 17:09
  • The file is stored locally – otusweb Nov 04 '15 at 13:40

1 Answers1

1

There's a hook that catches every delete on the back-end, (beforeDelete in cloud code), but from the question, it sounds like that's the wrong place to catch, because the file in need of deletion is local.

Parse recently open-sourced the SDK. Perusing the code. It looks like the delete variants ultimately all call deleteInBackground. So one idea -- a little too clever, IMO -- would be to override only that one. But I think it would be unwise to depend on this undocumented fact.

If you control the caller side, one idea is to just make a policy to never call delete directly, and provide an "otuswebDelete" method to do the object and file delete.

If you don't control the caller (or don't trust yourself to remember your own policy), I think you're better off, under your current design, to just override the few variants:

– delete
– delete:
– deleteInBackground
– deleteInBackgroundWithBlock:
– deleteEventually

They can all just call super to delete, then call a method in the subclass to delete the local file. Not so bad, IMO.

Finally, for reasons too numerous to detail here, I'm in the habit of "wrapping" my PFObjects (an NSObject subclass that has a PFObject property) rather than subclassing them.

The burden of this approach is a little tedium to create the accessors for the properties, but in return I get more control of (a) the use of SDK methods (as in your issue), (b) serialization, (c) fetching an managing related objects, (d) more...

danh
  • 62,181
  • 10
  • 95
  • 136
  • Unrelated to the OP but as someone who subclasses PFObject regularly, I'm interested in your wrapper idea. Have you represented multiple levels of PFObject inheritance this way? Since PFObject only allows for one level of subclass normally. – Russell Nov 03 '15 at 20:13
  • 1
    @Russell, yes, multiple levels of subclassing is another benefit of wrapping. – danh Nov 03 '15 at 20:41
  • very neat concept that I'll have to try out. Thanks for sharing! – Russell Nov 03 '15 at 20:45