2010-07-21 22 views
79

Entiendo que Android Activities tiene ciclos de vida específicos y que onCreate debe anularse y utilizarse para la inicialización, pero ¿qué ocurre exactamente en el constructor? ¿Hay algún caso en el que también podría/debería anular el constructor Activity, o nunca debería tocarlo?Android - Activity Constructor vs onCreate

Supongo que el constructor nunca se debe utilizar porque las referencias a Activities no se limpian por completo (lo que dificulta el recolector de basura) y que onDestroy está ahí para ese propósito. ¿Es esto correcto?

+2

¿Qué pasa con el hecho de que Android puede destruir/recrear su actividad en cualquier momento? No se sabe si se llamará al constructor en ese momento e incluso si: qué constructor se llamará ... (lo mismo se aplica a los Fragmentos y es por eso que cada Fragmento debe implementar un constructor predeterminado vacío). –

Respuesta

31

No puedo pensar en ninguna buena razón para hacer algo en el constructor. Nunca construyes una actividad directamente, por lo que no puedes usarla para pasar parámetros. En general, solo haz las cosas en onCreate.

+65

onCreate() le impide utilizar los campos finales. – Gili

+6

¿Pruebas? ' private final InterfaceDep dep; public MyActivity() {dep = new DepImpl(); } MyActivity (Depip de interfaz Dep) {this.dep = dep; } ... @Mock private InterfaceDep dep; @InjectMocks private MyActivity myActivity; ' – saiyancoder

+1

Pero OnCreate no se llama solo una vez, ¿me equivoco? Cuando cambio la orientación de la pantalla y regreso por mi mano, cada vez que la actividad se recarga, oncreate se llama – fercis

1

Debe sobrescribir el Constructor cuando su actividad tenga parámetros personalizados o si desea rastrear llamadas de clases heredadas.

+1

¿Puedes profundizar en esto más? Lo que describes parece interesante, pero es un poco vago. ¡Gracias! – idolize

+3

Supongamos que necesita crear una clase de actividad personalizada que tome 2 o más params. Solo necesita usar el Constructor, no puede hacer eso a través de onCreate y extras. ¿Ayuda? – Pentium10

+4

Pero no crea actividades explícitamente, crea una intención ... – idolize

7

Ahora estoy en un caso que necesita anular el constructor. De hecho, tengo algunas actividades que tienen la misma estructura. Entonces, en lugar de crear muchas actividades, crearé una actividad "Maestra" y las demás heredarán esta. De modo que debo anular el constructor de la actividad secundaria para poder inicializar algunas variables que se usarán en los métodos oncreate.

En dos palabras, el constructor te hace simular una "masteractividad" que se puede reutilizar por herencia.

+14

Sé que esto es viejo, pero ¿cuál es el beneficio aquí sobre simplemente implementar la creación de instancias de súper campo en él onCreate(). Llamará a super.onCreate() desde el niño de todos modos. –

+0

Así que al pasar diferentes valores a la misma CLAVE en paquete o intento al iniciar la actividad y, por lo tanto, usar la misma actividad, puede determinar qué mostrar en la actividad en función del valor recibido. ¿Cuál es la razón específica por la que acudió a construtors? O bien, mantener la parte no cambiante de la Actividad en común y para el resto de la parte cambiante podría haber creado Fragmentos. –

+0

a cuál llamar primero. constructor o oncreate. Creo constructor – Nepster

6

Una buena razón para poner cosas en el constructor como el comentario de Gili había indicado es el uso de los campos finales.

Sin embargo, si inicializa las cosas en el constructor, entonces la vida útil del objeto será un poco más larga, aunque no lo creo mucho porque el onCreate se llamaría poco después.

Aunque es contra mi ideal, evito el constructor para la inicialización de los miembros de la actividad y confío en onResume() y onPause() para los recursos que mi aplicación está tratando.

Para onCreate() Normalmente lo uso para ver la asignación de variables locales. Aunque las anotaciones de android ya lo hacen por mí, rara vez tengo un método onCreate() para mi actividad. Aún así lo uso en el Servicio.

Sin embargo, si nos fijamos en los miembros puede ser inicializar

  • Tendrían un método de "cierre" que usted tiene que invocar en el momento adecuado (onResume o onPause)

  • Serían parte de la vista lo que significa que necesita ser inicializado y luego onCreate necesita ser llamado

  • son constantes que no necesitan ser puestas en el constructor de todos modos, solo una final estática sería suficiente. Esto incluye las constantes Paint y Path que pueden ser inicializadas por un bloque estático

+0

¿Qué quieres decir con la vida útil del objeto será un poco más largo? ¿De qué manera? Dado que si movió estas incorporaciones a onCreate, por ejemplo, eso aún lleva el mismo tiempo. No hay diferencia en la esperanza de vida que puedo determinar. ¿Puedes ampliar esto un poco más, por favor, como me siento, como un recién llegado relativo, me podría perder algo crucial aquí. – RichieHH

+2

@RichieHH por Archimedes más largo solo dice que se llama al constructor antes de onCreate() y que lo que se haga allí habrá persistido (un poco) más tiempo de lo normal en el momento en que se destruya la actividad – pho79

+0

Gracias, no noté el comentario de el año pasado. Tu respuesta es correcta –