• Sandbox. • No se puede comunicar con otras aplicaciones directamente. • Se “comunican” a través de Intents. • Cada app corre en un proceso Linux. • El SO es el encargado de iniciar y terminar el proceso.
que ejecutarse por largo tiempo. • No debe confundirse con threads/hilos. • Corre en el MainThread de Android • Usos: música en segundo plano, descargas, sincronización de datos, etc. • Ejemplo: Spotify
• Internos • Systemwide • Parecido a un Bus de Datos. Clientes se suscriben a qué notificaciones desean recibir: • Nuevo SMS • Batería Baja • GPS Activado • Pueden “Despertar” apps que no estén corriendo. • Ejemplo: Dropbox
la aplicación • Incluso con otras aplicaciones. Ejemplo: Agenda de Contactos, Calendario. • “Abstrae” el lugar físico en donde se encuentra la información a través de URIs • Agenda: • App Contactos: Almacenados en SQLite • Otra App: “contacts://all/”
archivos generados por Android Studio en la fase de compilación. • *.iml • .idea/ • Recientemente el .gitignore default del proyecto viene con esta configuración.
Java podemos llamar código Kotlin y viceversa. • Conciso y Extendible • Código Seguro • Programación Funcional • Adoptado por Google gracias al empuje de la comunidad.
Thread • No debemos bloquear este hilo • Application Not Responding (ANR) • 5 segundos sin respuesta a inputs (touch events) • Crear nuestros propios hilos en background y refrescar el UI
el UI en el MainThread • Podemos crear hilos de cualquier manera siempre y cuando respetemos el MainThread. • Threads + Runnables, AsyncTask, Courutines (Kotlin), RxJava2, etc • No Silver Bullet • Actualmente RxJava2
está corriendo nuestra aplicación: • Orientación de Pantalla: De Portrait a Landscape • Disponibilidad de Teclado • Ejecución de Multi-Window • Densidad de Pantalla • etc • Nuestras apps deben comportarse correctamente ante estos cambios.
El SO provee de nuevos recursos a la App según el cambio de configuración experimentado. • El SO necesita liberar memoria RAM para poder ejecutar otras aplicaciones. • Apps con las que el usuario desea interactuar. • El SO no solo elimina de la memoria Actividades, sino todo el Proceso en el que se ejecuta la App. • Cada App debe saber como restaurar su estado al punto en que el usuario dejó de interactuar con ella.
para guardar el estado de la app. • onSaveInstanceState + ids en Views • El SO es el encargado de gestionar los cambios/datos que se desean mantener. • 50KB o menos recomienda Google • Debe ser combinado con otros mecanismos de persistencia de datos: • Base de Datos, SharedPreferences, Archivos
con 20 campos que proviene de una api? ¿Debo guardar cada uno en un key + value en onSaveInstanceState()? • Se puede hacer, pero depende de nuestra app: • ¿Tenemos base de datos? • ¿Tenemos cache de nuestra api? • ¿El valor es una preferencia? • ¿Se trata de un dato que puede ser recuperado nuevamente?
con 20 campos que proviene de una api? ¿Debo guardar cada uno en un key + value en onSaveInstanceState()? • Podemos guardar • Todo el objeto en cache/base de datos y solo grabar el id del registro en onSaveInstanceState() • Todo el objeto como Parcelable • Podemos mantenerlo en memoria • Podemos hacer el request nuevamente • No Silver Bullet
Startup • onStart: pantalla visible pero no interactiva. • onResume: pantalla visible e interactiva. • onPause: pantalla visible pero no interactiva. • onStop: pantalla no visible • onDestroy: pantalla fuera de memoria.
y por responsabilidades. • Api, Base de Datos, Lógica de Negocio, UI, etc. • Todos empezamos escribiendo código de manera desordenada. • No está mal. Así vamos aprendiendo. • Error: No darnos cuenta de la necesidad de la separación de responsabilidades.
el acoplamiento (“binding”). • A través del “binding” se actualizan las variables u objetos declarados en el layout.xml y la vista se actualiza automáticamente.
Antes se declaraban únicamente. • Marshmallow 6.0: se declaran y se solicitan en ejecución. • Siempre verificar que se tiene el Permiso, a pesar de que previamente nos lo hayan otorgado.
Es difícil de implementar, pero no imposible. • No existe un patrón / estándar definido. Varía de arquitectura en arquitectura. • JUnit y Espresso • Barista
asantibanez
ogurotakayuki
.JPG){kind=avatar}
ymd65536
youkidearitai
pangmoo
kuroppe1819
linew_official
kj455
seike460
demuyan
mizdra
oskmr
teamlab
holman
zenorocha
yeseniaperezcruz
carmenintech
jacobian
lauravandoore
pedronauck
trallard
aleyda
eileencodes
addyosmani
brad_frost
