Memoria

La memoria RAM de un dispositivo m´ovil posee caracter´ısticas f´ısicas muy diferentes a la memoria RAM presente en una computadora de escritorio, como su tama˜no mucho menor y su eficiencia orientada a consumir la menor cantidad posible de bater´ıa. En general, la memoria RAM de una computadora de escritorio es ampliamente m´as r´apida que la presente en un dispositivo m´ovil. Es por ello que es de suma importancia que las aplicaciones desarrolladas para sistemas m´oviles hagan un uso eficiente de la misma, utilizando la menor cantidad posible.

Android es un sistema operativo basado en Linux, y por lo tanto el manejo de la me- moria es similar a dicho sistema. Los sistemas Android reservan memoria RAM libre para las aplicaciones en ejecuci´on, de manera que las mismas podr´ıan no estar efectivamente utili- zando toda sus memoria asignada. De esta manera, si la aplicaci´on aumenta sus necesidades de memoria, la misma se le puede ser entregada de forma inmediata.

Otro concepto importante del manejo de la memoria en Android, es que la memoria RAM no utilizada es considerada como memoria desperdiciada. Por tal motivo, se intenta utilizar la mayor cantidad de memoria posible, sin llegar nunca al l´ımite disponible, para aumentar la eficiencia. Cuantas m´as aplicaciones que se usan frecuentemente se encuen- tren pre-cargadas en memoria, mayor ser´a la eficiencia y menor el consumo de bater´ıa del dispositivo.

Para desarrollar aplicaciones que hagan un uso ´optimo de la memoria, es necesario tener en cuenta todos los conceptos mencionados con respecto a la administraci´on de la misma en sistemas Android. Existe una lista de consejos y buenas pr´acticas [47] que los desarrolladores deben seguir para mejorar el uso de la memoria en aplicaciones Android, entre los cuales se encuentran los siguientes que fueron especialmente tenidas en cuenta para el desarrollo de la herramienta presentada:

Evitar la creaci´on innecesaria de objetos. No ocupar memoria con objetos temporales o con un corto ciclo de vida si puede evitarse. De esta forma, cuando la creaci´on de objetos sea la m´ınima posible, el proceso de garbage collection ocurrir´a con menor frecuencia.

Hacer uso de servicios con precauci´on. Los servicios son un tipo de componente de una aplicaci´on Android que puede realizar operaciones de larga ejecuci´on en segundo plano y que no proporciona una interfaz de usuario.

Utilizar librer´ıas externas optimizadas. Muchas librer´ıas externas frecuentemente est´an escritas para dispositivos no m´oviles y pueden funcionar ineficientemente en Android. Evitar el uso de clases embebidas (inner classes) no est´aticas en lasactivities (compo- nente de una aplicaci´on Android que ser´a detallado en la siguiente secci´on). En Java, las clases an´onimas no est´aticas tienen una referencia impl´ıcita a su clase contenedo- ra. Si no se tienen precauciones, mantener estas referencias puede resultar en que la

activity sea retenida cuando de otra manera ser´ıa eligible por el garbage collect. No olvidar cerrar los cursores luego de consultar una base de datos. Si se requiere mantener un cursor por un tiempo considerable, el mismo debe ser utilizado cuidado- samente y ser cerrado tan pronto como concluya la tarea sobre la base de datos.

3.2.

Programaci´on en Android

3.2.1.

Componentes de la aplicaci´on

La plataforma Android ofrece diversos tipos de componentes que pueden utilizarse para la implementaci´on de una aplicaci´on. Los componentes son los bloques de creaci´on fundamentales de las mismas, y cada uno de ellos posee un rol espec´ıfico que contribuye a

3.2 Programaci´on en Android 23

definir el comportamiento general de la herramienta. Cada componente es ´unico, y puede requerir de otros componentes para llevar a cabo sus tareas. A continuaci´on se describen los principales componentes utilizados en este trabajo.

3.2.1.1. Activity

Una actividad o activity es un componente que representa una pantalla dentro de la aplicaci´on, mediante la cual el usuario puede interactuar y realizar las tareas que est´en disponibles dentro de la misma.

La representaci´on de la pantalla en s´ı misma, no se encuentra dentro de este tipo de componente, sino en archivos xml denominados layouts asociados a cada uno de ellos. Cada activity, entonces, tiene su correspondiente layout el cual le permite acceder a todos los elementos de la vista para asignarle a cada uno de ellos el comportamiento que debe ejecutarse cuando el usuario realiza acciones sobre ellos.

Una aplicaci´on est´a normalmente formada por m´ultiplesactivities que se vinculan entre s´ı, determinando el flujo de la misma. Generalmente, una de lasactivities de la aplicaci´on se denomina como “principal”, por ser la primer pantalla que se le presenta al usuario. A partir de all´ı, laactivitity principal puede iniciar otrasactivities de acuerdo a las acciones realizadas por el usuario, y as´ı sucesivamente con cada una que se vaya ejecutando a continuaci´on.

Para mantener un registro de lasactivities ejecutadas, cada vez que se inicia una nueva, la misma capta el foco del usuario y es agregada a la denominada “pila de activities”. Esta pila sigue un mecanismo FIFO (First In, First Out), lo que significa que cuando el usuario termina de interactuar con la activity actual y presiona el bot´on “atr´as” del dispositivo, la misma es removida de la pila (y por lo tanto destruida), reanud´andose la activity anterior.

3.2.1.2. Listeners

Un listener es una interfaz que se registra en una vista y cuya funci´on es capturar un evento. Los eventos son interacciones que el usuario realiza sobre los elementos de la vista. Por ejemplo, para que la aplicaci´on responda cuando un usuario hace click (o tap) sobre un bot´on, dicho elemento debe tener registrado unlistener mediante su m´etodo setOnClic- kListener, y dicho listener implementar el m´etodo onClick. Com´unmente, para implementar esta funcionalidad se debe extender la clase listener deseada e implementar los m´etodos correspondientes, pero dado que las vistas utilizan los listeners recurrentemente para hacer sus tareas, ´esto no ser´ıa pr´actico. Para evitar ´esto, las clases de vista contienen una colec- ci´on de interfaces anidadas concallbacks que permiten definir estos m´etodos m´as f´acilmente, directamente en el c´odigo de la clase de la vista.

Uno de loslisteners m´as destacados de la aplicaci´on, es el que se registra para el elemen- to que visualiza la imagen DICOM. Estelistener se encarga de capturar el evento onTouch, es decir, cuando el usuario toca y desliza sobre la imagen para realizar la segmentaci´on del

3.2.2.

Librer´ıa DICOM

En la actualidad existen varias librer´ıas o toolkits que permiten manipular archivos DICOM mediante el lenguaje de programaci´on Java. Algunas de ellas soportan la manipu- laci´on de estructuras de datos DICOM (no solamente im´agenes, sino tambi´en waveforms o reportes estructurados) y/o servicios provistos por el est´andar (como el env´ıo de mensajes, encriptaci´on y firma electr´onica) [48]. Tambi´en existen librer´ıas que ´unicamente permiten realizar operaciones sobre las im´agenes, como lectura de frames, lectura de encabezados y conversi´on de las im´agenes a otro formato m´as convencional como JPG.

Para la elecci´on de la librer´ıa con la cual desarrollar la aplicaci´on, no solamente se debi´o tener en cuenta que la misma provea las funcionalidades necesarias para llevar a cabo las tareas requeridas sobre los archivos DICOM, sino tambi´en otros aspectos como la licencia a la cual estuviera sujeto su uso, y la posibilidad de integraci´on con una implementaci´on para el sistema Android.

Entre las librer´ıas mencionadas en [48] se destaca dcm4chee, una librer´ıa open source

muy completa y ampliamente utilizada para manipular archivos DICOM en aplicaciones Java. La misma fue considerada como primera opci´on para el desarrollo de la aplicaci´on, pero debi´o ser descartada ya que no es posible su integraci´on con un desarrollo para Android. Esto se debe a quedcm4chee utiliza clases del paquete AWT de Java, el cual no es soportado en Android.

Otras librer´ıas, como DeCaMino y Java Dicom Toolkit, fueron directamente descar- tadas por poseer s´olo licencias comerciales ya que uno de los objetivos propuestos es una aplicaci´on extensible, y las licencias privativas puede ser un limitante para futuros desarro- llos.

Finalmente, se determin´o queImebra [49] era la librer´ıa adecuada ya que cumple con todas las condiciones necesarias. Esta librer´ıa, adem´as de realizar las operaciones habituales sobre archivos DICOM, como lectura de frames, lectura de valores de tags, modificaci´on y escritura dedatasets, entre otras, posee una versi´on compatible para el desarrollo en Android. Por ´ultimo, Imebra se encuentra bajo licencia GPLv2 (GNU General Public License), con lo cual su utilizaci´on para proyectos sin fines de lucro y c´odigo abierto es gratuito.

A pesar de haber encontrado la librer´ıa adecuada, en el primer intento de uso de la mis- ma para leer unframe dentro de alg´un archivo DICOM, se obten´ıa constantemente un error. El mismo no daba demasiados detalles sobre qu´e era lo que estaba fallando exactamente. Ante la imposibilidad de saber qu´e era lo que estaba sucediendo, se contact´o con el autor de la librer´ıa para obtener ayuda. Muy amablemente, el autor constat´o que el error proven´ıa de un bug dentro de la misma librer´ıa. Luego de arreglarlo, y de realizar otras modificaciones para que los errores obtenidos no fueran tan cr´ıpticos, actualiz´o la versi´on disponible en la sitio web de Imebra.

Superado este inconveniente, y gracias a la excelente documentaci´on sobre la utilizaci´on de la librer´ıa, no hicieron falta subsecuentes comunicaciones con el autor para llevar a cabo

3.2 Programaci´on en Android 25

las operaciones requeridas por la aplicaci´on desarrollada.