In my application, I have a homepage with a card / grid with several sections. So a UICollectionView is an obvious choice. But these cards vary greatly in design, data loading and functionality. Thus, all those who are in one controller would be bulky, difficult and difficult to maintain. Therefore, we thought that we needed to split them into our own UIViewControllers . Each processes the type of card and calculates its contents, which will be displayed inside the card. Our main home page controller is responsible for placing these viewcontroller views inside UICollectionView cells.
To summerize,
- HomeViewController that has a CollectionView
- Each view inside the ViewCell collection and its data is supported by its own controller class.
- All controller instances are inside the HomeViewController and added as its children . Apple Guide
- The appearance for all children of the viewControllers is created by us, because the contentSize (which is used as the size of the element for the layout of the collection) for calculating the controllerβs views requires the view to be loaded and the data to be set.
My question is, is this design right? Or what approach would you choose to implement such a screen? Since we create many viewControllers (one for each cell), does this affect memory or performance? And if I want to cache only some viewControllers or load them as the user scrolls or when it is time to add it to the collectionView cell, how do I do this, since the calculation of the size of this cell depends on the data and views when stacking from the CollectionView layout.
source share