GDG DevFest III: Persistiendo que es gerundio, Jorge Juan Barroso Carmona

Contenido:

Persistencia: mostramos/guardamos datos aún cuando no hay red.
Mobile first vs offline first
Pensar que nuestra app pueda funcionar SIN que haya conexión a red: offline is not an error
No exigir conexión a internet puede ser ventajoso para nosotros y para el cliente.
Mem caché: guardar info en memoria
Usar shared preferences (https://developer.android.com/reference/android/content/SharedPreferences.html)
weakReference (https://developer.android.com/reference/java/lang/ref/WeakReference.html)
Bases de datos
- Si solo queremos guardar > JSON y guardr en disco
- ORM, ORMLite (mejor que GreenDAO y SugarORM)
- Realm: rápida, no SQL; no permite acceder desde diferentes hilos
- Hacer siempre operaciones transaccionales
Network
- Retrofit para apis rest
Patrón Repositorio: http://www.martinfowler.com/eaaCatalog/repository.html

Anuncios

GDG DevFest II: Programando Android como Ingenieros, Olmo Gallegos

Conceptos

STUPID: Código malo (http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/)
- Singleton
- Tight Coupling
- Untestability
- Premature Optimization
- Indescriptive Naming
- Duplication
Patrones de diseño
- Singleton: peligroso > Android SDK permite hacer lo mismo pero de otra forma menos peligrosa
- Observer (=Listener)
- Respository
- Builder
- NullObject
- Model-View-Presenter
Arquitectura CLEAN:
- Ejemplo en Github: https://github.com/voghDev
- XML para definir los estilos de las vistas
Librerías externas
- retrofit / retrofit2
- dagger
- otto
- picasso
- butterknife
- dagger2
- RecyclerView
- Glide
- renderers
- google/exoplayer
- DBFlow
- SectionedRecyclerView
- WheelIndicatorView

Hate de code you wrote 6 months ago

Clean Code
Metodología SOLID: http://www.cmjackson.net/2009/09/04/solid-programming-principles/
- Single responsability
- Open/Close
- Liskov Substitution
- Interface segregation
- Dependency Inversion
Gran importancia de hacer test al código… ¡test automáticos!
- Refactorizar código sin hacer tests, no es refactorizar.
Alta “mantenibilidad”, baja “deuda técnica” (=consecuencia de nuestras malas decisiones)
No obstante…¡¡ojo con la “sobre-ingeniería”
Arquitectura Hexagonal:
- http://alistair.cockburn.us/Hexagonal+architecture
- Distintos actores pueden ejecutar tu aplicación: usuarios, programas autónomos, scripts de test…
- Puertos + Adaptadores: Puerto = API, Adaptador = Implementación de un puerto
- En Java los puertos son las interfaces y los adptadores son las implementaciones de la interfaz