Android - Activity Constructor vs onCreate

89

Eu entendo que o Android Activitiestem ciclos de vida específicos e que onCreatedevem ser substituídos e usados para inicialização, mas o que exatamente acontece no construtor? Existem casos em que você também pode / deve substituir o Activityconstrutor ou nunca deve tocá-lo?

Estou assumindo que o construtor nunca deve ser usado porque as referências a Activitiesnão são totalmente limpas (atrapalhando o coletor de lixo) e onDestroyexiste para esse propósito. Isso está correto?

— idolatrar
fonte

2

E o fato de que o Android pode destruir / recriar sua atividade a qualquer momento? Você não sabe se o construtor será chamado então e mesmo se - qual construtor será chamado ... (o mesmo se aplica a Fragments e é por isso que cada Fragment tem que implementar um construtor padrão vazio).

— Marian Paździoch

34

Não consigo pensar em nenhum bom motivo para fazer nada no construtor. Você nunca constrói uma atividade diretamente, portanto, não pode usá-la para passar parâmetros. Geralmente, basta fazer as coisas em onCreate.

— Cheryl Simon
fonte

75

onCreate () impede que você use campos finais.

— Gili

2

Mas OnCreate não é chamado apenas uma vez, estou errado? Quando eu mudo a orientação da tela e de volta pela minha mão, cada vez que a atividade recarrega, oncreate é chamado

— fercis

2

@fercis onCreate é chamado apenas uma vez por instância, eu acredito. Ao girar o dispositivo, aquela instância da Activity é destruída e uma nova é criada, chamando onCreate. Dito isso, tenho quase certeza de que você não pode instanciar campos finais em onCreate porque Java não sabe que onCreate só será chamado uma vez (e, de fato, você mesmo poderia chamá-lo novamente em seu código - coisas ruins acontecerão, mas ainda será compilado) e, portanto, a única maneira de instanciar os campos finais seria no construtor.

— Harvey Adcock

Quando o evento OnCreate começa a ser executado exatamente? Quando defino um ponto de interrupção no início do evento OnCreate para que o aplicativo seja executado e carregue a atividade na tela, o ponto de interrupção é ativado e o aplicativo entra em pausa. Preciso de um evento sobre a atividade que seja ativado exatamente antes da inicialização e do lançamento da atividade.

— Mohammad Afrashteh

@Cheryl Simon, Você disse que nunca cria uma atividade diretamente, então quem cria a atividade?

— Sreekanth Karumanaghat

7

Uma boa razão para colocar coisas no construtor como o comentário de Gili havia declarado é o uso de campos finais.

No entanto, se você inicializar coisas no construtor, a vida útil do objeto será um pouco mais longa, embora eu não pense muito porque o onCreateseria chamado logo depois.

Embora seja contra o meu ideal, eu evitar o construtor para inicialização dos membros da atividade e dependem de onResume()e onPause()para recursos que meu aplicativo está lidando.

Pois onCreate()eu geralmente o uso para fazer mapeamento de visualização para variáveis locais. Embora o android-annotations já faça isso para mim, raramente tenho um onCreate()método para minha atividade. Eu ainda o uso no Serviço.

No entanto, se você olhar para os membros, pode estar inicializando

eles teriam um método "fechar" que você deve invocar no momento adequado (onResume ou onPause)
eles fariam parte da visualização, o que significa que precisa ser inicializado e então onCreate precisa ser chamado
elas são constantes que não precisam ser colocadas no construtor de qualquer maneira, apenas um final estático bastaria. Isso inclui as constantes Paint e Path que podem ser inicializadas por um bloco estático

— Arquimedes Trajano
fonte

1

O que você quer dizer com a vida útil do objeto será um pouco mais longa? Eu de que maneira? Se você mover essas inicializações para o onCreate, por exemplo, ainda leva o mesmo tempo. Não há diferença na expectativa de vida que eu possa determinar. Você pode expandir isso um pouco mais por favor, pois sinto, como um novato, que posso estar perdendo algo crucial aqui.

— RichieHH

2

@RichieHH por mais Arquimedes está apenas dizendo que o construtor é chamado antes de onCreate () e então tudo o que for feito lá terá persistido (ligeiramente) por mais tempo quando a atividade for destruída

— pho79

6

Agora estou em um caso que precisa substituir o construtor. Na verdade, tenho algumas atividades que têm a mesma estrutura. Portanto, em vez de criar muitas atividades, criarei uma atividade "Mestre" e as outras herdarão esta. Portanto, preciso substituir o construtor da atividade filho para poder inicializar algumas variáveis que serão usadas nos métodos oncreate.

Em duas palavras, o construtor faz você simular uma "atividade principal" que pode ser reutilizada por herança!

— biboMandroid
fonte

15

Eu sei que isso é antigo, mas qual é a vantagem aqui sobre apenas implementar a instanciação de supercampo onCreate (). De qualquer forma, você chamará super.onCreate () do filho.

— Andrew G

Portanto, apenas passando valores diferentes para a mesma CHAVE no pacote ou intenção ao lançar a atividade e, portanto, usar a mesma atividade, você pode determinar o que mostrar na atividade dependendo do valor recebido. Qual é o motivo específico pelo qual você escolheu construtores? Ou então mantendo a parte não mutável de Activity comum e para o resto da parte mutável você poderia ter criado Fragments.

— Nayanesh Gupte

0

Você precisa sobrescrever o Construtor quando sua atividade tiver parâmetros personalizados ou você quiser rastrear chamadas de classes que herdaram de.

— Pentium10
fonte

1

Você pode elaborar mais sobre isso? O que você descreve parece interessante, mas é um pouco vago. Obrigado!

— idolatrar

3

Suponha que você precise criar uma classe Activity customizada que leva 2 ou mais parâmetros. Você só precisa usar o Construtor, você não pode fazer isso através do onCreate e extras. Ajuda?

— Pentium10

1

Pode ser que eu precise de um particular. Suponha que eu queira criar um componente personalizado, por exemplo, um seletor de contato personalizado. Para ter startActivityForResult, devo incluir um construtor privado em meu componente personalizado, mesmo que essa atividade nunca seja iniciada e não tenha elementos visíveis, eu apenas uso o material de resultado dela.

— Pentium10 de

6

Eu vou dizer que isso não faz sentido para mim @Pentium, não sem um exemplo de código.

— Blundell

Acho que uma vantagem de fazer as coisas por meio do construtor é ter uma atividade de "modelo" que pode receber parâmetros que uma classe herdada pode aproveitar. Por exemplo, se você tiver duas atividades que diferem apenas em algumas das propriedades, por exemplo, R.id.cameraSurface, R.id.videoSurface, então você pode criar um construtor que receberá um parâmetro, chamá-lo de AbstractResourceActivity e então você terá CameraActivity que está registrado no manifesto que estende AbstractResourceActivity passando o ID do recurso.

— Archimedes Trajano