I am looking at displaying a database record. The layout is designed by the user but typically looks more like an index card than the row of a spreadsheet.
There might be 20-30 fields in a record. Multiplying by the number of records that might be on the screen at a time, that could be a lot of fields.
Most fields are text, so UITextView is a natural choice. But is UITextView too heavy or expensive to be used in so many copies?
I seem to have 3 choices, in ascending order of apparent efficiency and also ascending order of difficulty of implementation:
- Have one UITextView per field.
- Have one UIView subclass per field, designed to look like a UITextView but be cheaper. When the user comes to edit, the current field (but no other) can be overlaid with a UITextView to enable editing.
- Have one UIViewSubclass for the entire record, designed to look like a collection of UITextViews but cheaper (one view per record instead of one view per field). When the user comes to edit, overlay the current field (but no other) with a UITextView to do the editing.
I would welcome advice as to how expensive UITextView actually is. Is it in fact so cheap that there is no point in working hard to avoid having many UITextViews?
In general, it is preferable to use UILabel for displaying short contents especially when many instances are displayed at once in a screen.
UITextView is designed to handle a large amount of text and have overheads associated with it.
When needed to edit contents of a cell, you could overlay either UITextView or UITextField at that point.
