Conceitos do desenvolvimento para Android - Parte II

Serviços

Um serviço roda em background por um período de tempo indeterminado, este não possui uma interface visual . O exemplo de um serviço é tocar uma música de playback enquanto o usuário faz outras coisas, ou pode buscar informações na rede ou calcular alguma coisa e devolver o resultado para as atividades que precisam daquilo. Cada serviço herda da classe base Service.

Para manter a música tocando, a atividade do media player poderia iniciar um serviço para executar em background. O sistema então manteria o serviço com a música de playback rodando mesmo depois que a atividade que o iniciou deixasse a tela.

É possível conectar-se (bind) a um serviço em execução (e iniciar o serviço caso ele não esteja rodando). Enquanto conectado, você pode se comunicar com o serviço através de uma interface de que ele disponha. Para o serviço de música, essa interface poderia permitir ao usuário pausar, retroceder, parar e recomeçar a música.

Assim como as atividades e os outros componentes, os serviços rodam na thread principal do processo da aplicação. Para que eles não bloqueiem outros componentes da interface do usuário, geralmente eles criam uma outra thread para tarefas demoradas (como tocar uma música). Veja Processes and Threads, depois.

Broadcast receivers

Um broadcast receiver é um componente que não faz nada além de receber e reagir a broadcasts. Muitos broadcasts se originam no core do sistema — por exemplo, mensagens de que o timezone mudou, que a bateria está fraca, que uma foto foi tirada, ou que o usuário modificou a preferência de idioma. As aplicações também podem iniciar broadcasts — por exemplo, para avisar a outras aplicações que alguns dados foram baixados para o dispositivo e estão disponíveis para uso.

Uma aplicação pode ter vários broadcast receivers para responder a mensagens que ela considera importantes. Todos os receivers herdam da classe base BroadcastReceiver.

Os broadcast receivers não exibem uma interface de usuário. Entretanto, eles podem iniciar uma activity em resposta à informação que receberam, ou podem usar o NotificationManager para alertar o usuário. Notificações podem chamar a atenção do usuário de várias formas — piscando a luz de fundo, vibrando o dispositivo, tocando um som, e assim por diante. Elas normalmente inserem um ícone persistente na barra de status, a qual os usuários podem abrir para pegar a mensagem.

Content providers

Um content provider torna um determinado conjunto dos dados da aplicação disponível para outras aplicações. Os dados podem ser armazenados no sistema de arquivos, em uma base de dados SQLite, ou de qualquer outra maneira que faça sentido. O content provider herda da classe base ContentProvider para implementar um conjunto padrão de métodos que habilitam outras aplicações a recuperar e armazenar dados do tipo que ele controla. Entretanto, as aplicações não podem chamar estes métodos diretamente. Ao invés disso, elas utilizam um objeto ContentResolver e chamam seus métodos. Um ContentResolver pode conversar com qualquer content provider; ele coopera com o provider para gerenciar qualquer comunicação envolvida entre os processos.

Veja o documento à parte Content Providers para maiores informações sobre o uso de content providers.

Sempre que há uma requisição que deveria ser manipulada por um componente em particular, o Android se certifica de que o processo da aplicação esteja em execução, iniciando-o caso necessário, e que uma instância apropriada do componente esteja disponível, criando a instância se for preciso.


fonte: http://zendroid.com.br/documentacao/principios-basicos-da-aplicacao-parte-1-componentes/

Leandro Santos