Blog

Tiếp tục trong chuỗi bài liên quan đến Bluetooth Classic trong Android. Mình xin chia sẻ phần liên quan đến Tìm kiếm (Scanning – Discovery) và Enable discoverability thiết bị.

1. Tìm kiếm (Scanning – Discovery) thiết bị Bluetooth

   Để bắt đầu tìm kiếm (Scanning) thiết bị, hàm startDiscovery() thông qua đối tượng BluetoothAdapter được gọi. Quá trình này bất đồng bộ (asynchronous) và trả về một giá trị boolean cho biết quá trình discovery đã bắt đầu thành công hay chưa. Theo như mình tìm hiểu thì quá trình scan thường được truy vấn trong khoảng 12 giây, sau đó hiển thị output lên màn hình hoặc nơi hiển thị kết quả.

   Để nhận thông tin về từng thiết bị được quét (tìm thấy) thành công, ứng dụng của bạn phải register một BroadcastReceiver với ACTION_FOUND intent. Hệ thống sẽ broadcasts intent này cho từng thiết bị. Trong intent này sẽ chứa công tin về device thông qua các extra fields như EXTRA_DEVICE và EXTRA_CLASS.

   Cụ thể:

class LegacyPairingFlowBluetoothDeviceReceiver(
    private val mListener: Listener
) : BroadcastReceiver() {

    companion object {
        private const val RESTART_DISCOVERY_DELAY = 5_000L // ms
    }

    private val handler = Handler(Looper.getMainLooper())
    private val restartDiscovery = Runnable {
        if (!cancelScan) {
            BluetoothAdapter.getDefaultAdapter()?.startDiscovery()
        }
    }

    var cancelScan: Boolean = false
        set(value) {
            field = value
            if (value) {
                handler.removeCallbacks(restartDiscovery)
            }
        }

    override fun onReceive(context: Context, intent: Intent) {
        val state = intent.getIntExtra(BluetoothAdapter.EXTRA_STATE, BluetoothAdapter.ERROR)
        if (state == BluetoothAdapter.STATE_ON && !cancelScan) {
            BluetoothAdapter.getDefaultAdapter()?.startDiscovery()
        }

        val action = intent.action
        if (BluetoothDevice.ACTION_FOUND == action) {
            val device = intent.getParcelableExtra(BluetoothDevice.EXTRA_DEVICE) as? BluetoothDevice
            if (device != null) {
                mListener.onFoundBluetoothDevice(device)
            }
        } else if (BluetoothAdapter.ACTION_DISCOVERY_STARTED == action) {
            mListener.onDiscoveryStarted()
        } else if (BluetoothAdapter.ACTION_DISCOVERY_FINISHED == action) {
            if (!cancelScan) {
                handler.postDelayed(restartDiscovery, RESTART_DISCOVERY_DELAY)
            }
            mListener.onDiscoveryFinished()
        }

        if (BluetoothAdapter.STATE_ON == state) {
            mListener.onBluetoothStateOn()
        }
    }

    interface Listener {
        fun onFoundBluetoothDevice(device: BluetoothDevice)

        fun onDiscoveryStarted()

        fun onDiscoveryFinished()

        fun onBluetoothStateOn() {}
    }
}

Để bắt đầu kết nối với thiết bị Bluetooth, bạn gọi getAddress() của BluetoothDevice để truy xuất địa chỉ MAC được liên kết.

Note: Thực hiện tìm kiếm (gọi discovery) thiết bị tiêu tốn rất nhiều tài nguyên. Sau khi bạn đã tìm thấy một thiết bị để kết nối, hãy chắc chắn rằng bạn dừng việc tìm kiếm lại bằng function cancelDiscovery() trước khi thử connect với thiết bị đó. Ngoài ra, bạn không nên thực hiện tìm kiếm (gọi discovery) khi được kết nối với thiết bị vì quá trình tìm kiếm làm giảm đáng kể băng thông khả dụng cho bất kỳ kết nối hiện có.

2. Enable discoverability

   Nếu bạn chỉ cần kết nối từ ứng dụng của bạn với một thiết bị Bluetooth, transfer data với chúng thì bạn không cần phải Enable discoverability của thiết bị. Enable discoverability chỉ cần thiết khi bạn muốn ứng dụng của mình là một host a server socket chấp nhận các kết nối đến, vì các thiết bị Bluetooth phải có thể khám phá các thiết bị khác trước khi khởi động kết nối với các thiết bị khác.

   Để thực hiện điều đó, chúng ta gọi hàm startActivityForResult(Intent, int) với action Intent tương ứng là ACTION_REQUEST_DISCOVERABLE. Theo mặc định, thiết bị có thể được discover trong hai phút. Bạn có thể xác định thời lượng khác, tối đa một giờ, bằng cách thêm EXTRA_DISCOVERABLE_DURATION extra cho Intent đó.

    val requestCode = 1;
    val discoverableIntent: Intent = Intent(BluetoothAdapter.ACTION_REQUEST_DISCOVERABLE).apply {
       putExtra(BluetoothAdapter.EXTRA_DISCOVERABLE_DURATION, 500)
    }
    startActivityForResult(discoverableIntent, requestCode)

Note: Nếu Bluetooth chưa được bật trên thiết bị, thì việc Enable discoverability sẽ tự động bật Bluetooth.

Bài tiếp theo mình sẽ trình bày về việc Connect và Transfer giữa ứng dụng và thiết bị Bluetooth. Hẹn gặp lại các bạn ở bài viết sắp tới.

Tiếp tục chuỗi bài liên quan đến việc tìm hiểu kết nói giữa ứng dụng và thiết bị thông qua Bluetooth. Các bạn có thể tìm hiểu về BLE mình đã chia sẻ tại đây, giống như BLE, hôm nay mình cũng xin phép overview qua và chia sẻ kiến thức mình biết được liên quan đến Bluetooth Classic.

Chuỗi bài chia sẻ này mình xin chia sẻ một số phần chính

• Setup Bluetooth Classic trong Android
• Lấy danh sách các thiết bị ghép nối
• Tìm kiếm (Scanning) thiết bị
• Connect và Transfer giữa Ứng dụng và Thiết bị thông qua Bluetooth Classic

1. Setup Bluetooth Classic trong Android

Để sử dụng các tính năng Bluetooth trong ứng dụng của mình, bạn phải khai báo vs xin một số quyền để được sử dụng. Tại file AndroidManifest chúng ta yêu cầu các quyền.

<manifest>
    <!-- Request legacy Bluetooth permissions on older devices. -->
    <uses-permission android:name="android.permission.BLUETOOTH"
                     android:maxSdkVersion="30" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN"
                     android:maxSdkVersion="30" />

    <!-- Needed only if your app looks for Bluetooth devices.
         If your app doesn't use Bluetooth scan results to derive physical
         location information, you can strongly assert that your app
         doesn't derive physical location. -->
    <uses-permission android:name="android.permission.BLUETOOTH_SCAN" />

    <!-- Needed only if your app makes the device discoverable to Bluetooth
         devices. -->
    <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE" />

    <!-- Needed only if your app communicates with already-paired Bluetooth
         devices. -->
    <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

    <!-- Needed only if your app uses Bluetooth scan results to derive physical location. -->
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    ...
</manifest>

Như các bạn thấy ở trên:

• BLUETOOTH permission cho phép ứng dụng kết nối, ngắt kết nối, và truyền dữ liệu với các thiết bị Bluetooth khác.
• BLUETOOTH_ADMIN permission cho phép ứng dụng phát hiện ra các thiết bị Bluetooth mới và thay đổi cài đặt Bluetooth của thiết bị.
• BLUETOOTH_SCAN permission phục vụ cho việc Scan thiết bị cho cả Bluetooth Classic và BLE
• BLUETOOTH_CONNECT cho phép ứng dụng communicates với thiết bị đã được Pair sẵn trong System trước đó
• BLUETOOTH_ADVERTISE cho phép các thiết bị hiện tại có thể discoverable với các thiết bị khác

Đối với Android 12 or higher, các bạn chú ý them:

• Đối với các khai báo quyền liên quan đến Bluetooth cũ, hãy đặt android:maxSdkVersion thành 30. Bước compatibility ứng dụng này giúp hệ thống chỉ cấp cho ứng dụng của bạn các quyền Bluetooth mà ứng dụng đó cần khi cài đặt trên các thiết bị chạy Android 12 trở lên.
• ACCESS_FINE_LOCATION quyền này chỉ cần thiết nếu ứng dụng của bạn sử dụng kết quả quét Bluetooth để xác định vị trí thực tế. Về quyền này, đặc biệt là các quyền liên quan đến Location, mình sẽ trao đổi rõ hơn ở bài viết tiếp theo liên quan đến Companion Device Manager.

Note: Trong các quyền trên thì BLUETOOTH_SCAN, BLUETOOTH_CONNECT, BLUETOOTH_ADVERTISE là các runtime permissions. Các bạn chú ý việc xử lý code về việc nhận approve từ người dùng.

2. Lấy danh sách các thiết bị ghép nối

Cụ thể mình lấy các thiết bị Bluetooth đã được ghép nối và hiển thị chúng trong một danh sách. Tại các trạng thái mà thiết bị Bluetooth hiển thị trong ứng dụng của mình sẽ là:

• unknown
• paired (đã ghép nối).
• connected (đang kết nối).

Có một lưu ý là chúng ta cần phải phân biệt giữa paired và connected của một thiết bị Bluetooth. Thiết bị đã paired là chỉ biết về sự tồn tại của nhau và sẵn sàng kết nối thông qua một mã code. Mã code được sử dụng để xác thực và dẫn đến một kết nối. Đầu tiên chúng ta gọi lớp BluetoothAdapter để giao tiếp với Bluetooth. Tạo một object của cuộc gọi bằng cách gọi statics method getDefaultAdapter().

fun getBluetoothAdapter(context: Context?): BluetoothAdapter? {
    val manager =
        if (context == null) null else context.getSystemService(Context.BLUETOOTH_SERVICE) as BluetoothManager
    return if (manager == null) {
        BluetoothAdapter.getDefaultAdapter()
    } else {
        manager.adapter
    }
}

Sau khi chúng ta get danh sách Devices đã từng Paired.

Set<BluetoothDevice> pairedDevices = getBluetoothAdapter(context).getBondedDevices();

Nếu trong trường hợp ứng dụng chưa bật Bluetooth, để cho phép bật Bluetooth của thiết bị, chúng ta gọi intent với hằng số Bluetooth ACTION_REQUEST_ENABLE.

Intent turnOn = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
startActivityForResult(turnOn, 0);

Ngoài ra Android còn cung cấp các hằng số khác, các bạn có thể xem phía dưới đây:

• ACTION_REQUEST_DISCOVERABLE: Hằng số này sử dụng cho việc bật discovering của bluetooth
• ACTION_STATE_CHANGED: Hằng số này sẽ thông báo rằng trạng thái Bluetooth sẽ được thay đổi
• ACTION_FOUND: Hằng số này dùng để nhận thông tin về mỗi device mà được discover

Bài tiếp theo mình sẽ trình bày về việc tìm kiếm Bluetooth Devices, cũng như Connect và Transfer giữa ứng dụng và thiết bị.

Hôm nay mình xin chia sẻ một chút kiến thức của mình liên quan đến Dependency Injection.

Đầu tiên mình xin phép nói sơ qua về khái niệm của Dependency Injection. Vậy Dependency Injection là gì ? Cụ thể dựa vào DI trong Principle, Dependency Injection cơ bản là cung cấp đối tượng phụ thuộc như 1 tham số. Ứng dụng phụ thuộc này khi các class đã được xây dựng hoặc chuyển chúng (các đối tượng phụ thuộc) vào các function cần mỗi phụ thuộc. Cách triển khai chúng theo lý thuyết là lấy đấy tượng phụ thuộc và cung cấp chúng vào class thay vì tạo ra thể hiện của chúng trực tiếp trong class bị phụ thuộc.

Ưu điểm:

• Khả năng tái sử dụng lại các class và tách rời các phụ thuộc (dependencies): Dễ dàng hơn trong việc thay đổi một dependency. Việc tái sử dụng code được cải thiện do Inversion of Control, và các class không còn kiểm soát việc tạo ra các dependencies như thế nào, thay vào đó nó có thể làm việc với bất kỳ cấu hình nào.
• Dễ tái cấu trúc: Các dependencies trở thành những phần có thể kiểm tra như API. Hoàn toàn có thể kiểm tra lúc tạo đối tượng, lúc biên dịch chứ không bị ẩn đi.
• Dễ dàng cho việc Testing: Các class không quản lý các dependencies của nó. Vì thế khi testing chúng ta có thể truyền các dependency khác nhau và xử lý được nhiều test case

Tiếp đến mình sẽ nói phần chính của bài này liên quan đến Annotation in Android Hilt (Một framework trong Android support việc triển khai Dependency Injection trong Project).

Chúng ta có 3 annotation thường dùng để inject các object trong Hilt:

• @Inject: annotation dùng ở constructor của class
• @Provides: annotation dùng ở Module
• @Binds: một annotation khác cũng dùng ở Module

Vậy khi nào dùng chúng, đặc biệt là giữa @Provide và @Binds?

1. Inject

Chúng ta dùng @Inject annotation ở tất cả các constructor mà mình cần inject đối tượng (Object). Ví dụ như ViewModel, Repository, UseCase, DataSource, thậm trí là Android classes (ex. Activity, Fragment, …)

class ConnectRepositoryImpl @Inject constructor(
    private val connectManager: ConnectManager
) : ConnectRepository {

   fun doSomething() {}
}

    class ConnectUseCaseImpl @Inject constructor(
        private val connectRepository: ConnectRepository,
    ) : ConnectUseCase {

    fun doSomething() {
        // Using connectRepository 
    }
 }

Qua ví dụ trên sau khi khởi tạo class ConnectRepositoryImpl với @Inject constructor. Chúng ta có thể dễ dàng sử dụng ConnectRepository ở các class khác (như ViewModel, Android class, UseCase) bằng cách inject chúng vào nơi cần chúng. Tuy nhiên thì chúng ta lại chỉ có thể sử dụng annotation này để annotate constructor của những class mà mình tự define.

2. Provide

Vậy thì để khắc phục hạn chế chỉ có thể sử dụng annotation này để annotate constructor của những class mà mình tự define của @Inject, inject object của những class mà mình không define (Ví dụ như Retrofit, OkHttpClient hoặc Room database), chúng ta cùng đến với @Provides. Trước tiên, chúng ta cần tạo một @Module để chứa các dependency với annotation @Provides.

    @InstallIn(SingletonComponent::class)
    @Module
    class DatabaseModule {

        @Provides
        @Singleton
        fun provideGSDatabase(@ApplicationContext context: Context): GSDatabase {
            return Room.databaseBuilder(context, GSDatabase::class.java, GS_DATABASE_NAME)
                .fallbackToDestructiveMigration()
                .build()
        }

        @Provides
        fun provideSpeakerDao(gsDatabase: GSDatabase): SpeakerDao {
            return gsDatabase.speakerDao()
        }
    }

Như đoạn code ở trên, mình khởi tạo đối tượng RomDatabase và một đối tượng Dao của chúng,  đó là khởi tạo object không phải code của chúng ta define, hơn nữa trong trường hợp này còn khởi tạo theo kiểu Builder pattern, nên chúng ta không thể dùng @Inject annotation mà bắt buộc phải dùng @Provides. Bây giờ, chúng ta đã có thể inject object của interface GSDatabase và SpeakerDao ở bất cứ đâu.

3. Bind

Đối với interface, chúng ta không thể dùng annotation @Inject, vì nó không có constructor function. Tuy nhiên, nếu bạn có một interface mà chỉ có duy nhất một implementation (một class implement interface đó), thì bạn có thể dùng @Binds để inject interface đó. Việc inject interface thay vì class là trong những cách triển khai được Recommend sử dụng bởi vì nó tuân theo nguyên tắc Dependence Inversion của SOLID, từ đó dễ dàng cho việc testing và maintain mai này.

interface ConnectRepository {
    fun doSomething()
}

class ConnectRepositoryImpl @Inject constructor(
    private val connectManager: ConnectManager
) : ConnectRepository {

   fun doSomething() {}
}

@Module
@InstallIn(SingletonComponent::class)
abstract class ConnectDeviceModule {
    @Binds
    @Singleton
    abstract fun provideConnectRepository(
        connectRepository: ConnectRepositoryImpl
    ): ConnectRepository
}

class ConnectUseCaseImpl @Inject constructor(
    private val connectRepository: ConnectRepository,
) : ConnectUseCase {

  fun doSomething() {
      // Using connectRepository
  }
}

Cụ thể trong ví dụ trên, mình khai báo 1 interface ConnectRepository thể hiện cho đối tượng ConnectRepositoryImpl. Từ đó khi sử dụng ConnectRepositoryImpl chúng ta sẽ sử dụng và gọi nó thông qua ConnectRepository.

Ưu điểm của việc dùng @Binds thay cho @Provides là nó giúp giảm lượng code được generate, như là Module Factory class. Từ đó tăng thời gian build và tăng kích thước file .apk và .aab của Project.

Trên đây là chia sẻ của mình về 1 số Annotation của Hilt Android. Mong sẽ giúp ích được ít nhiều mọi người. Hẹn mọi người ở bài viết sắp tới

Hôm nay mình xin chia sẻ một chút kiến thức của mình liên quan đến Dependency Injection.

Đầu tiên mình xin phép nói sơ qua về khái niệm của Dependency Injection. Vậy Dependency Injection là gì ? Cụ thể dựa vào DI trong Principle, Dependency Injection cơ bản là cung cấp đối tượng phụ thuộc như 1 tham số. Ứng dụng phụ thuộc này khi các class đã được xây dựng hoặc chuyển chúng (các đối tượng phụ thuộc) vào các function cần mỗi phụ thuộc. Cách triển khai chúng theo lý thuyết là lấy đấy tượng phụ thuộc và cung cấp chúng vào class thay vì tạo ra thể hiện của chúng trực tiếp trong class bị phụ thuộc.

Ưu điểm:

• Khả năng tái sử dụng lại các class và tách rời các phụ thuộc (dependencies): Dễ dàng hơn trong việc thay đổi một dependency. Việc tái sử dụng code được cải thiện do Inversion of Control, và các class không còn kiểm soát việc tạo ra các dependencies như thế nào, thay vào đó nó có thể làm việc với bất kỳ cấu hình nào.
• Dễ tái cấu trúc: Các dependencies trở thành những phần có thể kiểm tra như API. Hoàn toàn có thể kiểm tra lúc tạo đối tượng, lúc biên dịch chứ không bị ẩn đi.
• Dễ dàng cho việc Testing: Các class không quản lý các dependencies của nó. Vì thế khi testing chúng ta có thể truyền các dependency khác nhau và xử lý được nhiều test case

Tiếp đến mình sẽ nói phần chính của bài này liên quan đến Annotation in Android Hilt (Một framework trong Android support việc triển khai Dependency Injection trong Project).

Chúng ta có 3 annotation thường dùng để inject các object trong Hilt:

• @Inject: annotation dùng ở constructor của class
• @Provides: annotation dùng ở Module
• @Binds: một annotation khác cũng dùng ở Module

Vậy khi nào dùng chúng, đặc biệt là giữa @Provide và @Binds?

1. Inject

Chúng ta dùng @Inject annotation ở tất cả các constructor mà mình cần inject đối tượng (Object). Ví dụ như ViewModel, Repository, UseCase, DataSource, thậm trí là Android classes (ex. Activity, Fragment, …)

<pre> class ConnectRepositoryImpl @Inject constructor( private val connectManager: ConnectManager ) : ConnectRepository {

fun doSomething() {} } </pre>

<pre> class ConnectUseCaseImpl @Inject constructor( private val connectRepository: ConnectRepository, ) : ConnectUseCase {

fun doSomething() { // Using connectRepository } } </pre>

Qua ví dụ trên sau khi khởi tạo class ConnectRepositoryImpl với @Inject constructor. Chúng ta có thể dễ dàng sử dụng ConnectRepository ở các class khác (như ViewModel, Android class, UseCase) bằng cách inject chúng vào nơi cần chúng. Tuy nhiên thì chúng ta lại chỉ có thể sử dụng annotation này để annotate constructor của những class mà mình tự define.

2. Provide

Vậy thì để khắc phục hạn chế chỉ có thể sử dụng annotation này để annotate constructor của những class mà mình tự define của @Inject, inject object của những class mà mình không define (Ví dụ như Retrofit, OkHttpClient hoặc Room database), chúng ta cùng đến với @Provides. Trước tiên, chúng ta cần tạo một @Module để chứa các dependency với annotation @Provides.

<pre> @InstallIn(SingletonComponent::class) @Module class DatabaseModule {

@Provides
@Singleton
fun provideGSDatabase(@ApplicationContext context: Context): GSDatabase {
    return Room.databaseBuilder(context, GSDatabase::class.java, GS_DATABASE_NAME)
        .fallbackToDestructiveMigration()
        .build()
}

@Provides
fun provideSpeakerDao(gsDatabase: GSDatabase): SpeakerDao {
    return gsDatabase.speakerDao()
}

} </pre>

Như đoạn code ở trên, mình khởi tạo đối tượng RomDatabase và một đối tượng Dao của chúng,  đó là khởi tạo object không phải code của chúng ta define, hơn nữa trong trường hợp này còn khởi tạo theo kiểu Builder pattern, nên chúng ta không thể dùng @Inject annotation mà bắt buộc phải dùng @Provides. Bây giờ, chúng ta đã có thể inject object của interface GSDatabase và SpeakerDao ở bất cứ đâu.

3. Bind

Đối với interface, chúng ta không thể dùng annotation @Inject, vì nó không có constructor function. Tuy nhiên, nếu bạn có một interface mà chỉ có duy nhất một implementation (một class implement interface đó), thì bạn có thể dùng @Binds để inject interface đó. Việc inject interface thay vì class là trong những cách triển khai được Recommend sử dụng bởi vì nó tuân theo nguyên tắc Dependence Inversion của SOLID, từ đó dễ dàng cho việc testing và maintain mai này.

<pre> interface ConnectRepository { fun doSomething() } </pre>

<pre> class ConnectRepositoryImpl @Inject constructor( private val connectManager: ConnectManager ) : ConnectRepository {

fun doSomething() {} } </pre>

<pre> @Module @InstallIn(SingletonComponent::class) abstract class ConnectDeviceModule { @Binds @Singleton abstract fun provideConnectRepository( connectRepository: ConnectRepositoryImpl ): ConnectRepository } </pre>

<pre> class ConnectUseCaseImpl @Inject constructor( private val connectRepository: ConnectRepository, ) : ConnectUseCase {

fun doSomething() { // Using connectRepository } } </pre>

Cụ thể trong ví dụ trên, mình khai báo 1 interface ConnectRepository thể hiện cho đối tượng ConnectRepositoryImpl. Từ đó khi sử dụng ConnectRepositoryImpl chúng ta sẽ sử dụng và gọi nó thông qua ConnectRepository.

Ưu điểm của việc dùng @Binds thay cho @Provides là nó giúp giảm lượng code được generate, như là Module Factory class. Từ đó tăng thời gian build và tăng kích thước file .apk và .aab của Project.

Trên đây là chia sẻ của mình về 1 số Annotation của Hilt Android. Mong sẽ giúp ích được ít nhiều mọi người. Hẹn mọi người ở bài viết sắp tới

Chào các bạn, tiếp tục loạt bài vè chủ đề BLE, hôm nay mình tiếp tục trình bày về Discovery Service và Transfer BLE Data

1. Discovery Service Sau khi kết nối thành công, để phục vụ việc Transfer dữ liệu, điều đầu tiên cần làm khi bạn kết nối với GATT Server trên thiết bị BLE là thực hiện Discovery Service. Điều này cung cấp thông tin về các Available Service trên remote device cũng như các service characteristics và thông tin của chúng. Cụ thể là

   

   

   

   

   3 thông số trên thì device sẽ có một mã code riêng phục vụ việc Discovery và mở cổng transfer dữ liệu giữa App và thiết bị.

2. Turning notifications on and off

   Để thực hiện việc Read và Write dữ liệu giữa ứng dụng và Device BLE chúng ta cần Turning notifications sau khi Discovery Service thành công. Cụ thể là việc Call setCharacteristicNotification(). Điều này các bạn hiểu đơn giản là sẽ báo cho ngăn xếp Bluetooth về cái mong đợi nhận thông báo cho characteristic cụ thể của Device BLE đó. Nếu không có điều này hoàn bạn bạn không thể nhận được dữ liệu response từ Device BLE cho dù bạn có thể gọi thành công writeCharacteristic.

   Cụ thể về việc gọi Turning notifications. Chú ý về việc thực hiện sau khi Discovery Service thành công. Bạn có thể làm điểu này bằng Callback. Nhưng trong ví dụ của mình thì mình sử dụng 1 SingleSubject của Rx để thực hiện nó. 

   

   

    

3. Read and Write dữ liệu

   Đầu tiên các bạn clear rằng, kiểu dữ liệu giao tiếp giữa ứng dụng và Device BLE là ByteArray. Và để nhận biết việc nhận gửi đó giữa ứng dụng và Device BLE nào thì nó sẽ thông qua outputCharacteristic và inputCharacteristic tương ứng với việc Write và Read. 2 thông số outputCharacteristic và inputCharacteristic lấy được từ đối tượng BluetoothGattService khi sau khi chúng ta Discovery Service.

   Data ByteArray gửi lên được define cụ thể cho từng Device BLE cụ thể. Đa phần sẽ thuộc về team Hardware và Firmware cung cấp file command request và response tương ứng của thiết bị đó.

   Có 1 điểm lưu ý là trong quá trình trao đổi dữ liệu giữa ứng dụng và Device BLE, chúng ta sẽ gửi nhận liên tục. Hoàn toàn bài toán của việc gửi dữ liệu, Device BLE chưa trả về và mình lại đã gửi tiếp dữ liệu 1 lần nữa. Để giải quyết bài toán này, các bạn nên quản lý việc gửi nhận dữ liệu (hay ở đây mình hay gọi là command request ) trong 1 Queue tương ứng. Điều đó sẽ giúp các bạn quản lý dễ dàng cho dù bạn muốn việc thực hiện tuần tự, hay loại nào khác cũng sẽ dễ dàng hơn.

   

• Đây là quá trình gửi dữ liệu từ ứng dụng sang Device BLE. Thông qua việc gọi writeCharacteristic qua đối tượng bluetoothGatt.

  

• Sau khi gọi thành công. System sẽ trả về hàm callback tương ứng, thông về status đã gửi thành công hay thất bại đến Device BLE.

  

• Tiếp đến là quá trình nhận dữ liệu sau khi request gửi đến Device BLE thành công. Thiết bị sẽ trả về response tương ứng tại 1 trong 2 functions.

   Sau khi nhận được dự liệu kiểu ByteArray. Chúng ta sẽ thực hiện việc xử lý dữ liệu tương ứng.

Lưu ý:

Vì BLE là asynchronous nên là có nhiều Thread được tạo ra và thực thi. Cụ thể ở đây là  khi nhận callbacks on BluetoothGattCallback, thì các dòng code này sẽ thực thực hiện **Binder** threads. Các hàm mình muốn nói đến ở đây ví dụ như các hàm **onCharacteristicWrite()**, **onCharacteristicRead()**, **onCharacteristicChanged()**, … đây là 1 số functions quan trọng trong việc xử lý và thực thi gửi nhận dữ liệu. 

Vậy tại sao nên tránh xử lý trên Binder threads? Khi bạn nhận được nội dung nào đó trên **Binder** Thread, Android sẽ không gửi bất kỳ lệnh gọi lại mới nào cho đến khi code của bạn hoàn thành trên **Binder** Thread. Vì vậy, nói chung, bạn nên tránh thực hiện nhiều thao tác trên các luồng **Binder** vì bạn đang chặn các cuộc gọi lại mới khi bạn đang sử dụng nó.

Đây là những chia sẻ mang tính overview của mình về BLE của Android. Mong ít nhiều có thể chia sẻ cho mọi người.