Ver arquitectura del controlador/NIB para la aplicación de no navegación con transiciones?

Question

Estoy jugando con una aplicación para iPad que (como muchas aplicaciones de iPad) no utiliza el sistema de control de vista raíz de uinavigación, por lo que no tengo propiedad natural para cada aplicación "Vista". Básicamente, tengo dos vistas básicas: una vista de lista de documentos y una vista de edición de documentos.

Estoy jugando con UIView Animation para obtener de un documento seleccionado a la vista Editar.

También tengo una barra de herramientas en la parte superior que existe (con diferentes botones) en ambas "vistas".

Debido a que no tengo uinavigation que me ejecute el programa, tengo una tendencia a lanzar más y más cosas en un controlador de una punta y un controlador de vista que posee todo el contenedor. Pero ahora estoy tratando de descubrir cómo aparecer desde la vista de la lista de documentos a la vista Editar si la vista de edición vive dentro de una punta diferente, preservando la barra de herramientas también.

¿Alguien tiene pensamientos o experiencia en estructuras de aplicaciones como esta? Encuentro que los documentos carecen de las mejores prácticas en torno a la estructura del código/UI para cualquier cosa excepto aplicaciones triviales de una pantalla o aplicaciones de navegación completas.

No se supone que "se supone" que los controladores de visión de los padres/niños posean subcomponentes de la misma "pantalla" de acuerdo con los documentos, pero esto implica un controlador de vista masivo que básicamente contiene toda la aplicación, y eso no puede ser correcto.

No estoy seguro si hay una "respuesta correcta" a esto; Estoy buscando algunos ejemplos o sugerencias inteligentes. Nadie ha tocado esta pregunta en meses, así que estoy agregando una recompensa para generar una buena charla. :)

¡Gracias!

ACTUALIZAR: No estoy hablando de una vista dividida, que claramente está bien manejada por un controlador de vista dividida. En su lugar, eche un vistazo a las aplicaciones IWork de Apple (por ejemplo, páginas) que tienen una vista de lista de documentos y una vista de edición independiente, pero están relacionadas con animación.

Tal vez la verdadera pregunta aquí es: ¿cómo podría (o podría hacerlo?) Construir un controlador de vista "contenedor" como la vista dividida o el controlador de navegación, usted mismo? ¿Se le exige que construya toda la maldita cosa desde cero? Siento que lo eres, porque parece ser el cableado oculto en la interacción entre los controladores de vista. Si es así, ¿pensamientos sobre esto?

Answer 1

Creo que el único cableado oculto en los controladores de vistas es configurar ParentViewController, que se requiere para admitir las categorías declaradas para división y navegación.

Los controladores de vista están diseñados para ser anidados, y cada controlador posee una parte de la jerarquía de vista. El único objetivo de diseño es que ningún controlador de vista llegue a la jerarquía de vista de otro controlador. Un controlador de vista principal generalmente tendrá una llamada para agregar controladores infantiles para que pueda establecer el marco de la vista dentro de la jerarquía de vista que posee. Un controlador de vista infantil no debe hacer nada a la supervisión de la vista que controla, ya que es propiedad de otro controlador. No debe establecer el centro o el marco de la vista que controla.

Por ejemplo, un controlador de navegación tiene un método push, en el que elimina la vista del controlador anterior, agrega la nueva vista del controlador y establece el marco de la vista recientemente agregada. En general, un controlador de visión principal es libre de establecer el marco de la vista de un controlador infantil, pero no los límites.

Si desea cambiar la animación de un controlador de navegación, creo que comenzará implementando cada método con un argumento animado. Configure su animación y luego llame a Super con la bandera animada antes de cometer la animación.

Answer 2

No he probado el asunto de los controladores de visión múltiple fuera de los proporcionados por UIKIT (navegación/tabar/modal/etc.), pero no veo por qué no debería funcionar. Bajo el capó, todo es una vista, aunque notaré que UIKIT tiene vistas especiales para los controladores de vista que sin duda tienen algún tipo de manejo especial del sistema (UIViewController tiene una vista de envoltorio, UinavigationController tiene una vista de controla de Uinavigation o algo así, .. .).

Aconsejaría que no se preocupe demasiado por las "mejores prácticas", solo codifique algo que haga lo que desea. Un par de opciones:

• Stick Logic en las clases de vista (¡ewwww!). Una de nuestras aplicaciones hace esto para que pueda manejar la rotación de una manera personalizada (las vistas se deslizan adentro/hacia afuera en lugar de girar). Probablemente deberíamos haber implementado nuestra propia lógica de controlador de vista.
• Romper el modelo en componentes que corresponden a las vistas. Haga que cada vista sepa cómo cargar su componente y cargar recursivamente subcomponentes. Luego, el controlador View solo necesita preocuparse por las cosas de "panorama general".

También tenga en cuenta que puede cargar múltiples nibs en el mismo controlador de vista al conectarlo a una salida llamada EditView. La gran diferencia es que no lo hace automáticamente por -[UIViewController LoadView] para que debe hacer algo como

-(EditView*)editView {
  if (!editView) {
    // Loads EditView into the outlet editView
    [NSBundle loadNibNamed:@"EditView" owner:self];
  }
  return editView;
}

También deberá preocuparse por agregarlo a su jerarquía de vista, descargarla en (void) ViewDidUnload (iPhone OS 3.0+), configurarlo en (void) ViewDidload en caso de que haya una advertencia de memoria durante el modo de edición, etc...

No es fácil, pero UI nunca lo es.

Answer 3

Necesita una vista maestra de detección implementada con una vista de visión dividida/popover y controlada con un UISPLITViewController.

La vista maestra es la lista de documentos y la vista de detalle es la vista de edición. Cada uno tiene su propio controlador. Los dos controladores en sí son administrados por UISPLITVIEWController.

Si no usa el controlador SplitView, simplemente terminará codificando a la mano algo que funcione muy parecido. Esta es realmente la única forma de hacer lo que desea fácilmente en la API y es el diseño que los usuarios de iPad esperarán.

Ver Creando una interfaz de vista dividida En la Guía de programación del iPad para obtener más detalles.