[View]  [Edit]  [Lock]  [References]  [Attachments]  [History]  [Home]  [Changes]  [Search]  [Help] 

[Transcripcion cruda]Reunion COCO8 a Ale Reimondo, Elvio Fernandez y Claudio Campos

Reunion Tecnica COCO8


Ale comenta sobre la complicación de mostrarnos algo en vivo dado que la plataforma es iOS y debería poner apuntando una cámara con el Skype para mostrarnos la pantalla del iPhone, etc.

Claudio: Ale vos hiciste una contribución en U8, hay un zip para bajar; yo lo baje y por lo que vi parte del código está usando los mensajes de NativeObject, del framework de NativeObject. Podrías contarnos un poco lo que hay en la contribución y como funciona. Yo lo que entendí es que vos estas creando clases de Objective-C dinámicamente, puede ser?

Ale: Les cuento un poco como es la plataforma. Si quieren les cuento un par de minutos el motivante para hacer esta plataforma. Entonces arrancamos por ahí y después les cuento lo que sería la forma en que se trabaja, los detalles de implementación que quieran ver y después por ahí lo que estaría bueno es repasar algún ejemplito por acá y vemos juntos el texto, etc.
La plataforma que tenemos, la que sería Cva8 (Cordova + S8), permite desarrollar de manera compatible, compatible me refiero a todo lo que uno escribe en Smalltalk corre dentro de un WebView en un Android, en un iPhone o en un iPad. Cualquier elemento que uno quiera usar y sea nativo se tiene que conectar por medio de un plugin. Toda la plataforma de Cordova está definida con plugins y eso resulta muy cómodo para las aplicaciones normales. Por ejemplo: si uno quiere hacer una aplicación que esta accediendo a datos locales, que este viendo si esta la conexión wifi abierta, que este bajando datos directamente de un servidor, etc. Todas esas cosas ya Cordova viene con plugins y tiene especificadas las API’s donde uno por medio del framework Cva8 directamente desde S8 Smalltalk accedemos a toda esa API que es bastante extensa y está muy buena. Así uno puede hacer aplicaciones que corren dentro de una WebView, es decir aplicaciones que son HTML5 mas accesos nativos dados por Cordova o por alguna extensión que uno haga haciendo plugins nuevos. Ahí es donde está la parte extensible de Cordova que está buena, porque uno hace el plugin y después la conexión con el plugin se conecta directamente desde Smalltalk. Es decir, en Cordova te proponen que vos tengas que escribir en un archivo aparte en Javascript, pero en el framework Cva8 ya implemente absolutamente todo lo que uno tiene que hacer para conectarse con un plugin nativo y lo hace directamente desde S8.
[NM(1): Como es la plataforma, qué hay hecho hasta hoy]

Elvio: En Cordova el plugin hay que escribirlo a bajo nivel?

Ale: El plugin lo tenes que escribir con el tool de cada plataforma. Es decir tenes que implementar el plugin en cada plataforma que va a ejecutar. Entonces lo tendrías que tener implementado en iOS y en Android.

Elvio: Perdón, y la conexión en javascript es algo engorroso?

Ale: No, no es engorroso la conexión desde el lado de javascript, y te agregaría que, menos desde el lado de Smalltalk. Lo que es engorroso es escribir del lado nativo. Porque las dos plataformas iOS y Android son distintas. Y porque principalmente el plugin no necesariamente corre en el mismo espacio de ejecución, en el mismo thread, que el WebView. Entonces esto complica la escritura del plugin.
Una complicación es que en algo que sea nativo vos preguntaras y el valor volviera inmediatamente, pasar por el plugin del lado de javascript, hace que no llegue en la misma operación. Es decir vos tenes que hacer como si fuera un callback. Un bloque que se va a activar cuando el plugin logre tener el valor. Entonces eso empieza a complicar todo el modelo de programación. Porque va a un modelo asincrónico.
[NM(2): Cva8, coneccion de plugin, problematicas]

Claudio: Si vos integras el mecanismo de generators que te permite escribir de manera secuencial sin complicar el fuente, o lo lineal del fuente, crees que solamente esas implicancias tiene o también además hay un tema de performance, de eficiencia?

Ale: No, en una plataforma puede ser de una manera y en la otra de otra. La verdadera razón es porque la forma más compatible, es que sea esa. Entonces desde arriba uno siempre espera de forma diferida el resultado. Y después la implementación nativa puede encolar el resultado antes o después, pero el tema es que son cosas puntuales las que puede devolver inmediatamente el valor.

Elvio: pero por ejemplo Ale cuando tomas datos de teclado,…

Ale: ese un buen ejemplo en donde no podes hacerlo instantáneo.

Elvio: No es instantáneo?

Ale: No lo que pasa es que uno lo que hace es crear un elemento de interfaz y ese mismo elemento de interfaz te esta disparando el evento. Ese evento ya tiene el dato. Entonces en ese caso no hay problema porque lo que fue diferido fue la atención del evento. El tema es cuando, para darte un ejemplo….
(acá mi conexión empezó a meter mucho ruido, yo estaba en un bar y se colaba todo el ruido de música y tazas y platos golpeándose… así que perdimos el hilo de lo que estaba explicando Ale para ayudarme a aplacar el volumen del micrófono que yo como un salamito no encontraba dentro del Skype. Esta parte me gustaría preguntarle a Ale a ver si se acuerda lo que iba a decir)
Todo el diseño del plugin de Cordova está planeado para que cuando uno pide algo viene en un callback y eso genera problemas en varias cosas. Este es una de los motivantes, que no es algo que moleste demasiado, pero si es un factor de incomodidad cuando uno desarrolla. Al menos cuando uno desarrolla en Smalltalk uno esta más acostumbrado trabajar más imperativamente.
[NM(3): Cva8, detalles de implementación y naturaleza asincronica del desarrollo]

Claudio: Eso me pasó a mí en NodeJS.

Ale: Si claro claro, es un modo de trabajo que es muy costoso porque fracciona el sistema.

Claudio: Por eso te decía que con Generators uno podría hacer un poco más sincrónica la lectura del código.

Ale: Claro pero no es el único problema que le veo a Cordova. Digo, no es el mayor problema. El mayor problema es que la aplicación queda dentro de una WebView. Y qué implicancias tiene eso? Uno diría: “bueno vos pones todo dentro de una ventana si después lo que dibujas adentro se puede ver igual”. Que eso es la aplicación esa que yo hice hace un tiempo, Elvio la vio, vos Claudio no sé, creo que no. Yo hice una aplicación con Cordova en donde el look es el de iPhone, después estuvimos trabajando un poco en tratar de minimizar el tiempo que llevaría cambiar de look y demás, entonces uno podría pensar en usar HTML5 para renderizar la interfaz y hacer un skin que sea igual a cada una de las plataformas y listo. Pero eso no termina viéndose/sintiéndose nativo. Porque en los teléfonos por ejemplo en iOS, en los modelo nuevos sobre todo, el usuario está acostumbrado que las cosas se muevan en interfaz. Que se mueva toda la ventana. En Android ya se está empezando a ver exactamente lo mismo. Y eso invalida la idea de tengo todo en una WebView, porque nunca vas a tener la performance que tenes cuando lo haces nativo.
[NM(4): Detalles de implementación. Motivantes para el desarrollo de COCO8]

Elvio: Si, la interfaz fluye distinto.

Ale: Si, claro pero si uno dice: “bueno puedo programar para todas las plataformas” pero después no se puede ver igual que en ninguna, estamos como cuando decíamos: “bueno trabajamos en Smalltalk y nuestras pantallas son de color pastel y muy lindas pero no se ve igual que en ningún sistema operativo! Eh? Naces con un look con un jopo de viejo terrible (risas).

Claudio: Che yo seré un hereje pero a mí me gusta SenchaTouch. Hay un caso en que facebook había hecho una aplicación en HTML5 y después dijeron que HTML5 no servía para hacer aplicaciones eficientes en móviles y los tipos reescribieron la misma aplicación en HTML5+SenchaTouch y era muchísima más eficiente que la que habían hecho en facebook y además mostraban los errores que habían sido cometidos. Yo no soy usuario de iPhone por eso te doy el beneficio de la duda del planteo que haces con respecto a eso porque nunca tuve un iPhone en mis manos ni tampoco nunca lo use. Tendría que cargar una aplicación de SenchaTouch y percibir si hay diferencias.

Ale: Si digamos, si yo te digo el look lo hago similar, no resolviste la parte del feel. Y es muy importante. Eso desde el punto de vista del usuario es importante. Estamos haciendo un gran esfuerzo para después vernos “viejos” o como un “bicho raro”, que se note diferencias porque uno lo hizo, me parece mucho esfuerzo para obtener insatisfacciones después. Y el tercer punto (me cuesta ordenar en importancia, hasta ahora los dos que nombre me parecen muy importante) El tercer punto, también me parece muy importante, no sé si más o menos que los dos anteriores y es el siguiente. Yo estuve trabajando bastante tiempo en escribir plugins que sean widgets nativos y usar Cordova para instanciar y para setear y para tener los eventos de esos elementos nativos. Es decir, hice la experiencia de trabajar con Cordova y una WebView pero minimizo la WebView o la pongo en otro lado y creo widgets nativos y desde Smalltalk accedo a esos elementos nativos vía un plugin. Entonces ahí me fumo el tema del callback, pero si eso termina siendo conveniente tengo un look & feel. Tengo lo que busco.
Ehh… costó escribir los plugins (risas) pero creo que fue una buena experiencia que logre hacer para las dos plataformas. No con muchos elementos pero si lo suficiente para lo que quería evaluar. E hice una valoración de qué era lo que me quedo. Y qué encontré? Que en realidad es muy importante la energía que uno pone en la parte de los plugins. Para escribir algo que funciona igual en iOS con el tool de XCode5, con lo mejor que tiene la plataforma iOS, para escribir el plugin, configurar todo y demás, que eso lo tenes que hacer si o si trabajando con Cordova. La documentación que hay sobre los plugins es bastante escueta, entonces la implementación no es algo que lo hace cualquiera, me imagino, pero lleva bastante tiempo hacerlo y testearlo. Con Android exactamente lo mismo, es un poco más precario la forma de hacerlo, en lo que respecta a como uno escribe el código, el tool es el eclipse entonces es equivalente al XCode y el esfuerzo de escribir los plugins es equivalente. Y en los dos casos, es mucho mayor que si uno estuviera laburando en Smalltalk. Esto me parece muy importante porque el costo de mantenimiento (un costo que se multiplica por cada plataforma que uno camine) del plugin implica mantener los tools todo el seteo, por ejemplo me paso con el XCode que actualizaron y dejo de andar y la gente de Cordova decía que en la próxima versión lo iban a tener resuelto y la gente decía: “pero como, la otra versión la tienen planificada para el otro año!”.O sea dejo de funcionar Cordova para XCode5 que es la última versión para Apple y los tipos lo van a actualizar cuando hagan el próximo release. Mientras tenes que compilar con una versión de XCode anterior que no es la ultima de Apple, es decir, todo para atrás, viste? Son los costos que tiene la manutención de un sistema que está escrito en más de un tool.
[NM(5): Cva8, costos de implementación. Probelamticas: look & feel y multiples plugins (uno por cada plataforma) en Cva8]

Elvio: Cual sería un caso concreto de un plugin.

Ale: El widget de la fecha, el calendario que es como un tamborcito que corre la fecha. En iPhone es algo que toda la gente lo identifica como de iPhone y todos dicen es una porquería, pero las aplicaciones usan eso. Android tiene una forma un poquito más elegante pero también es nativa. Y en la plataforma web, al día de hoy, no hay nada decoroso. Si lo hacemos con HTML5 hay que hacer un control custom que vos haces en HTML5 y no andar con una rueda con toda una animación que no la podes lograr igual con HTML5, o lo vas a lograr al costo de rehacer la rueda. Ese me parece que es un buen ejemplo de un control que tiene que ser nativo. Yo estoy seguro que la WebView de Android muy pronto ya lo va a traer cuando vos pongas un campo fecha en un formulario. Pero al día de hoy y hace 4 meses no estaba. Entonces es un candidato que uno tendría como un plugin y de hecho hay tres o cuatro proyectos de plugins para Cordova, ninguno igual, y algunos son para iOS y otros para Android. Tenes toda esta problemática, si tenes que usar un plugin, te lo vas a hacer vos, porque si vas a tomar de uno o de otro no te andan para todas las plataformas. Porque cada uno hace para los equipos que tiene. Entonces este es un buen ejemplo para ver que ir vía un plugin y hacer un plugin nativo es una frazada muy corta. Pensando en ese problema me costó mucho decir bueno dejo de lado lo del WebView porque la comodidad de trabajar con HTML5 y todo lo que tenemos estaba dentro de una WebView te tienta a decir: “eso no lo podes sacar ni loco”. Entonces empecé a buscar, primero tratando de hacer andar V8 en forma nativa en iOS y encontré un proyecto que se llama jsCOCOA (ver bien como se llama el proyecto no sé si Ale se equivoco pero yo encontre jsCOCOA) que es la base de lo que estoy usando ahora. Y es interesante lo que hacen, y es levantar la VM de javascript de Apple, que es la que usa el WebView de Apple, y cargan un framework que integra esa VM de javascript con la librería de FFI, de llamadas a API, y desde esa manera desde javascript tenes una interfaz a C y Objective-C. Esta muy bueno eso…
[NM(6): Evaluacion del desarrollo basado en Cva8 (plugins). jsCOCOA]

Claudio: Esa librería de FFI funciona en Android?

Ale: Hay una versión para Android pero todavía no la pude hacer andar. No sé si anda o no en la última versión, pero cuando la probé no andaba. Estaba en desarrollo todavía. Pero para iOS me encontré con un precedente, los tipos habían trabajado bastante sobre la parte de javascript es decir, había una parte que no me servía, hacían las cosas más complejas de lo que necesitaba. Pero tenía ahí una base, y no andaba en el teléfono de verdad. Andaba en el simulador. Y no andaba porque una de las parte en assembler que tenía en FFI no andaba en el teléfono y empecé a buscar en otros proyectos. Y encontré dos o tres proyectos de FFI para iPhone y ninguno de esos andaba en el telefono. Es decir por diferentes ensambladores por diferentes versiones de XCode no había caso. Entonces volví al (… aca se corto el audio y no sé que dijo Ale. Y continúa con lo siguiente) … de iPhone y iPad que hay ahora. Los puse, los “debuguié” y saque andando FFI en el iPhone y en el iPad y lo integre, es decir saque una versión más nueva, con lo de estos tipos entonces tuve andando las partes que quería. Es decir, podía instanciar la maquina virtual, cargar un image de S8-U8 y acceder a las clases de Objective-C, y la parte que ellos tenia de generación de clases que ellos ya estaban haciendo me sirvió.
Entonces con esto escribí una aplicación una de las demos que ellos tenían que es de una estrellita, es un widget grafico nativo como si fuera el GraphPane que dibuja una estrella, mas un control que le cambia la cantidad de lados que tiene la estrella (acá se entrecorta de nuevo …) luz y sombra, maneja drag & drop sobre ese elemento visual y va girando la estrella con drag & drop, o va cambiando de forma. Es una demo bastante simple, pero fue mi mayor motivante para meterme por ese camino porque vi la posibilidad de que uno puede hacer un panel grafico con cualquier dibujo, con cualquier cosa y manejar los eventos y generar los cambios dinámicamente en toda la grafica en tiempo real.
Implemente las partes de bajo nivel en S8 Smalltalk, sacando toda la parte de javascript. Es decir me quede con lo que era útil quedando escrito en S8. No necesitaba más nada, ni de ninguna incorporación de nada en javascript.
Al final lo que tenemos es una aplicación XCode que lo único que hace es levanta el engine de javascript y carga un image nuestro, y ese image cuando carga, arranca el image de la aplicación. Luego la aplicación esta escrita totalmente en S8 Smalltalk. Esto se logra porque tenemos un mecanismo de reflexión. Hice una jerarquía en Objective-C ( aca se corta definitivamente la comunicación, nos volvemos a reconectar e intentamos continuar el hilo de la conversación)
En Objective-C la clase equivalente a Object de Smalltalk se llama NSObject, yo lo que hice es en S8 tenemos una clase que se llama ObjectiveCImplementation y la única subclase, en teoría, de esa clase es NSObject. Se llama igual a la de Objective-C. De ahí para abajo uno agrega subclases con nombres de clases que pueden estar en Objective-C , o no, en el runtime de Objective-C. Es decir, cuando carga nuestra imagen de S8, lo que va a hacer la imagen nuestra después de cargar es ir a esa clase ObjectiveCImplementation y para todas las subclases de Smalltalk se fija si esa clase está actualmente corriendo en Objective-C. Si esta, no hace nada en el startup del sistema; y la clase se usa como un wrapper de la existente en Objective-C (runtime). Si no está, crea una clase del lado de Objective-C (S8) que se llama igual y le instala algo que uno pone en un literal que lo implementa en un método de la clase, que es la interface que uno le pone a esa clase. Entonces se instancia una clase del lado de Objective-C (S8) y con esa interface, se agarran los métodos que estén implementados del lado de instancia en Smalltalk, que uno definió en esa interface, y se instala del lado de Objective-C como wrappers de métodos, véanlo un poco así. Es decir, se instalan métodos de Objective-C, que cuando son llamados llaman a javascript, activando el método smalltalk. Se entiende?
(...silencio)
[NM(7): Detalles de implementacion de COCO8. Arranque de sistema, activación de metodos Objective-C]

Claudio, Elvio: más o menos…

Elvio: Lo que no entiendo es cómo haces para ver las clases que están del lado de Objective-C.

Ale: Hay una capa de reflection para eso. Vos podes ver si existe una clase con un determinado nombre, esa clase que métodos implementa, podes instalar un método en esa clase, pero no cualquier método, sino que tiene que ser un método que vos tengas instalado del lado de la clase de Smalltalk e implementado como un método de la instancia.

Elvio: O sea lo que primero haces es llamar a la capa de interface del lado de Objective-C y le preguntas: “Dame todas las clases que tenes” empezas a levantar eso y del lado de S8 lo levantas también.

Ale: No. Tu aplicación tiene un image y de las clases que hereden de NSObject (del lado de Smalltalk) se recorren todas las subclases y se ven si no están implementadas en Objective-C, las que no estén implementadas, se implementan como clases que cuyos métodos están del lado de S8. Entendes? (…silencio…) Es decir, uno arranca con un sistema que es el que tiene los frameworks de base de Objective-C y después carga un conjunto de clases del lado de S8 que si no llegan a estar en Objective-C, se implementan, entonces es como que se prende todo tu sistema Smalltalk al runtime de Objective-C cuando el sistema arranca.
[NM(8): Arranque de un sistema implementado en COCO8. Capacidades de reflection]

Claudio: Esas clases que no están del lado de Objective-C, que son clases de tu aplicación?

Ale: De cualquier cosa, y ahí es donde viene la parte interesante. …

Elvio: Si esta debajo de NSObject lo va a implementar.

Ale: Claro, pero es el equivalente a Object. Por ejemplo: las ventanas, los archivos, las librerías de acceso a file system, sockets, widgets, todo iOS esta imeplementado debajo de NSObject. Hay algunas excepciones porque también tienen proxys y demás, pero para lo que estamos hablando ahora, vos podes implementar una clase que cuelga de cualquier clase de Objective-C. Entonces vos podes subclasificar, por ejemplo, TextView. Podes subcliasificar cualquier panel, o subclasificar un file un directory.

Claudio: Y esa subclase es una subclase de S8…

Ale: es una subclase que vos implementas en S8 y en un método que vos lo pones como si fuera un método primitivo, arriba le decis: “este es un Objective-C method”. Que es completamente en Smalltalk y si queres, o necesitas, decis: “super tal cosa” y se va a hacer el super en Objective-C.
[NM(9): Transparencia de activacion de metodos del lado Smalltalk y Objective-C]

Claudio: Ale, vos te traes las clases que vos estas usando en la app que necesita cargar, o te traes toda la jerarquía? Si te traes toda la jerarquía sería imposible…

Ale: Claro, no. Nosotros cargamos un image. Ese image tiene debajo de NSObject implementados clases con nombres, con la misma jerarquía, que concuerdan con los de Objective-C. Y algunas clases más que son de aplicaciones que son sublcases que no están en el runtime de Objective-C.

Claudio: Las clases que vos vas a usar las definis vos en la jerarquía de tu aplicación. Y despues el framework busca cuales corresponden con las que ya existen.

Ale: En el startup del image se recorre ese pedazo de jerarquía y cuando hay una clase que no se encuentra, no está del lado de Objective-C, agarra y se crea del lado de Objective-C esa clase y se va a buscar lo que seria la API de la clase. Y con esa definición se instala en Objective-C métodos que llaman a Smalltalk cuando se active el método Objective-C.
[NM(10): Detalles de implementacion en el startup del image. Mecanismos]

Elvio: Ale, y como se instala del lado de Objective-C?

Ale: Ahora en un momento les comento mas. Pero quiero que entiendan un poco como es el mecanismo de booteo. Porque eso va a servir para que entiendan como uno haría una aplicación. Imaginemos que vamos a hacer una subclase de un TextPane. Uno implementa unTextPane que hace en uno de los métodos algo antes y hace “super tal cosa” y entonces eso va a la implementación de Objective-C del panel original. En ese caso, lo que se hace es definir una subclase de ese panel de texto, que es nueva, y ahí dice el método “tal” que está en al API del panel de texto, yo lo voy a sobre-escribir, uno pone el mismo nombre de mensaje y los mimos argumentos, para que entonces cuando al objeto ese cualquier parte de Objective-C mande ese mensaje, viene a javascript y se activa el método S8, y en ese método vos haces lo que quieras hacer y haces el super para que vaya al método nativo de la superclase en Objective-C. Entonces te permite innovar en métodos que son de base de Objective-C. Ahora que pasaría con un método que vos implementaste en Smalltalk de la misma clase y es interno de tu implementación. No es necesario llevar ese método a Objective-C, porque ahí no conviene andar saltando a Objective-C, a mitad de camino. Entonces esos métodos no se ponen en la interface de la clase tuya, la que se va a replicar del otro lado, se ponen nada más que en los métodos que son, de alguna manera subimplementaciones, entonces esa parte corre toda en S8. Y los mensajes que se llamen o que suban y activan métodos que son de S8 (de Object de S8) y demás, eso la ejecución es toda en javascript, y va a ir al espacio de Objective-C en la situación que se haga un “super” o que se envíe un mensaje a un objeto que está del otro lado. Del lado de Objective-C, y ahí, ocurre el camino inverso, del lado que no es nuestro se hace la llamada a un método, se transforman los argumentos, para que vaya a Objective-C y se active Objective-C y devuelve. La ventaja que tiene todo esto es de mensaje y el resultado vuelve instantáneamente. Entonces, uno puede acceder a cualquier cosa que sea nativa. Uno puede subclasificar lo que está en nativo escribiéndolo en Smalltalk, sin perder nada de la forma de trabajo de Smalltalk y de envio de mensajes instantaneo. Salvo en las cosas que que son ya por naturaleza diferida. Por ej: buscar algo a la web y cuando vuelva vas a tener por medio de un mecanismo diferido el resultado, pero todo lo que tenga que ver con llamadas a la API o llamadas al framework de base se accede con muy buena performance y se tiene un objeto que va a venir de manera directa, o te va a venir un proxy de Objective-C al cual se le va a poder enviar mensajes como si tuvieras el objeto en Smalltalk. Entonces la forma de programar una aplicación es muy transparente y se puede usar cualquier parte del framework del iOS e incluso subclasificarlo y crear instancias de las subclases, enviarlas en llamadas API donde estas enviando una instancia de una subclase, todo eso funciona al pelo.

Claudio: El ida y vuelta de la activación de los métodos me interesaría verlo.

Ale: Yo ahora les paso código así vemos juntos. Lo que pasa es que ahora vamos a entrar a algo que requiere un poco de conocimiento de cómo funciona iOS, por eso lo fui retrasando un poco, pero podemos ver lo mínimo.

(…Ale nos pasa un archivo st por skype y luego nos comparte la pantalla)

Ale: Bueno ahí pueden ver que dice NSObject sublcass COCOApp. Ese nombre… bueno digamos lo más lindo ahí es COCO8, todo lo demás es una porqueria característica de Objective-C, van a encontrar nombre extremadamente largos, como cuando uno comienza a trabajar en Smalltalk, viste que uno empieza a pegar un monton de cosas y pone todos los nombres… o pone “App” en vez de “Aplication”. En el nombre del mensaje pone #applicationTalCosa y en la clase pone “App”; y uno lo que más escribe son mensajes, viste? Pero bueno, mas alla de eso la forma de trabajar en iOS uno lo que hace es definir un objeto al cual se va a delegar lo que tiene que implementar una aplicación. Eso se hace asi, en los manuales de iOS lo van a a encontrar porque es el “Pattern” que hay que usar para hacer aplicaciones. Pero en realidad es así porque la aplicación cuando arranca esta en un problema (la aplicación de Objective-C), que si uno no le escribe en el código a mano cual es la clase y uno no quiere subclasificar la aplicación, entonces hay parte del protocolo que uno lo tiene que implementar aparte, y para eso se una un patrón de delegado, es decir, se instancia una aplicación y se busca un delegado para complementar la aplicaion en los mensajes que son de implementación para que arranque. Es como un truco para no tener que subclasificar, es más o menos como cuando uno ve las ideas que son un poco más modernas de traits y demás que en realidad lo que están tratando intentar pegar cosas con plasticola para no subclasificar.
Entonces nosotros implementamos para hacer un aplicación un AppDelegate y lo colgamos de Object. Cualquier clase que uno implemente la puede colgar del Object de Objective-C porque al ponerlo ahí ya hereda todos esos mecanismos, que cuando yo les dije que el image carga se instala la clase y demás. La instalación de una clase y de su protocolo y demás, se puede hacer dinámicamente también mandándole enviándole mensajes a la clase pero ocurre automáticamente si ya está en image. Es decir, esto no invalida que uno pueda cargar frameworks e instalarlos dinámicamente.

(…aqui se dejo de transcribir la reunion dado que sin los materiales/recursos (pantallas, codigo fuente) que se nombran en la reunion es muy dificil de seguir )