Android Package Structure Best Practice

Tengo una pregunta sobre las mejores prácticas para la estructura del paquete de aplicaciones.Android Package Structure Best Practice

Vi Reto Meier Google I/O 2011 presentación "Android Protips: Advanced Topics for Expert Android Developer s" y leer su blog "A Deep Dive Into Location" y tomó nota de su estructura de paquete de la aplicación de:.

com ... .content_providers
com ... . .receivers
com. ... .Servicios
com. com ... .ui . ... .UI.fragments
com. ... .utils
com. ... .utils. base

¿Es esta la estructura preferida para los paquetes? ¿Hay una mejor estructura?

Fuente

2011-07-07 Carl G

+10

Realmente me encantan este tipo de preguntas. También estaría interesado en saber qué piensan los demás acerca de eso – barmaley

No es exactamente lo mismo, pero esta pregunta podría ser útil en un sentido más general http://stackoverflow.com/questions/5525872/android-project-package-structure – derekerdmann

Me gusta de esta manera, clasifico mis paquetes según cuál sea la función principal de las clases en ellos. Me gusta * .activities - Esto es subjetivo sin embargo. –

El objetivo principal de empaquetar sus clases es simplificar la navegación a través de su código fuente. Esto es especialmente importante para las aplicaciones de código abierto. En mi opinión, una estructura de paquete fácil de navegar incluye los siguientes paquetes:

com.example.main - contiene las principales funciones del controlador, como su actividad principal, su clase de aplicación (si tiene una), etc.

com.example.conf - contiene los archivos de configuración, tales como aquellas constantes que contienen (variables estáticas y finales)

com.example.net - clases relacionadas con la red, tales como los que hacen las peticiones HTTP

com.example.util - clases de utilidad, como los servicios , Br oadcastReceivers u otros procesos en segundo plano

Fuente

2011-08-16 18:27:06 Phil

ese es uno de los propósitos de los paquetes, pero no necesariamente el principal. el otro es ocultar adecuadamente las áreas de preocupación. por ejemplo, puede hacer que todo su código de UI esté en el paquete .ui, hacer privadas todas las clases pkg y no exponerlas a ninguna otra capa del código. –

Veo una gran cantidad de proyectos estructurados de esa manera (creo que incluso Google IO 2012 es). Me gusta mi proyecto agrupado (empaquetado) por tema: (com.apps.player con PlayerActivity, PlayerListView, PlayerListAdapter, com.apps.sync con SyncService, SyncHelper, etc.) El código me resulta más fácil de navegar y comprender en ese camino. Además, si trabajo en una función específica, tengo todas las clases a mano. No entiendo por qué alguien pone clases que indican su función en su nombre (por ejemplo, PlayerActivity) en paquetes que indican sus funciones de clases (por ejemplo, com.apps.activities). – user511

Android Package Structure Best Practice

Respuesta

Cuestiones relacionadas