CURSSO DE DESAR

RROLLO DE A
APLICACIONEES ANDROID  
 
 

TTema 2
2 

Esttructura de u
un Pro
oyecto Andro
oid 
 
TEMA
A 2. ESTRUCTTURA DE UN PROYECTO A
ANDROID 
 

Estrructura d
de un pro
oyecto An
ndroid
 

Cuando  inicialmeente  se  crea a  un  proyeccto  Android  en  Eclipse,,  este  entorrno  de  desa
arrollo 
consttruye  una  esstructura  de
e  directorios  básica,  un  esqueleto,  que 
q será  com mún  en  todos  los 
proyeectos de estee tipo y que facilitará la oorganizaciónn de los distin
ntos archivoss que formarrán  la 
aplicaación.  

La  esstructura  creeada,  tal  y  como 

c se  muuestra  en  laa  siguiente  figura, 
f contieene  una  serrie  de 
carpeetas  que  alb
bergarán  los  distintos  tippos  de  archivos  de  la  ap rganizados  de  una 
plicación,  org
formaa lógica que facilitará el mantenimie nto y ampliaación de la m misma. 

 
ntinuación, se detalla el ccontenido dee las carpetas más imporrtantes. 
A con

 
CURSSO DE DESAR
RROLLO DE A
APLICACIONEES ANDROID 2 
 
 
TEMA
A 2. ESTRUCTTURA DE UN PROYECTO A
ANDROID 
 

Carpeeta libs 

Contiiene libreríass externas a la API de An droid y que son utilizada
as por la apliccación. 

Carpeeta src 

Es unna de las carp petas princip pales del prooyecto, por n no decir la más importantte. En ella re esiden 

todoss los archivo os de código  fuente Java  que forman n la aplicacióón, entre elloos, las activiidades 
(clasees  que  extienden  de  Act tivity).  Un na  buena  prááctica  es  que,  dentro  dee  esta  carpe
eta,  se 
organ nicen los disttintos archivvos en difereentes paquettes, dependie endo de su ffuncionalidad d. Así, 
se deeberían crearr paquetes d distintos paraa las actividaades (paquette generalmeente llamado o “ui”, 
ya  qu
ue  hace  refeerencia  a  la  interfaz  de  usuario  –  User  Interface e‐.  Las  activiidades  generan  la 
interffaz  de  usuarrio),  para  lass  clases  que  manejen  arrchivos  (“io”,,  Input‐Outpput),  para  aquellas 
otrass clases que ssean servicio os (“service”)), etc.  

Carpeeta gen 

Esta  carpeta  con ntiene  las  clases  Java  qque  crea  auutomáticame ente  el  pluggin  ADT,  R.jjava  y 
BuilddVConfig.java a.  La  clase  más 
m importaante,  que  será  actualiza ada  automááticamente  por  p el 
plugin ADT cada vvez que sea necesario, ees R.java. Diccha clase, que no ha de sser nunca ed ditada, 
manttiene un índiice de recursos que son  accesibles d desde la parrte de códigoo Java (clase es que 
resideen en la cap peta res), asignándoles iddentificadores numérico os (por ejem plo, a caden nas de 
textoo, cuyo valor podrá depender del idiooma mostrad do, o a comp ponentes grááficos, proveyyendo 
la  dirrección  para  acceder  a  un  archivo  dde  imagen,  a 
a través  de  su  identificaador,  invocando  a 
“R.drrawable.nom mbreArchivoIm magen”). 

Android x.y 

Esta ccarpeta conttiene la referencia a la vversión de la SDK de And
droid con la ccual se compila la 
aplicaación. 

Carpeeta assets 

En  essta  carpeta  residirán  tod dos  aquelloss  otros  recursos  de  la  aplicación 
a a  los  cuales  no 
n sea 
necessario  accedeer  a  ellos  a  través 
t de  suu  id  ya  que  no 
n se  querrá
án  modificarr  en  la  aplicación, 
tales como imágeenes, vídeos, audio, archiivos de fuentes de texto…  

 
CURSSO DE DESAR
RROLLO DE A
APLICACIONEES ANDROID 3 
 
 
TEMA
A 2. ESTRUCTTURA DE UN PROYECTO A
ANDROID 
 

Carpeeta bin 

Contiiene los arch
hivos de la ap
plicación com
mpilados. 

Carpeeta res 

Carpeeta  que  juegga  un  importante  papel  en  la  estrucctura  de  las  aplicacioness  Android.  En 
E ella 
resideen todos loss recursos acccesibles dessde la clase R R, organizados en difereentes subcarpetas. 
Práctticamente  cualquier 
c applicación  deebe  provee er  recursos  alternativoos  para  sop portar 
dispoositivos  con  diferentes  configuracio
c nes.  Se  pueede  proporciionar  por  ejjemplo  diferrentes 
recurrsos  de  tipo  drawable  (imágenes) 
( ppara  diferenntes  densida ades  de  panntalla  y  diferrentes 
conjuuntos de strinngs para los distintos idiiomas. Cuando la aplicacción se ejecuuta, Android carga 
los reecursos más adecuados d disponibles een función de e la configuración del disspositivo.  

Para  organizar  lo
os  recursos  de  las  difereentes  configguraciones,  de 
d forma  quue  Android  pueda 
p
encon ntrarlos auto omáticamente, se debe  respetar la  siguiente sin ntaxis para laas supcarpettas de 
la carrpeta “res”: 

<nombre_de
< l_recurso><clasificador
< r> 

 <nombre__del_recurso o>: nombre dde la carpetaa del corresp pondiente reecurso por de efecto 

(animator, anim, colo or, drawable,, layout, men nu, raw, valu
ues o xml). 
 <clasifica
ador>:  nomb onfiguración  concreta  deel  dispositivo
bre  que  espeecifica  la  co o  que 
hace  quee  estos  recu
ursos  sean  uutilizados.  See  pueden  añ
ñadir  múltipples  clasifica
adores 
separado os por guionees medios.  

Los recursos recu ursos alterna
ativos deberrán estar en  las correspo ondientes caarpetas y  deberán 
tenerr todos exacttamente el m mismo nombbre que el re ecurso por de
efecto. Por eejemplo, si d dentro 
de  laa  carpeta  “values”  está  el  recurso  sstrings.xml  que 
q contiene e  las  cadenaas  de  texto  en  el 
ma  por  defecto  de  la  aplicación,  laa  carpeta  “vvalues‐es”  ta
idiom ambién  conttendrá  el  re ecurso 
stringgs.xml, pero  con las cadenas de textto en castellano. Del missmo modo, een el caso d de una 
imageen,  se  podrrán  crear  archivos  de  laa  misma  imagen  en  differentes  res oluciones.  Dichos 
D
archivvos tendrán el mismo no ombre y se uubicarán en laas diferentess carpetas drrawable‐*. 

Subcarpe etas  drawab ble  y  drawaable‐*:  contienen  todoss  los  recursoos  gráficos  de  la 
aplicaciónn,  pudiendo o  organizarsee  en  funció ón  de  la  ressolución  y  oorientación  de  la 
pantalla  sobre  la  que  se  ejecutaa  la  aplicación.  De  este e  modo,  si  eel  dispositivo
o  que 
ejecuta  laa  aplicación  es  tipo  HD PI,  se  utilizaarán  automááticamente  l os  recursos  de  la 
carpeta  drawable‐hd
d dpi¸  en  caso  de  dispositivos  LDPI,  se e  utilizarán  llos  recursos  de  la 
carpeta  drawable‐ldp
d pi,  etc.  Porr  otro  lado,,  la  Android d  utilizará  aaquellos  reccursos 

CURSSO DE DESAR
RROLLO DE A
APLICACIONEES ANDROID 4 
 
 
TEMA
A 2. ESTRUCTTURA DE UN PROYECTO A
ANDROID 
 

necesario os,  pese  a  no  residir  een  la  carpe

eta  correspo
ondiente  a  la  resolució
ón  del 
dispositivvo. 

Subcarpe
etas  anim    y 
y anim‐*:  coontendrá  arcchivos  xml  de 
d que  definnen  secuenciias  de 
animaciones. 

Subcarpe etas  layout  y 

y layout‐*:  ccarpetas  con ml  que  definirán  la 
ntendrá  los  archivos  xm
estructurra  de  las  diferentes  paantallas  de  la  aplicació
ón.  Se  podrrán  crear  la
ayouts 
específicoos  para  pantallas  en  modo  landsscape  o  po ortrait  o  paara  pantallass  con 
diferentees dimensiones. 

Subcarpe
etas  menu  y y menu‐*:  coontendrá  loss  archivos  xm
ml  que  definnen  los  diferrentes 
menús dee la aplicació
ón. 

Subcarpe etas values yy  values‐*: ccontiene, ese encialmente,, ficheros xmml con pares clave‐

valor.  Por  ejemplo,  contendrá 
c onde  se  agluutinarán  todas  las 
e l  fichero  strrings.xml,  do
cadenas  de 
d texto  mo ostradas  en  lla  aplicaciónn.  También  podrá 
p contenner  otros  ficcheros 
para  defiinir  tamañoss  (dimens.xmml),  colores (colors.xml),,  arrays  de  ttipos  de  reccursos 
(arrays.xmml) o estilos (styles.xml).   

Ficheero AndroidM
Manifiest.xm
ml 

El  maanifiesto  de  la  aplicaciónn  es  un  impportante  e  im

mprescindible  fichero  quue  toda  apliccación 
Andro oid  debe  tener  y  describe  qué  com mponentes  tiene 
t la  apliccación  (activvidades,  servvicios, 
recep ptores  de  brroadcasts,  proveedores 
p de  contenido…),  y  en  qué  condiciiones  puede en  ser 
ejecuutados,  así  como 
c los  permisos  quee  necesitaráá  para  funciionar  correcctamente  y  otros 
much hos  parámettros  que  pe ermiten,  ent re  otras  cossa,  que  la  aplicación 
a seea  correctam
mente 
filtrad
da en Googlee Play para q que no sea m mostrada en d dispositivos que no pueddan instalarla a. 

   

CURSSO DE DESAR
RROLLO DE A
APLICACIONEES ANDROID 5 
 
 
TEMA ANDROID 
A 2. ESTRUCTTURA DE UN PROYECTO A
 

Com
mponente
es de una
a aplicaciión Andrroid
 

Los componentess son las piezzas básicas ccon las que sse construye una aplicaciión Android.. Cada 
compponente reprresenta una  puerta diferrente a travé és de la cual el sistema ppuede intera
actuar 
con laa aplicación y tiene un tipo de compoortamiento cconcreto. 

Existeen  cuatro  tipos  fundamentales  de  ccomponente es  en  las  aplicaciones.  CCada  componente 
tiene  una  funció ón  distinta  así 
a como  unn  ciclo  de  viida  distinto (que  definee  cómo  se  crea 
c y 
destrruye dicho co omponente). 

Activvidades 

Cada  actividad  (cclases  Java  que 

q extiendeen  a  Activi ity)  represe enta  una  ún ica  pantalla  de  la 
aplicaación  y  provvee  una  inte
erfaz  de  usuuario,  es  deccir,  una  pantalla  sobre  la  que  el  ussuario 
puede  interactuaar.  Por  lo  tanto, 
t una  aplicación  con 
c tres  pantallas  disti ntas,  tendráá  tres 
activiidades  distin
ntas  e  indep
pendientes  ( existe  también  la  posibilidad  de  uttilizar  fragmeentos, 
clases que extienden a  Fragm ment  y que reepresentan partes de un na pantalla, ttal y como se e verá 
en  un  prósimo  tema). 
t De  este 
e modo,  se  puede  permitir 
p a  otras  aplicaciiones  que  inicien 
cualqquiera de lass actividades de nuestra  aplicación (siempre y cu uando se dé é acceso exte erno a 
las  m
mismas  desd de  nuestra  aplicación a  través  de e  la  declara ación  de  inntent‐filters  en  el 
manifiesto). 

Servicios 

Un seervicio (clasee java que exxtiende a Serrvice) es un componentte que permiite ejecutar ttareas 
en seegundo plano o de forma q que no se blloquee la intteracción del usuario co n la actividad que 
esté eejecutándose en ese momento y perrmitiendo qu ue dichas tareas sigan ejeecutándose p pese a 
que  lla  actividad  haya  finalizado.  A  diferrencia  de  las  actividades,  un  serviciio  no  provee  una 
interffaz gráfica de usuario. Lo os servicios ppueden ser iiniciados porr otros compponentes quienes, 
ademmás, podrán iinteractuar ccon los mism mos de diverssas formas. 

Proveeedores de C
Contenido 

Los pproveedores  de contenid do (subclasess de  Content tProvider) gestionan co onjuntos de  datos 

que la aplicación comparte co on otras apli caciones. Lo
os datos compartidos pueeden almace enarse 
en  diistintos  lugares  como,  por  ejemplo,  en  una  base  de  datos  SQLite, 
S o  enn  un  archivo en  el 
ma. Estos daatos compartidos por el  proveedor d
sistem de contenido o podrán seer consultado os por 

CURSSO DE DESAR
RROLLO DE A
APLICACIONEES ANDROID 6 
 
 
 A 2. ESTRUCTTURA DE UN PROYECTO A
TEMA ANDROID 
 

otrass aplicaciones e, incluso,  ser modificaados, siemprre y cuando el proveedoor de contennido lo 
permmita (puede q que no se pe
ermita siquieera el acceso
o a dicha infformación y  que simplem
mente 
se utiilice el proveeedor como una interfaz  para un alm
macén privado o de datos). 

Receptores Broad
dcast 

Los  rreceptores  de 

d broadcasst,  o  event os  (subclasees  de  BroadcastReceiiver)  escuch han  y 
respoonden  ante  un  amplio  rango  de  aanuncios  que e  ocurren  en 
e el  sistem
ma  continuam mente 
(“battería baja”, ““GPS encendiido”…). Estass clases no tienen asociada una interrfaz gráfica p
pero sí 
que ppueden geneerar notificacciones en la  barra de esttado para avisar al usuarrio. En generral, los 
recepptores  de  brroadcast  son  desencadeenantes  de  otros  comp ponentes,  coomo  por  eje
emplo 
serviccios. Los eveentos son en
nviados comoo objetos  In ntent  (tal y como se veerá en un pró óximo 
tema). 

Por  úúltimo,  se  ha  de  resaltaar  una  diferrencia  en  el  diseño  del  sistema  An droid  respecto  al 
comp portamiento  normal de a aplicaciones  Java. Una ap plicación pue ede iniciar u n componen nte de 
cualqquier  otra  ap plicación.  De
e  esta  formaa,  la  aplicación  que  se  desarrolle  ppuede  amplia ar  sus 
funcionalidades  sin  s tener  qu ue  implemenntar  el  códiggo  que  las  realiza. 
r Basttará  con  inicciar  el 
comp ponente adecuado de otra aplicaciónn. Una vez haaya realizado o la tarea sollicitada, devo olverá 
la  infformación  a  a la  aplicación  que  lo  ha  invocad do.  Para  inicciar  el  com
mponente  de e  otra 
aplicaación,  el  sisstema  lanzarrá  el  processo  de  dichaa  aplicación, instancianddo  las  clases  que 
necessite  el  comp ponente  invocado.  Debiido  a  las  restricciones  de  d permisoss  existentes  en  el 
sistemma  Android,  y  al  ser  dos  procesos  sseparados,  realmente 
r la  aplicación  no  puede  innvocar 
directtamente al ccomponente de la otra a plicación, sin no que ha de e enviar un m mensaje al sisstema 
que  eespecifique  su  intención n  (Intent)  dde  iniciar  aqquel  particular  componeente  y  el  sisstema 
activaará dicho componente. 

Esta ppeculiaridad (el poder in niciar compoonentes de otras aplicacio ones), provooca además q que, a 

difereencia  de  las  aplicaciones  Java  norm
males,  las  aplicaciones  Android  no  teengan  un  método 
principal  de  entrrada  “main())”  ya  que  ell  sistema  lass  inicia  también  a  travéés  de  el  envvío  de 
Intents específicos. 

CURSSO DE DESAR
RROLLO DE A
APLICACIONEES ANDROID 7