2012-01-05 1 views
11

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

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

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

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

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

ответ

13

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

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

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

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

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

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

0

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

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