tima2015 / modules-library Goto Github PK

Назначение сенсору DataWriter и DataReader по отдельности не имеет смысла, если сенсор использует запись в файл, то и логично, что чтение он так же выполняет из файла. Так же увеличение функционала работы с хранилищем повлечет за собой создание новых интерфейсов, которых необходимо было бы передавать сенсору.

Стоит передавать сенсору не DataWriter и DataReader, а DataProcessor. При этом, DataProcessor может быть интерфейсом наследующим оба интерфейса DataWriter и DataReader, либо интерфейсом содержащим методы read и write (и конечно же набор других методов)

Необходимо создать что-то подобное настройкам для модулей. Сейчас это не срочно, но в будущем будет необходимо

Изначально предполагалось, использование контроллеров только для приёмщиков.
Но сегодня утром меня посетила мысль, что стоило бы использовать их и для сенсоров.

Контроллеры сенсоров позволят сделать управление проведения замеров более гибким. Можно будет проводить не только по таймеру, но и по запросу или же по таймеру + по запросу.

Стоит подумать об архитектуре контроллеров.

Есть желание реализовать подключение различных устройств отдельно от основной библиотеки.
Т.е. чтобы датчики влажности воздуха, температуры, света, моторчики не находились все в NativeModuleLibrary.

Две идеи реализации:

1. Стандартизировать вывод сенсоров, что в свою очередь не особо сложно. И стандартизировать устройства принимающие сигнал, что уже чуть сложнее. И реализовать подключение устройств как считывание файла конфигурации.
   Т.е. есть файл "ДатчикТемпературы.nml" и NativeModuleLibrary читает этот файл и знает как пользоваться этим датчиком. Плюс тут в простоте добавлении новых устройств, но минус в жесткой стандартизации.

2. Реализовывать отдельные устройства как отдельные библиотеки зависящие от интерфейсов и классов NativeModuleLibrary. Например, есть у нас проект использующий NativeModuleLibrary, нам нужно использовать датчик температуры, и таким образом, чтобы его использовать нужно подключить к проекту "ДатчикТемпературы.jar". Здесь плюс в том, что можно спокойно реализовывать и обновлять все устройства по отдельности и с учетом всех особенностей устройств, но минус в том, что это библиотеки (хотя минус ли это?).

В любом случае, это лишь желание-предложение, его вполне можно и отклонить. Я не думаю что библиотека разбухнет даже от трёх сотен модулей под капотом.

Некоторым классам может пригодиться оповещение о произведении замера сенсором

при тестировании другой библиотеки, зависящей от этой был обнаружен баг в 62 строчке кода
if (!directory.exists() || directory.isDirectory()){
тут мы проверяем является ли файл директорией и существует ли он вообще. Если нет, то мы проваливаемся в блок и создаем эту папку. Но в данном куске кода условие звучит так "Если файл не существует или это директория" =)

Исправленный код должен принять вид
if (!directory.exists() || !directory.isDirectory()){