Qué es Fastlane

Dentro del desarrollo de software es habitual que los entornos de desarrollo incluyan muchas herramientas para realizar tareas relacionadas con el mantenimiento y la publicación de una aplicación software. Pero la mayoría de estas herramientas integradas en los entornos de desarrollo funcionan de forma manual requiriendo una completa atención por parte de la persona que está desarrollando el software.

La automatización de procesos dentro de la ingeniería del software se ha demostrado como uno de los caminos más beneficiosos para aumentar la productividad y la fiabilidad del software. Por esta razón han ido apareciendo multitud de herramientas que permiten realizar más tareas y procesos que los entornos de desarrollo y, sobre todo, automatizar estos procesos.

¿Qué es Fastlane?

Fastlane es una de estas herramientas que permiten automatizar muchos de los procesos y tareas relacionadas con el desarrollo de software para iOS y Android.

Esta herramienta creada por Felix Crause consiste en un conjunto de servicios y aplicaciones ejecutadas desde la línea de comandos (CLI) utilizando lenguaje Ruby y permite automatizar muchos de los procesos que se realizan con Android Studio y Xcode.

Entre las diversas tareas que permite automatizar Fastlane están las siguientes:

  • Creación de capturas de pantalla para la tienda de aplicaciones
  • Despliegue de la app dentro de entornos de betatesting como Test flight.
  • Publicación del proyecto en la tienda de aplicaciones
  • Firma de paquetes de software para la distribución del proyecto
  • Ejecución de planes de tests

Como todas estas automatizaciones se ejecutan desde la línea de comandos es muy fácil incluir scripts de la Terminal para realizar comprobaciones o actualizaciones de recursos para la distribución de nuestro proyecto software.

En futuros artículos veremos algunas de estas automatizaciones con más detalle.

La instalación de fastlane es muy sencilla y su uso consiste principalmente en la ejecución de ciertos comandos de Terminal en la propia carpeta raíz de nuestro proyecto software. Este uso de la Terminal hace que el uso de Fastlane resulte más accesible que utilizar ciertas herramientas visuales incluidas en Xcode o Android studio.

Puedes obtener documentación, ejemplos y más información en la página oficial de Fastlane.

Cómo utilizar VoiceOver en VisionOS

El próximo 2024 Apple introducirá en el mercado su nuevo producto Apple vision Pro. Un visor que permite interactuar al usuario entre lo real y lo virtual. VisionOS es el sistema operativo para este dispositivo y como viene siendo habitual en Apple sale al mercado con varias características de accesibilidad y de personalización para que todos los usuarios puedan disfrutar de esta nueva forma de interactuar con la tecnología.

VoiceOver para VisionOS

Dentro de los ajustes de VisionOS, en el apartado de accesibilidad, el primer elemento que podemos activar es VoiceOver.

Podemos configurar la activación rápida de un elemento de accesibilidad pulsando 3 veces la corona del Apple vision pro.

La navegación de esta versión de VoiceOver es muy similar a la que podemos disfrutar con VoiceOver para iPadOS permitiendo navegar mediante gestos o conectando un teclado externo.

Utilizar VoiceOver para VisionOS con gestos

el Apple Vision pro no necesita pantalla táctil ya que reconoce la posición de nuestras manos y dedos en todo momento y esto nos permite hacer gestos para manipular la interfaz de VisionOS. ¿Pero cómo solucionar la necesidad de feedback háptico para las personas ciegas? Pues Apple ha apostado por sustituir los movimientos en el aire por tocar nuestros dedos de la mano derecha con nuestro pulgar.

Colocando nuestra mano derecha con la palma mirando hacia arriba podemos tocar nuestro dedo índice con el pulgar. Este gesto mueve el foco de VoiceOver al siguiente elemento de la interfaz.

Si con nuestro pulgar derecho tocamos nuestro dedo corazón el foco de VoiceOver se moverá al elemento anterior.

Por último para hacer tab en un elemento y activarlo deberemos tocar con nuestro pulgar nuestro dedo anular.

Existen más gestos y más opciones de personalización en los ajustes de VoiceOver para VisionOS pero con estos 3 gestos ya podemos explorar la interfaz de este nuevo sistema operativo.

Utilizar VoiceOver para VisionOS con teclado

Los atajos de teclado de VoiceOver para VisionOS son los mismos que para la versión de iPadOS.

Pulsando la combinación Control+Opción+Flecha derecha moveremos el foco de VoiceOver al elemento siguiente.

Pulsando Control+Opción+flecha izquierda moveremos el foco de VoiceOver al elemento anterior.

Por último pulsando control+Opción+barra espaciadora activaremos el elemento focalizado.

Otro atajo de teclado útil es Control+Opción+k que activará el modo de ayuda y podremos explorar los distintos atajos de teclado disponibles.

Para salir de este modo de ayuda y de otros modos de ajuste de VoiceOver deberemos utilizar el atajo de escape que es Control+Opción+tecla Escape.

Cómo probar VisionOS sin el Apple vision pro

Actualmente no está disponible este nuevo dispositivo de Apple pero los desarrolladores ya pueden crear nuevas aplicaciones para este sistema operativo. ¿Cómo lo hacen? Pues utilizando un simulador incluido con Xcode.

Al crear con Xcode un nuevo proyecto de aplicación y seleccionando como destino VisionOS podremos ejecutar una simulación de VisionOS en nuestro equipo con MacOS.

Una vez en ejecución el simulador el primer arranque de VoiceOver no es accesible y deberemos ir a los ajustes de VisionOS, activar la categoría accesibilidad y activar VoiceOver.

Una vez activado VoiceOver cada vez que arranquemos el simulador VoiceOver comenzará a hablar.

Para poder controlar con el teclado el VoiceOver de VisionOS debemos activar la opción del simulador de enviar las pulsaciones de teclas al simulador. Esto lo podemos hacer pulsando Opción+Comando+k. Una vez activada esta modalidad el teclado se utilizará exclusivamente por el simulador.

Para desactivar esta modalidad de uso del teclado deberemos pulsar a la vez las 2 teclas de Comando situadas a la izquierda y la derecha de la barra espaciadora.

Obtener el contenido del portapapeles con AppleScript

Ya hemos visto que en AppleScript podemos acceder a mucha de la información que está disponible en nuestro equipo pero aún no hemos visto una de las funciones más simples y útiles de los sistemas operativos modernos: el portapapeles.

El portapapeles es un espacio en memoria donde se aloja una copia del contenido que hayamos copiado o cortado con las funciones del sistema operativo.

¿Para qué podemos querer acceder a la información de portapapeles desde un script? Pues desde una simple función para mostrar el contenido del portapapeles en un cuadro de diálogo para verificar qué tenemos almacenado en esa memoria o para crear un script que nos traduzca el texto del portapapeles al idioma que necesitemos.

Con AppleScript podemos acceder a ese espacio de memoria utilizando la variable the clipboard. Esta variable de AppleScript puede almacenar cualquier tipo de contenido como imágenes, texto, audio o la información de un fichero de una carpeta. Esto nos obliga a convertir esta información en algo comprensible para nuestro script.

Veamos un ejemplo en el que obtenemos como texto la información guardada en el portapapeles:

set clipboardContent to (the clipboard as text)

Con esto podemos crear un script para verbalizar el contenido del portapapeles utilizando la voz del sistema. El código sería algo como esto:

set clipboardContent to the clipboard as text

say clipboardContent

Este código funciona pero no tiene en cuenta si en el portapapeles el contenido que está almacenado es convertible a texto. Para evitar posibles errores de ejecución de nuestro script debemos emplear un bloque try que nos permita controlar errores de ejecución en un script. El código quedaría así:

try

  set clipboardContent to the clipboard as text

  say clipboardContent

on error

  say "El portapapeles no contiene texto"

end try

Con esta modificación nuestro script siempre verbalizará algo aunque sea para notificarnos que el contenido de nuestro portapapeles no es texto.

Regla YAGNI – You aren’t gonna need it

La última de las 5 reglas para escribir software simple y robusto es la regla de YAGNI. Su acrónimo traducido dice: no lo vas a necesitar.

En muchas ocasiones cometemos el error de hacer sobreingeniería en un proyecto. Esto significa que el cliente nos ha pedido una calculadora para hacer sumas y terminamos desarrollando una hoja de cálculo con soporte para funciones y un lenguaje propio de scripting. Esto provoca que el mantenimiento y el esfuerzo para desarrollar y mantener el proyecto se ha sobredimensionado de forma incontrolada e innecesaria.

Para evitar caer en este código innecesario o código YAGNI debemos centrarnos en los requerimientos del producto final, no desarrollar código que no se esté utilizando en el proyecto, eliminar el código comentado (Si está comentado es que no es necesario) y utilizar ciertos patrones de trabajo como TDD (Test Driven Development) o trabajar con PullRequests pequeñas enfocadas en aspectos muy específicos de un requerimiento o característica del proyecto. También realizar procesos de refactorización del código al terminar un plazo de entrega o el desarrollo de un módulo facilita la desaparición de código YAGNI.

Regla SOC – Separation of concerns

Dentro de las reglas para escribir software simple y robusto tenemos la regla de SOC cuyo acrónimo significa Separation of concerns. Esto se traduce como separación de intereses. Este término de ingeniería fue creado por Edsger Dijkstra en un artículo para indicar la necesidad de centrar la atención en aspectos específicos dentro de las distintas estructuras de manipulación de la información dentro del software. Esta separación de intereses dentro del software se puede aplicar a nivel de arquitectura del proyecto y a nivel de codificación de los métodos y funciones.

Arquitectura de intereses

A nivel de arquitectura debemos agrupar los distintos intereses dentro de módulos o microservicios. Cada módulo o servicio deberá encargarse de un aspecto del proyecto.

Se busca que cada módulo o microservicio sea independiente y tengan claras sus responsabilidades.

Dentro de la modularización del código se aplican patrones de diseño como MVC (Modelo vista controlador), MVP (Modelo vista presentador) y patrones de diseño similares. Esta forma de organizar el código nos permite diferenciar cláramente las clases relacionadas con el modelo de datos, la interfaz de usuario y la forma de presentar y manipular los datos en la interfaz de usuario. 

Aplicando estos patrones de diseño a la hora de modularizar nuestro código podremos realizar modificaciones en la interfaz de usuario sin necesidad de afectar al modelo de datos o a la lógica de negocio ya que las responsabilidades de cada parte del módulo están conceptualmente definidas.

Separación del código por intereses

Para separar el código por intereses se debe realizar un ejercicio de análisis observando desde el punto más alto de abstracción de nuestro proyecto, tanto en funcionalidad como en la información que se manipula, hasta delimitar la responsabilidad y relación entre las distintas clases y módulos del proyecto.

Con este esfuerzo se busca obtener las siguientes ventajas: eliminar la posible duplicación en la lógica de negocio, ampliar la capacidad de mantenimiento del proyecto, incremento de la cohesión entre clases y reducción del acoplamiento entre clases y módulos.

Una vez realizado este análisis se aplican distintos paradigmas de programación como la programación orientada a aspectos, arquitectura hexagonal, inyección de dependencias y la separación de métodos por responsabilidad.

Regla LOD – Law of Demeter

Una de las reglas para escribir software simple y robusto que también podemos aplicar a otros aspectos de la vida es la regla de Demeter. Esto es lo que significa LOD: law of Demeter.

Esta regla se resume en el concepto de: no hables con desconocidos.

Dentro de la ingeniería de software esta regla representa al principio del mínimo conocimiento.

Este principio nos dice que una función o método X perteneciente a un objeto Y sólo puede llamar a otros métodos o funciones pertenecientes al objeto, un parámetro del método X, cualquier objeto creado dentro del método X o cualquier propiedad definida dentro del método X.

Esto establece que la comunicación del método X se limita al dominio de su objeto contenedor o al propio dominio del método X.

De forma más comprensible este principio nos permite escribir un método de forma que cualquier información que el método necesite consultar o manipular estará dentro del propio código del método o dentro del código de la clase que lo contiene. De esta forma podemos detectar fácilmente posibles errores o seguir el movimiento de la información que manipula ese método.