Local blog for Spanish speaking developers in LATAM
App de Google I/O 2018: Arquitectura y pruebas
viernes, 14 de septiembre de 2018
Ilustración de
Virginia Poltrack
La
app de Google I/O
es un proyecto de código abierto que muestra el cronograma e información de la conferencia anual de Google I/O. Está orientada a los asistentes y espectadores remotos del evento.
Este año, tuvimos la oportunidad de comenzar de cero. Pudimos elegir las herramientas y pensar en el diseño general de la arquitectura de la app. ¿Cuál es la mejor arquitectura? Una que permita a los desarrolladores de tu equipo alcanzar la mayor productividad. Deben poder trabajar sin reinventar la rueda, concentrándose en las características para el usuario. Los desarrolladores también deben poder recibir comentarios oportunos sobre su trabajo. La mayoría de los miembros del equipo que desarrollan la app son googlers que dedican el 20% de su tiempo al proyecto y provienen de diferentes equipos, contextos y zonas horarias, algo que debe tenerse en cuenta al tomar estas decisiones.
Arquitectura
Un proyecto desarrollado por un equipo diverso necesita pautas claras sobre cómo hacer frente a problemas comunes. Por ejemplo, los desarrolladores necesitan una manera de
salir del subproceso principal
. Una buena idea es proporcionar un marco de trabajo para hacer esto regularmente. Asimismo, una buena arquitectura debe ser difícil de corromper: definir las
capas de una app
y describir claramente sus relaciones evita errores y simplifica las revisiones de código.
Tomamos conceptos de
The Clean Architecture
para resolver estos dos problemas (disposición de capas y ejecución en segundo plano). La app se divide en una estructura de tres capas:
Capa de presentación (vistas y ViewModels)
Capa de dominio (casos de uso)
Capa de datos (repositorios y administrador de usuarios)
La capa de presentación no puede comunicarse directamente con la de datos. Un ViewModel solo puede obtener un repositorio a través de uno o más casos de uso. Esta limitación garantiza independencia y capacidad de prueba. También aporta una buena oportunidad para pasar a un subproceso en segundo plano; todos los casos de uso se ejecutan en segundo plano, lo cual garantiza que no se produzca el acceso a datos en el procesamiento de IU.
Arquitectura general de la app
Capa de presentación: Vistas + ViewModels + Vinculación de datos
ViewModels proporcionan datos a las vistas a través de
LiveData
. Las llamadas reales a la IU se realizan con
Vinculación de datos
. Esto libera las actividades y los fragmentos del código estándar.
Abordamos los eventos utilizando un
contenedor de eventos
, diseñado como parte del estado de la IU.
Podrás obtener más información sobre este patrón en esta entrada del blog.
Capa de dominio: UseCases
La capa de dominio gira alrededor de la clase
UseCase
, que atravesó muchas iteraciones. A fin de evitar un
infierno de callbacks
, decidimos usar LiveData para exponer los resultados de UseCases.
De forma predeterminada, los casos de uso se ejecutan en un
DefaultScheduler
(un objeto Kotlin) que luego puede
modificarse a partir de pruebas
para ejecutarse de forma síncrona. Encontramos esta solución más sencilla que tener que lidiar con un gráfico de Dagger personalizado para inyectar un programador síncrono.
Capa de datos
La app abordó 3
tipos
de datos, considerando la frecuencia con la que cambian:
Datos estáticos que nunca cambian: mapa, agenda, etc.
Datos que cambian hasta 10 veces por día: datos de cronograma (sesiones, disertantes, etiquetas, etc.)
Datos que cambian constantemente, incluso sin la interacción del usuario: reservas y calificación de sesiones
Un requisito importante para la app es la
asistencia sin conexión
. Los datos deben estar disponibles para el usuario en la primera ejecución e incluso con una conexión Wi-Fi inestable (no podemos suponer que habrá una cobertura perfecta en el evento y debemos prever que muchos visitantes desactivarán sus datos de itinerancia).
Los datos estáticos se codifican. Por ejemplo, el repositorio de agenda comenzó como un archivo JSON incorporado, pero era tan estático que lo tradujimos a Kotlin por motivos de simplicidad y rendimiento.
Los datos de conferencia vienen en un archivo JSON relativamente grande (alrededor de 600 kb sin comprimir). Se incluyó una versión inicial de esto en el APK para lograr la asistencia sin conexión completa. La app descarga datos actualizados de una URL estática cada vez que el usuario actualiza el cronograma o cuando la app recibe una señal de
Firebase Cloud Messaging
con una solicitud de actualización. Los datos de conferencia se descargan en una tarea administrada por un
JobScheduler
para garantizar que los datos del usuario se usen de forma responsable.
El archivo JSON descargado se almacena en caché usando
OkHttp
, de modo que la próxima vez que se inicie la app se use la versión almacenada en caché en lugar del archivo de arranque. Este enfoque evitó que tuviéramos que abordar los archivos de manera directa.
Para los datos del usuario (reservas, calificación de sesiones, carga de tokens de Firebase, etc.), usamos
Firestore
: una base de datos NoSQL en la nube. Puesto que viene con asistencia sin conexión, pudimos sincronizar los datos de usuario en Android, la Web e iOS sin esfuerzo.
Se implementó asistencia para el acceso con
Firebase Authentication
. Un
AuthStateListener
indica el momento en que cambia el usuario actual (por ejemplo, de desconectado a conectado) usando un LiveData observable.
Bibliotecas y herramientas
Decidimos evitar el uso de dependencias inestables, por lo que no usamos
corrutinas
, el componente
Navigation
ni
WorkManager
.
Además de las herramientas que observamos previamente, a continuación se destacan algunas:
Dagger2
para la inyección de dependencias
Timber
para el registro
Gson
para análisis de JSON
ThreeTen
para fechas y horas
Crashlytics
Utilizamos ampliamente
LiveData
para crear una arquitectura reactiva en la que todo esté conectado de modo que la IU se actualice automáticamente cuando cambien los datos. Puedes obtener más información sobre el uso de LiveData más allá del ViewModel en esta
entrada
.
Módulos de Gradle y organización del código
Tener una buena estrategia de modularización es fundamental para una buena experiencia de desarrollo. De hecho, los problemas de dependencia generalmente son indicio de una mala arquitectura o un mal enfoque de modularización. Creamos los siguientes módulos:
model: contiene las entidades que se utilizan en la app.
shared: lógica de negocios y clases principales.
mobile: la app para dispositivos móviles, en la que se incluyen actividades, fragmentos, ViewModels y clases relacionadas con la IU, como adaptadores para la vinculación de datos, BottomSheetBehavior, etc.
tv: la app Android TV.
test-shared: datos de prueba que se usarán en todos los módulos a partir de todas las pruebas de unidad.
androidTest-shared: utilidades que se usarán en todos los módulos a partir de todas las pruebas de IU.
La regla general es crear tantos módulos como sea posible para mejorar el encapsulamiento, que generalmente deriva en compilaciones incrementales más rápidas. En nuestro caso, los módulos shared y mobile podrían dividirse aún más.
Pruebas y tipos
Antes del desarrollo de características, nos esforzamos mucho por lograr que la app pudiera someterse a pruebas. Los desarrolladores solo son productivos si pueden obtener comentarios anticipados sobre lo que están haciendo, sin depender de otros.
Pruebas de unidad
La arquitectura y el enfoque de modularización permitieron un buen aislamiento para pruebas, imitación de dependencias y ejecución rápida. A las capas de dominio y datos se les realizan pruebas de unidad exhaustivas. En la capa de presentación, solo se realizan pruebas de unidad de algunas clases de utilidades.
Inicialmente evitamos la simulación al no agregar
Mockito
al proyecto. Usamos interfaces siempre que fue posible e imitamos las dependencias a partir de pruebas, un procedimiento mucho más limpio que las simulaciones. Sin embargo, eventualmente
agregamos
Mockito para crear simulaciones de dependencias externas. Usamos
Mockito-Kotlin
para una experiencia más idiomática.
Usamos una herramienta de integración continua interna que rechazó listas de cambio responsables de fallas en la compilación o en las pruebas de unidades. Contar con esto es fundamental en un proyecto con tantos contribuyentes y tiene particular importancia cuando hay muchas variantes, ya que Android Studio solo compila la variante activa. Para Github, agregamos la
IC de Travis
.
Pruebas de la IU
Nos aseguramos de que
Espresso
no requiriera
recursos de inactividad
para que el marco de trabajo de UseCase proporcione una manera de configurar un ejecutor de tareas síncrono. También nos aseguramos de que las pruebas se ejecutarían de forma hermética; usamos imitaciones para evitar el uso de dependencias poco confiables, como la red. Las preferencias, la hora y los programadores de tareas se modificaron a partir de pruebas usando reglas de JUnit, que proporcionaron estabilidad y pruebas repetibles.
Las pruebas de IU se ejecutan solo en el tipo “staging”. Esta variante especial de la app siempre simula un usuario registrado y no realiza solicitudes de red. Esto también es útil para realizar iteraciones de forma más rápida al probar la app manualmente.
Mantener pruebas de IU cuando esta se somete un trabajo arduo de desarrollo puede ser una carga. Tenemos planeado introducirlas después de incorporar los diseños de la IU. Sin embargo, las pruebas de IU se demoraron y lanzamos la primera versión sin un conjunto adecuado establecido. Esto provocó algunas
fallas
en la producción que podrían haberse evitado simplemente ejecutando una ruta de acceso viable (pruebas que solo contemplan el funcionamiento normal, no las interacciones menos frecuentes) en
Firebase Test Lab
.
En un mundo ideal, no tendríamos que modificar nuestro
código
de lanzamiento solo para las pruebas, pero tuvimos que [
aplicar
] algunos cambios:
Tuvimos que agregar una manera de inhabilitar las animaciones en la clase
BottomSheetBehavior
, ya que no usa ninguno de los marcos de trabajo de animación (por lo que las animaciones no se inhabilitan automáticamente).
También tuvimos que agregar una función que se ejecutara cuando se iniciara una animación determinada en la clase
EventFilterView
.
Separar nuestra arquitectura en capas diferentes y documentar la responsabilidad de cada una funcionó bien para nuestro equipo de contribuyentes distribuidos. Por ejemplo, obligar al marco de trabajo UseCase a obtener datos de las capas de repositorio hizo que el comportamiento predeterminado fuera partir del subproceso principal, lo cual evitó la introducción de un problema desde el principio y la necesidad de tener que detectarlo más adelante. Asimismo, la mayoría de los problemas que surgen en las pruebas son problemas de arquitectura disimulados. Crear una buena base es fundamental para compilar una experiencia de prueba segura.
Iosched es una app real con usuarios reales... y un plazo muy real. Hay áreas en las que queremos seguir trabajando para que la base de código se mantenga en buenas condiciones, pueda someterse a mantenimiento y se convierta en una mejor app de ejemplo. Por ejemplo, el
ScheduleViewModel
creció orgánicamente y el desglose puede resultar beneficioso para este. Tenemos pensando mejorar la app agregando nuevos componentes de arquitectura, solucionando problemas, refactorizando y aumentando la cobertura del código.
No dudes en abrir
casos
si encuentras problemas o quieres contribuir con el proyecto.
App Google I/O 2018: Arquitectura y pruebas
se publicó originalmente en
Android Developers
en Medium, donde las personas dan continuidad a la conversación destacando esta historia y emitiendo respuestas relacionadas con ella.
Labels
.app
.dev
.txt
#AMP
#CPU
#DeveloperStudentClubs
#DevFest
#DragonBall
#DSC
#Forsety
#ForsetySecurity
#freeandopen
#GCP
#Google
#GoogleCloud
#GoogleCloudPlatform
#GoogleLaunchpad
#iio2009
#Kubernetes
#MaterialDesign
#OneCommunity
#Security
#TensorFlow
#UPGlobal
#UpLatam
#WithGoogle
+page
10 YEARS
2013
2019
64 bits
A/B Testing
AA
Accelerator
Action on Goolge
actionbar
Actions
Actions Console
AdMob
Ads
adwords
adwords api
AI
AIY
ajax
alarmmanager
ALFA
almacenamiento
alojamiento de proyectos en google code
AMP
AMP Conf
AMP Project
amp-date-picker
amphtml
Analytics
Andorid
android
Android (operating System)
Android 3.1
android 3.3
android 4.2
android 9
Android 9 Pie
Android App Bundle
android design
Android Dev Summit
Android Developers
android Jetpack
Android P
Android SDK
Android Studio
Android Things
Android Wear
AndroidDevStory
androititlan
angelina jolie
Annotation
Announcements
anuncios
API
API Analytics YouTube
Apigee
APIs
Aplicaciones
aplicaciones chrome
app
app engine
App Indexing
app invites
App Server
applications
AppQuality
apps
Apps Script
AR
ARCore
arte
ATLAS
AWP
backend
Base64
batch
Bava
Betatesting
Better Ads Standars
bigdata
BigQuery
Biometrics
blink
bootcamp
BOT
BQ
Business
búsqueda ajax
by Google
byCases
byCommunity
byDevelopers
byGoogle
C++
CALENDAR
Cardboard
case
caso de éxito
Casos de éxito
casos destacados
CCOSS
Century Fox
chat
chrome
chrome web store
chromebook
chromecast
chromium
Cinéfilos
cloud
Cloud Anchors
CLOUD endpoints
Cloud Firestore
Cloud Functions
Cloud IoT Core
Cloud Next
Cloud Scheduler
Cloud services
cloud test lab
Cloud Text-to-Speech
Cloud Translation
CMD en vivo
coconut
code
code-in
code.org
CodeLabs
código
código abierto
Colab
colombia
Communities
Comunidades
concurso google
conference
contenedores
convocatoria
Coordinate
crashlytics
CRE
crear aplicaciones ajax
creatividad
Crowdsource
CSS
cws
daniela robles
dart
dart sdk
dartium
dartlang
Dataset
DCL
denis labelle
desarrolladores
Desarrolladores Google
desarrolladores LatAm
Desarrollar
Design
Design Sprint
Destacados
dev
Dev.f
DevArt
DevBus
DevBusLatAm
Developer Bus
Developer Summit
DeveloperConsole
developers
DevFest
devoxx
dialogflow
diseño UX
Distribuir
DNS
DOM
domain
DonkeyCar
doubleclick
Drive SDK
Drivers
ecommerce
ecosistema
elections
elizalde
Emoticons
emprendedores
empresas
engagement
english
Enhanced Campaigns
enterprise
eventos
Events
evolución de aplicaciones
Excel
ExpertosDicen
Faas
Family
FanBridge
FCM
FCP
Featured
fido
find people
Fintech
firebase
Firebase Cloud Messaging
firebase summit
flu trends
Flutter
Flutter 1.0
flutter 1.7
flutter developers
Flutter Live
FlutterLive
FoundersLab
Freebase
Fuction
Fuctions
Full-Stack
functional programming
G Suite Dev Show
G+
g+ goto gal
G+GotoGal
GAE
game
games
GCloud
gcm
GCP
GCS
GDA
GDE
GDG
GDH
GDL
GDLevent
GDS
Get Inspired
get.app
GitHub
GLP
gmail
golang
GOMO
Google
Google Accelerator
Google AdMob SDK
Google AdWords
Google Analytics
Google APIS
Google App Engine
Google Apps
Google Apps Script
Google Art Project
Google Assistant
google calendar
google cast
Google Charts
Google Chrome
Google Cloud
Google Cloud Console
Google Cloud Messaging
Google Cloud Next
Google Cloud Platform
Google Cloud Platform Newsletter
google cloud platforn
Google Cloud Storage
google code-in
Google Compute Engine
Google Dataset
Google Developer Groups
google developers
Google Developers Academy
google developers expert
Google Developers Hackademy
google dns
Google Drawings
Google Drive
Google Earth
Google for games
Google Forms
google geo
Google Home
google i/o
google i/o extended
google io
Google Keep
Google Kubernetes Engine
Google Launchapad
Google Launchpad
Google Maps
google maps coordinate
Google Maps Platform
Google Mexico
Google Nose
google now
Google Person Finder
google places api
Google Play
Google Play Books
Google Play Developer API
google play games
Google Play Movies
Google Play Protect
Google Play Services
Google Plus
Google Science Fair
google search
Google Sheets
google sign in
Google Top Geek
Google+
Google+ Communities
Google+ Hangouts
google+ sign-in
GoogleAPI
googlecloud storage
GoogleCloudPlatform
googledevs
GooglePlay
Googleplex
Goolge Lunchpad
GTG
Hackademy
hackers
Haiko
Haití
hangouts
Hangouts Remote Desktop
hardcode
Heello
honeycomb
HTML
HTML5
HTTPS
I/O
IA
IAM
IETF
IFAI
in app purchases
in-app
ingles
Ingress
instagram
integración de soluciones
interactive post
Interesante
International
International Women’s Day
IO
io15
io18
io19
iOS
IoT
istio
IU
IVR
J2EE
java
JavaScript
jelly bean
JS
JSON
Juegos
juegos html5
Kit ML
Knative
kotlin
kUBERNATES
Kubernetes
LATAM
latamRegionSur
Launchpad
Launchpad Studio
Lenovo Mirage Solo
lightbox
linux
lucero galindo
machine learning
Made with Code
Mapdata
Mapeo
maps
Maps Ad Unit
Maps API
Maps Engine
Market
Marketing
Marshmallow
MATERIAL DESIG
Material Design
mejores apps 2013
México
michelle marie
MIT
MIT Global Start-up Labs
MIT-AITI
ML
ML Kit
mobile
monetizar
mongoDB
MOOC
Motorola
Mountain View
móvil
MQTT
mr.white
mTLS
natalie villalobos
Navigation
NBA JAM
NES
Next Big Sound
Next Level
nfc
Niantic
Nik
NINTENDO
node.js
NoSQL
nube
OAuth2
Objective-C
OClock
open source
OPenApi
OS
OSS
Paas
PageSpeed
PagesSpeed
parallel18
patrones
patters
performance
permisos
Pipeline API
Pixability
pixel
Píxel
play
Play Console
Playtime
Podcast
pollito pio
Polymer
por lote
Posse
Prediction API
primer
Producto
programación
Propositos
Protocol Buffers
proyecto 20%
Push API
PYMES
python
Q
Q4
quickoffice
Rasberry Pi Zero WH
Raspberry Pi
Realtime
Reflectly
register
Release
Resources
robots.txt
Safe
SDK
Search
Security
seedbank
seguridad
SEO
servidores
Showyou
sign-in
SNES
SO
social media
Spain
SpLATAM
SQL
SQLite
Start
startup grind
Startup Launch
startup weekend
startup weekend for the planet
startupbus
startups
StayAtHome
story
Street View
subtitles
success
sw
SyScan
tablet
Tablet Optimization Tips
tabletas
takeaction
Tango
tendencias 2013
TensorFlow Developer Summit
testing
TextView
TF JAM
The Garage
The Venture City
tips G+
tips gmail
TLD
TLS
Top Experts
Top Geek
top level domain
TopExpert
topics
traducciones
Transparency Report
triggers
Tubular Labs
twilio
Tyka
TypeScript
UAC
udacity
ui
Umbrales
UNAM
unity
Unity3D
universal search
UX
Vector
VectorDrawable
video juegos
vidIQ
ViewPager
Visual Progress
Voicekit
VPC
VR
VSCode
web
Web hosting
Web móvil
WebAssembly
with google
Wizdeo
WizTracker
Women at Google
Women Techmakers
workmanager
WTM
XKCD
XML
Yifat Cohen
youtube
YouTube Analytics API
YouTube API
YouTube Data API
YouTube One Channel
YouTube Player API
Archive
2024
sept
2023
nov
oct
sept
ago
jun
may
abr
mar
ene
2022
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2021
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
2020
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2019
dic
nov
oct
sept
ago
jun
may
abr
mar
feb
ene
2018
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
2017
nov
sept
ago
jul
jun
may
abr
ene
2016
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2015
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2014
dic
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2013
dic
nov
oct
ago
jul
jun
may
abr
mar
feb
ene
2012
dic
nov
oct
sept
ago
jul
2011
nov
oct
may
mar
2010
dic
nov
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2009
dic
nov
sept
ago
jul
jun
may
abr
mar
feb
ene
2008
oct
sept
ago
jul
jun
may
abr
mar
feb
ene
2007
dic
Feed
Desarrolladores
Eventos y Comunidad
Casos Destacados
Dicen los Expertos
Google Accelerator
