NoticiasBlog.

pago móvil

Buenas prácticas para desarrollar una App

13 diciembre, 2017 | APPs, Desarrollo

En la vida del desarrollador, puede que comiences un proyecto de cero o te encuentres con uno ya en proceso de desarrollo.
Para el primer caso, eres tu el que comienzas a desarrollarlo, por lo que tienes una libertad en cuanto a la arquitectura y el desarrollo de la misma. La barrera que obstaculiza el entendimiento del proyecto y las horas de depuración para entender el funcionamiento del mismo, desaparecen.

Seguramente te encuentres en el segundo caso, por lo que si el proyecto se realizó con buenas prácticas, no te será muy complicado realizar las modificaciones oportunas para incorporar nuevas funcionalidades, ajustes visuales, optimizaciones…

Lamentablemente, eso no es una realidad para la mayoría de los casos, por lo que se pueden encontrar con proyectos, que si bien, son plenamente funcionales, su escalabilidad es un autentico laberinto, obligando a posteriores desarrolladores a que se adentren dentro de un misterioso y ominoso mundo, algo así como “Alicia, en el país de la maravillas” pero con mucho café de por medio.

Se pierde mucho tiempo para adaptar y escalar dichos proyectos. Es por ello, que entran en juego las llamadas “Buenas practicas para el desarrollo”. El tiempo tiene un valor incalculable, valor que determina el resultado final del proyecto. Hay unas estimaciones y unos costes. Lo que interesa es reducir el tiempo de entendimiento y de escalabilidad del proyecto, logrando unos resultados.

Como desarrolladores, debemos hacer aplicaciones funcionales, útiles y atractivas, pero también seguras, o al menos hacer todo lo posible para proteger la información privada. Se van a definir una serie de buenas practicas y algunos tips que servirán como primera toma de contacto con el tema:

 

1.Hay que tener en cuenta la complejidad del proyecto.

Si sabemos de primera mano que va a disponer de una gran cantidad de funcionalidades, y que a posteriori, se van a ir incorporando cada vez más, la arquitectura MVP es una buena solución en cuento a escalabilidad y seguridad.
Aplicar una arquitectura limpia consumirá más tiempo a la hora de empezar a diseñar la base del proyecto, pero a la larga, reducirá tiempos de cara a posteriores modificaciones.
Esto es debido al hecho de dividir la parte visual de la lógica, eliminando la dependencia de la base del proyecto con elementos externos y garantizando su funcionamiento integro, acceso de repositorios, reutilización de código, y librerías de terceros para simplificar las arduas tareas (Butterknife, Dagger. Glide, FlowUp, Calligraphy…)

Recomiendo estos enlaces para una toma de contacto con ello:

https://www.paradigmadigital.com/dev/introduccion-los-componentes-arquitectura-android-go-clean/
https://erikcaffrey.github.io/ANDROID-clean-architecture/
https://www.genbetadev.com/paradigmas-de-programacion/usando-mvp-e-inversion-de-dependencias-para-abstraernos-del-framework-en-android

2. Documentar el proyecto.

Algo tan cotidiano como ir comentando cada una de las funciones que estamos incorporando al proyecto y que termina en el olvido en muchas ocasiones. El objetivo de esto es tener una hoja de ruta para los actuales y futuros desarrolladores, accediendo a la información desde un documento generado y reducir así el tiempo para entender el funcionamiento del mismo. Piensa en un mapa para turistas en el que consultar cada elemento del lugar… pues la documentación es exactamente igual.

3. Ofuscar el código del proyecto compilado y cifrar los datos comprometedores.

No emplear un mecanismo criptográfico pone en riesgo la integridad de los datos privados del usuario.

Pero utilizar dichos mecanismos de manera inadecuada, garantizando una inexistente seguridad para con el usuario, lo deja en una situación de riesgo incluso peor.
Prevenir siempre sera la mejor contramedida. Es por ello, que se suelen utilizar soluciones como Proguard, que es gratuita, para ofuscar los métodos del proyecto y realiza optimizaciones del mismo. Como debilidad, no cifra los Strings del proyecto, por lo que si las claves son definidas en dichas variables, pues serán claramente legibles.
Por ello, hay otras soluciones, algunas de pago como DexGuard y DexProtector, que impiden por completo la visualización de la información del mismo mediante algoritmos de cifrado más robustos que los anteriores.
Es importante mantener las comunicaciones y llamadas a servidores (Retrofit, Volley), bases de datos (Realm) de manera segura. Esto es fundamental para pasarelas de pago, tarjetas de crédito y transacciones varias (BrainTree).
Existen diversas formas de cifrar la información, recomiendo las soluciones de SpongyCastle (Version recortada de Bouncycastle) e IQrypt. Crypto ha dado algunos problemas de vulnerabilidad en estos últimos años, y teniendo en cuenta que dispone de unas librerías más básicas que las de SpongyCastle, es un paso atrás.
https://www.redeszone.net/2016/06/13/google-prescinde-crypto-software-cifrado-android-n/

Recomiendo estos enlaces para una toma de contacto con ello:

https://www.developereconomics.com/android-cryptography-tools-for-beginners
http://rtyley.github.io/spongycastle/
http://www.bouncycastle.org/java.html

4. Mantener las librerías en la misma versión.

Cuando añadimos dependencias en gradle, en muchas ocasiones, incluimos referencias a librerías con versiones diferentes. Esto da problemas a la hora de firmar y/o compilar el proyecto en un .apk de producción. Se recomienda introducir variables que gestionen dichas versiones e incluir las referencias necesarias.

5. Pruebas y verificación.

Recomiendo encarecidamente Firebase y su crash-reporting.
Es fundamental para poder detectar problemas en diferentes terminales y casuísticas. Ademas que es muy fácil de integrar dado que el propio IDE viene con esa opción.También se dispone de Hockeyapp, que permite la subida de versiones en depuración de una app por cada versión para que podamos probar la app en diferentes terminales móviles, pudiendo gestionar y tratar los posibles errores.

6. Tips varios:

☛ Ralentizaciones con imágenes de alta densidad de pixeles.
En muchas ocasiones solo disponemos de un recursos gráfico de alta densidad, y no podemos adaptarlo de diferentes versiones.
Para evitar re-escalados y ralentizaciones en terminales móviles, se recomienda introducir dichos drawables en un directorio inexistente llamado “drawable-nodpi”, para evitar que el dispositivo tenga que re-escalar y calcular los mipmaps de la imagen, generando ralentizaciones.

☛ Problemas de carga de librerías ya definidas.
En el editor Android Studio, con acceder a File/Invalidate caches/restart se suele solucionar el problema. Comprobar si la versión del SDK es la adecuada.
También consultar si en build.gradle del proyecto tiene la dependencia.

maven { url “https://maven.google.com” } ,

Todas las librerías vienen definidas en un .iml con el nombre del proyecto.

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *