07 - Diplomado en Desarrollo de Aplicaciones Móviles

Desarrollo de Aplicaciones Móviles | Unidad 7
DESARROLLO DE APLICACIONES MÓVILES
Unidad 7: Desarrollo de aplicaciones móviles: interfaces

Instituto Profesional IACCusuarios
| 2017 y almacenamiento
1
ÍNDICE
OBJETIVO ESPECÍFICO ......................................................................................................................... 3

INTRODUCCIÓN ................................................................................................................................... 4
1. UTILIZACIÓN DE ELEMENTOS DE COMPATIBILIDAD ................................................................... 5
1.1. FRAGMENTS ........................................................................................................................ 5
1.2. ACTIONBAR.......................................................................................................................... 8
1.3. NAVIGATIONDRAWER ....................................................................................................... 11
2. ALMACENAMIENTO................................................................................................................... 13
2.1. ALMACENAMIENTO DE DATOS EN ANDROID ................................................................... 13
2.2. ALMACENAMIENTO DE PREFERENCIAS DE USUARIO ....................................................... 14
2.3. ALMACENAMIENTO EN LA MEMORIA INTERNA Y EXTERNA ............................................ 16
REFERENCIAS ..................................................................................................................................... 25
Instituto Profesional IACC | 2017 2

OBJETIVO ESPECIFICO
 Construir una aplicación Android con elementos básicos.

INTRODUCCIÓN
Android, como sistema operativo, ha sido una interfaz de usuario flexible que se
diseñado para correr en distintos adapte a distintas configuraciones de
dispositivos, desde teléfonos a tabletas y pantallas. Lo anterior conlleva la
televisores. Como desarrollador, este rango incorporación de algunos elementos de
de dispositivos significa una audiencia compatibilidad. Dichos elementos, junto con
potencial gigante para una aplicación. Sin algunas nociones de lectura y escritura de
embargo, para que tu aplicación sea exitosa archivos, se revisarán durante esta semana.
en todos estos dispositivos, debe ser
tolerante a ciertas variaciones en las
características, y al mismo tiempo proveer de
Realmente no entiendo su estrategia. A lo mejor la entiende otro.
Steve Ballmer.

1. UTILIZACIÓN DE ELEMENTOS DE COMPATIBILIDAD

Para facilitar el esfuerzo de desarrollar aplicaciones compatibles con múltiples dispositivos,
Android provee una biblioteca dinámica en la cual el desarrollador puede indicar recursos
específicos asociados a una configuración de dispositivos en archivos estáticos (como por ejemplo
distintos layouts XML para distintos tamaños de pantalla). Luego, Android carga el recurso
necesario basado en la configuración del dispositivo específico. De esta manera, se pueden
publicar aplicaciones con un solo APK que contenga experiencias de usuario personalizadas en una
variedad de dispositivos.
Algunas de las variantes más importantes que se deben considerar al momento de desarrollar una
aplicación son: soporte para varios lenguajes, tamaños de pantalla y versiones distintas de la
plataforma Android (Developer.android.com, s. f.a). A continuación, se tratarán en profundidad
aquellos elementos de Android Studio que permiten adaptar una aplicación a distintas pantallas:
fragments, ActionBar y NavigationDrawer.
1.1. FRAGMENTS
Un fragment representa un comportamiento o una parte de la interfaz de usuario en una activity.
Se pueden combinar múltiples fragmentos en una sola actividad para crear una UI (interfaz de
usuario) multipanel y volver a usar un fragmento en múltiples actividades. Se puede pensar en un
fragmento como una sección modular de una actividad que tiene su ciclo de vida propio, recibe
sus propios eventos de entrada y que se puede agregar o quitar mientras la actividad se esté
ejecutando (algo así como una "subactividad" que se puede volver a usar en diferentes
actividades) (Developer.android.com, s. f.b).
Un fragmento siempre debe estar integrado a una actividad, donde el ciclo de vida del fragmento
se ve directamente afectado por el ciclo de vida de la actividad anfitriona. Por ejemplo, cuando la
actividad está pausada, también lo están todos sus fragmentos, y cuando la actividad se destruye,
lo mismo ocurre con todos los fragmentos. Sin embargo, mientras una actividad se está
ejecutando, se puede manipular cada fragmento de forma independiente; por ejemplo, para
agregarlos o quitarlos. Cuando se realiza una transacción de fragmentos como esta, también se
pueden agregar a una pila de actividades administrada por la actividad; cada entrada de la pila de
actividades en la actividad es un registro de la transacción de fragmentos realizada. La pila de
actividades le permitirá al usuario invertir una transacción de fragmentos (navegar hacia atrás) al
presionar el botón Atrás.

Al agregar un fragmento como parte del diseño de una actividad, este se ubica en el ViewGroup,
dentro de la jerarquía de vistas de la actividad y el fragmento define su propio diseño de vista. Se
puede insertar un fragmento en el diseño de una actividad declarando el fragmento en el archivo
de diseño de la actividad como elemento <fragment> o bien agregándolo a un ViewGroup
existente desde el código fuente de la aplicación. Sin embargo, no es necesario que un fragmento
forme parte del diseño de la actividad; también se puede usar un fragmento con su propia interfaz
de usuario.
Android introduce los fragmentos en Android 3.0 (nivel de API 11), principalmente para admitir
diseños de interfaz de usuario más dinámicos y flexibles en pantallas grandes, como las de las
tabletas. Como la pantalla de una tableta es mucho más grande que la de un teléfono, hay más
espacio para combinar e intercambiar componentes de la interfaz de usuario. Los fragmentos
admiten esos diseños sin la necesidad de que se administren cambios complejos en la jerarquía de
vistas. Al dividir el diseño de una actividad en fragmentos, se puede modificar el aspecto de la
actividad durante el tiempo de ejecución y conservar esos cambios en una pila de actividades
administrada por la actividad.
Las plataformas Android se identifican de tres formas alternativas:

versión, nivel de API y nombre comercial.
El nivel de API corresponde a números enteros, comenzando desde 1.

Para los nombres comerciales se han elegido postres en orden
alfabético: Cupcake (v1.5), Donut (v1.6), Éclair (v2.0), Froyo (v2.2),
Gingerbread (v2.3), etc.
Las dos primeras versiones, que hubieran correspondido a las letras A y

B, no recibieron nombre.
En el siguiente link se puede revisar el detalle de las funciones incluidas

en cada versión.
https://goo.gl/yosbcp
Por ejemplo, una aplicación de noticias puede usar un fragmento para mostrar una lista de
artículos a la izquierda y otro fragmento para mostrar un artículo a la derecha; ambos fragmentos
aparecen en una actividad, uno al lado del otro, y cada fragmento tiene su propio conjunto de

métodos callback del ciclo de vida y administran sus propios eventos de entrada del usuario.
Entonces, en lugar de usar una actividad para seleccionar un artículo y otra actividad para leer el
artículo, el usuario puede seleccionar un artículo y leerlo dentro de la misma actividad, tal y como
se ilustra en el diseño de tableta en la figura 1.
Cada fragmento se debe diseñar como un componente modular y reutilizable de la actividad.

Como cada fragmento define su propio diseño y su propio comportamiento con sus propios
callbacks del ciclo de vida, se puede incluir un fragmento en múltiples actividades; por lo tanto, se
debe diseñar para volver a utilizarlo y evitar la manipulación directa de un fragmento desde otro
fragmento. Esto es muy importante porque un fragmento modular permite cambiar las
combinaciones de fragmentos para diferentes tamaños de pantalla. Cuando se diseña una
aplicación para que admita tabletas y teléfonos, se pueden reutilizar los fragmentos en diferentes
configuraciones de diseño para optimizar la experiencia del usuario en función del espacio de
pantalla disponible. Por ejemplo, en un teléfono, podría ser necesario separar los fragmentos para
proporcionar una interfaz de usuario de panel único cuando no quepa más de uno en la misma
actividad.
Figura 1. Ejemplo de la manera en que dos módulos de la interfaz de usuario definidos por fragmentos se
pueden combinar en una actividad para un diseño de tablet y se presentan por separados para un diseño
de teléfono.
Fuente: https://developer.android.com/guide/components/fragments.html
Así por ejemplo, para continuar con el ejemplo de la aplicación de noticias, la aplicación puede
integrar dos fragmentos en la Actividad A cuando se ejecuta en un dispositivo del tamaño de una

tableta. Sin embargo, en una pantalla de teléfono, no hay suficiente espacio para ambos
fragmentos, por lo que la Actividad A incluye solo el fragmento para la lista de artículos, y cuando
el usuario selecciona un artículo, se inicia la Actividad B, que incluye el segundo fragmento para
poder leer el artículo. Por lo tanto, la aplicación admite tabletas y teléfonos al reutilizar
fragmentos en diferentes combinaciones, como se ilustraba en la figura 1.
 Para revisar conceptualmente por qué se usan fragments, se

recomienda visualizar el siguiente video.
https://www.youtube.com/watch?v=m3A_82efr70
Nota: dado que está en inglés, se deberán activar los subtítulos en

el apartado de configuración > subtítulos > español.
 Para revisar un ejemplo práctico de creación de fragments, se

recomienda la revisión de los siguientes videos en el orden en
que se presentan:
https://goo.gl/Xvl8NW
https://goo.gl/2KN3bZ
1.2. ACTIONBAR
El actionbar es un elemento que se encuentra en la parte superior de cada pantalla y que
generalmente es persistente a través de la aplicación, es decir, que persiste entre los cambios de
pantalla. En esta barra se ponen funciones importantes como buscar o nuevo, y al mismo tiempo
oculta otras menos importantes. Es uno de los elementos de diseño más importantes pues todas
las aplicaciones lo contienen. A continuación, se pueden ver ejemplos de ActionBars en las figuras
2 y 3.

Figura 2. Ejemplo ActionBar
Fuente: https://goo.gl/ZTPNx
Figura 3. Ejemplo de ActionBars
Fuente: https://goo.gl/E8abAL
El ActionBar está dividido en 4 áreas funcionales que aplican en la mayoría de las aplicaciones
(figura 4). Como son:
Figura 4. Áreas funcionales del ActionBar

1. Application icon: el ícono de la aplicación establece la identidad de la misma, y puede ser

reemplazada con un logo propio. Para ver cómo queda el ícono con y sin la posibilidad de
navegar hacia atrás, se puede ver la figura 5.
Figura 5. Ícono de aplicación con y sin la opción "up"
2. View control: si la aplicación va a desplegar información en varias vistas, esta partirá del
ActionBar, que permite cambiar entre vistas. Un ejemplo de control que cambia entre
vistas es el menú desplegable. Ahora bien, si la aplicación no soporta distintas vistas, este
espacio se puede usar para desplegar contenido no interactivo como el título de la
aplicación u otro asociado al marketing de la misma.
3. Action buttons: muestran las acciones más importantes de la aplicación. Para ordenarlas,
hay que pensar cuáles van a ser usadas más frecuentemente que otras. Algo importante a
tener en cuenta es que esta barra debe mostrar solo acciones que están disponibles para
el usuario; así, si una acción no se encuentra disponible en un contexto, es mejor
esconderla y no mostrarla como deshabilitada. Ejemplos de botones de acción que usa la
aplicación Gmail se muestran en la figura 6.
Figura 6. Botones de acción
4. Action overflow: muestra las acciones menos utilizadas de la aplicación.

 Para revisar un ejemplo de cómo añadir una ActionBar a una

activity, se recomienda el visionado del siguiente material
multimedia:
https://www.youtube.com/watch?v=vzMhVYVLW_Q
1.3. NAVIGATIONDRAWER
El panel lateral de navegación es un panel en el que se muestran las principales opciones de

navegación de la aplicación en el borde izquierdo de la pantalla. La mayor parte del tiempo está
oculto, pero aparece cuando el usuario desliza un dedo desde el borde izquierdo de la pantalla, o
mientras está en el nivel superior de la aplicación y el usuario toca el ícono de la aplicación en la
barra de acciones. En las figuras 7 y 8 se visualizan ejemplos de NavigationDrawers.
Figura 7. Ejemplo de NavigationDrawer
Fuente: http://nixmash.com/x/blog/2015/navdrawer0109c.png

Figura 8. Ejemplos de NavigationDrawer
Fuente: https://s3-us-west-1.amazonaws.com/vizteck.bucket/uploads/navigation-drawer1.jpg
Antes de decidir usar un panel lateral de navegación en una aplicación, se deben comprender los
casos de uso y los principios de diseño definidos en la guía de diseño de panel lateral de
navegación1.
 Para una explicación más gráfica de los NavigationDrawer

de Android Studio, se puede revisar el siguiente video:
https://www.youtube.com/watch?v=-s39b_Ki1C8
1
Acceso a la guía en: https://material.io/guidelines/patterns/navigation-drawer.html#

2. ALMACENAMIENTO
Android ofrece diferentes opciones para guardar datos
persistentes de la aplicación. La solución que se elija dependerá
de ciertas necesidades específicas, por ejemplo, de si los datos
deben ser privados para la aplicación o estar disponibles para
otras aplicaciones (y el usuario), y de la cantidad de espacio
que requieren estos datos.
Fuente: https://goo.gl/S3fTJ6
2.1. ALMACENAMIENTO DE DATOS EN ANDROID

Las opciones de almacenamiento de datos en Android son las siguientes (Dveloper.android.com, s.
f.c):
 Preferencias compartidas: almacenamiento de datos primitivos privados en pares clave-

valor.
 Almacenamiento interno: almacenamiento de datos privados en la memoria del

dispositivo.
 Almacenamiento externo: almacenamiento de datos públicos en el almacenamiento

externo compartido.
 Bases de datos SQLite: almacenamiento de datos estructurados en una base de datos

privada.
 Conexión de red: almacenamiento de datos en la web mediante un servidor de red

propio.
La elección del tipo de almacenamiento dependerá de las necesidades de la aplicación. Android

ofrece un método para exponer datos privados a otras aplicaciones mediante un proveedor de
contenido. Un proveedor de contenido es un componente opcional que expone el acceso de
lectura y escritura a los datos de una aplicación, sujetos a las restricciones que desees establecer.
Tanto el almacenamiento a través de la red como los proveedores de contenidos se revisarán en
detalle en la unidad 9 del curso.

2.2. ALMACENAMIENTO DE PREFERENCIAS DE USUARIO

Las preferencias no son más que datos que una aplicación debe guardar para personalizar la
experiencia del usuario, como por ejemplo información personal, opciones de presentación, etc.
Android proporciona un método diseñado específicamente para administrar este tipo de datos: las
preferencias compartidas o shared preferences. Cada preferencia se almacenará en forma de
clave-valor, es decir, cada una de ellas estará compuesta por un identificador único (p. ej., “email”)
y un valor asociado a dicho identificador (p. ej., “prueba@email.com”). Estos datos se guardarán
en archivos XML.
La API para el manejo de estas preferencias es muy sencilla. Toda la gestión se centraliza en la
clase SharedPrefences, que representará a una colección de preferencias. Una aplicación Android
puede gestionar varias colecciones de preferencias, que se diferenciarán mediante un
identificador único. Para obtener una referencia a una colección determinada se utiliza el método
getSharedPrefences() al que se le pasa el identificador de la colección y un modo de acceso. El
modo de acceso indicará qué aplicaciones tendrán acceso a la colección de preferencias y qué
operaciones tendrán permitido realizar sobre ellas. Así, existen tres posibilidades (Herrera, s. f.):
 MODE_PRIVATE. Solo la aplicación tiene acceso a estas preferencias.
 MODE_WORLD_READABLE. Todas las aplicaciones pueden leer estas preferencias, pero

sólo la aplicación en desarrollo puede modificarlas.
 MODE_WORLD_WRITABLE. Todas las aplicaciones pueden leer y modificar estas

preferencias.
Las dos últimas opciones son relativamente “peligrosas”, por lo que en condiciones normales no
deberían usarse. De hecho, se han declarado como obsoletas en la API 17 (Android 4.2). Teniendo
todo esto en cuenta, para obtener una referencia a una colección de preferencias llamada por
ejemplo “MisPreferencias” y como modo de acceso exclusivo para una aplicación, se haría lo
indicado en el código 1.
Código 1. Obtención de referencia a una colección de preferencias
Fuente: https://goo.gl/qgOlGL

Una vez obtenida la referencia a la colección de preferencias, ya se puede obtener, insertar o

modificar preferencias utilizando los métodos get o put (get para obtener, put para insertar)
correspondientes al tipo de dato de cada preferencia. No existe una lista de preferencias de
usuario, ya que cada programador define las preferencias que quiere almacenar dependiendo de
su aplicación. Los tipos de datos disponibles para almacenar preferencias son los mismos tipos de
datos del lenguaje de programación Java. Así, por ejemplo, para obtener el valor de una
preferencia llamada “email” de tipo String,se escribiría el código indicado en el código 2.
Código 2. Obtención del valor de la preferencia llamada email
Como se puede observar, al método getString() se le pasa el nombre de la preferencia que se

quiere recuperar y un segundo parámetro con un valor por defecto. Este valor por defecto será el
devuelto por el método getString() si la preferencia solicitada no existe en la colección. Además
del método getString(), existen por supuesto otros métodos análogos para el resto de tipos de
datos básicos, por ejemplo: getInt(), getLong(), getFloat(), getBoolean(), etc.
Para actualizar o insertar nuevas preferencias, el proceso será igual de sencillo, con la única
diferencia de que la actualización o inserción no se hará directamente sobre el objeto
SharedPreferences, sino sobre su objeto de edición SharedPreferences.Editor. A este último
objeto se accede mediante el método edit() de la clase SharedPreferences. Una vez obtenida la
referencia al editor, se utilizan los métodos put correspondientes al tipo de datos de cada
preferencia para actualizar/insertar su valor, por ejemplo putString(clave, valor), para actualizar
una preferencia de tipo String. De forma análoga a los métodos get vistos, se tendrán disponibles
métodos put para todos los tipos de datos básicos: putInt(), putFloat(), putBoolean(), etc.
Finalmente, una vez actualizados/insertados todos los datos necesarios, se debe llamar al método
commit() para confirmar los cambios. Un ejemplo sencillo se puede revisar en el código 3.

Código 3. Ejemplo de edición de preferencias
Pero, ¿dónde se almacenarán estas preferencias compartidas? Como se mencionó al comienzo del
punto 2.2, las preferencias no se almacenan en ficheros binarios como las bases de datos SQLite,
sino en ficheros XML. Estos ficheros XML se almacenan en una ruta que sigue el siguiente patrón:
/data/data/paquete.java/shared_prefs/nombre_coleccion.xml
 Explicación paso a paso de cómo configurar las preferencias

de usuario.
https://www.youtube.com/watch?v=Pay4nZu9Kuc
2.3. ALMACENAMIENTO EN LA MEMORIA INTERNA Y

EXTERNA
En Android, es posible manipular archivos tradicionales de una forma muy similar a como se
realiza en Java. Lo primero que hay que tener en cuenta es dónde se quieren almacenar los
archivos y el tipo de acceso que se quiere tener a ellos. Así, se pueden leer y escribir ficheros
localizados en:
1. La memoria interna del dispositivo.

2. La propia aplicación, en forma de recurso.
3. La tarjeta SD externa, si existe.

Se pueden guardar archivos directamente en el almacenamiento interno del dispositivo. De forma

predeterminada, los archivos que se guardan en el almacenamiento interno son privados para la
aplicación y otras aplicaciones no pueden tener acceso a ellos (tampoco el usuario). Cuando el
usuario desinstala la aplicación, estos archivos se eliminan. Hay que tener en cuenta las
limitaciones de espacio que tienen muchos dispositivos, por lo que no se debería abusar de este
espacio utilizando archivos de gran tamaño.
Para crear y escribir un archivo privado en el almacenamiento interno, se deben seguir los
siguientes pasos:
1. Llamar a openFileOutput() mediante el nombre del archivo y el modo de operación. Esto

muestra un FileOutputStream. Ver código 4.
2. Realizar operaciones de escritura en el archivo con write().
3. Cerrar el flujo con close().
Código 4. Ejemplo de escritura en archivo interno de Android
Fuente: https://goo.gl/xLOiUa
Para leer un archivo desde el almacenamiento interno, se deben seguir los siguientes pasos:
1. Llamar a openFileInput() y usar el nombre del archivo que se desea leer. Esto muestra un
FileInputStream.
2. Leer los bytes del archivo con read().
3. A continuación, cerrar el flujo con close().
Otros métodos útiles para la manipulación de archivos son:
 getFilesDir(): obtiene la ruta de acceso absoluta al directorio de sistema de archivos donde

se guardan los archivos internos.

 getDir(): crea un directorio (o abre uno existente) dentro del espacio de almacenamiento
interno.
 deleteFile(): quita un archivo guardado en el almacenamiento interno.
 fileList(): muestra un conjunto de archivos que la aplicación guarda actualmente.
La segunda forma de almacenar archivos en la memoria interna del dispositivo es incluirlos como
recurso en la propia aplicación. Aunque este método es útil en muchos casos, solo se debe utilizar
cuando no se necesiten realizar modificaciones sobre los archivos, ya que solo se pueden leer
estos archivos pero no escribir. Para incluir un fichero como recurso de la aplicación se debe
colocar en la carpeta “/resources/raw” del proyecto de Android Studio. Esta carpeta no suele estar
creada por defecto, por lo que se debe crear manualmente en Android Studio.
Una vez creada la carpeta /raw, se pueden colocar en ella cualquier archivo que se quiera incluir
con la aplicación en tiempo de compilación en forma de recurso. Para efectos del ejemplo que se
viene analizando, se incluirá un archivo llamado “prueba_raw.txt“. Ya en tiempo de ejecución se
puede acceder a este archivo, solo en modo de lectura, de una forma similar a la que ya se ha visto
para el resto de archivos en memoria interna. Para acceder al archivo, primero se debe acceder a
los recursos de la aplicación con el método getResources() y sobre estos se utiliza el método
openRawResource(id_del_recurso) para abrir el archivo en modo lectura. Este método devuelve
un objeto InputStream que se puede manipular con los métodos de la API java.io. Como ejemplo,
se convertirá el stream en un objeto BufferedReader para leer el texto contenido en el archivo de
ejemplo (por supuesto, los archivos de recurso también pueden ser binarios, como por ejemplo
archivos de imagen, video, etc.). El código quedaría como el que se muestra en el código 5.
Código 5. Lectura de archivo como recurso de la aplicación
Fuente: https://goo.gl/R0qimN

Como puede verse en el código 5, al método openRawResource() se le pasa como parámetro el ID

del archivo incluido como recurso, que seguirá el patrón “R.raw.nombre_del_fichero”.
Las dos alternativas anteriores suponen un uso precavido

del tamaño de los archivos. La alternativa que permite
almacenar archivos grandes es la memoria externa del
dispositivo, constituida normalmente por una tarjeta de
memoria SD, aunque en dispositivos recientes también
está presente en forma de almacenamiento no extraíble
del dispositivo, aunque no por ello debe confundirse con
la memoria interna. A diferencia de la memoria interna,
el almacenamiento externo es público, es decir, todo lo
que se escriba en él podrá ser leído por otras
aplicaciones y por el usuario, por tanto hay que tener
cierto cuidado a la hora de decidir lo que se escribe en la
memoria interna y externa.
Fuente: https://goo.gl/VT7UEZ
Es posible que el almacenamiento externo deje de estar disponible si el usuario conecta el

almacenamiento externo a una computadora o quita el medio, y no se implementan medidas de
seguridad en los archivos que se guardan en el almacenamiento externo. Todas las aplicaciones
pueden realizar operaciones de lectura y escritura en los archivos guardados en el
almacenamiento externo y el usuario puede quitarlos.
Android proporciona (como método estático de la clase Environment) el método

getExternalStorageStatus(), que indica si la memoria externa está disponible y si se puede leer y
escribir en ella. Este método devuelve una serie de valores que indican el estado de la memoria
externa, siendo los más importantes los siguientes:
 MEDIA_MOUNTED, que indica que la memoria externa está disponible y se puede tanto
leer como escribir en ella.
 MEDIA_MOUNTED_READ_ONLY, que indica que la memoria externa está disponible

pero solo se puede leer de ella.
 Otra serie de valores que indicarán que existe algún problema y que por tanto no se puede
ni leer ni escribir en la memoria externa (MEDIA_UNMOUNTED, MEDIA_REMOVED, …). Se

pueden consultar todos estos estados en la documentación oficial de la clase

Environment2.
Teniendo todo esto en cuenta, se podría realizar un chequeo previo del estado de la memoria
externa del dispositivo tal y como se muestra en el código 6.
Código 6. Chequeo previo del estado de la memoria externa
Fuente: https://goo.gl/eUPuwc
Una vez chequeado el estado de la memoria externa, y dependiendo del resultado obtenido, ya se
puede leer o escribir en ella cualquier tipo de archivo. Así, el estado que permite leer y escribir es
MEDIA_MOUNTED; mientras que el estado que permite solo leer desde el dispositivo es
MEDIA_MOUNTED_READ_ONLY. Todos los otros estados no permitirán acceso al dispositivo.
Para escribir un fichero a la memoria externa se debe obtener en primer lugar la ruta al directorio
raíz de esta memoria. Para ello, se puede utilizar el método getExternalStorageDirectory() de la
clase Environment, el cual devuelve un objeto File con la ruta de dicho directorio. A partir de este
objeto, se construye otro con el nombre elegido para el archivo (como por ejemplo
“prueba_sd.txt“), creando un nuevo objeto File que combine ambos elementos. Tras esto, ya solo
queda encapsular en algún objeto de escritura de archivos de la API de Java y escribir algún dato
de prueba. En el caso de ejemplo, se convertirá una vez más a un objeto OutputStreamWriter para
escribir al archivo un mensaje de texto. El código quedaría como el que se muestra en el código 7.
2
Disponible en: https://developer.android.com/reference/android/os/Environment.html

Código 7. Ejemplo de escritura a tarjeta SD
El código 7 anterior funciona sin problemas, pero escribirá el fichero directamente en la carpeta
raíz de la memoria externa. Esto, aunque en ocasiones puede resultar necesario, no es una buena
práctica. Lo correcto sería disponer de una carpeta propia para la aplicación, lo que además tendrá
la ventaja de que al desinstalar la aplicación también se liberará este espacio. Esto se consigue
utilizando el método getExternalFilesDir(null), en vez de getExternalStorageDirectory(). El método
getExternalFilesDir() devuelve directamente la ruta de una carpeta específica para la aplicación
dentro de la memoria externa siguiendo el siguiente patrón:
<raíz_mem_ext>/Android/data/nuestro.paquete.java/files
Si en vez de null se le indica como parámetro un tipo de datos determinado (DIRECTORY_MUSIC,

DIRECTORY_PICTURES, DIRECTORY_MOVIES, DIRECTORY_RINGTONES, DIRECTORY_ALARMS,
DIRECTORY_NOTIFICATIONS, DIRECTORY_PODCASTS), devolverá una subcarpeta dentro de la
anterior con su nombre correspondiente. Así, por ejemplo, una llamada al método
getExternalFilesDir(Environment.DIRECTORY_MUSIC) devolvería la siguiente carpeta:
<raíz_mem_ext>/Android/data/nuestro.paquete.java/files/Music
Esto último, además, ayuda a Android a saber qué tipo de contenidos hay en cada carpeta, de
forma que puedan clasificarse correctamente, por ejemplo, en la galería multimedia.
Sea como sea, para tener acceso a la memoria externa se tendrá que especificar en el archivo
AndroidManifest.xml que la aplicación necesita permiso de escritura en dicha memoria. Para
añadir un nuevo permiso se usa la cláusula <uses-permission> utilizando el valor concreto

“android.permission.WRITE_EXTERNAL_STORAGE“. Con esto, el archivo

AndroidManifest.xml quedaría de forma similar al del código 8.
Código 8. Ejemplo de AndroidManifest.xml con permiso para escribir en memoria externa
Si se exploran los archivos, se puede comprobar cómo se ha creado correctamente el fichero en el

directorio raíz de la tarjeta SD. Esta ruta puede variar entre dispositivos, pero para Android 2.x
suele localizarse en la carpeta /sd-card/, mientras que para Android 4 suele estar en
/mnt/sdcard/.

Figura 9. Evidencia de creación de archivo prueba_sd.txt en tarjeta externa
Por su parte, leer un fichero desde la memoria externa es igual de sencillo. Se obtiene el directorio
raíz de la memoria externa con getExternalStorageDirectory(), o la carpeta específica
de la aplicación con getExternalFilesDir(), se crea un objeto File que combine esa ruta
con el nombre del archivo a leer y se encapsula dentro de algún objeto que facilite la lectura,
donde para leer texto se puede utilizar un BufferedReader. Un ejemplo de código se puede
revisar a continuación.

Código 9. Ejemplo de lectura desde tarjeta SD
 Revise el siguiente video para ver un ejemplo completo de

lectura y escritura en memoria interna, externa y como
recurso.
https://www.youtube.com/watch?v=lbBosCrFE7Y
COMENTARIO FINAL
Esta semana ha sido intensa en el abordaje de nuevos conceptos, considerando además que
Android Studio como herramienta de desarrollo también es una novedad, por lo que la curva de
aprendizaje puede que no sea tan rápida como se quisiera. Sin embargo, este proceso es
incremental y al mismo tiempo requiere de tiempo de maduración de los conceptos, por lo que
hay que tomárselo con calma.
En la próxima unidad de estudio, se seguirán viendo conceptos técnicos en la programación

Android, focalizándose el estudio en el almacenamiento de datos interno y externo al dispositivo.

REFERENCIAS
Developer.android.com (s. f.a). Supporting Different Devices. Recuperado de:
https://developer.android.com/training/basics/supporting-devices/index.html
Developer.android.com (s. f.b). Fragments. Recuperado de:
https://developer.android.com/guide/components/fragments.html
Developer.android.com (s. f.c). Opciones de almacenamiento. Recuperado de:
https://developer.android.com/guide/topics/data/data-storage.html?hl=es
Herrera, D. (s. f.). Desarrollo avanzado web. Recuperado de:
http://todosobreprogramacion.blogspot.cl/
PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:
IACC (2017). Desarrollo de aplicaciones móviles: interfaces usuarios y almacenamiento.

Desarrollo de Aplicaciones Móviles. Unidad 7.


07 - Diplomado en Desarrollo de Aplicaciones Móviles

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

07 - Diplomado en Desarrollo de Aplicaciones Móviles

Cargado por

Copyright:

Formatos disponibles

Desarrollo de Aplicaciones Móviles | Unidad 7

DESARROLLO DE APLICACIONES MÓVILES

Unidad 7: Desarrollo de aplicaciones móviles: interfaces

OBJETIVO ESPECÍFICO ......................................................................................................................... 3

Instituto Profesional IACC | 2017 2

 Construir una aplicación Android con elementos básicos.

Instituto Profesional IACC | 2017 3

Realmente no entiendo su estrategia. A lo mejor la entiende otro.

Instituto Profesional IACC | 2017 4

1. UTILIZACIÓN DE ELEMENTOS DE COMPATIBILIDAD

Instituto Profesional IACC | 2017 5

Las plataformas Android se identifican de tres formas alternativas:

El nivel de API corresponde a números enteros, comenzando desde 1.

Las dos primeras versiones, que hubieran correspondido a las letras A y

En el siguiente link se puede revisar el detalle de las funciones incluidas

Instituto Profesional IACC | 2017 6

Cada fragmento se debe diseñar como un componente modular y reutilizable de la actividad.

Instituto Profesional IACC | 2017 7

 Para revisar conceptualmente por qué se usan fragments, se

Nota: dado que está en inglés, se deberán activar los subtítulos en

 Para revisar un ejemplo práctico de creación de fragments, se

Instituto Profesional IACC | 2017 8

Figura 2. Ejemplo ActionBar

Figura 3. Ejemplo de ActionBars

Figura 4. Áreas funcionales del ActionBar

Instituto Profesional IACC | 2017 9

1. Application icon: el ícono de la aplicación establece la identidad de la misma, y puede ser

Figura 5. Ícono de aplicación con y sin la opción "up"

Figura 6. Botones de acción

4. Action overflow: muestra las acciones menos utilizadas de la aplicación.

Instituto Profesional IACC | 2017 10

 Para revisar un ejemplo de cómo añadir una ActionBar a una

El panel lateral de navegación es un panel en el que se muestran las principales opciones de

Figura 7. Ejemplo de NavigationDrawer

Instituto Profesional IACC | 2017 11

Figura 8. Ejemplos de NavigationDrawer

 Para una explicación más gráfica de los NavigationDrawer

Instituto Profesional IACC | 2017 12

2.1. ALMACENAMIENTO DE DATOS EN ANDROID

 Preferencias compartidas: almacenamiento de datos primitivos privados en pares clave-

 Almacenamiento interno: almacenamiento de datos privados en la memoria del

 Almacenamiento externo: almacenamiento de datos públicos en el almacenamiento

 Bases de datos SQLite: almacenamiento de datos estructurados en una base de datos

 Conexión de red: almacenamiento de datos en la web mediante un servidor de red

La elección del tipo de almacenamiento dependerá de las necesidades de la aplicación. Android

Instituto Profesional IACC | 2017 13

2.2. ALMACENAMIENTO DE PREFERENCIAS DE USUARIO

 MODE_PRIVATE. Solo la aplicación tiene acceso a estas preferencias.

 MODE_WORLD_READABLE. Todas las aplicaciones pueden leer estas preferencias, pero

 MODE_WORLD_WRITABLE. Todas las aplicaciones pueden leer y modificar estas

Código 1. Obtención de referencia a una colección de preferencias

Instituto Profesional IACC | 2017 14

Una vez obtenida la referencia a la colección de preferencias, ya se puede obtener, insertar o

Código 2. Obtención del valor de la preferencia llamada email

Como se puede observar, al método getString() se le pasa el nombre de la preferencia que se

Instituto Profesional IACC | 2017 15

Código 3. Ejemplo de edición de preferencias

 Explicación paso a paso de cómo configurar las preferencias

2.3. ALMACENAMIENTO EN LA MEMORIA INTERNA Y

1. La memoria interna del dispositivo.

Instituto Profesional IACC | 2017 16

Se pueden guardar archivos directamente en el almacenamiento interno del dispositivo. De forma

1. Llamar a openFileOutput() mediante el nombre del archivo y el modo de operación. Esto