Está en la página 1de 6

Normas de desarrollo

Android es una plataforma basada en el kernel de linux, una aplicacin android esta compuesta por
activities que es algo que el usuario puede hacer,intents que bsicamente nos permiten llamar a
aplicaciones externas a la nuestra, lanzar eventos a los que otras aplicaciones puedan responder y
servicios son funciones que se ejecutan sin que el usuario interactue directamente con l.Android
proporciona libreras que otor!an la funcionalidad de java,posee su propia maquina virtual denominada
dalvik que se usa cuando se dispone de pocos recursos tanto de memoria y procesador,tambine permite
ejecucin de varias instancias a la vez.
"a codificacin se realizo en java y xml por ende se aprovec#aron al mximo las caractersticas de la
pro!ramacin orientada a objetos y enfocada a los eventos, el ciclo de vida de los objetos cobra vital
importancia en la codificacin expuesta, desde su declaracin, instanciacin, uso y desaparicin esta
controlada por java,dentro de la creacin de clases se declaran de manera privada sus atributos y se usa
la sobrecar!a de mtodos para tener distintos tipo de acceso a ellos, la inicializacin de sus atributos
involucra a la sentencia $t#is% para diferenciar al atributo del parmetro de lle!ada. &ambien se ocupa
la composicin de clases refirindose a la creacin de esta conteniendo instancias a otras clases, se
procura realizar clases con poco acoplamiento para no caer en la posterior modificacin en cascada de
cdi!o.
'n cuanto a la pro!ramacin enfocada a eventos destacamos el ciclo de vida de las actividades
(oncreate,onresume,onpause,ondestroy) las cuales manejan y controlan los eventos, el enfoque creado
por el equipo de pro!ramadores fue el de crear una actividad principal la cual nos muestra * cate!oras
de funcionalidades las cuales estn accesibles para el usuario mediante el click el cual es manejado por
una actividad para iniciar su ciclo de vida,cabe mencionar que todas las actividades estan declaradas en
el manifiesto de la aplicacin para que puedan interactuar con el usuario.
+e consideraron las si!uientes normas bsicas de codificacin al momento de pro!ramar,
'l nombre de las clase sera en min-scula y si es mas de una palabra identificadora sera separada por el
carcter $.%
/dentificadores , &odo identificador debe comenzar con una letra que puede estar se!uida de ms letras
o d!itos. 0na letra es cualquier smbolo del alfabeto y el carcter 1.2. 0n d!ito es cualquier carcter
entre 132 y 142.
"os nombres de variables y mtodos empiezan con min-sculas. +i se trata de un nombre compuesto
cada palabra se debe utilizar el !uin bajo para separar las palabras.
"os nombres de constantes se escriben en may-sculas. 5ara nombres compuestos se utiliza el !uin
bajo para separar las palabras.
6ariables (nombre,tipo,ran!o), 'l nombre de una variable permite #acer referencia a ella. 'ste nombre
debe cumplir las re!las aplicables a los identificadores. 'l tipo indica el formato de los valores que
puede almacenar la variable, cadenas de caracteres, valores l!icos, n-meros enteros, n-meros reales o
tipos de datos complejos. 'l ran!o indica los valores que puede tomar la variable.
+e realizan varias conversiones de tipo(cast) para ase!urarnos que los objetos devueltos por ciertos
metodos sean compatibles con el requerido
"os atributos de las clases sern declarados de forma privada y solo se podra acceder a ellos mediante
los metodos !etters y setters.
Android divide todas sus aplicaciones en componentes o bloques bsicos que, combinados, constituyen
el pro!rama final. As, tenemos bloques visibles para el usuario mediante interfaces (Activity), bloques
que se ejecutan en back!round fuera de su conocimiento (Service), bloques a la escuc#a de
determinados eventos (Broadcast Receiver) y bloques que ofrecen contenidos a otras aplicaciones
(Content Providers). 'sta filosofa es ori!inal y ayuda a modularizar funcionalmente las aplicaciones.
7asicamente se definen $6ie8s% a las que se le asocian $listeners% para capturar el evento esperado en
este caso dra! a drop
6ocabulario basico
6ie8s,'s una estructura de datos cuyas propiedades contienen los datos de la capa, la informacin
especfica del rea rectan!ular de la pantalla.
"isteners,+irven para definir el cdi!o que se ejecutar en un determinado evento(clic, clic lar!o,
pulsacin,...).
9aquina virtual es un pro!rama dentro de un sistema operativo que simula ser su propio sistema
operativo.
:ava,es un len!uaje de pro!ramacin y una plataforma informtica
;ml,es un sistema estndar de codificacin de informacin. "os pro!ramas que utilizan el formato
;9" pueden intercambiar fcilmente sus datos, ya que responden a una misma l!ica interna.
<lases,es una construccin que se utiliza como un modelo para crear objetos de ese tipo
=bjetos,es una unidad dentro de un pro!rama que consta de un estado y de un comportamiento, que a
su vez constan respectivamente de datos almacenados y de tareas realizables durante el tiempo de
ejecucin.
"inux,sistema operativo de cdigo abierto y libre.
Introduccin
El objeto del presente documento es el establecimiento de los estndares o convenciones de
programacin empleados en el desarrollo de software sobre la plataforma android (Java). Este modelo de
programacin est basado en los estndares recomendados por Sun Microsystems !ue "an sido
difundidos y aceptados ampliamente por toda la comunidad Java y !ue "an terminado por consolidarse
como un modelo estndar de programacin.
Estas normas son muy #tiles por muc"as ra$ones entre las !ue destacan%
&acilitan el mantenimiento de una aplicacin. 'ic"o mantenimiento constituye el ()* del coste del ciclo
de vida de la aplicacin.
+ermite !ue cual!uier programador entienda y pueda mantener la aplicacin. En muy raras ocasiones
una misma aplicacin es mantenida por su autor original.
,os estndares de programacin mejoran la legibilidad del cdigo al mismo tiempo !ue permiten su
compresin rpida.
Fichero fuente Java (.java)
-ada fic"ero fuente Java contiene una #nica clase o interfa$ p#blica. El nombre del fic"ero coincide con el
nombre de la clase. -uando e.istan varias clases privadas asociadas funcionalmente a una clase p#blica
podrn colocarse en el mismo fic"ero fuente !ue la clase p#blica. ,a clase p#blica debe estar situada en
primer lugar dentro del fic"ero fuente.
En todo fic"ero fuente Java distinguimos las siguientes secciones%
-omentarios de inicio.
Sentencia de pa!uete.
Sentencias de importacin.
'eclaraciones de clases e interfaces.
,a primera l/nea no comentada de un fic"ero fuente debe ser la sentencia de pa!uete !ue indica el
pa!uete al !ue pertenece(n) la(s) clase(s) inclu/da(s) en el fic"ero fuente.
Sentencias de importacin
0ras la declaracin del pa!uete se incluyeron las sentencias de importacin de los pa!uetes necesarios.
Esta importacin de pa!uetes obligatorios seguir el siguiente orden%
+a!uetes del J'1 de java.
+a!uetes de utilidades no pertenecientes al J'1 de Java de framewor2s de desarrollo o de proyectos
opensource tales como apac"e "ibernate springframewor2 etc.
+a!uetes de la aplicacin.
Declaraciones de clases e interfaces
-Comentario de documentacin de la clase/interfaz /** ... */ %+ermite describir la clase3interfa$
desarrollada
-Variales de clase (estticas)% En primer lugar las variables de clase p#blicas (public) despu4s las
protegidas (protected) posteriormente las de nivel de pa!uete (sin modificador) y por #ltimo las privadas
(private).
-Variales de instancia%+rimero las p#blicas (public) despu4s las protegidas (protected) luego las de
nivel de pa!uete (sin modificador) y finalmente las privadas (private).
-!"todos% Se agruparon por funcionalidad en lugar de agruparse por mbito o accesibilidad. +or ejemplo
un m4todo privado puede estar situado entre dos m4todos p#blicos. El objetivo es desarrollar cdigo fcil
de leer y comprender.
-San#r$a%-omo norma general se establecieron 5 caracteres como unidad de sangr/a.
-&na declaracin por l$nea
Se estableci el uso de una declaracin por l/nea promoviendo as/ el uso de comentarios.
Inicializacin
0oda variable local fue iniciali$ada en el momento de su declaracin salvo !ue su valor inicial dependa de
alg#n valor !ue tenga !ue ser calculado previamente.
,as declaraciones se situaron al principio de cada blo!ue principal en el !ue se utilicen y nunca en el
momento de su uso.
Declaracin de clases / interfaces
'urante el desarrollo de clases 3 interfaces se seguieron las siguientes reglas de formateo%
6o incluir ning#n espacio entre el nombre del m4todo y el par4ntesis inicial del listado de parmetros.
El carcter inicio de blo!ue (787) debe aparecer al final de la l/nea !ue contiene la sentencia de
declaracin.
El carcter fin de blo!ue (797) se sit#a en una nueva l/nea tabulada al mismo nivel !ue su correspondiente
sentencia de inicio de blo!ue e.cepto cuando la sentencia sea nula en tal caso se situar detrs de 787.
,os m4todos se separarn entre s/ mediante una l/nea en blanco.
Sentencias
-ada l/nea contiene como m.imo una sentencia. ,as sentencias pertenecientes a un blo!ue de cdigo
estarn tabuladas un nivel ms a la derec"a con respecto a la sentencia !ue las contiene.
'spacios en lanco
Se utili$arn espacios en blanco en los siguientes casos para mejorar la legibilidad%
:Entre una palabra clave y un par4ntesis. Esto permite !ue se distingan las llamadas a m4todos de las de
las palabras claves
:0ras cada coma en un listado de argumentos
:+ara separar las e.presiones incluidas en la sentencia 7for7
:;l reali$ar el moldeo o 7casting7 de clases
(omenclatura de identificadores
,as convenciones de nombres de identificadores permiten !ue los programas sean ms fciles de leer y
por tanto ms comprensibles. 0ambi4n proporcionan informacin sobre la funcin !ue desempe<a el
identificador dentro del cdigo es decir si es una constante una variable una clase o un pa!uete entre
otros.
-)a*uetes
Se escribi siempre en letras min#sculas para evitar !ue entren en conflicto con los nombres de clases o
interfaces
-Clases e interfaces
,os nombres de clases fueron sustantivos y debieron tener la primera letra en may#sculas. Si el nombre
fuese compuesto cada palabra componente deber comen$ar con may#sculas. ,os nombres sern
simples y descriptivos. Se evito el uso de acrnimos o abreviaturas salvo en a!uellos casos en los !ue
dic"a abreviatura sea ms utili$ada !ue la palabra !ue representa (=>, ?00+ etc.).
-!"todos
,os m4todos fueron nombrados por verbos escritos en min#sculas. -uando el m4todo fuese compuesto
por varias palabras cada una de ellas tendr la primera letra en may#sculas.
-Variales
,as variables se escribirn siempre en min#sculas. ,as variables compuestas tendrn la primera letra de
cada palabra componente en may#sculas. ,os nombres de variables deben ser cortos y sus significados
tienen !ue e.presar con suficiente claridad la funcin !ue desempe<an en el cdigo. 'ebe evitarse el uso
de nombres de variables con un slo carcter e.cepto para variables temporales.
-Constantes
0odos los nombres de constantes fueron escritos en may#sculas. -uando los nombres de constantes
fueron compuestos las palabras se separarn entre s/ mediante el carcter de subrayado 7@7.
-Visiilidad de atriutos de instancia + de clase
,os atributos de instancia y de clase son siempre privados e.cepto cuando tuviesen ser visibles en
subclases "erederas en tales casos fueron declarados como protegidos.
El acceso a los atributos de una clase se reali$ por medio de los m4todos 7get7 y 7set7 correspondientes
incluso cuando el acceso a dic"os atributos se realice en los m4todos miembros de la clase.
-,eferencias a miemros de una clase
Se evito el uso de objetos para acceder a los miembros de una clase (atributos y m4todos estticos).
=tili$aremos en su lugar el nombre de la clase.
--si#nacin sore variales
Se evito las asignaciones de un mismo valor sobre m#ltiples variables en una misma sentencia ya !ue
dic"as sentencias suelen ser dif/ciles de leer.
-)ar"ntesis
Se utili$o la buena prctica de el uso de par4ntesis en e.presiones !ue incluyan distintos tipos de
operadores para evitar problemas de precedencia de operadores. ;un!ue la precedencia de operadores
nos pueda parecer clara debemos asumir !ue otros programadores no tengan un conocimiento
e."austivo sobre las reglas de precedencia.