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. Không sử dụng Data Layer API (API Lớp dữ liệu) để kết nối ứng dụng Wear OS với mạng. Thay vào đó, hãy làm theo các nguyên tắc và các bước trong hướng dẫn này.

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ó kết nối Bluetooth với điện thoại, lưu lượng truy cập mạng của đồng hồ thường được xử lý qua đ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 của đồ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 dùng đượ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ò các khoảng thời gian thông thườ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 trạng thái mạng.

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 mang lại trải nghiệm tổng thể tốt nhất cho người dùng. Nền tảng này chọn mạng đang hoạt động mặc định bằng cách cân bằng 2 nhu cầu: thời lượng pin lâu và băng thông mạng.

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

Phần này đưa ra hướng dẫn về cách sử dụng lớp ConnectivityManager để đảm bảo ứng dụng của bạn có băng thông mạng cần thiết. Để biết thông tin chung về quyền kiểm soát chi tiết đối với tài nguyên mạng, hãy 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ư truyền tải các tệp có kích thước 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 mạng truyền tải băng thông cao, chẳng hạn như Wi-Fi. Lệnh này được minh hoạ trong ví dụ sau:

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

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

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 huỷ bỏ. Để duy trì thời lượng pin, hãy huỷ lệnh gọi lại như trong ví dụ sau khi bạn không cần mạng Wi-Fi nữa.

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

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

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

Khi yêu cầu 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ạng đó được định cấu hình và trong phạm vi phủ sóng. Nếu không có mạng Wi-Fi đã lưu nào để kết nối, thì phương thức gọi lại onAvailable của thực thể NetworkCallback sẽ không được gọi.

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

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

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

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 để hoạt động với băng thông cao, hãy nhớ cho người dùng biết rõ lý do kết nối trước khi bạn mở chế độ cài đặt Wi-Fi. Chỉ yêu cầu người dùng thêm mạng Wi-Fi mới khi cần dùng mạng băng thông cao. Không được chặn người dùng truy cập vào các tính năng không yêu cầu mạng băng thông cao của ứng dụng.

Hình 1 minh hoạ một ứng dụng nhạc. Ứng dụng cho phép người dùng duyệt 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 họ muốn tải nhạc xuống hoặc phát nhạc trực tuyến.

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

Để 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 tác vụ kết nối không cần thiết, 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ì kết nối 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. Hãy tham khảo tài liệu hiện có về cách kết nối mạng và gửi thông báo qua đám mây.

FCM hoạt động tốt với Chế độ nghỉ và là cách được đề xuất để gửi thông báo đến đồ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 đó, hãy đưa mã thông báo vào dưới dạng đích đến khi máy chủ gửi thông báo đến điểm cuối REST của FCM. FCM gửi thông báo 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 đồng hồ nhận được tải trọng thông báo, dữ liệu sẽ hiển thị trực tiếp cho người dùng trong luồng thông báo. Khi người dùng nhấn vào thông báo đó, ứng dụng của bạn sẽ 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ó một ứng dụng Wear OS độc lập và một ứng dụng điện thoại tương ứng, thì có thể xảy ra các thông báo trùng lặp. Ví dụ: một thông báo từ FCM mà cả điện thoại và đồng hồ đều nhận được, có thể hiển thị độc lập trên cả hai thiết bị. 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

Để đả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 Chế độ nghỉ 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 thời gian đủ lâu, một tập hợp con của chế độ Nghỉ có thể xuất hiện 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. API này cho phép ứng dụng đă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 bảo toàn thời lượng pin. Chọn một hoặc nhiều quy tắc ràng buộc sau để đưa vào yêu cầu của bạn:

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

  Chỉ định xem NetworkType là CONNECTED hay UNMETERED. UNMETERED dùng để chuyển dữ liệu có dung lượng lớn, còn CONNECTED dùng để chuyển các dữ liệu nhỏ.

• 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. Điều này rất hữu ích cho công việc hoặc đồng bộ hoá có mức độ ưu tiên thấp hơn ở chế độ nền, đặc biệt là khi thiết bị đang sạc.

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