platforms-imopm-wwdc-2017-visual-engineering

TEAMLEARNING CINEMA – WWDC 2017: Platforms state of the union

Nuestro equipo de iOS también ha estado muy comprometido con las sesiones de formación interna de Teamlearning Cinema.

El pasado 5 de Junio se celebró el evento más esperado del año para los developers de iOS: la WWDC 2017 (World Wide Developer Conference).

Nuestro developer Alberto Irurueta asistió personalmente pero todo nuestro equipo de iOS también quiso estar presente, por eso vieron las conferencias en sus sesiones de formación interna. De ese modo estarían al día de todas las novedades presentadas, más específicamente sobre el estado de las tecnologías actuales de Apple.

En el siguiente enlace podéis ver un resumen de todas las conferencias. Sólo disponible en Safari.

Si os interesa ver todas las sesiones que han realizado nuestro equipo de iOS podéis acceder aquí.


Model View ViewModel blog visual engineering

TEAMLEARNING CINEMA – MODEL VIEW VIEWMODEL FOR IOS

Ya es la segunda entrega de Teamlearning Cinema para nuestro equipo de iOS, donde ven vídeos de tutoriales y charlas como formación interna para mejorar su día a día en el trabajo.

Inicialmente se centraron en recordar las diferentes opciones de arquitectura para apps de iOS, con el objetivo de encontrar modelos comunes para nuevos proyectos, mejorar la sintaxis de los proyectos ya desarrollados e introducir fácilmente test-unitarios del código.

En esta entrega, "Model View ViewModel (MVVM) for iOS" de Ben DiFrancesco, se centró en cómo introducir buenas prácticas para producir un código más desacoplado y mantenible. Esto lo logra a través de pequeña variaciones con respecto a MVC, el paradigma por defecto de iOS.

¡Os recomendamos ver la presentación!

https://vimeo.com/122706243

También os recomendamos la sesión anterior "Isolating network calls from View Controllers" de .


Model View ViewModel blog visual engineering

TEAMLEARNING CINEMA – Model view Viewmodel for iOS

Ya es la segunda entrega de Teamlearning Cinema para nuestro equipo de iOS, donde ven vídeos de tutoriales y charlas como formación interna para mejorar su día a día en el trabajo.

Inicialmente se centraron en recordar las diferentes opciones de arquitectura para apps de iOS, con el objetivo de encontrar modelos comunes para nuevos proyectos, mejorar la sintaxis de los proyectos ya desarrollados e introducir fácilmente test-unitarios del código.

En esta entrega, “Model View ViewModel (MVVM) for iOS” de Ben DiFrancesco, se centró en cómo introducir buenas prácticas para producir un código más desacoplado y mantenible. Esto lo logra a través de pequeña variaciones con respecto a MVC, el paradigma por defecto de iOS.

¡Os recomendamos ver la presentación!

También os recomendamos la sesión anterior “Isolating network calls from View Controllers” de .


Isolating network calls visual engineering

TEAMLEARNING CINEMA – ISOLATING NETWORK CALLS FROM VIEWS CONTROLLERS

¡Nuestro equipo de iOS también se ha sumado a la iniciativa Teamlearning Cinema! Y para empezar han visto la sesión "Isolating network calls from View Controllers" de , conocido por su gran experiencia en Core Data.

La idea de unirse a esa iniciativa es empezar a debatir sobre algunos tipos de arquitectura de las apps de iOS para que puedan consensuar un modelo a aplicar para todos los desarrolladores.

Si queréis ver la sesión y la documentación podéis acceder aquí. ¡Totalmente recomendable!

MARCUS ZARRA


Isolating network calls visual engineering

TEAMLEARNING CINEMA – Isolating network call from views controllers

¡Nuestro equipo de iOS también se ha sumado a la iniciativa Teamlearning Cinema! Y para empezar han visto la sesión “Isolating network calls from View Controllers” de , conocido por su gran experiencia en Core Data.

La idea de unirse a esa iniciativa es empezar a debatir sobre algunos tipos de arquitectura de las apps de iOS para que puedan consensuar un modelo a aplicar para todos los desarrolladores.

Si queréis ver la sesión y la documentación podéis acceder aquí. ¡Totalmente recomendable!


closures-ios-visual-engineering

WORKSHOP IOS - CLOSURES, GENÉRICOS Y OPERADORES

En los primeros workshops de iOS tratamos el tema de las closures. Si recordamos, una closure, también denominada función de cierre, era como un bloque de Objective-C o C, en la que una función en vez de comenzar con la palabra reservada func incorpora unas llaves { }:

{ (parámetros) -> tipo de retorno in declaración del bloque }

En este workshop entramos en detalle con genéricos y operadores. Respecto a los genéricos, éstos sirven para definir código de una forma más abstracta, sin depender de un tipo en concreto para que el mismo código pueda aplicarse luego a distintos tipos siempre que sigan una serie de reglas, o restricciones, como un protocolo.

El propio módulo de foundation define estructuras como el array o el diccionario que hacen un uso extensivo de generics y eso les permite almacenar colecciones de cualquier tipo. Incluso, ese es quizás el uso más habitual de los generics.

Y en cuanto a los operadores, son símbolos que se usan para trabajar como valores. Se pueden usar para realizar manipulaciones matemáticas o lógicas específicas, pero también pueden servir para comparar números, juntar textos,... Es decir puedes definir operadores que hagan lo que quieran. E incluso, aunque Objective-C cuenta con una gran cantidad de operadores,  te puedes crear operadores nuevos que aún no existen en el lenguaje.

Si quieres conocer más sobre estos aspectos, nuestro ingeniero Alberto Irurueta nos enseñó ese workshop de "Closures, generics & operators":

Puedes descargar su presentación aquí.


closures-ios-visual-engineering

WORKSHOP IOS - Closures, genéricos y operadores

En los primeros workshops de iOS tratamos el tema de las closures. Si recordamos, una closure, también denominada función de cierre, era como un bloque de Objective-C o C, en la que una función en vez de comenzar con la palabra reservada func incorpora unas llaves { }:

{ (parámetros) -> tipo de retorno in declaración del bloque }

En este workshop entramos en detalle con genéricos y operadores. Respecto a los genéricos, éstos sirven para definir código de una forma más abstracta, sin depender de un tipo en concreto para que el mismo código pueda aplicarse luego a distintos tipos siempre que sigan una serie de reglas, o restricciones, como un protocolo.

El propio módulo de foundation define estructuras como el array o el diccionario que hacen un uso extensivo de generics y eso les permite almacenar colecciones de cualquier tipo. Incluso, ese es quizás el uso más habitual de los generics.

Y en cuanto a los operadores, son símbolos que se usan para trabajar como valores. Se pueden usar para realizar manipulaciones matemáticas o lógicas específicas, pero también pueden servir para comparar números, juntar textos,… Es decir puedes definir operadores que hagan lo que quieran. E incluso, aunque Objective-C cuenta con una gran cantidad de operadores,  te puedes crear operadores nuevos que aún no existen en el lenguaje.

Si quieres conocer más sobre estos aspectos, nuestro ingeniero Alberto Irurueta nos enseñó ese workshop de “Closures, generics & operators“:

Puedes descargar su presentación aquí. 


testing ios blog visual engineering

WORKSHOP IOS - TESTING, PROTOCOLOS Y EXTENSIONES

Las pruebas o tests unitarios nos permiten verificar de forma ágil y segura que nuestra app hace lo que debe hacer. Para verificarlo se basa en los casos de prueba que hayamos definido previamente.

Normalmente se usan para verificar pruebas de regresión, es decir, que nuestra app sigue haciendo lo que antes hacía tras incorporar los nuevos cambios. Es importante tenerlo en cuenta porque Apple puede rechazar una actualización de nuestra app debido a que ésta produzca errores no controlados que podríamos evitar con estas pruebas.

Las pruebas unitarias son la base para el desarrollo guiado por pruebas o Test-Driven Development (TDD), que es un estilo de programación que impone la creación de los casos de prueba con antelación al código que va a ser verificado.

En Xcode existen principalmente dos tipos de pruebas unitarias:

  • Pruebas unitarias lógicas: verifican el correcto funcionamiento de un fragmento de código de forma independiente.
  • Pruebas unitarias de aplicación: verifican el correcto funcionamiento de fragmentos de código dentro del contexto de nuestra app, y verificar funcionalidades específicas de un dispositivo, como el uso de la geolocalización, acelerómetro, etc.

Los casos de pruebas deben ser:

  • Automatizables: que no requieran intervención humana para su verificación.
  • Completas: deben cubrir el mayor código posible, es decir que debemos tener casos de prueba que cubran cuántos más métodos de nuestra app mejor.
  • Repetibles: un caso de prueba no debe tener ninguna dependencia que impida ser ejecutado varias veces con el mismo resultado.
  • Independencia: un caso de prueba no puede depender del resultado de otro caso.

Tan necesarias son las pruebas unitarias como lo es la práctica de la integración continua.

La integración continua consiste en tener un proceso automatizado en el que, después de que cada developer suba código al repositorio, se obtiene la última versión, se compila, se ejecutan el conjunto de pruebas unitarias seleccionado, y se dejan los binarios/resultados en una ubicación conocida.

Con la integración continua evitaríamos el posible problema de que no compile o que de repente fallen funcionalidades dependientes de referencias externas, nos ahorraría tiempo en los desarrollos y nos permitiría centrarnos en lo importante de la aplicación: su funcionalidad.

Existen dos sistemas de integración continua:

  • Travis CI: especialmente diseñado para construir y testear proyectos en Github de forma automática.
  • Jenkins: es gratuito, open-source y actualmente uno de los más empleados para esta función. Además es muy fácil de utilizar y permite actualizaciones fáciles.

Todos esto lo puedes profundizar en el siguiente workshop "TESTING, PROTOCOLOS Y EXTENSIONES", impartido por Alberto Irurueta y Alejandro García, que se hizo con el objetivo de:

  • Entender el funcionamiento de los protocolos
  • Aprender a crear tests unitarios
  • Generar informes de resultados de tests y de cobertura de código
  • Integración continua (Travis vs. Jenkins)

Puedes descargar la presentación aquí.

 


testing ios blog visual engineering

WORKSHOP IOS - Testing, protocolos y extensiones

Las pruebas o tests unitarios nos permiten verificar de forma ágil y segura que nuestra app hace lo que debe hacer. Para verificarlo se basa en los casos de prueba que hayamos definido previamente.

Normalmente se usan para verificar pruebas de regresión, es decir, que nuestra app sigue haciendo lo que antes hacía tras incorporar los nuevos cambios. Es importante tenerlo en cuenta porque Apple puede rechazar una actualización de nuestra app debido a que ésta produzca errores no controlados que podríamos evitar con estas pruebas.

Las pruebas unitarias son la base para el desarrollo guiado por pruebas o Test-Driven Development (TDD), que es un estilo de programación que impone la creación de los casos de prueba con antelación al código que va a ser verificado.

En Xcode existen principalmente dos tipos de pruebas unitarias:

  • Pruebas unitarias lógicas: verifican el correcto funcionamiento de un fragmento de código de forma independiente.
  • Pruebas unitarias de aplicación: verifican el correcto funcionamiento de fragmentos de código dentro del contexto de nuestra app, y verificar funcionalidades específicas de un dispositivo, como el uso de la geolocalización, acelerómetro, etc.

Los casos de pruebas deben ser:

  • Automatizables: que no requieran intervención humana para su verificación.
  • Completas: deben cubrir el mayor código posible, es decir que debemos tener casos de prueba que cubran cuántos más métodos de nuestra app mejor.
  • Repetibles: un caso de prueba no debe tener ninguna dependencia que impida ser ejecutado varias veces con el mismo resultado.
  • Independencia: un caso de prueba no puede depender del resultado de otro caso.

Tan necesarias son las pruebas unitarias como lo es la práctica de la integración continua.

La integración continua consiste en tener un proceso automatizado en el que, después de que cada developer suba código al repositorio, se obtiene la última versión, se compila, se ejecutan el conjunto de pruebas unitarias seleccionado, y se dejan los binarios/resultados en una ubicación conocida.

Con la integración continua evitaríamos el posible problema de que no compile o que de repente fallen funcionalidades dependientes de referencias externas, nos ahorraría tiempo en los desarrollos y nos permitiría centrarnos en lo importante de la aplicación: su funcionalidad.

Existen dos sistemas de integración continua:

  • Travis CI: especialmente diseñado para construir y testear proyectos en Github de forma automática.
  • Jenkins: es gratuito, open-source y actualmente uno de los más empleados para esta función. Además es muy fácil de utilizar y permite actualizaciones fáciles.

Todos esto lo puedes profundizar en el siguiente workshop “TESTING, PROTOCOLOS Y EXTENSIONES”, impartido por Alberto Irurueta y Alejandro García, que se hizo con el objetivo de:

  • Entender el funcionamiento de los protocolos
  • Aprender a crear tests unitarios
  • Generar informes de resultados de tests y de cobertura de código
  • Integración continua (Travis vs. Jenkins)

Puedes descargar la presentación aquí.


swift estructuras visual engineering

WORKSHOP IOS - SWIFT: ESTRUCTURAS

En Swift tanto las estructuras como las clases son fundamentales para hacer un proyecto completo.

Las estructuras (structs) son uno de los pilares principales de Swift como lenguaje. Las estructuras representan unidades de información.

Las clases (class) son las partes esenciales que organizar y que dividen nuestra aplicación en diferentes archivos y dentro de estos en diferentes métodos que nos permiten estructurar todo.

Las estructuras y las clases tiene mucho en común. Ambas pueden:

  • Definir propiedades para guardar valores

  • Definir métodos para proveer funcionalidades

  • Definir sub-scripts para proveer acceso a sus valores usando la sintaxis del sub-script

  • Definir inicializadores  para configurar en estado inicial

  • Para ser extendidos y expandir su funcionalidad más allá de su implementación por defecto

  • Ajustar protocolos para proveer funcionalidades estándares de cierto tipo.

Las clases tienen capacidades adicionales que las estructuras no tienen:

  • La inner-herencia permite una clase heredar las características de otra clase.

  • El type-casting te permite revisar e interpretar el tipo de instancias dentro de una clase al crear un runtime.

  • Los des-inicializadores permiten a la instancia de una clase liberar cualquier recurso que se le haya asignado.

  • El conteo de referencias permite a que más haya más de una referencia a la instancia de una clase.

Por otro lado, las enumeraciones (enums) en Swift son elementos de primera clase. Ellos adoptan muchas funcionalidades tradicionalmente soportadas por las clases, como propiedades computadas que proveen información adicional sobre los valores actuales de las enumeraciones, y métodos de instancias que proveen funcionalidades relacionadas a los valores que las enumeraciones representan, entre otras cosas.

Para conocer mejor todos estos elementos del código, nuestros ingenieros Jordi Serra y Pierluigi Cifani nos presentaron "Swift - Estructuras".

Puedes descargar su presentación: Swift: structs, enums and classes.

Para mayor información sobre las clases y estructuras, puedes visitar la página de Apple para developers.