Trying to get a handle on using Parse (Parse.com BaaS [back-end as a service], for the uninitiated), and in reading the PFFile reference, I'm kind of unclear on what "non-relational way" means in the "Overview" description: "A file of binary data stored on the Parse servers. This can be a image, video, or anything else that an application needs to reference in a non-relational way."
Can someone, preferably with Parse experience, clarify this? Right now, I'm working out sending basic Objective-C objects and primitive data types to the server only. No images, audio, or anything else.
When should I use PFFile over, say, PFObject?
(Also, somebody should add BaaS, MBaaS, backend-as-a-service, mobile-backend-as-a-service tags. I can't, of course.)
EDIT: And some or all of the Parse classes, PFObject, PFFile, etc., etc..
I'm relatively early in process of using Parse for my iOS app. Partly because I must support offline operation and partly because I was well along in development, I chose to have a native DB using CoreData. I essentially replicate information from my CoreData objects into Parse objects that look vary similar. If I had looser requirements for offline operation I might try to do a purely Parse based DB. Parse does support caching for off line operation, but that just seemed too iffy for me.
All my images are given UUID file names and stored locally to my app. The file names can appear in objects. I will move these files to Parse as files using the same file names. Since they are UUIDs I know I don't have to worry about conflicts.
In certain cases, I will move the sqlite DB files that are my local persistent stores on iOS to Parse as files and then attempt to download them back to iOS. I expect that to work, but have not verified that there are no unseen gotcha's. I will be doing this for large packages of objects that will be used only on the iOS apps themselves.
If my App only needed to communicate objects to other iOS apps, I might not use Parse. I need to share data with a web site and with an Android app. That and my desire for an easy to deal with API to my back-end make Parse seem like the right choice.