Comunicar-se diretamente por uma rede em dispositivos independentes

Com o Wear OS by Google, um smartwatch pode se comunicar diretamente com uma rede, sem acessar um smartphone Android ou iOS. Não use a API Data Layer para conectar um app para Wear OS a uma rede. Em vez disso, siga as diretrizes e as etapas deste guia.

Acesso à rede

Os apps Wear OS podem fazer solicitações de rede. Quando um smartwatch tem conexão Bluetooth com um smartphone, o tráfego de rede do relógio geralmente usa o smartphone como proxy.

Quando um smartphone não está disponível, o Wi-Fi e as redes celulares são usados, dependendo do hardware do relógio. A plataforma Wear OS processa as transições entre redes.

Você pode usar protocolos como HTTP, TCP e UDP. No entanto, as APIs android.webkit, incluindo a classe CookieManager, não estão disponíveis. Você pode usar cookies lendo e gravando cabeçalhos em solicitações e respostas.

Use WorkManager para solicitações assíncronas, incluindo pesquisa em intervalos regulares.

Se você precisar se conectar a tipos de rede específicos, consulte Como ler o estado da rede.

Acesso à rede de alta largura de banda

A plataforma Wear OS gerencia a conectividade de rede para oferecer a melhor experiência geral do usuário. A plataforma escolhe a rede ativa padrão considerando duas necessidades: bateria de longa duração e largura de banda da rede.

Quando a economia da bateria é priorizada, a rede ativa pode não ter largura de banda suficiente para tarefas de rede, como transporte de arquivos grandes ou streaming de mídia.

Esta seção fornece orientações sobre como usar a classe ConnectivityManager para garantir que seu app tenha a largura de banda de rede necessária. Para informações gerais sobre controle detalhado de recursos de rede, consulte Gerenciar o uso da rede.

Solicitar conectividade Wi-Fi

Para casos de uso que exigem acesso à rede de alta largura de banda, como ao transportar arquivos grandes ou fazer streaming de mídia, solicite conectividade com um transporte desse tipo, como Wi-Fi. Isso é mostrado neste exemplo:

val callback = object : ConnectivityManager.NetworkCallback() {
    override fun onAvailable(network: Network) {
        super.onAvailable(network)
        // The Wi-Fi network has been acquired. Bind it to use this network by default.
        connectivityManager.bindProcessToNetwork(network)
    }

    override fun onLost(network: Network) {
        super.onLost(network)
        // Called when a network disconnects or otherwise no longer satisfies this request or callback.
    }
}
connectivityManager.requestNetwork(
    NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(),
    callback
)

ConnectivityManager.NetworkCallback callback = new ConnectivityManager.NetworkCallback() {
    public void onAvailable(Network network) {
        super.onAvailable(network);
        // The Wi-Fi network has been acquired. Bind it to use this network by default.
        connectivityManager.bindProcessToNetwork(network);
    }

    public void onLost(Network network) {
        super.onLost(network);
        // Called when a network disconnects or otherwise no longer satisfies this request or callback.
    }
};
connectivityManager.requestNetwork(
        new NetworkRequest.Builder().addTransportType(NetworkCapabilities.TRANSPORT_WIFI).build(),
        callback
);

A conexão a uma rede pode não ser instantânea, porque o Wi-Fi ou o rádio celular de um relógio pode estar desativado para economizar bateria. Se não for possível conectar o smartwatch a uma rede, o método onAvailable() da instância NetworkCallback não vai ser chamado.

Depois que onAvailable() é chamado, o dispositivo tenta permanecer conectado à rede Wi-Fi até que o NetworkCallback seja liberado. Para preservar a duração da bateria, libere o callback, conforme mostrado no exemplo abaixo, quando você não precisar mais de uma rede Wi-Fi.

connectivityManager.bindProcessToNetwork(null)
connectivityManager.unregisterNetworkCallback(callback)

connectivityManager.bindProcessToNetwork(null);
connectivityManager.unregisterNetworkCallback(callback);

Iniciar a atividade de configuração de Wi-Fi

Ao solicitar uma rede Wi-Fi, o sistema tenta se conectar a uma rede salva se uma estiver configurada e dentro do alcance. Se nenhuma rede Wi-Fi salva estiver disponível, o método de callback onAvailable da instância NetworkCallback não vai ser chamado.

Se você estiver usando um Handler para definir o tempo limite da solicitação de rede, será possível direcionar o usuário para adicionar uma rede Wi-Fi quando o tempo limite for atingido. Envie o usuário diretamente à atividade para adicionar uma rede Wi-Fi usando a intent abaixo:

context.startActivity(Intent("com.google.android.clockwork.settings.connectivity.wifi.ADD_NETWORK_SETTINGS"))

context.startActivity(new Intent("com.google.android.clockwork.settings.connectivity.wifi.ADD_NETWORK_SETTINGS"));

Para iniciar a atividade de configuração, o app precisa ter a permissão CHANGE_WIFI_STATE.

Considerações sobre a interface do usuário

Se o app precisar de uma conexão com uma nova rede Wi-Fi para uma operação de alta largura de banda, confira se o motivo para a conexão está claro para o usuário antes de iniciar as configurações de Wi-Fi. Só peça para o usuário adicionar uma nova rede Wi-Fi quando a rede de alta largura de banda for necessária. Não bloqueie o acesso a recursos do app que não exigem uma rede de alta largura de banda.

A Figura 1 mostra um app de música. O app permite que o usuário procure músicas em uma rede de largura de banda menor e só exige que ele adicione uma nova rede Wi-Fi se quiser fazer o download ou streaming de músicas.

Figura 1. Fluxo de um app para download de música.

Considerações sobre o uso de dados e energia

Para preservar a duração da bateria e minimizar o uso de dados móveis, adie tarefas de rede não essenciais, como relatórios de análise ou coleta de registros, até que o dispositivo Wear OS restabeleça uma conexão Bluetooth ou Wi-Fi em vez de uma conexão LTE ou limitada.

Mensagens na nuvem

Para enviar notificações, use o Firebase Cloud Messaging (FCM) diretamente.

Nenhuma API para acesso à rede ou FCM é específica do Wear OS. Consulte a documentação sobre como se conectar a uma rede e sobre mensagens na nuvem.

O FCM funciona bem com o recurso Soneca e é a maneira recomendada de enviar notificações para um smartwatch.

Forneça mensagens do FCM coletando um token de registro para um dispositivo quando o app Wear OS for executado. Em seguida, inclua o token como parte do destino quando o servidor enviar mensagens para o endpoint REST do FCM. O FCM envia mensagens para o dispositivo identificado pelo token.

As mensagens do FCM são enviadas no formato JavaScript Object Notation (JSON) e podem incluir um ou ambos os payloads a seguir:

• Payload de notificação:quando um payload de notificação é recebido por um relógio, os dados são exibidos para um usuário diretamente no stream de notificações. Quando o usuário toca na notificação, o app é iniciado.
• Payload de dados:quando o payload tem um conjunto de pares personalizados de chave ou valor. O payload é enviado como dados para o app do Wear OS.

Para mais informações e exemplos de payloads, consulte Sobre as mensagens do FCM.

Por padrão, as notificações são compartilhadas de um app do smartphone para o relógio. Se você tiver um app independente para Wear OS e um app para smartphones correspondente, é possível que ocorram notificações duplicadas. Por exemplo, uma única notificação do FCM, recebida tanto pelo smartphone quanto pelo relógio, pode ser exibida por ambos os dispositivos de maneira independente. Para evitar isso, use as APIs de ponte.

Usar serviços em segundo plano

Para garantir que as tarefas em segundo plano sejam executadas corretamente, elas precisam considerar a Soneca e o App em espera.

Quando uma tela é desligada ou entra no modo ambiente por um certo período, um subconjunto do modo Soneca pode ser ativado, e as tarefas em segundo plano podem ser adiadas por algum tempo. Depois, quando o dispositivo fica inativo por um tempo prolongado, o modo Soneca normal é ativado. Programe solicitações com a API WorkManager, que permite que seu app se registre para a execução de códigos seguros para o modo Soneca.

Programar com restrições

Você pode usar restrições para configurar solicitações de forma a preservar a duração da bateria. Selecione uma ou mais das seguintes restrições para incluir nas suas solicitações:

• Agende uma solicitação que exija rede.

  Especifique se NetworkType é CONNECTED ou UNMETERED. UNMETERED serve para grandes transferências de dados e CONNECTED para pequenas transferências.

• Programe uma solicitação ao carregar.

• Programe uma solicitação enquanto o dispositivo estiver inativo. Isso é útil para trabalhos ou sincronizações em segundo plano de menor prioridade, especialmente quando o dispositivo está carregando.

Para saber mais, consulte o guia do WorkManager: Efeito das restrições no trabalho periódico.