Adobe Air ios packager

Parece que hay mucha confusión con respecto a la implementación de aplicaciones de Adobe Air en ios después de que se levantaron las restricciones. Antes de que Apple levantara las restricciones que tenía para pasar por el process documentado aquí: http://blogs.adobe.com/cantrell/archives/2010/09/packager-for-iphone-refresher.html usando el Packager para iPhone. Pero ahora que se han levantado las restricciones y la actualización Air 2.7 podemos usar la misma herramienta ADT en el SDK flexible que usamos con todas las aplicaciones aéreas.

Mi entendimiento es que el antiguo Packager para iPhone (PFI), algunos de cómo convertir el código de script en el objective nativo C para que Apple lo acepte.

Si eso es correcto, ¿se eliminan las restricciones significa que la herramienta ADT no se está convirtiendo al objective C y solo agrupa el file AS3 .swf y el reproductor de air cuando se crea el file de aplicación .ipa?

¿Qué cambió exactamente en el process de deployment aéreo después de que Apple eliminó sus restricciones?

Si alguien puede apuntarme a alguna documentation sobre cómo se crea el file .ipa detrás de escena, creo que esto realmente aclararía cierta confusión.

Gracias por la ayuda

Nada cambió realmente; Apple acaba de levantar la prohibición. La prohibición no era solo en las aplicaciones creadas con flash, sino en cualquier herramienta que creara cualquier tipo de lenguaje intermedio o utilizara una máquina virtual, etc. Lo que hace el PFI: en realidad usa el comstackdor LLVM para comstackr estáticamente actionscript 3 BYTECODE ( no fuente AS3) en ensamblaje de ARM nativo. Entonces, esencialmente, cuando está implementando un IPA, es la misma idea que publicar un SWF a un exe (como en la configuration de publicación) en el sentido de que tanto su aplicación SWF como la máquina virtual flash están agrupadas, excepto que en vez de ser un exe donde el código interno es x86 ASM con AS3 bytecode ejecutado a lo largo de la VM, es ARM. El PFI y todas sus classs simplemente se combinaron en la herramienta ADT. El PFI contenía una LLVM dll a la que se accede a través de varias classs de Java de LLVM que se agregaron a la versión interna de Adobe del comstackdor ASC o ActionScript. Sin embargo, estas classs de LLVM y otras classs asociadas no son de código abierto, lo que adobe se permite, aunque el ASC es de código abierto porque está licenciado bajo la licencia pública MPL o mozilla, lo que permite el uso del código fuente abierto en aplicaciones privadas de código cerrado sin compartir sus cambios.

Como testing de todo lo que te he dicho, solo descarga el nuevo SDK de Flex que incluye el ADT con el PFI combinado y encontrarás el DLL de LLVM, etc. Además, puedes descomstackr el jar de ADT y ver todas las classs de LLVM . Las classs de LLVM (creo) interceptan el bytecode ASC a través de la class GlobalOptimizer, o al less lo hicieron en el día … probablemente hayan cambiado eso. La única otra cosa que ha cambiado es que aparentemente Adobe ha optimizado mucho el PFI (ahora fusionado con ADT). Más información aquí:

http://blogs.adobe.com/cantrell/archives/2010/09/packager-for-iphone-refresher.html

http://www.leebrimelow.com/?p=2754

Actualizar

Aquí hay un artículo oficial de Adobe que confirma las cosas que te he dicho:

http://www.adobe.com/devnet/logged_in/abansod_iphone.html . También debo aclarar que realmente he simplificado en exceso el process detrás de escena y me parece que se equivoca en uno de mis puntos. Supongo que, de alguna manera, el PFI en realidad fusiona el bytecode AS3 y la VM en un solo ejecutable sin usar que no utiliza la compilation JIT y, por lo tanto, técnicamente no sería una máquina virtual. No estoy seguro sobre este punto, pero el artículo anterior parece implicar esto:

"Cuando construyes tu aplicación para iOS, no hay código interpretado ni time de ejecución en tu binary final. Tu aplicación es verdaderamente una aplicación nativa de iOS".