Get best of the week

Probar proyectos sin dolor. Informe Yandex

En el equipo Yandex.Maps para iOS creamos proyectos de prueba usando un pequeño complemento para CocoaPods y varias clases de utilidades. Crear un proyecto es rápido y confiable. ¿Pero tal vez nos molestamos demasiado y no es tan difícil armar un proyecto manualmente con las configuraciones y dependencias necesarias? En el informe, pasé de lo opuesto: primero miré el proceso manual, luego el nuestro.


- Primero, un poco de historia. Yandex.Maps se recopilan durante más de un minuto. En mi computadora, construir la aplicación lleva un poco más de tres minutos. Desarrollamos en proyectos de prueba para pasar menos tiempo en cada ensamblaje. Tenemos suficiente modularidad, y para cada módulo estamos haciendo un proyecto de prueba. En este proyecto de prueba, se están desarrollando características.

Crear un proyecto de prueba ahora lleva de 15 minutos a una hora. Esto se debe al hecho de que el proyecto debe estar configurado. Es decir, debe configurar la firma para que podamos desarrollar en los mismos dispositivos a los que estamos acostumbrados. Es necesario configurar las bibliotecas necesarias. En el proceso de desarrollo de la función en sí, constantemente volvemos y terminamos el proyecto de prueba para que satisfaga nuestras necesidades.

¿Por qué necesitamos proyectos de prueba? Para ahorrar tiempo en el montaje. Cuanto más pequeño sea el proyecto, más rápido se ensambla, más a menudo podremos lanzar nuestra aplicación en el dispositivo y más cómodo será para nosotros desarrollarlo.



¿Qué debería estar en el proyecto de prueba? Deberíamos poder iniciar, depurar nuestra aplicación en los mismos dispositivos en los que estamos acostumbrados a iniciar y depurar nuestra aplicación principal.

El proyecto debe configurarse de la forma más similar posible al proyecto principal, de modo que en el proceso de transferencia de características del proyecto de prueba al proyecto principal, no nos sorprendamos. O al menos redujo al mínimo el número de sorpresas recibidas.

También necesitamos un entorno mínimo en el proyecto de prueba, para no perder el tiempo creando UIWindows, configurando bibliotecas, anulando la llamada para abrir la aplicación en la biblioteca que se ocupa de la autorización, etc.

CocoaPods app_spec


Toda mi historia de hoy se basará en la función CocoaPods llamada app_spec.



App_spec es como una subespecificación regular, solo que no genera un marco que se pueda conectar, sino una aplicación que se puede iniciar en el dispositivo.



Y listo para usar, CocoaPods nos permite insertar Info.plist y xcconfig en app_spec. Esto ya nos permite configurar nuestro proyecto bastante bien.

Pero si vamos a escribir grandes diccionarios en cada pods_spec, con valores para Info.plist y xcconfig, entonces creceremos podspec nosotros mismos y será inconveniente modificarlos. Si necesitamos cambiar algo, tenemos que ir a cada archivo podspec y editar algo con bolígrafos. En cualquier caso, esto es inconveniente.



Para deshacernos de esto, creamos un complemento local muy simple para CocoaPods. Incluso cabe completamente en una diapositiva. Y hace lo único: nos da la resolución DSL CocoaPods, que crea app_spec con valores ya obstruidos en Info.plist y xcconfig. Esto ya nos permite configurar la firma, configurar esas cosas importantes que queremos ver configuradas en nuestro proyecto de prueba.



Pregunta: cómo transferir la ruta a los derechos, más precisamente, dónde almacenar los derechos para que podamos codificar la ruta en complementos.

Hay dos maneras. O indique la ruta de un archivo que simplemente se encuentra en nuestro repositorio, por ejemplo, a los derechos del proyecto principal. O guarde en el complemento un archivo de derechos especiales para proyectos de prueba. Y usando el mismo complemento, cópielo en nuestro desarrollopod.



Elegimos el primer camino, y aquí tuvimos algunas dificultades. El hecho es que en nuestro repositorio de desarrollo los iPod están en diferentes subcarpetas. Por lo tanto, no podemos indicarles una ruta relativa desde el DevelopmentPod al archivo de derechos.

Es importante enfatizar aquí que debe especificar una ruta relativa, porque esta ruta permanece en pods_spec. Esto significa que participará en el cálculo del monto del cheque, que se almacena en Podfile.lock. Y si hay una ruta absoluta, esto afectará el monto del cheque. Esto significa que el monto del cheque variará dependiendo de la carpeta desde la cual llamar a $ pod install, desde dónde tiene el repositorio, en qué máquina ejecuta $ pod install. En general, esto lleva al conflicto.



Ahora mostraré otra pequeña extensión del mismo complemento, que nos permite calcular la ruta relativa a estos derechos.

Conocemos la ruta relativa desde nuestro complemento al archivo con derechos, si están en el mismo repositorio. Y también durante el lanzamiento de la instalación de $ pod, conocemos el camino hacia nuestro desarrollopod. Toda la magia que hay en este código es una línea resaltada donde simplemente contamos la ruta relativa, conociendo estas dos rutas absolutas.



Entonces, ¿qué obtuvimos cuando ya teníamos app_spec configurado de esta manera? Podemos ejecutar nuestro proyecto de prueba en los mismos dispositivos de inmediato. Tenemos una gran cantidad de configuraciones, incluidos los derechos, que necesitamos.

Medio ambiente


Lo siguiente de lo que quiero hablar es del entorno, el entorno mínimo necesario que necesitamos para comenzar a escribir código de inmediato.



En nuestro caso, necesitamos MapKit, ya configurado, con las claves transferidas, con reenvío de llamadas en el AccountManager. Esta es nuestra biblioteca de autorizaciones. También necesita lanzar llamadas al sistema, también necesita transferir claves, incluso para pasar la apertura de la aplicación por referencia.

También necesitamos una pantalla de inicio con un mapa y una pila de navegación, para que podamos usar la misma pila de navegación que en Mapas, y es más fácil transferir características del proyecto de prueba al principal. Y el punto de entrada para que, sin pensarlo, podamos comenzar a escribir código útil de inmediato.



En su caso, esto podría ser, por ejemplo, configurar el SDK de Facebook, al que también debe transferir claves; sus bibliotecas para iniciar sesión, que seguramente necesitará omitir el enlace de apertura de la aplicación. Algún tipo de controlador de inicio de inicio de Windows y el mismo punto de entrada para ejecutar el script principal que desea desarrollar en su proyecto de prueba.



¿Cómo hicimos esto? Al hacer una sola plantilla AppDelegate. Allí inicializamos todos los entornos necesarios, bibliotecas. Reenviamos todas las llamadas necesarias, transferimos las claves necesarias. Al crear un proyecto de prueba, nos queda crear un nuevo AppDelegate para el proyecto de prueba y heredarlo de la plantilla.

Después de eso, anulamos el único método que se llama después de que la plantilla AppDelegate haya hecho todo lo necesario. Y allí ya tenemos el ViewController de inicio y además podemos ejecutar nuestro script, que queremos depurar en el proyecto de prueba.

Fue / se convirtió


¿Cómo puedo crear un proyecto de prueba en la frente y cómo puedo crearlo usando el método que describí hoy?

Crear un proyecto de prueba en la frente:

- Vamos a Xcode, creamos un nuevo proyecto (Archivo> Nuevo proyecto).

- Ingrese el nombre, preferiblemente sin errores, firme el ID del paquete. Estamos preparando este proyecto.

- Cambiar la versión de Swift, cambiar la versión de destino. Estamos intentando ejecutarlo todo en el dispositivo, editar la firma, etc. Este es un proceso bastante triste.

- A continuación, creamos un podfile, conectamos dependencias allí, instalamos pods.

- Después de eso, vamos y comenzamos a configurar muy tediosa y suavemente nuestro AppDelegate, transfiriendo a través de las piezas de inicialización de las bibliotecas que necesitamos.

- Cree una UIWindows de inicio con nuestro ViewController

Y solo después de eso podemos comenzar el código útil. Procedimiento bastante desagradable, de acuerdo.

¿Cómo podemos crear un proyecto de prueba utilizando las mejores prácticas que describí en el informe de hoy?

- Creamos sample_app_spec, usando la extensión, para CocoaPods, con el que comenzamos.

- Cree un AppDelegate y herede de la plantilla AppDelegate.

Después de eso, podemos comenzar a escribir código útil.

Crear un proyecto de prueba de esta manera es mucho más rápido y más confiable. Definitivamente no nos equivocaremos en la configuración de la firma, definitivamente no nos equivocaremos en la configuración del proyecto. Todo el entorno necesario para comenzar a trabajar se nos acerca de inmediato.

¿Puede ser más fácil?


Puede hacer una pregunta: ¿se puede hacer esto más fácilmente? Por supuesto.



He identificado tres niveles de dificultad. Lo primero es de lo que hablé hoy, de una vez, cuando creamos un complemento incorporado para CocoaPods, que puede reparar las rutas a los derechos, y una plantilla AppDelegate.

El segundo método es ideal en la relación de esfuerzos a ganancias. Contiene solo el complemento para CocoaPods, que fue el primero en la historia de hoy. Es decir, simplemente sustituye los valores en Info.plist y xcconfig. Ya hace la vida mucho más fácil.

Si no necesita su archivo de derechos en sus aplicaciones de prueba, si sus aplicaciones de prueba son bastante diferentes entre sí y no necesitan componentes comunes, este método es muy adecuado para usted.

El tercer método es el más fácil, no requiere ninguna preparación. Simplemente comience a usar app_spec. El proyecto que se genera desde app_spec se crea en el mismo espacio de trabajo que su proyecto principal. Por lo tanto, ya hereda, por ejemplo, Swift, la versión de destino y todas las configuraciones que tiene en Workspace. Será mucho más fácil para ti comenzar a trabajar con él. Eso es todo, gracias por su atención. Hoy les diré cómo crear proyectos de prueba sin problemas, y cómo creamos proyectos de prueba en Yandex.Maps.

- Primero, un poco de historia. Yandex.Maps se recopilan durante más de un minuto. En mi computadora, construir la aplicación lleva un poco más de tres minutos. Desarrollamos en proyectos de prueba para pasar menos tiempo en cada ensamblaje. Tenemos suficiente modularidad, y para cada módulo estamos haciendo un proyecto de prueba. En este proyecto de prueba, se están desarrollando características.

Crear un proyecto de prueba ahora lleva de 15 minutos a una hora. Esto se debe al hecho de que el proyecto debe estar configurado. Es decir, debe configurar la firma para que podamos desarrollar en los mismos dispositivos a los que estamos acostumbrados. Es necesario configurar las bibliotecas necesarias. En el proceso de desarrollo de la función en sí, constantemente volvemos y terminamos el proyecto de prueba para que satisfaga nuestras necesidades.

¿Por qué necesitamos proyectos de prueba? Para ahorrar tiempo en el montaje. Cuanto más pequeño sea el proyecto, más rápido se ensambla, más a menudo podremos lanzar nuestra aplicación en el dispositivo y más cómodo será para nosotros desarrollarlo.



¿Qué debería estar en el proyecto de prueba? Deberíamos poder iniciar, depurar nuestra aplicación en los mismos dispositivos en los que estamos acostumbrados a iniciar y depurar nuestra aplicación principal.

El proyecto debe configurarse de la forma más similar posible al proyecto principal, de modo que en el proceso de transferencia de características del proyecto de prueba al proyecto principal, no nos sorprendamos. O al menos redujo al mínimo el número de sorpresas recibidas.

También necesitamos un entorno mínimo en el proyecto de prueba, para no perder el tiempo creando UIWindows, configurando bibliotecas, anulando la llamada para abrir la aplicación en la biblioteca que se ocupa de la autorización, etc.

CocoaPods app_spec


Toda mi historia de hoy se basará en la función CocoaPods llamada app_spec.



App_spec es como una subespecificación regular, solo que no genera un marco que se pueda conectar, sino una aplicación que se puede iniciar en el dispositivo.



Y listo para usar, CocoaPods nos permite insertar Info.plist y xcconfig en app_spec. Esto ya nos permite configurar nuestro proyecto bastante bien.

Pero si vamos a escribir grandes diccionarios en cada pods_spec, con valores para Info.plist y xcconfig, entonces creceremos podspec nosotros mismos y será inconveniente modificarlos. Si necesitamos cambiar algo, tenemos que ir a cada archivo podspec y editar algo con bolígrafos. O no bolígrafos. En cualquier caso, esto es inconveniente.



Para deshacernos de esto, creamos un complemento local muy simple para CocoaPods. Incluso cabe completamente en una diapositiva. Y hace lo único: nos da la resolución DSL CocoaPods, que crea app_spec con valores ya obstruidos en Info.plist y xcconfig. Esto ya nos permite configurar la firma, configurar esas cosas importantes que queremos ver configuradas en nuestro proyecto de prueba.



Pregunta: cómo transferir la ruta a los derechos, más precisamente, dónde almacenar los derechos para que podamos codificar la ruta en complementos.

Hay dos maneras. O indique la ruta de un archivo que simplemente se encuentra en nuestro repositorio, por ejemplo, a los derechos del proyecto principal. O guarde en el complemento un archivo de derechos especiales para proyectos de prueba. Y usando el mismo complemento, cópielo en nuestro desarrollopod.



Elegimos el primer camino, y aquí tuvimos algunas dificultades. El hecho es que en nuestro repositorio de desarrollo los iPod están en diferentes subcarpetas. Por lo tanto, no podemos indicarles una ruta relativa desde el DevelopmentPod al archivo de derechos.

Es importante enfatizar aquí que debe especificar una ruta relativa, porque esta ruta permanece en pods_spec. Esto significa que participará en el cálculo del monto del cheque, que se almacena en Podfile.lock. Y si hay una ruta absoluta, esto afectará el monto del cheque. Esto significa que el monto del cheque variará dependiendo de la carpeta desde la cual llamar a $ pod install, desde dónde tiene el repositorio, en qué máquina ejecuta $ pod install. En general, esto lleva al conflicto.



Ahora mostraré otra pequeña extensión del mismo complemento, que nos permite calcular la ruta relativa a estos derechos.

Conocemos la ruta relativa desde nuestro complemento al archivo con derechos, si están en el mismo repositorio. Y también durante el lanzamiento de la instalación de $ pod, conocemos el camino hacia nuestro desarrollopod. Toda la magia que hay en este código es una línea resaltada donde simplemente contamos la ruta relativa, conociendo estas dos rutas absolutas.



Entonces, ¿qué obtuvimos cuando ya teníamos app_spec configurado de esta manera? Podemos ejecutar nuestro proyecto de prueba en los mismos dispositivos de inmediato. Tenemos una gran cantidad de configuraciones, incluidos los derechos, que necesitamos.

Medio ambiente


Lo siguiente de lo que quiero hablar es del entorno, el entorno mínimo necesario que necesitamos para comenzar a escribir código de inmediato.



En nuestro caso, necesitamos MapKit, ya configurado, con las claves transferidas, con reenvío de llamadas en el AccountManager. Esta es nuestra biblioteca de autorizaciones. También necesita lanzar llamadas al sistema, también necesita transferir claves, incluso para pasar la apertura de la aplicación por referencia.

También necesitamos una pantalla de inicio con un mapa y una pila de navegación, para que podamos usar la misma pila de navegación que en Mapas, y es más fácil transferir características del proyecto de prueba al principal. Y el punto de entrada para que, sin pensarlo, podamos comenzar a escribir código útil de inmediato.



En su caso, esto podría ser, por ejemplo, configurar el SDK de Facebook, al que también debe transferir claves; sus bibliotecas para iniciar sesión, que seguramente necesitará omitir el enlace de apertura de la aplicación. Algún tipo de controlador de inicio de inicio de Windows y el mismo punto de entrada para ejecutar el script principal que desea desarrollar en su proyecto de prueba.



¿Cómo hicimos esto? Al hacer una sola plantilla AppDelegate. Allí inicializamos todos los entornos necesarios, bibliotecas. Reenviamos todas las llamadas necesarias, transferimos las claves necesarias. Al crear un proyecto de prueba, nos queda crear un nuevo AppDelegate para el proyecto de prueba y heredarlo de la plantilla.

Después de eso, anulamos el único método que se llama después de que la plantilla AppDelegate haya hecho todo lo necesario. Y allí ya tenemos el ViewController de inicio y además podemos ejecutar nuestro script, que queremos depurar en el proyecto de prueba.

Fue / se convirtió


¿Cómo puedo crear un proyecto de prueba en la frente y cómo puedo crearlo usando el método que describí hoy?

Crear un proyecto de prueba en la frente:

- Vamos a Xcode, creamos un nuevo proyecto (Archivo> Nuevo proyecto).

- Ingrese el nombre, preferiblemente sin errores, firme el ID del paquete. Estamos preparando este proyecto.

- Cambiar la versión de Swift, cambiar la versión de destino. Estamos intentando ejecutarlo todo en el dispositivo, editar la firma, etc. Este es un proceso bastante triste.

- A continuación, creamos un podfile, conectamos dependencias allí, instalamos pods.

- Después de eso, vamos y comenzamos a configurar muy tediosa y suavemente nuestro AppDelegate, transfiriendo a través de las piezas de inicialización de las bibliotecas que necesitamos.

- Cree una UIWindows de inicio con nuestro ViewController

Y solo después de eso podemos comenzar el código útil. Procedimiento bastante desagradable, de acuerdo.

¿Cómo podemos crear un proyecto de prueba utilizando las mejores prácticas que describí en el informe de hoy?

- Creamos sample_app_spec, usando la extensión, para CocoaPods, con el que comenzamos.

- Cree un AppDelegate y herede de la plantilla AppDelegate.

Después de eso, podemos comenzar a escribir código útil.

Crear un proyecto de prueba de esta manera es mucho más rápido y más confiable. Definitivamente no nos equivocaremos en la configuración de la firma, definitivamente no nos equivocaremos en la configuración del proyecto. Todo el entorno necesario para comenzar a trabajar se nos acerca de inmediato.

¿Puede ser más fácil?


Puede hacer una pregunta: ¿se puede hacer esto más fácilmente? Por supuesto.



He identificado tres niveles de dificultad. Lo primero es de lo que hablé hoy, de una vez, cuando creamos un complemento incorporado para CocoaPods, que puede reparar las rutas a los derechos, y una plantilla AppDelegate.

El segundo método es ideal en la relación de esfuerzos a ganancias. Contiene solo el complemento para CocoaPods, que fue el primero en la historia de hoy. Es decir, simplemente sustituye los valores en Info.plist y xcconfig. Ya hace la vida mucho más fácil.

Si no necesita su archivo de derechos en sus aplicaciones de prueba, si sus aplicaciones de prueba son bastante diferentes entre sí y no necesitan componentes comunes, este método es muy adecuado para usted.

El tercer método es el más fácil, no requiere ninguna preparación. Simplemente comience a usar app_spec. El proyecto que se genera desde app_spec se crea en el mismo espacio de trabajo que su proyecto principal. Por lo tanto, ya hereda la versión Swift, la versión de destino y todas las configuraciones que tiene en Workspace. Será mucho más fácil para ti comenzar a trabajar con él.
Gracias por la atención.

More articles:


All Articles