Какие рамки следует использовать для настольного / сенсорного углового приложения, которое использует USB/ аппаратные интерфейсы API?
Мне нужно разработать приложение, которое в значительной степени зависит от USB/ Serial, WebAudio и, возможно, другого использования аппаратных API.
На данный момент, это приложение предназначено только для планшета Windows 10, поэтому оно также должно поддерживать сенсорные и жесты. Но, конечно, я буду рад отделить логику приложения от API-интерфейсов Windows/UWP, чтобы в будущем можно было распространить приложение на многие другие платформы.
Я решил написать это приложение, используя Typescript & Angular, но на самом деле не определился с комбинацией фреймворка, которую я должен использовать для этой цели:
1) Я должен использовать только чистую комбинацию Electron-Angular-HammerJS? (И, возможно, разверните его как приложение UWP)
2) Должен ли я задействовать Ionic Framework, чтобы лучше поддерживать связь и мобильность? Или эта комбинация Electron с Ionic излишне раздувает мое приложение?
3) Поддерживает ли pure Ionic (как приложение UWP без Electron) возможности Windows USB/Serial? Я нашел пока только плагины USB-Cordova для Android...
4) Ионный конденсатор служит цели этого приложения? С одной стороны, эта инфраструктура, как правило, поддерживает многие платформы, включая Electron, но с другой стороны, ее базовая библиотека не включает USB/ последовательный API, и даже если я решу написать общие плагины для аппаратного использования (например, USB) не много документации по созданию плагинов конденсатор-электрон...
Я буду рад вашему мнению, потому что в настоящее время я очень смущен и не знаю, что выбрать...
1 ответ
Я предложу немного спорное мнение.
Если вам нужно полагаться на многочисленные технологии, вам нужна библиотека для каждой, потому что обычно вы не хотите начинать изобретать велосипед. Например, для поддержки криптографии я бы посмотрел криптографическую библиотеку.
Теперь, если определенная библиотека рекламирует себя как фреймворк, беги! Фреймворк может и будет бороться с любым другим фреймворком в вашем приложении. Вы можете иметь не более одной структуры. Вы должны обернуть все ваше приложение вокруг фреймворка. В вашем приложении может быть только 0 или 1 фреймворк.
В связи с этим мой совет заключается в том, что оптимальное количество фреймворков в вашем приложении равно 0.
Используйте библиотеки, не используйте фреймворки. Если библиотека рекламирует себя как фреймворк, не используйте ее.
Рамки очень быстро выходят из моды. Библиотеки обычно не выходят из моды так быстро.
Теперь, конечно, определенная библиотека может в конечном итоге стать необслуживаемой. Таким образом, я планирую "стратегию выхода" для каждой библиотеки. Внимательно посмотрите, какие библиотеки доступны. Посмотрите на их программные интерфейсы. Какую бы библиотеку вы ни выбрали, создайте оболочку вокруг ее интерфейса программирования, предлагая минимально необходимый интерфейс для работы вашего варианта использования. По сути, это самый низкий общий знаменатель из всех доступных библиотек. Если библиотека перестает обслуживаться, вы не переписываете все свое приложение, вы просто переписываете оболочку.