Opinions on approach to dynamic UITableView creation?

  • I've been thinking about the best way to approach one part of an iOS app. I need to generate editable 'forms' for instances of each of a potentially largish number of classes (starting at about 10, but more will be added in quick succession). To make adding new classes/forms simple, and avoid duplication, I want to make the form generation fairly dynamic -- essentially a table view controller which creates a table view suited for any of the classes I throw at it.

    The editable classes are facades for a moderately complex Core Data graph, but are themselves simple enough -- a bunch of @propertys. Each of the properties is of a custom NSManagedObject subclass type. There are 10 or so of these core data property types (and only a couple more likely to be added).

    The approach I'm considering is as follows:
    - create a custom UITableViewCell class for each of the (NSManagedObject) property types, with a factory method to create the right subclass in the view controller's tableView:cellForRowAtIndexPath: method. Each cell type will know how to display and edit its associated NSManagedObject.
    - the table data source will obviously have a reference to the editable object. That object will be able to supply a collection specifying the object's 'fields' (ie. the name and type of each @property). The data source can use this collection to determine the numbers of table rows and sections , types of table view cells needed, etc.
    - the field specification collections will be created by using runtime introspection functions (class_copyPropertyList etc) to discover the editable object's public @property name and type.

    I'm generally suspicious of this kind of 'soft'/dynamic scheme, and my iOS/Cocoa experience is limited to much more vanilla work than this, so I'm wondering if this (admittedly broad-brush) description sets off any red flags for anyone here?
  • I've been thinking about the best way to approach one part of an iOS app. I need to generate editable 'forms' for instances of each of a potentially largish number of classes (starting at about 10, but more will be added in quick succession). To make adding new classes/forms simple, and avoid duplication, I want to make the form generation fairly dynamic -- essentially a table view controller which creates a table view suited for any of the classes I throw at it.

    The editable classes are facades for a moderately complex Core Data graph, but are themselves simple enough -- a bunch of @propertys. Each of the properties is of a custom NSManagedObject subclass type. There are 10 or so of these core data property types (and only a couple more likely to be added).

    The approach I'm considering is as follows:
    - create a custom UITableViewCell class for each of the (NSManagedObject) property types, with a factory method to create the right subclass in the view controller's tableView:cellForRowAtIndexPath: method. Each cell type will know how to display and edit its associated NSManagedObject.
    - the table data source will obviously have a reference to the editable object. That object will be able to supply a collection specifying the object's 'fields' (ie. the name and type of each @property). The data source can use this collection to determine the numbers of table rows and sections , types of table view cells needed, etc.
    - the field specification collections will be created by using runtime introspection functions (class_copyPropertyList etc) to discover the editable object's public @property name and type.

    I'm generally suspicious of this kind of 'soft'/dynamic scheme, and my iOS/Cocoa experience is limited to much more vanilla work than this, so I'm wondering if this (admittedly broad-brush) description sets off any red flags for anyone here?
previous month july 2012 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today