objective-c - mac - xcode features

¿Cómo creo interfaces Cocoa sin Interface Builder? (5)

Preferiría crear mis interfaces programáticamente.

¿Por qué? Interface Builder es más fácil y más rápido. No puedes escribir un error al arrastrar y soltar, y no obtienes esas prácticas guías Aqua cuando estás escribiendo rectángulos a mano.

No luchar contra eso. Interface Builder es tu amigo. Deja que te ayude

Si insistes en perder tu propio tiempo y energía escribiendo tu UI en código:

No basado en documentos (generalmente basado en bibliotecas, como Mail, iTunes, iPhoto): cree una subclase de NSObject, ejemplifíquela y conviértala en el delegado de la applicationDidFinishLaunching: , y en el método applicationDidFinishLaunching: del delegado, cree una ventana, rellene con vistas y pídelo de frente.

Basado en documentos (como TextEdit, Preview, QuickTime Player): en el método makeWindowControllers en su subclase de NSDocument, cree sus ventanas (y rellenelas con vistas) y cree controladores de ventana para ellas, asegurándose de enviarse usted mismo addWindowController: para cada ventana controlador.

Preferiría crear mis interfaces programáticamente. Parece que todos los documentos de Apple Developer asumen que estás usando Interface Builder. ¿Es posible crear estas interfaces programáticamente y, de ser así, dónde empiezo a aprender cómo hacerlo?

Pensé que el documento relevante para esto, de ser posible, estaría en esta sección: http://developer.apple.com/referencelibrary/Cocoa/idxUserExperience-date.html

Aunque esto es un poco antiguo ... Intenté muchas veces hacer todo solo mediante programación. Esto es difícil, pero posible.

Actualización : publiqué otra pregunta para este problema específico: NSOutlineView basado en la vista sin NIB? , y ahora creo que todo se puede hacer de forma programática, pero es increíblemente difícil sin consultar con los ingenieros de Apple debido a la falta de información o ejemplos.

El argumento a continuación podría estar fuera de tema, pero me gustaría señalar por qué lo prefiero de manera programática.

También prefiero la forma programática. Porque

La herramienta de diseño estático no puede manejar nada dinámico.
Reproducir el mismo estado de UI en múltiples NIB es difícil. Todo está implícito u oculto. Debe visitar todos los paneles para encontrar parámetros. Este tipo de trabajo es muy fácil de cometer errores, es un error amistoso.
Gestionar el estado coherente es difícil. Porque reproducir el mismo aspecto es difícil.
Automatización imposible. No puede hacer forma de entrada generada automáticamente.
La indirección del parámetro, como el tamaño del elemento variable elegido por el usuario, no es posible.
Apuntar con un punto pequeño es mucho más difícil que golpear teclas del tamaño de un dedo en una ubicación fija. ¡Es gracioso que este sea un serio problema de usabilidad para los desarrolladores!
IB a veces los tornillos. Lo que significa que es compilable y sigue funcionando, pero cuando abro la fuente, se ve rota y la edición adicional se vuelve imposible. (Puede que aún no lo haya experimentado, pero si el archivo XIB se vuelve complejo, debe suceder)
Es una serialización basada en imágenes. El concepto es bueno Pero el problema es solo por imagen. IB no mantiene el código fuente para el inicio limpio al reproducir el código fuente. El arranque limpio es muy importante para garantizar un estado de funcionamiento específico. Además, no podemos corregir los errores en el código fuente. Los errores solo se apilarán infinitamente. Esta es la razón principal por la cual no podemos reproducir el estado UI igual (que no se ve) en IB.

Por supuesto, estos productos se pueden resolver mediante el procesamiento posterior de la interfaz de usuario NIB, pero si tenemos que configurar todo de nuevo , no hay ninguna razón para utilizar IB al principio.

Con el código de texto, es fácil reproducir el mismo estado, solo copie el código. También es fácil inspeccionar y reparar la pieza incorrecta, porque tenemos control total. Pero en IB, no tenemos control sobre detalles de núcleo duro.

IB no puede ser la solución definitiva. Es como un Photoshop, pero incluso Photoshop ofrece funciones de scripting basadas en texto. GUI es un programa en movimiento, y no una imagen estática o gráfica. Un enfoque IB es completamente incorrecto incluso para la edición visual de la GUI. Si usted es una de las personas de Apple que está leyendo esto, le ruego que elimine completamente toda la dependencia de IB lo antes posible.

Como desarrollador completamente ciego, puedo decir que IB no es compatible con VoiceOver (el lector de pantalla incorporado en OS X).

Esto significa que sin acceso a una sólida documentación sobre el uso de Cocoa sin IB no puedo desarrollar aplicaciones para OS X / iPhone en Cocoa, lo que significa que (irónicamente) no puedo desarrollar aplicaciones que sean accesibles para los ciegos (y todos los demás) en OS X / iOS.

Mi solución actual, que preferiría no usar, es Java + SWT, por supuesto, esto funciona para OS X, no tanto para iOS.

De hecho, IB se vuelve totalmente inútil cuando comienzas a escribir tus propias clases de UI. Digamos que creas tu propio botón que usa un sistema de máscara basado en un plist. O puede crear una barra de herramientas dinámica que cargue y descargue elementos según la selección del usuario.

IB no acepta elementos personalizados de interfaz de usuario, por lo que una interfaz de usuario más compleja no puede usarlo. Y SÍ, querrá hacer cosas más complejas que el UIKit le ofrece.

Me gusta la pregunta, y también me gustaría saber de recursos para ir sin IB. La utilidad (el "por qué") está limitada solo por la imaginación. Fuera de mi cabeza, aquí hay algunas razones posibles para programar IU explícitamente:

Implementando un mejor Interface Builder.
Programación de IU dinámicas, es decir, aquellas cuya estructura no es cognoscible de forma estática (en tiempo de compilación / xcode).
Implementación del back-end de Cocoa de una biblioteca o lenguaje multiplataforma para UI.

Hay una serie de publicaciones en el blog sobre el trabajo sin punta y una descripción reciente de Michael Mucha sobre cocoa-dev .