Giao tiếp trực tiếp qua mạng trên các thiết bị độc lập

Với Wear OS by Google, đồng hồ có thể giao tiếp trực tiếp với mạng mà không cần quyền truy cập vào điện thoại Android hoặc iOS. Đừng sử dụng Data Layer API (API Lớp dữ liệu) để kết nối Ứng dụng Wear OS vào một mạng. Thay vào đó, hãy làm theo hướng dẫn và các bước trong hướng dẫn này của chúng tôi.

Quyền truy cập mạng

Ứng dụng Wear OS có thể thực hiện các yêu cầu về mạng. Khi đồng hồ có Bluetooth kết nối với điện thoại, thì lưu lượng truy cập mạng của đồng hồ thường được xử lý qua proxy điện thoại.

Khi không có điện thoại, Wi-Fi và mạng di động sẽ được sử dụng, tuỳ thuộc vào phần cứng đồng hồ. Nền tảng Wear OS sẽ xử lý quá trình chuyển đổi giữa các mạng.

Bạn có thể sử dụng các giao thức như HTTP, TCP và UDP. Tuy nhiên, Các API android.webkit, bao gồm cả lớp CookieManager, không được sẵn có. Bạn có thể sử dụng cookie bằng cách đọc và ghi tiêu đề theo yêu cầu và phản hồi.

Sử dụng WorkManager cho các yêu cầu không đồng bộ, bao gồm cả việc thăm dò ý kiến thông thường ngắt quãng.

Nếu bạn cần kết nối với các loại mạng cụ thể, hãy xem phần Đọc mạng trạng thái.

Quyền truy cập mạng băng thông cao

Nền tảng Wear OS quản lý kết nối mạng nhằm mục tiêu cung cấp trải nghiệm người dùng tổng thể tốt nhất. Nền tảng này chọn mạng đang hoạt động mặc định theo cân bằng hai nhu cầu: thời lượng pin lâu và băng thông mạng.

Khi bảo toàn pin được ưu tiên, mạng đang hoạt động có thể không đủ băng thông cho các tác vụ về mạng như truyền tải tệp có kích thước lớn hoặc truyền trực tuyến nội dung đa phương tiện.

Phần này cung cấp hướng dẫn về cách sử dụng lớp ConnectivityManager để giúp đảm bảo ứng dụng của bạn có băng thông mạng cần thiết. Dành cho tất cả mọi người thông tin về việc kiểm soát chi tiết các tài nguyên mạng, xem phần quản lý mức sử dụng mạng.

Yêu cầu kết nối Wi-Fi

Đối với các trường hợp sử dụng yêu cầu quyền truy cập mạng băng thông cao, chẳng hạn như chuyển dữ liệu các tệp lớn hoặc phát trực tuyến nội dung nghe nhìn, hãy yêu cầu kết nối với băng thông cao mạng, chẳng hạn như Wi-Fi. Lệnh này được minh hoạ trong ví dụ sau:

Kotlin

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
)

Java

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
);

Quá trình kết nối mạng có thể không diễn ra ngay lập tức vì Wi-Fi của đồng hồ hoặc đài di động có thể đã tắt để tiết kiệm pin. Nếu đồng hồ không thể kết nối với thì phương thức onAvailable() của thực thể NetworkCallback không được có tên.

Sau khi onAvailable() được gọi, thiết bị sẽ cố gắng duy trì kết nối với Mạng Wi-Fi cho đến khi NetworkCallback được giải phóng. Để duy trì tuổi thọ pin, giải phóng lệnh gọi lại như trong ví dụ sau khi bạn không cần một lệnh gọi lại Mạng Wi-Fi.

Kotlin

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

Java

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

Chạy hoạt động cài đặt Wi-Fi

Khi bạn yêu cầu một mạng Wi-Fi, hệ thống sẽ cố gắng kết nối với một mạng đã lưu nếu một giá trị được định cấu hình và nằm trong phạm vi. Nếu chưa có mạng Wi-Fi đã lưu nào, Phương thức gọi lại onAvailable của thực thể NetworkCallback không được gọi.

Nếu đang sử dụng Handler để tạm dừng yêu cầu mạng, bạn có thể chuyển hướng thêm mạng Wi-Fi khi hết thời gian chờ. Chuyển thẳng người dùng đến hoạt động thêm mạng Wi-Fi bằng ý định sau:

Kotlin

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

Java

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

Để chạy hoạt động cài đặt, ứng dụng của bạn phải có CHANGE_WIFI_STATE quyền.

Những điều cần cân nhắc về giao diện người dùng

Nếu ứng dụng của bạn yêu cầu kết nối với mạng Wi-Fi mới để sử dụng băng thông cao hoạt động, đảm bảo rằng lý do kết nối rõ ràng cho người dùng trước khi bạn mở phần cài đặt Wi-Fi. Chỉ yêu cầu người dùng thêm Wi-Fi mới khi cần phải có mạng băng thông cao. Đừng chặn người dùng truy cập vào các tính năng của ứng dụng không yêu cầu mạng băng thông cao.

Hình 1 là một ứng dụng nhạc. Ứng dụng cho phép người dùng duyệt qua nhạc trên mạng băng thông thấp hơn và chỉ yêu cầu người dùng thêm mạng Wi-Fi mới nếu tải xuống hoặc phát trực tuyến nhạc.

Tải nhạc xuống

Hình 1. Quy trình tải nhạc xuống qua ứng dụng âm nhạc.

Những điều cần cân nhắc về việc sử dụng nguồn điện và dữ liệu

Để giúp duy trì thời lượng pin và giảm thiểu mức sử dụng dữ liệu di động, hãy trì hoãn mọi các nhiệm vụ mạng không thiết yếu, chẳng hạn như báo cáo phân tích hoặc thu thập nhật ký, cho đến khi thiết bị Wear OS thiết lập lại kết nối Bluetooth hoặc Wi-Fi thay vì dùng LTE hoặc kết nối có đo lượng dữ liệu.

Gửi thông báo qua đám mây

Để gửi thông báo, hãy sử dụng trực tiếp Giải pháp gửi thông báo qua đám mây của Firebase (FCM).

Không có API nào để truy cập mạng hoặc FCM dành riêng cho Wear OS. Tham khảo tài liệu về cách kết nối mạnggửi thông báo qua đám mây.

FCM hoạt động tốt với chế độ Nghỉ ngơi và là cách bạn nên dùng để gửi thông báo với một chiếc đồng hồ.

Cung cấp tin nhắn từ FCM bằng cách thu thập mã thông báo đăng ký cho thiết bị khi ứng dụng Wear OS của bạn chạy. Sau đó, thêm mã thông báo vào đích đến khi máy chủ gửi thông báo đến điểm cuối REST của FCM. FCM gửi tin nhắn tới thiết bị được xác định bằng mã thông báo.

Thông báo FCM có định dạng JavaScript Object Notation (JSON) và có thể bao gồm một hoặc cả hai tải trọng sau:

  • Tải trọng thông báo: khi một tải trọng thông báo nhận được xem, dữ liệu sẽ hiển thị trực tiếp với người dùng trong luồng thông báo. Thời gian người dùng nhấn vào thông báo đó, ứng dụng của bạn sẽ khởi chạy.
  • Tải trọng dữ liệu: khi tải trọng có một tập hợp các cặp giá trị hoặc khoá tuỳ chỉnh. Tải trọng dữ liệu được phân phối dưới dạng dữ liệu gửi tới ứng dụng Wear OS của bạn.

Để biết thêm thông tin và ví dụ về tải trọng, hãy xem phần Giới thiệu về thông báo FCM.

Theo mặc định, thông báo sẽ được kết nối từ ứng dụng dành cho điện thoại sang đồng hồ. Nếu bạn có ứng dụng Wear OS độc lập và ứng dụng điện thoại tương ứng, thông báo trùng lặp có thể xảy ra. Ví dụ: một thông báo từ FCM, nhận được từ cả điện thoại và đồng hồ, có thể được hiển thị trên cả hai thiết bị độc lập. Bạn có thể ngăn chặn điều này bằng cách sử dụng API cầu nối.

Sử dụng các dịch vụ nền

Để giúp đảm bảo thực thi chính xác các tác vụ trong nền, các tác vụ trong nền phải tính đến cho chế độ Nghỉ ngơi và Chế độ chờ ứng dụng.

Khi một màn hình tắt hoặc chuyển sang chế độ môi trường xung quanh trong một khoảng thời gian đủ lâu, một tập hợp con có thể xảy ra chế độ Nghỉ và các tác vụ trong nền có thể bị trì hoãn trong một số khoảng thời gian nhất định. Sau đó, khi thiết bị đứng yên trong một thời gian dài, thì chế độ Nghỉ thông thường sẽ diễn ra. Lên lịch cho các yêu cầu bằng API WorkManager để ứng dụng của bạn có thể đăng ký để thực thi mã an toàn với chế độ Nghỉ.

Lên lịch kèm các điều kiện ràng buộc

Bạn có thể sử dụng các quy tắc ràng buộc để định cấu hình các yêu cầu theo cách tiết kiệm pin cuộc sống. Chọn một hoặc nhiều điều kiện ràng buộc sau để đưa vào yêu cầu:

  • Lên lịch cho yêu cầu cần kết nối mạng.

    Chỉ định xem NetworkTypeCONNECTED hay UNMETERED. UNMETERED dùng để chuyển dữ liệu có kích thước lớn, còn CONNECTED dùng để chuyển các dữ liệu nhỏ chuyển cuộc gọi.

  • Lên lịch cho một yêu cầu khi đang sạc pin.

  • Lên lịch cho một yêu cầu khi thiết bị ở trạng thái rảnh. Thông tin này hữu ích cho công việc hoặc đồng bộ hoá ở chế độ nền có mức độ ưu tiên thấp hơn, đặc biệt khi thiết bị đang sạc.

Để biết thêm thông tin, hãy xem Ảnh hưởng của các điều kiện ràng buộc đối với WorkManager hướng dẫn công việc định kỳ.