ios - How to retrofit Parse’s PFObject to an existing, complex, aggregate model class? -

ios - How to retrofit Parse’s PFObject to an existing, complex, aggregate model class? -

i have existing model class manage parse, ideally changing superclass nsobject pfobject. real-world model class, designed without parse in mind, presents number of challenges.

challenges

the challenges are:

this class in swift. this class has stored properties , computed properties. (so parse should manage stored properties, of course.) some properties hold arrays of instances of other custom model classes some of custom classes hold user objects, should managed parse.

every 1 of these things seems require special treatment handled correctly in parse, , parse’s documentation brief on these issues.

existing model class hierarchy

to give example, class this:

// i’d alter pfuser subclass. class user : nsobject { /* ordinary user object */ } // , pfobject subclass class tango : nsobject { var user:user // presumably, parse "pointer" pfuser var opponent:participant var info:nsstring? var watchers:nsarray // array of participants var duration:nstimeinterval? // (notice optional value type, in accessible objc) // various methods } // custom class contains user class participant : nsobject { var status:string var user:user // pointer pfuser? // etc.. } key questions

so have few key questions here:

should references user replaced pointers user subclass of pfuser? do need replace participant plain old cocoa type nsdictionary? or there way provide interconversion nsdictionary purposes of parse’s internal serialization? is there provision swift-only types optional<nstimeinterval> ? or case there’s extension point provide inter-conversion info type parse can handle? how model array of participants? user objects within participants? given these apparent difficulties tango, wiser implement method converting instance to/from plain old plist types (dictionaries, arrays, strings, numbers), , have pfobject handle those?

i not interested in maximal query flexibility or maximal performance. interested in quickest thing can work reliably, , requires minimum re-writing of existing code depends on existing class hierarchy. aware user / tango relationship described many-to-many, pfrelation for, have impression require major redesign utilize it.

in other words, hoping can avoid replacing entire model layer new class hierarchy designed denormalized tables for parse's pleasure. have existing code works current structure, , trying fit in parse without breaking there.

so these key questions right ones retrofit class parse? right way handle them?

you should check out subclassing guide. few things note particularly of import utilize case:

if subclass built-in class (e.g. user : pfuser) need register subclass. constructor methods homecoming instancetype can phone call them on user , you'll actual user back. similarly, query parse user class homecoming results deserialized type. if subclass pfobject own types, must implement +parseclassname. maps class name want see in info browser. name must consistent across languages create sure you're talking same data. the pfobject subclassing library written implement @dynamic properties. if @static or define method pfobject leaves alone. if have ivar same name, property isn't saved parse, instead create accessor/mutator pair respects pfobject's internal lock take when merging in server info or preparing save operation. pfobject can handle properties of json serializable primitive, pointers other pfobject subtypes, arrays/dictionaries thereof, , pfrelation pointers. haven't played swift yet, don't know how it's going interact optional properties; assume they're nsnumbers under covers , pfobject handles nsnumbers primitives (which auto-boxed/unboxed). [bonus] create subclasses self-contained can add together next definition: // note: +initialize objective-c's non-polymorphic function; every class // must implement directly. +(void) initialize { [self registersubclass]; }

ios parse.com pfobject