Proposal for Device Structure (Not Final or Decided)

[mdmohsin7]

• Abstract DeviceBase will define of all the core methods that will have to be implemented by a device. This includes all the methods related to connectivity and read/write operations. The communication to device will be managed by KeepAlivedConnection

  abstract interface class DeviceBase {
    KeepAlivedConnection get connection;
  }
  

• Every unique feature will be defined as a separate mixin (RecordAudio, CaptureImage, StoreAudio, StreamVideo) and will be extended by the device depending on the features it supports

  mixin RecordAudio {
    stream<Uint8List> streamAudioBytes();
  }
  

• Each Device will implement all the methods defined by the DeviceBase and will also extend the functionality mixins (implemented using KASM)

  class DevKit extends DeviceBase with RecordAudio {
    final KeepAlivedConnection _connection;
  
    DevKit(String deviceId) : _connection = KeepAlivedServiceManagement.instance.ble(deviceId);
  
    @override
    KeepAlivedConnection get connection => _connection;
  
    @override
    stream<Uint8List> streamAudioBytes() {
      // Implementation
     _connection.read();
    }
  }
  
  class DevKit2 extends DeviceBase with RecordAudio, StoreAudio {}
  
  class OpenGlass extends DeviceBase with RecordAudio, CaptureImage {}
  

• DeviceProvider will be changed to DeviceManager, whose sole responsibility would be to act as an interface which allows the user to interact with the Device and perform various operations.

[beastoin]

man, good approach, btw let's go with the better approach. Quick question: which (software)design pattern do you are use / or aim to use ?

[josancamon19]

• Understand the data (how many are still on pcm8?) depends on this ticket. To be able to receive firmware version on mixpanel.

[mdmohsin7]

There are two different objects basically holding the same information to an extent. And both of them are dependent on each other (DeviceInfo and BTDeviceStruct)

class DeviceInfo {
  String modelNumber;
  String firmwareRevision;
  String hardwareRevision;
  String manufacturerName;
  DeviceType type;
  }

class BTDeviceStruct {
String name;
String id;
int? rssi;
List<int>? fwver;
DeviceType? type;
}

The DeviceInfo object has methods to read characteristics to get data like the firmware version, hardware name etc., But it depends on BtDeviceStruct to differentiate between device type using the type property. And in many places in the code, both of them are being used together.

Both of them can be combined together to have a unified object for device details.

 class BtDevice {
   String name;
   String id;
   int? rssi;
   DeviceType type;
   BtDeviceInfo? btDeviceInfo;
  }

class BtDeviceInfo {
 String modelNumber;
 String firmwareRevision;
 String hardwareRevision;
 String manufacturerName;
 }

The BtDevice will also includes methods to convert BluetoothDevice (from flutter_blue_plus) to BtDevice etc., apart from the already existing methods, getters and setters. The BtDeviceInfo is basically DeviceInfo but renamed to BtDeviceInfo

[mdmohsin7]

man, good approach, btw let's go with the better approach. Quick question: which (software)design pattern do you are use / or aim to use ?

I was thinking of the Abstract Factory pattern, but you know it better man. Please guide

[beastoin]

@mdmohsin7 man, please read more about Decorator, Strategy, Factory, Composite design pattern and tell me, what is the best fit for(and why)?

Every unique feature will be defined as a separate mixin (RecordAudio, CaptureImage, StoreAudio, StreamVideo) and will be extended by the device depending on the features it supports

In the meantime, you could try to implement it and provide me w/ a PR. Don't worry about the design pattern but after that you should know which one is the best-fit for our case.