Android - Activity Constructor vs onCreate

88

Capisco che Android Activitiesha cicli di vita specifici e che onCreatedovrebbe essere sovrascritto e utilizzato per l'inizializzazione, ma cosa succede esattamente nel costruttore? Ci sono casi in cui potresti / dovresti sovrascrivere anche il Activitycostruttore, o non dovresti mai toccarlo?

Presumo che il costruttore non dovrebbe mai essere utilizzato perché i riferimenti a Activitiesnon vengono completamente ripuliti (ostacolando così il garbage collector) e questo onDestroyè lì per quello scopo. È corretto?

— idolatrare
fonte

2

Che dire del fatto che Android può distruggere / ricreare la tua attività in qualsiasi momento? Non sai se il costruttore verrà chiamato allora e anche se - quale costruttore verrà chiamato ... (lo stesso vale per i frammenti ed è per questo che ogni frammento deve implementare un costruttore predefinito vuoto).

— Marian Paździoch

34

Non riesco a pensare a nessuna buona ragione per fare qualcosa nel costruttore. Non si costruisce mai un'attività direttamente, quindi non è possibile utilizzarla per passare i parametri. In generale, basta fare le cose in onCreate.

— Cheryl Simon
fonte

73

onCreate () ti impedisce di utilizzare i campi finali.

— Gili

2

Ma OnCreate non viene chiamato solo una volta, sbaglio? Quando cambio l'orientamento dello schermo e ritorno con la mano, ogni volta che l'attività si ricarica, viene chiamato

— oncreate

2

@fercis onCreate viene chiamato solo una volta per istanza, credo. Quando si ruota il dispositivo, quell'istanza dell'attività viene distrutta e ne viene creata una nuova, chiamando onCreate. Detto questo, sono abbastanza sicuro che non puoi istanziare i campi finali in onCreate perché Java non sa che onCreate verrà chiamato solo una volta (e in effetti, potresti chiamarlo di nuovo tu stesso nel tuo codice - accadranno cose brutte, ma verrà comunque compilato) e quindi l'unico modo per istanziare i campi finali sarebbe nel costruttore.

— Harvey Adcock

Quando inizia esattamente l'evento OnCreate? Quando imposto un punto di interruzione all'inizio dell'evento OnCreate in modo che l'app venga eseguita e carichi l'attività sullo schermo, il punto di interruzione si attiva e l'app va in pausa. Ho bisogno di un evento sull'attività che si attiva esattamente prima dell'inizializzazione e dell'avvio dell'attività.

— Mohammad Afrashteh

@Cheryl Simon, hai detto che non crei mai un'attività direttamente, quindi chi crea l'attività?

— Sreekanth Karumanaghat

7

Un buon motivo per mettere le cose nel costruttore come aveva affermato il commento di Gili è l'uso dei campi finali.

Tuttavia, se si inizializzano le cose nel costruttore, la durata di vita dell'oggetto sarà un po 'più lunga, anche se non penso di molto perché onCreateverrebbe chiamato poco dopo.

Sebbene sia contro il mio ideale, evito il costruttore per l'inizializzazione dei membri dell'attività e faccio affidamento su onResume()e onPause()per le risorse con cui la mia app ha a che fare.

Di onCreate()solito lo uso per eseguire la mappatura della vista su variabili locali. Sebbene le annotazioni Android lo facciano già per me, raramente ho un onCreate()metodo per la mia attività. Lo uso ancora in Servizio però.

Tuttavia, se guardi i membri che stai inizializzando

avrebbero un metodo "close" che devi invocare al momento giusto (onResume o onPause)
farebbero parte della vista, il che significa che deve essere inizializzato, quindi deve essere chiamato onCreate
sono costanti che non devono essere inserite comunque nel costruttore, basterebbe solo una finale statica. Ciò include le costanti Paint e Path che possono essere inizializzate da un blocco statico

— Archimedes Trajano
fonte

1

Cosa vuoi dire che la durata di vita dell'oggetto sarà un po 'più lunga? In che modo? Dal momento che, ad esempio, se si spostano queste initalizzazioni in onCreate, ciò richiede lo stesso tempo. Non c'è differenza nella durata della vita che posso determinare. Puoi approfondire questo argomento un po 'di più, per favore, visto che, in quanto relativamente nuovo arrivato, potrei perdere qualcosa di cruciale qui.

— RichieHH

2

@RichieHH di più Archimede sta solo dicendo che il costruttore viene chiamato prima di onCreate () e quindi qualsiasi cosa venga fatta lì sarà persistita (leggermente) più a lungo che altrimenti nel momento in cui l'attività viene distrutta

— pho79

6

Sono ora su un caso che deve sostituire il costruttore. In effetti, ho alcune attività che hanno la stessa struttura. Quindi, invece di creare molte attività, creerò un'attività "Master" e le altre erediteranno questa. Quindi ho bisogno di sovrascrivere il costruttore dell'attività figlio per poter inizializzare alcune variabili che verranno utilizzate nei metodi oncreate.

In due parole, il costruttore ti fa simulare una "masteractivity" che può essere riutilizzata per eredità!

— biboMandroid
fonte

15

So che questo è vecchio, ma qual è il vantaggio qui rispetto alla semplice implementazione dell'istanza del super campo in esso onCreate (). Chiamerai comunque super.onCreate () dal bambino.

— Andrew G

Quindi, semplicemente passando valori diversi alla stessa KEY in bundle o intent durante l'avvio dell'attività e quindi utilizzando la stessa attività, è possibile determinare cosa mostrare in Activity in base al valore ricevuto. Qual è il motivo specifico per cui hai scelto i costruttori? Oppure mantenendo la parte non mutevole dell'Attività comune e per il resto della parte mutevole avresti potuto creare Frammenti.

— Nayanesh Gupte

0

Devi sovrascrivere il Costruttore quando la tua attività avrà parametri personalizzati o vuoi tenere traccia delle chiamate dalle classi che hanno ereditato da.

— Pentium10
fonte

1

Puoi approfondire meglio questo? Quello che descrivi sembra interessante, ma è un po 'vago. Grazie!

— idolatrare il

3

Supponi di dover creare una classe Activity personalizzata che richiede 2 o più parametri. Hai solo bisogno di usare il Constructor, non puoi farlo tramite onCreate e gli extra. Aiuta?

— Pentium10

1

Potrebbe aver bisogno di uno privato. Supponiamo di voler creare un componente personalizzato, ad esempio un selettore di contatti personalizzato. Per averlo startActivityForResultdevo includere un costruttore privato nel mio componente personalizzato, anche se quell'attività non verrà mai lanciata e non ha elementi visibili, ne uso solo il contenuto per il risultato.

— Pentium10

6

Dirò che non ha senso per me @Pentium, non senza un esempio di codice.

— Blundell

Penso che un vantaggio di fare le cose tramite il costruttore sia avere un'attività "modello" che può accettare parametri di cui una classe ereditata può trarre vantaggio. Ad esempio, se hai due attività che differiscono solo in alcune delle proprietà, ad esempio R.id.cameraSurface, R.id.videoSurface, puoi creare un costruttore che accetterà un parametro chiamandolo AbstractResourceActivity e quindi avrai CameraActivity che è registrato sul manifesto che estende AbstractResourceActivity passando l'ID risorsa.

— Archimedes Trajano