Declare una variable global, o declare varias veces en cada clase

No hay nada malo con el uso de variables globales. Generalmente se evitan para mantener las cosas flexibles y encapsuladas. Pero algunos patrones de diseño como el patrón de fábrica van bien con las clases estáticas / globales. También evita la duplicación de código.

(Sin embargo, podría evitar usar mi clase de Application para que mis campos globales sólo se utilicen cuando sea necesario, pero eso es un detalle de implementación).

Yo haría algo como esto probablemente. Mantiene las cosas flexibles al tiempo que también pone las cosas en un solo lugar para que sean consistentes en toda la aplicación.

 public class MyGlobals { private static SimpleDateFormat dateFormat; public static SimpleDateFormat getDateFormat() { if(dateFormat== null) { dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); } return dateFormat; } } 

A continuación, puede utilizar esto en otras clases:

 MyGlobals.getDateFormat(); 

===

Aquí hay alguna información de los documentos de desarrollo acerca de ello:

http://developer.android.com/guide/faq/framework.html#3

Para compartir objetos complejos no persistentes definidos por el usuario de corta duración, se recomiendan los siguientes enfoques:

Clase Singleton

Puede aprovechar el hecho de que los componentes de la aplicación se ejecutan en el mismo proceso mediante el uso de un singleton. Se trata de una clase que está diseñada para tener sólo una instancia. Tiene un método estático con un nombre como getInstance () que devuelve la instancia; La primera vez que se llama a este método, crea la instancia global. Debido a que todas las personas que llaman obtienen la misma instancia, pueden utilizar esto como un punto de interacción. Por ejemplo, la actividad A puede recuperar la instancia y llamar a setValue (3); La actividad posterior B puede recuperar la instancia y llamar a getValue () para recuperar el último valor establecido.

Un campo / método estático público

Una forma alternativa de hacer accesibles los datos a través de Actividades / Servicios es utilizar campos y / o métodos estáticos públicos. Puede acceder a estos campos estáticos desde cualquier otra clase de la aplicación. Para compartir un objeto, la actividad que crea el objeto establece un campo estático para apuntar a este objeto y cualquier otra actividad que desee utilizar este objeto sólo accede a este campo estático.

Un HashMap de WeakReferences a objetos

También puede utilizar un HashMap de WeakReferences a objetos con teclas largas. Cuando una actividad quiere pasar un objeto a otra actividad, simplemente coloca el objeto en el mapa y envía la clave (que es un Long único basado en un contador o marca de tiempo) a la actividad del destinatario a través de extras de intención. La actividad del destinatario recupera el objeto utilizando esta clave.

Objetos persistentes

Incluso mientras una aplicación parece seguir ejecutándose, el sistema puede elegir matar su proceso y reiniciarlo más tarde. Si tiene datos que necesita para persistir de una invocación de actividad a la siguiente, debe representar esos datos como estado que se guarda por una actividad cuando se informa de que podría desaparecer.

Para compartir objetos persistentes complejos definidos por el usuario, se recomiendan los siguientes enfoques:

 Application Preferences Files contentProviders SQLite DB 

Si los datos compartidos deben mantenerse en los puntos donde el proceso de aplicación puede ser eliminado, coloque los datos en almacenamiento persistente como Preferencias de aplicación, DB de SQLite, Archivos o ContentProviders. Consulte el Almacenamiento de datos para obtener más detalles sobre cómo utilizar estos componentes.

Sí, es una buena idea definirlos en un solo lugar, no sólo porque es más limpio, sino porque también es mucho más fácil cambiarlos a escala global sin pasar por toda la base de código. Personalmente, me gustaría ir con algo como esto:

 public static final LONG_DATE_FORMAT = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); 

Sin embargo, en este caso particular debe tener cuidado, ya que los objetos de SimpleDateFormat no son seguros para subprocesos. Esto significa que si va a compartir una instancia en toda la aplicación, hay algunos pasos adicionales que debe seguir para evitar problemas de concurrencia. Consulte uno de los siguientes para obtener más detalles:

Seguridad del hilo de SimpleDateFormat

Probar que SimpleDateFormat no es thread-safe

"Java DateFormat no es threadafe" ¿a qué conduce esto?

Todo se reduce a lo que usted necesita y su contexto actual.

Si usted puede permitirse un poco de refactorización, IMHO el mejor enfoque sería crear una clase de contexto que contiene todo este tipo de variables. Usted puede tomar el adventage de su sesión refactoring e incluso mover otros parámetros de la configuración a esa clase y tenerla como Singleton:

 public class MyApplicationContext { //Constants and other global variables (I'd make the strings global, rather than //The time formats in this case. public final String TIME_FORMAT = "HHmm"; //Context variables (taken from your source of choice) private String someConfigurationPath = "..."; //Getters & Setters } 

Las variables globales pueden ser un indicador del olor de código.

Tal vez sea posible encontrar un patrón en las diferentes ubicaciones, donde se utiliza el mismo formato de fecha simple. Esto puede ser una oportunidad para refactorizar el código y mover todas las partes comunes en un solo lugar, por ejemplo, combinado en un nuevo método (como printDate (aDate)) en lugar de las múltiples instanciaciones de SimpleDateFormat y más adyacentes al código duplicado.

Lo haría, todo depende de lo que va a cambiar, pero si usted tiene todas sus variables de configuración como estática puede cambiar el formato de la fecha en un lugar y todos los demás no tendrá que ser cambiado.

A veces, para cosas como los formatos de fecha, es conveniente poner la cadena de fecha en el archivo stings.xml para que pueda variar el formato de fecha por país / idioma.