Серверная архитектура для мобильных веб-приложений - PullRequest
11 голосов
/ 05 января 2012

В большинстве настольных веб-приложений, над которыми я когда-либо работал, вам нужна серверная веб-инфраструктура. Серверная веб-инфраструктура (Struts, Spring MVC и т. Д.) Имеет своего рода контроллер для обработки запросов, а затем шаблонизатор (Velocity, JSP и т. Д.) Для генерации динамического содержимого.

Сейчас я начинаю работать над мобильными веб-приложениями, и все обсуждения, которые я вижу, вращаются вокруг выбора инфраструктуры пользовательского интерфейса (jQuery Mobile, jQTouch, Sencha Touch и т. Д.), Но я не вижу обсуждения того, что происходит на на стороне сервера фактически обрабатывать HTTP-запросы или генерировать HTML, CSS и JavaScript.

Означает ли это, что большинство мобильных веб-приложений не используют серверную веб-инфраструктуру ... означает, что сервер обслуживает статический контент, большая часть интерактивного поведения кодируется в JavaScript, а единственным серверным кодом является REST сервисы, которые загружает клиент JavaScript?

Если бы я хотел использовать серверную веб-инфраструктуру, это было бы плохой идеей? С какими проблемами я столкнусь? У кого-нибудь есть рекомендации относительно веб-фреймворка, который был бы продуктивной платформой, а не «мешал» мобильным UI-фреймворкам, таким как jQuery mobile?

ПРИМЕЧАНИЕ. Разработчики, с которыми я работаю, в основном работают на корпоративных Java-фонах, однако я бы не стал ограничивать их только веб-фреймворками на основе Java. Существуют и другие фреймворки, имеющие корни в Java, которые можно рассмотреть (Grails, Lift и т. Д.).

Ответы [ 2 ]

13 голосов
/ 05 января 2012

Хороший вопрос, и я отвечу на него так.Текущая тенденция заключается в том, чтобы встроить много интерактивности в интерфейс.На это есть несколько причин.Некоторые делают это, потому что это новая вещь, другие делают это, потому что они пытаются повторить опыт рабочего стола.В конце концов, у любого веб-проекта есть только одна цель - создать лучший и наиболее устойчивый пользовательский интерфейс.

При этом, будут технологии на стороне сервера, которых следует избегать , и это будет любой из тех, что сгенерируют интерфейс для вас, но не используют jQuery.Более 45% всех веб-сайтов сегодня используют jQuery, и если вы выберете что-то другое, вы сразу же вступите в противоречие с преобладающими мобильными платформами.(GWT, IceFaces, я смотрю на тебя).

Вероятно, самый безопасный и гибкий способ - использовать реализацию на основе Spring или Prime Faces .Spring Mobile стоит посмотреть.Prime Faces на самом деле реализует jQuery Mobile и может работать с темами с помощью Theme Roller.

В общем, действительно не имеет значения, какой базовый фреймворк (если таковой имеется), который вы используете, пока вы продвигаете хорошую разметку.Браузер не заботится, и единственное, что заботит пользователя - это хороший опытИтак, выберите то, что порадует ваших разработчиков для бэкэнда, если это не мешает.

Что касается интерфейсных сред, то их популярность растет, поскольку они стремятся стандартизировать некоторые из лучших практик в мобильных устройствах.Существует множество сравнений jQuery Mobile и Sencha с jQTouch.Я оставлю вас, чтобы понять, что лучше для вашего проекта, но, безусловно, будет использовать jQuery Mobile или Sencha, потому что сообщество поддержки вокруг них огромно, и вы вряд ли будете похожи на многие потрепанные, доморощенные мобильные сайты, которыепытался сделать это с нуля, когда у них не было опыта, чтобы осуществить это.Это просто грустно.Моя личная рекомендация - jQuery Mobile, потому что он охватывает такой широкий спектр устройств и (при условии, что вы придерживаетесь стандартной постраничной модели) будет изящно деградировать даже для самых дурацких функциональных телефонов и при этом будет функционировать, но на смартфонах будет выглядеть потрясающе.

На ваш вопрос просто используйте дизайн RESTful с JavaScript, загружающим все и управляющим состоянием.Многие делают это, и это, безусловно, быстрый опыт, но вы сразу же ограничитесь тем, кто может его использовать, людям, которые в мобильных браузерах поддерживают хороший JavaScript.Вы будете смотреть только на поддержку iOS, Android 2.2+, BlackBerry 6+ и Windows Phone 7+.Все остальные, вероятно, будут иметь значительные трудности при просмотре вашего сайта.Тщательно продумайте свою аудиторию, прежде чем переходить к такой реализации.Если ваш сайт не будет работать без JavaScript, а ваши основные клиенты - в корпоративном мире ... что происходит, когда последняя конференция Black Hat демонстрирует слабость в телефонах компании и из-за консервативного снижения рисков (паранойя), они настаивают на политике безопасности:у всех телефонов, которые отключают JavaScript.Такого рода вещи случаются постоянно.Итак, рассмотрим вашу аудиторию.

0 голосов
/ 05 апреля 2012

Посмотрите на ItsNat , ItsNat предлагает вам подумать о клиентском JavaScript, но кодировать на Java и выполнять на сервере, генерируя тот же код JS для клиента.

Разница с GWT заключается в том, что DOM-код Java W3C выполняется на сервере, а JS генерируется автоматически, в то время как GWT выполняется на клиенте, данные сервера должны передаваться клиенту.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...