Мобильный / настольный — Какая стратегия имеет смысл

#javascript #html #mobile #occasionallyconnected

#javascript #HTML #Мобильный #иногда подключенный

Вопрос:

У моего босса большие мечты.

Он хочет написать приложение, которое работает как на настольных, так и на мобильных устройствах. Кроме того, он хочет, чтобы он время от времени подключался (может запускаться без подключения к Интернету). Приложение будет в значительной степени полагаться на данные из базы данных.

Все, с кем он общается, продолжают навязывать ему HTML5 / JavaScript для решения с возможностью однократного запуска везде (ish).

У меня нет большого опыта работы с такого рода средой — получение данных из базы данных с использованием JavaScript, ORMS для JavaScript и тому подобное. Возможно, я забегаю вперед.

На какие вещи я должен обратить внимание, пытаясь использовать стратегию, чтобы максимально приблизиться к его целям, насколько это возможно? Вот предположения и вопросы, которые у меня есть:

Ожидания / предположения

  1. Я ожидаю, что мне придется использовать одну из «встроенных» или локальных баз данных, которые, похоже, возникли с HTML5 и локальным хранилищем.
  2. Я ожидаю, что мне также придется найти какой-то способ синхронизировать эти данные с данными, которые хранятся где-то на сервере.
  3. Я ожидаю, что синхронизация этих данных должна быть самодельной.
  4. Я хотел бы иметь какой-то ORM, чтобы упростить работу с данными.
  5. Я ожидаю столкнуться со всевозможными странными вещами, связанными с размером локальной базы данных.
  6. Я ожидаю, что мне придется запускать весь код приложения на стороне клиента, поскольку предполагается, что они смогут запускать приложение без подключения к Интернету.

Вопрос

Что я делаю?

Я даже не знаю, с чего начать.

Чтобы превратить это во что-то, что может дать правильные / неправильные ответы, вот то, что было бы полезно знать:

  1. Звучит ли подход HTML5 / JavaScript как хороший вариант (учитывая цели для периодически подключаемых устройств, мобильных устройств и десктопов)?
  2. На какие фреймворки и инструменты мне следует обратить внимание, чтобы упростить разработку приложения?
  3. Он просит слишком многого?

Заранее спасибо за любой совет, который у вас может быть.

По запросу: что делает приложение?Приложение является (более или менее) приложением для составления предложений / цен для настраиваемого продукта. Существует множество продуктов (базовые шкафы, настенные шкафы и т.д.), Множество стандартных настраиваемых опций (дерево, отделка, стиль дверей) и множество (менее стандартных) модификаций к ним (уменьшение глубины, увеличение высоты и т.д.).

В зависимости от выбранных вами стандартных настраиваемых параметров, это изменяет базовую цену каждого продукта. Затем вы можете добавить к ним модификации (которые также имеют свою цену).

Большая часть приложения уже существует (хотя и как приложение WPF без локально сохраненных данных). Он был разработан таким образом, чтобы его можно было продавать различным производителям, которые производят эти настраиваемые элементы (в первую очередь кухонные шкафы и тому подобное). У каждого производителя есть свои собственные правила относительно того, какие породы дерева / отделки / etc Они предлагают и как они определяют базовую цену продуктов (которые также различаются) и как вы можете смешивать / сочетать различные породы дерева / отделки и т.д.

Бла-бла-бла, каждый производитель очень уникален.

Чтобы решить эту проблему, мы создали подход, основанный на формулах, при котором после настройки продуктов / опций / etc вы можете написать несколько формул, чтобы определить не только взаимосвязь между ними, но и их цену.

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

С ним связано довольно много данных, поскольку данные любого производителя будут содержать изображения, описания, примечания, тысячи продуктов / модификаций и множество информации о них (ширина, высота, глубина, количество дверей и т.д.).

Ответ №1:

  1. Звучит ли подход HTML5 / JavaScript как хороший вариант (учитывая цели для периодически подключаемых устройств, мобильных устройств и десктопов)?
    • ДА. JavaScript, вероятно, является способом решения этой проблемы, однако это будет нелегко, если вы еще не разбираетесь в JavaScript. Большие приложения — это зверь в JavaScript, особенно на мобильных устройствах.
    • Я мало знаю о хранилище баз данных на стороне клиента, но для синхронизации серверных и клиентских баз данных почти наверняка потребуются преобразования AJAX и XML или JSON.
    • Учитывайте безопасность и размер данных на клиенте (должен ли клиент иметь доступ ко всем данным, хранящимся на его компьютере?).
  2. На какие фреймворки и инструменты мне следует обратить внимание, чтобы упростить разработку приложения?
    • Я использую jQuery для всех манипуляций с DOM, перехватов событий и AJAX. Плюс я использую много других функций / плагинов для других целей. Я настоятельно рекомендую взглянуть на это.
    • Firebug (<—must have)
  3. Он просит слишком многого?
    • Аспект отсутствия подключения может быть слишком большим. Я бы не удивился, если бы это удвоило время кодирования.
    • Возможно, вы захотите предоставить дополнительную информацию о том, что делает приложение. Если это огромная CMS с тяжелым пользовательским интерфейсом, этот проект может занять годы у одного человека. Однако, если это просто приложение, похожее на «Ужин для ботаников«, оно не должно быть слишком плохим.

Редактировать после обновления вопроса

Я бы сначала протестировал подход к базе данных на стороне клиента на мобильном устройстве. Вы можете столкнуться с непредвиденными ограничениями (скорость передачи данных, размер данных) в средах (браузер Android, мобильное Safari). Когда и что обновлять, когда у вас есть подключение к Интернету для работы, также является важным фактором, определяющим уровень усилий. На эти вопросы можно ответить, протестировав ограничения базы данных на стороне клиента.

Остальное кажется мне довольно простым. Удачи. =)

Комментарии:

1. Спасибо за отзыв! Я знаком с JavaScript (и jQuery), но я никогда не писал особо больших приложений с JavaScript в качестве «основного» языка. Чтобы ответить на один из ваших вопросов, пользовательский интерфейс далеко не так сложен, как работа со всеми (абстрагированными) вычислениями и отношениями между объектами. Существует множество данных для хранения обо всем, и как только вы добавляете один из продуктов в заказ, значительная его часть должна быть продублирована, чтобы он мог стать уникальным для этого конкретного заказа и модифицироваться (по мере того, как пользователь настраивает его).