9

I am tasked with designing an application framework that will allow each implementation to customize parts of the user interface. One such example would be that the implementation (let's call it client from now on) can define the collection view cells to return for a particular screen. The framework is simply responsible for vending the appropriate objects to make building an App much easier since we will be building several similar looking instances.

My current approach to the framework has been to design a Coordination Controller that is responsible for all presentation and dismissal events throughout the App. The default Coordination Controller vends out all the default view controllers inside the framework that all perform their relevant tasks without necessarily providing configured UI. For instance: one controller will show a collection view with template cells and nothing special. The benefit of this design is that it removes the coupling between controllers and also allows for a client to override the default coordinator and return an entirely new view controller for a specific task.

The problem I'm having is how should I design this framework to allow a client to add their own custom UI into the App.

Approach One

Make the framework require a view factory and let this view factory be responsible for vending out all the relevant views. Thus, in the App Delegate we might enforce that the client create a CollectionViewCellFactory for instance and the interface defines all the cells that any conforming class will need to supply. I inherited a code base with this design and moved away from it as it was far too abstract and customizable. It came with tons of factories for every aspect of the App and this added days onto the setup time of every App.

Approach Two

Each view controller specifies subclassing hooks or setup API that will allow for these custom UI classes to be defined at run time (Similar to how UISplitViewController allows callers to setup the controllers using the viewControllers property). To do this each client will simply subclass the base Coordination Controller and in each controllers presentation; set the appropriate values onto the controller so that it achieves the desired UI. Something like

viewController.registerReusableCellsBlock = ^(UICollectionView *collectionView){
   //perform custom registration
}

viewController.cellDequeueBlock = ^UICollectionViewCell<SomeProtocol> *(UICollectionView *collectionView,NSIndexPath *indexPath){
   //dequeue custom cells
}

Currently, I separate the data source for a view into a separate object to promote reusability and prevent ViewController bloat. This makes subclassing the view controller to supply the interface of the cells a little harder but not impossible.

Approach 3

Perhaps its a bad idea to attempt to design a framework and anticipate its usage. Maybe the best option is to allow for subclassing with maximum control, even if the setup cost is relatively high. Then, once I've built it for several clients I might notice the patterns that emerge and begin optimization along the route.

I understand how I might make it customizable internal to the framework, what I'm struggling with is how to best define an interface that defines potential customization points of the framework by the client.

TL;DR

The most complicated part of the interface deals with a Collection View nested inside Collection View Cells. This allows for horizontal paging and vertical scrolling of cells. This is achieved by having one data source that manages the horizontal cells and configures each cell's collection view with a new data source.

How would one design an interface that allows all these cells to be customizable?

  • Approach 1 gives the most flexibility, approach 2 the least but requires least effort from your users. So what do you want? – Trilarion Oct 23 '14 at 11:15
  • @Trilarion honestly I'm hoping for senior experience. My biggest concern is not being able to anticipate exactly how much control I need to provide regarding the customization – Daniel G Oct 23 '14 at 11:23
  • 4
    You cannot predict the customization. Defining general purpose frameworks is difficult. At best you can provide some common code that does not limit the other developers in any way. I would avoid solutions that require inheritance, and focus on components that can be extended in other ways. Keep your own contribution as simple as possible. – Frank Hileman Oct 27 '16 at 16:48
1

This is old but worthy question that never got a worthy answer, which, in my experience, in response to

How would one design an interface that allows all these cells to be customizable?

is- don't do it.

Constraining the choices a client can make in customization- whether in UI or in something else- is almost always better for the vendor- because it simplifies the solution and reduces the support burden- and also for the client- because then they are most able to leverage the vendor's expertise to get to the sweet spot of the solution space, without wasting their own time reinventing the wheel.

If they need a different solution, they will tell you. If they insist on customization, they need a different solution and just don't know it yet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.