Какие рамки следует использовать для настольного / сенсорного углового приложения, которое использует USB / аппаратные интерфейсы API? - PullRequest
0 голосов
/ 23 февраля 2019

Мне нужно разработать приложение, которое в значительной степени зависит от 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) Служит ли Ionic Capacitor для этого приложения?С одной стороны, эта инфраструктура, как правило, поддерживает многие платформы, включая Electron, но с другой стороны, ее базовая библиотека не включает USB / последовательный API, и даже если я решу написать общие плагины для аппаратного использования (например, USB)документации по созданию конденсатор-электронных плагинов не так много ...

Я буду рад вашему мнению, потому что в настоящее время я очень растерян и не знаю, что выбрать ...

1 Ответ

0 голосов
/ 23 февраля 2019

Я предложу немного противоречивое мнение.

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

Теперь, если определенная библиотека объявляет себя как фреймворк, RUN AWAY! Фреймворк может и будет бороться слюбой другой фреймворк в вашем приложении.Вы можете иметь не более одной структуры.Вы должны обернуть все ваше приложение вокруг фреймворка.В вашем приложении может быть только 0 или 1 фреймворк.

Поэтому я бы посоветовал, чтобы оптимальное количество фреймворков в вашем приложении равнялось 0.

Используйте библиотеки, но неиспользовать рамки.Если библиотека рекламирует себя как фреймворк, не используйте ее.

Фреймворки очень быстро выходят из моды.Библиотеки обычно не выходят из моды так быстро.

Теперь, конечно, определенная библиотека может в конечном итоге стать необслуживаемой.Таким образом, я планирую «стратегию выхода» для каждой библиотеки.Внимательно посмотрите, какие библиотеки доступны.Посмотрите на их программные интерфейсы.Какую бы библиотеку вы ни выбрали, создайте оболочку вокруг ее интерфейса программирования, предлагая минимально необходимый интерфейс для работы вашего варианта использования.По сути, это самый низкий общий знаменатель из всех доступных библиотек.Если библиотека перестает обслуживаться, вы не переписываете все свое приложение, вы просто переписываете оболочку.

...