Architecture de l'application cliente Android Ble

Question

Il s'agit plus d'une question générale que d'une question spécifique.

Fondamentalement, je développe une application Android qui communique avec Ble Périphérique périphérique. Je gère la communication Ble en utilisant la bibliothèque RxAndroidBle. En ce qui concerne le modèle général, j'ai décidé d'essayer Mosby MVI, cependant ce n'est pas si important. Ce que j'ai fait jusqu'à maintenant, c'est que j'ai créé la classe BluetoothManager qui est chargée d'effectuer toutes les opérations sur le périphérique Ble. Cette classe est un singleton (je sais que ce n'est pas recommandé sur Android) et je l'ai délimité en utilisant Dagger, que cela est injecté uniquement pour les interacteurs qui devraient effectuer une certaine communication Ble. Cette classe retourne Observables avec quelques POJO, qui sont transformés en ViewStates en interacteur et que déplacés plus haut vers l'interface utilisateur. Les abonnements sont dans les présentateurs suivant le modèle Mosby MVI.

Fondamentalement, grâce à cela, je traite ce périphérique Ble comme une source de données régulière, comme un service de rénovation ou de toute DB. Et c'était tout à fait bien tant que j'exécutais des opérations atomiques comme l'écriture et la lecture de certaines caractéristiques. Le problème est quand je dois lancer une sorte de synchronisation qui peut prendre beaucoup de temps, devrait être fait en arrière-plan, ne devrait pas être lié à l'interface utilisateur, mais sur certains écrans, l'utilisateur devrait être en mesure de voir les progrès. Ici j'ai commencé à penser à utiliser Android Service et mettre toute la logique Ble Communication là, mais à mon avis, l'utilisation du service Android brise toutes les tentatives de séparation logique et je ne pouvais pas trouver un bon moyen de s'y adapter. La troisième option consistait à avoir un service de synchronisation et de préservation de BluetoothManager pour les opérations atomiques limitées à l'interface utilisateur, mais je pense que c'est compliqué et je serais ravi d'avoir tous les éléments Ble au même endroit.

Je sais que c'est long mais tout va à une question -> quel serait le meilleur modèle à suivre lors de la communication avec l'appareil Ble sur Android pour préserver la séparation des calques et la garder aussi indépendante que possible. Je n'ai pas pu trouver de bons articles sur la façon de gérer cela, s'il y en a, ils sont assez démodés, n'utilisant pas l'approche Rx. Si c'est trop générique, je peux spécifier plus de détails, mais je cherche plutôt un conseil d'architecture plutôt que des extraits de code.

Answer 1

Qu'en est-il quelque chose comme ceci: au lieu de souscrire au présentateur de bluetooth directement, d'introduire une classe BleRepository

Ensuite BleRepository fournit une metod Observable<Foo> (Foo est toutes les données de votre présentateur/interface utilisateur devrait voir) et les opérations à exécuter des choses comme doA(). Quelque chose comme ceci:

interface BleRepository { 


    // Read Data 
    Observable<Foo> getDataObservable(); 

    // Write Data operations 
    Completable doA(); 
    Completable doB(); 

} 

Ainsi, le présentateur souscrit à la place BleRepository à la connexion Bluetooth directement. Donc maintenant, quand vous faites une "opération d'écriture", vous l'exécutez mais vous lisez toujours les nouvelles données de getDataObservable() même si l'opération d'écriture elle-même retourne de nouvelles données, la lecture des données passe toujours par getDataObservable().

Donc, BleRepository est simplement une API publique utilisée par votre présentateur. Le Presenter ne connaît pas la connexion Bluetooth actuelle. Donc, ce que vous pouvez faire ensuite est de déplacer la connexion Bluetooth réelle dans un service android, appelons le BluetoothService. Puis BluetoothService est connecté et chaque fois que la synchronisation s'exécute ou tout ce que votre connexion reçoit/envoie, il renvoie ces données à BleRepository.getDataObservable() qui est souscrite par le service. Vous devez simplement vous assurer que Service et Presenter "partagent" la même instance BleRepository. c'est-à-dire utiliser le poignard pour injecter la même instance ou en faire un singleton ... tout ce qui fonctionne le mieux pour vous. En fonction de votre utilisation, vous pouvez également activer l'abonnement BluetoothService comme démarrer le service android dans RxJavas onSubscribe et arrêter le service sur unsubscribe/onTerminal. Mais il semble que votre utilisation soit légèrement différente de sorte que Bluetooth soit toujours connecté même si Presenter/view a été destoryed, non? Quoi qu'il en soit, l'idée est d'utiliser Service (Services si cela a du sens pour votre problème) mais ils poussent tous les données dans BleRepository qui transmet ensuite les données au Presenter.