• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Opinions on approach to dynamic UITableView creation?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Opinions on approach to dynamic UITableView creation?


  • Subject: Opinions on approach to dynamic UITableView creation?
  • From: Crispin Bennett <email@hidden>
  • Date: Sat, 07 Jul 2012 12:08:46 +1000

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?
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Prev by Date: Opinions on approach to dynamic UITableView creation?
  • Next by Date: Icon Overlay on Mac OSX
  • Previous by thread: Opinions on approach to dynamic UITableView creation?
  • Next by thread: Icon Overlay on Mac OSX
  • Index(es):
    • Date
    • Thread