Tengo la tarea de diseñar un marco de aplicación que permita que cada implementación personalice partes de la interfaz de usuario. Un ejemplo de ello sería que la implementación (llamémosla cliente de ahora en adelante) puede definir las celdas de la vista de colección para volver a una pantalla en particular. El marco es simplemente responsable de vender los objetos apropiados para facilitar la creación de una aplicación, ya que crearemos varias instancias de aspecto similar.
Mi enfoque actual del marco ha sido diseñar un controlador de coordinación que sea responsable de todos los eventos de presentación y despido en toda la aplicación. El controlador de coordinación predeterminado distribuye todos los controladores de vista predeterminados dentro del marco que todos realizan sus tareas relevantes sin proporcionar necesariamente la IU configurada. Por ejemplo: un controlador mostrará una vista de colección con celdas de plantilla y nada especial. El beneficio de este diseño es que elimina el acoplamiento entre los controladores y también permite que un cliente anule el coordinador predeterminado y devuelva un controlador de vista completamente nuevo para una tarea específica.
El problema que tengo es cómo debo diseñar este marco para permitir que un cliente agregue su propia interfaz de usuario personalizada a la aplicación.
Enfoque uno
Haga que el marco requiera una vista de fábrica y deje que esta vista de fábrica sea responsable de distribuir todas las vistas relevantes. Por lo tanto, en el delegado de aplicaciones, podríamos exigir que el cliente cree una CollectionViewCellFactory, por ejemplo, y la interfaz define todas las celdas que cualquier clase conforme necesitará suministrar. Heredé una base de código con este diseño y me alejé de él porque era demasiado abstracto y personalizable. Llegó con toneladas de fábricas para cada aspecto de la aplicación y esto agregó días al tiempo de configuración de cada aplicación.
Enfoque dos
Cada controlador de vista especifica ganchos de subclasificación o API de configuración que permitirá que estas clases de IU personalizadas se definan en tiempo de ejecución (similar a cómo UISplitViewController permite a los llamadores configurar los controladores utilizando la propiedad viewControllers). Para hacer esto, cada cliente simplemente subclasificará el Controlador de coordinación base y en la presentación de cada controlador; establezca los valores apropiados en el controlador para que logre la IU deseada. Algo como
viewController.registerReusableCellsBlock = ^(UICollectionView *collectionView){
//perform custom registration
}
viewController.cellDequeueBlock = ^UICollectionViewCell<SomeProtocol> *(UICollectionView *collectionView,NSIndexPath *indexPath){
//dequeue custom cells
}
Actualmente, separo la fuente de datos para una vista en un objeto separado para promover la reutilización y evitar la hinchazón de ViewController. Esto hace que la subclasificación del controlador de vista para suministrar la interfaz de las celdas sea un poco más difícil pero no imposible.
Enfoque 3
Quizás sea una mala idea intentar diseñar un marco y anticipar su uso. Quizás la mejor opción es permitir la subclasificación con el máximo control, incluso si el costo de instalación es relativamente alto. Luego, una vez que lo he construido para varios clientes, puedo notar los patrones que surgen y comenzar la optimización a lo largo de la ruta.
Entiendo cómo podría hacer que sea personalizable internamente al marco, con lo que estoy luchando es cómo definir mejor una interfaz que defina los posibles puntos de personalización del marco por parte del cliente.
TL; DR
La parte más complicada de la interfaz trata con una vista de colección anidada dentro de las celdas de la vista de colección. Esto permite la paginación horizontal y el desplazamiento vertical de las celdas. Esto se logra al tener una fuente de datos que administra las celdas horizontales y configura la vista de recopilación de cada celda con una nueva fuente de datos.
¿Cómo diseñaría una interfaz que permita que todas estas celdas sean personalizables?
fuente
Respuestas:
Esta es una pregunta antigua pero valiosa que nunca obtuvo una respuesta digna, que, en mi experiencia, en respuesta a
es, no lo hagas.
Restringir las elecciones que puede hacer un cliente en la personalización, ya sea en la interfaz de usuario o en otra cosa, es casi siempre mejor para el proveedor, porque simplifica la solución y reduce la carga de soporte, y también para el cliente, porque entonces son más capaces de Aproveche la experiencia del proveedor para llegar al punto óptimo del espacio de la solución, sin perder su tiempo reinventando la rueda.
Si necesitan una solución diferente, se lo dirán. Si insisten en la personalización, necesitan una solución diferente y simplemente aún no la conocen.
fuente