Páginas

20 sept. 2015

Migrar una aplicación de Android a Xamarin

Tras las últimas batallas con arquitecturas Android he decidido darle una oportunidad a Xamarin ya que los problemas que estaba teniendo con Android Studio estoy acostumbrado a resolverlos a diario con Visual Studio, el entorno con el que habitualmente trabajo. Estoy muy contento pues he estado migrando la aplicación en la que más usuarios activos tengo y el proceso no ha sido demasiado costoso.

1º Crear una solución en Blanco
2º Añadir un Proyecto Android vacío
3º Copiar layouts de su carpeta en el proyecto antiguo a la carpeta del proyecto nuevo.
4º Renombrar de xml a axml esos ficheros
5º Lo mismo pero con los strings (en éste proyecto tengo muchísimas traducciones y esto fue un rollo)
6º Generar las carpetas para los drawables e ir copiando del proyecto viejo al nuevo.
7º Hacer los ajustes necesarios en el manifest.
8º Para poder usar los anuncios, tal y como los usaba con Admob, tuve que añadir el componente de Google Play Services (botón derecho sobre la carpeta componentes desde la solución, siguiente siguiente, etcétera...)
9º Copiar la actividad de inicio, el .java, al nuevo proyecto, renombrar el fichero a .cs y modificar el código para que sea C# en vez de java (son cuatro cosas, de imports a usings, the super a base, los getters y los setters pasan a ser propiedades y los namespaces se mantienen casi iguales)
10º Establecer la actividad de inicio en el código añadiendo el atributo así:

[Activity(Label = "YourProyect.Droid", MainLauncher = true, Icon = "@drawable/your_icon_resource")]

Ojo: todas las Activities tienen que tener el atributo [Activity]

Además, de esto añadí varios servicios, un bradcast reciever y ahora estoy adaptando los anuncios pero he tenido algún problema para que compilara y lo arreglé fijándome bien en las versiones de Android contra las que compilo (21 en mi caso) y añadiendo en las opciones del proyecto, en opciones de Android, Opciones avanzadas "Java Max Heap Size:" 1G.


Y de momento eso es todo por ahora, voy a seguir más actividades y dejando el código bonito, como a mi me gusta. ¡Que viva C#!

16 sept. 2015

Como sobrevivir a CryptoWall 3.0

El otro día me llamó mi madre mientras yo estaba escalando en la montaña y me dijo que el ordenador no arrancaba, que llevaba un rato y no había ni aparecido el escritorio así que le dije que lo apagara con un botonazo si hacía falta y le prometí que me pasaría en cuanto pudiera para echarle un vistazo. El lunes, al salir del trabajo, me pasé por su casa y encendí el ordenador y me encontré con que tras hacer login el equipo no respondía y si iniciaba el administrador de tareas éste se cerraba a los pocos segundos. 


Pensé que lo mejor era reiniciar y arrancar el equipo en el modo a prueba de fallos pero al intentarlo éste se reiniciaba automáticamente, no lo conseguí ni en modo consola, ni en modo a prueba de fallos ni en modo a prueba de fallos con funciones de red, se reiniciaba siempre, no obstante se me ocurrió probar el "Modo de restauración de servicios de directorio" (información sobre los modos de arranque) y para mi sorpresa el sistema, por fin, arrancó en modo a prueba de fallos. 

Según arrancó el sistema pulsé Ctrl+Sift+Esc para abrir el administrador de tareas y me puse a matar procesos como un loco hasta dejar lo imprescindible para que no se reiniciara el sistema. Me dí cuenta de que había una serie de procesos que pese a matarlos se relanzaban ellos solos y en concreto el que me llamó la atención era dllhost.exe. Éste proceso es el que estaba ralentizando el sistema y si lo mataba volvía a ejecutarse tras unos cinco segundos. 



Desde el propio administrador de tareas ejecuté cmd para abrir una consola de windows y mientras cada cinco segundos mataba el proceso dllhost.exe escribí lo siguiente en la consola:

for /l %x in (1,1,100) do ( taskkill /f /im dllhost.exe)


Ese comando ejecuta cien veces la instrucción de matar el proceso dllhost.exe, luego lo edité para que se ejecutara cien mil veces y entonces ya puede empezar a trabajar. El ordenador seguía yendo muy lento pero una vez muerto el proceso dllhost.exe por fin pude ver el escritorio y un montón de ficheros con extensión .aaa y busqué desde mi móvil al respecto mientras pasaba el Malwarebytes Antimalware. Vi que se trataba del virus Crypto Wall porque se abrieron varias ventanas de internet explorer con el mensaje de chantaje y también en formato txt. Mientras trabajaba para intentar quitar el virus vi en el administrador de tareas (no lo cerré en ningún momento) que se abrían procesos con nombrees conocidos tipo msiexec.exe y cosas así y esos los fui matando según me percataba. 

En ésta página vi varias rutas donde se suele alojar el virus y con rmdir /R NombreDelDirectorio, desde la consola, fui eliminando carpetas "raras" que iba encontrando en:
  • C:\<random>\<random>.exe
  • C:\Users\<User>\AppData\Local\<random>.exe (Vista/7/8)
  • C:\Users\<User>\AppData\Local\<random>.exe (Vista/7/8)
  • C:\Documents and Settings\<User>\Application Data\<random>.exe (XP)
  • C:\Documents and Settings\<User>\Local Application Data\<random>.exe (XP)
  • %Temp%
También me percaté de que en el registro había entradas del tipo svc+ 5 caracteres aleatorios así que busqué svc y me recorrí todo el registro borrando entradas sospechosas (ojo que aquí si no sabes lo que borras te la juegas)...

Y todo esto que os cuento lo hice mientras pasaba mbam.exe y me bajaba un antivirus y lo instalaba. Tras varias horas de lucha reinicié el equipo para que el antivirus hiciera un análisis profundo y éste quitó todo lo que yo no había sido capaz de encontrar y borrar a mano y mi madre vuelve a tener ordenador pero muchos de sus documentos fueron cifrados y tras probar varias recetas he preferido darlos por perdidos y directamente los he eliminado. Hubo mucha suerte porque el virus se cebó principalmente con varias copias de seguridad que yo tenía en ese ordenador con documentos de la universidad, de repositorios de código y cosas que, en el fondo, ya no eran útiles, eso sí, todo lo que había en el escritorio, fotos y documentos de MS Office, fueron cifrados y los hemos dado por perdidos y eliminado. En total la cantidad de ficheros cifrados han sido algo mas de once mil, unos 8 GB de ficheros de texto, código y documentos de MS Office... Pero lo cogí a tiempo y le corté los huevos.

Un detalle chulo al caso de todo esto, recordé varias pruebas que hice hace tiempo con rootkits caseros pues mbam y el antivirus encontraron entradas ADS (Alternate Data System) con el virus que es la delicia para los rootkits y el spyware. A grandes rasgos ADS puede servir como sistema de ficheros alternativo y oculto para el sistema operativo y el usuario, es el lugar ideal para meter mierda sin que nadie se entere...

Y lo dejo por hoy. Espero que esto le valga a alguien.

31 ago. 2015

Sobre arquitecturas en Android

Ya hablé algo sobre este tema hace mucho tiempo pero las cosas han cambiado mucho desde entonces y escribo este artículo puesto que me ha costado mucho encontrar información útil sobre la materia. Parece que a quienes documentan para los desarrolladores Android no les importan mucho las buenas prácticas en cuanto a arquitectura o dan por hecho que los desarrolladores son suficientemente maduros como para solucionarse ellos solos estas cuestiones. La verdad es que ideas no me faltan, ni me faltaban, pero al no encontrar ni una sola referencia a este tema uno acaba metiendo todo en el mismo proyecto Android y acaba cayendo en errores típicos de otra década como son alto acoplamiento, poca reutilización de código y poca cohesión, en definitiva código sucio y difícilmente escalable... Pero por suerte, tras mucho buscar y varias preguntas en Stack Overflow, entre ellas éste, he encontrado con algo que me gusta y sobre lo que quiero basar mi actual desarrollo, Clean Architecture.

Una de las últimas tendencias en cuanto a arquitecturas, no sólo para Android, se conoce como Clean Architecture, no voy a entrar en detalles pues el artículo que la presenta lo hace mucho mejor de lo que yo lo podría hacer, se merece al menos una lectura en diagonal si vas a seguir leyendo mi artículo:
Buscando por la red he encontrado una implementación de este patrón que es lo que quiero replicar hoy y es el objetivo de éste artículo. Estoy hablando del artículo de Fernando Cejas - Architecting Android…The evolution Él propone lo siguiente:


Fernando nos dice que la cantidad de círculos, de capas, no importa, que lo verdaderamente importante es que las dependencias vayan en una única dirección, hacia dentro. Si nos fijamos este modelo viene a ser el diseño guiado por domino (Domain Driven Design) pero representado en forma de círculos concéntricos. ¿Qué significa cada cosa? (Me voy a limitar a hacer una traducción casi literal)
  • Entities: Entidades, objetos de negocio de la aplicación.
  • Use Cases: dirigen el flujo de datos de y hacia las entidades, también se les conoce como Interactors
  • Interface Adapters: son un conjunto de adaptadores que convierten datos entre el formato mas conveniente para los Interactors y las entidades...
  • Frameworks and Drivers: aquí es donde van todos los detalles, la interfaz de usuario, herramientas y ese tipo de cosas...
Yo no voy a seguir el ejemplo de Fernando, yo ya tengo una aplicación con una funcionalidad muy básica que quiero migrar hacia éste modelo arquitectónico por capas tal y como estoy acostumbrado a hacerlo en otros entornos partiendo de mi actual proyecto y lo que voy a hacer va a ser crear una librería de Android para el dominio y otra para los datos y ahora os enseño como queda la estructura de mi proyecto.
Varias horas después...
 Hey! ¡Sigo aquí! Me he peleado con gradle y con temas de dependencias, con los nombres de los paquetes, con Android Studio y con un montón de cosas (de hecho empecé ayer con todo esto y hoy he seguido según he vuelto del trabajo...) Y bueno, ya tengo un proyecto que compila, aún no lo he ejecutado porque sé que el funcionamiento de lo que haya ahora será trivial, absurdo, he quitado mucho de lo que tenía para ceñirme a la estructura del proyecto de Fernando porque viendo su código y su estructura he visto muchas cosas que me gustan y muchas técnicas que quiero utilizar en mi proyecto... Y, lo dicho, por fin tengo un proyecto que compila y con la siguiente estructura:


Una de las cosas que me han gustado de lo que he visto y copiado del proyecto de Fernando es la Inyección de Dependencias ya que yo vengo de .Net y no había visto nada parecido aplicado a Android como Dagger 2. Lo nombro pero no voy a explicar como se hace ya que podéis verlo en el código del proyecto y podéis leer un manual bastante potente que el mismo Fernando escribió hace no mucho: Tasting Dagger 2 on Android

De igual forma me ha gustado mucho el uso de RxJava, ya me lo habían recomendado pero hasta ahora no me había atrevido a adentrarme mucho, pero ya que el ejemplo lo traía le he dedicado un buen tiempo a leer sobre él, tanto en sus orígenes como Rx (Reactive Extensions) (puede que lo use para solucionar un requisito con el que estamos de lleno en el curro), hasta varios ejemplos de RxJava como éste del propio Fernando y o este otro muy interesante de Matthias Käppler, además de la Wiki de GitHub ... Pero quizá lo que más aclare su aplicación y uso sea ésta página sobre el The RxJava Android Module y éste diagrama que explica como se utiliza, con qué intenciones:


Al final el resultado es, a grandes rasgos, el módulo de presentación que contiene lo relativo a presentación pura, con un patrón MVP además de varios paquetes de utilidades (constantes, excepciones, la inyección de dependencias, etcétera); un modulo de Datos cuya responsabilidad es la gestión de los datos de la aplicación, esto es, cachés, ficheros locales, llamadas al API Rest, etcétera; y un módulo de Dominio donde se definen las clases del dominio y los casos de uso, los interactors, que son inyectados en la capa de presentación mediante ActivityComponentes y Módulos (ésto está en presentation/internal.di/).  

Me ha costado bastante, la verdad, sacar conclusiones de lo que he ido viendo, entender usos de algunas cosas haciendo ingeniería inversa, adaptar su proyecto y la inyección de dependencias en la capa de presentación para tirar de AppCompatActivity y poder seguir usando Material tal y como lo estaba haciendo antes... pero todo o casi todo lo que he visto me ha gustado y definitivamente voy a usar esta estructura para mi proyecto actual. Aún tengo que refactorizar cosas, por ejemplo me gustaría sacar clases genéricas en varias cosas pues en su ejemplo trabaja con users pero yo voy a trabajar con otras entidades y ya he visto mientras estudiaba el código varios puntos donde tendría que generalizar... Quizá dentro de poco vuelva a escribir para contar qué tal me va con ésta aventura en la que ando liado últimamente, espero que todo esto que he escrito, que no dejan de ser divagaciones, le sirva a alguien para mejorar un poco la estructura y la calidad de sus proyectos Android.

A Fernando, si alguna vez me lees, gracias!