Create recursive layout

Question

I'm creating an application that receives a dynamic and recursive data structure, ie, an element can have an identical element within it, something similar to the HTML´s DOM.

At this stage I have "simple" elements type text, date, buttons, and others likes: grid, tables and sections. These last ones, can have a elements inside is structure, something like childrens, for example, a grid element can have other grid.

These models elements are already being built on a framework through my JSON received, usign a Factory pattern. In that order, i have already a list of elements to be drawn in the view.

My first approach was to implement a UICollectionView, but now i am having trouble drawing elements belongings to others. Any idea what the best approach to solve this problem? always taking into account the performance of the app.

Thanks in advance

Answer 1

I am not 100% sure about your questions but sticking to your 'how can I create dynamic layout supporting recursion', I'd advise the following

• Create a UIView subclass
• Give it a model property (e.g. @property GridModel model) or give it an initialiser method with model (e.g initWithModel:(GridModel *)model)
• In either drawRect method or initialiser methods, make it draw its subviews based on the model
• In your code, parse the json and according to the type of object, initialise this special subview and make it draw
• To draw many subviews dynamically and recursively, keep track of your y offset and make sure next subview starts from where the previous subview ends

Does this make sense?

Answer 2

Beware of auto layout in such complex layouts. Auto layout has a cost, and the more views and more complex the scene is, the more toll it takes. Adding and removing constraints is costly, and layout passes themselves are costly.

Looks to me a rather simple layout where a collection view is placed inside a table view. Main view seems like a table view (can be a collection but is simple for that). Each element is a cell. Since you tell the table view the cell size, you can have whatever you want inside as long as you can calculate the size. In fact, the section element to me looks like the same table as the main table. Grid element is a collection view. You could do it as a grid view, and then you can use more reuse.

So let's take a look. Simple elements first, text element, date element, title section and footer section are either simple table view cells or collection view cells. Table element looks like a collection view to me but can be anything custom. A grid is a collection view with a flow layout. If you implement everything with collections, you can reuse the same classes for text and date elements as the ones in the main view, otherwise you use collection view cells here. Section element is a cell with a table view. The cell can act as a data source of the table view, or there can be a "nested table controller" which the cell can use as data source of the table view. To get the height of the section element cell, you can get the table view's content size's height and return that. If we further consider, the main view is basically a top level section element table. If you pick the "nested table controller" root, your main view controller can have that as a datasource of the main table view.

To track elements in the section nested view controller (or cell-as-data-source model), I recommend having an array of data representing, and an enum to determine the type. This way you can design the various types and select the cell identifiers based on the enum.

A crude object representation of this backing data structure would look like this:

{
    type: Section
    items: {
        {
            type: Text
            items: {}
        },
        {
            type: Date
            items: {}
        },
        {
            type: Grid
            items: {
                {
                    type: Text
                    items: {}
                },
                {
                    type: Date
                    items: {}
                },
                {
                    type: Text
                    items: {}
                },
                {
                    type: Text
                    items: {}
                },
                {
                    type: Date
                    items: {}
                }
            }
        },
        {
            type: Section
            items: {
                {
                    type: Title
                    items: {}
                },
                {
                    type: Text
                    items: {}
                },
                {
                    type: Grid
                    items: {
                        {
                            type: Text
                            items: {}
                        },
                        {
                            type: Text
                            items: {}
                        },
                        {
                            type: Text
                            items: {}
                        }
                    }
                }
                {
                    type: Text
                    items: {}
                },
                {
                    type: Footer
                    items: {}
                },
            }
        },
        {
            type: Table
            items: {
                ...
            }
        }
    }
}

This gives you the same example as your above example scheme.

Parsing this is very simple. At the top, you can either always assume there is a section element, or, even better, just iterate the top level items and use each item's type and in cellForRow: return an identifier according to the type, and if a complex type, pass the array of sub-items to the cell, who would perform the same logic and so on.

I used a table view for the vertical flow because they are easier to manager. You can use a collection view with a vertical flow layout as well.

Using iOS7's table view estimatedRowHeight, you could even not parse everything but only the most immediate cells for optimization, and create more and more as the user scrolls.