-
В качестве примера, исходный код нового приложения для Android: github.com
Навигация и ActionBar приложения выполнены с использованием Android SDK. А лента сообщений отображается в WebView. Для того, чтобы не загружать ничего лишнего, а только текст сообщений, приложение запрашивает страницы с измененным User-Agent (строка 88).
Если сервер видит в конце User-Agent строку вида " Juick/1.23", то он отдает страницы без лишних заголовков, чтобы данные загружались быстрее.
Этот принцип можно использовать для создания клиентов под iOS, WinPhone и другие платформы. Создание простого приложения занимает один-два дня.
С радостью отвечу на вопросы разработчиков. Пожалуйста, без оффтопа.
Replies (74)
-
@ugnich, ну в ios оно будет выглядеть не нативно и будет рендериться, как в браузере. и не очень понятно, что будет, если я, например, нажму на кнопочку комментов в этом webview? оно мне новое webview с комментами откроет? и как сделать push сообщения, тоже не очень понятно. нет, ну можно конечно использовать html парсер, чтобы вычленить весь контент в массивы. покажи, плз, кусок html, который отдается сервером
-
@n3lab, В официальном Android клиенте все ссылки с домена juick.com открываются внутри приложения. Для внешних ссылок запускается браузер.
Исключение делается для ссылок, где URL заканчивается на ".jpg" — изображения, для простоты, тоже открываются внутри клиента.
Не вижу никаких проблем с push-уведомлениями.
Парсить ничего не нужно. В этом весь смысл с заменой User-Agent: вам сразу отдается страница, готовая для отображения в клиенте. -
@ugnich, обстоятельная статья, все приложения с UIWebView, включая Chrome, работают медленнее чем сафари — phonegap-tips.com
А о чем еще разговаривать, если API теперь "не рекомендовано"? -
@ugnich, я извиняюсь,
вопрос не в том, что нативнее, быстрее и т.д.
а в том, что на каждой платформе свой UX.
например, MS требует, чтобы был определенный набор подходов в UI/UX, который ну никак не реализуешь, если будешь просто webview с сайта показывать.
короче, что делать, если гайды расходятся с тем, как оно на сайте реализовано? -
@LL1ypuk, офигенно выглядит =/ все это — будет отдаваться по запросу? и да, кстате, если потом выкладывать клиент для ios в аппстор, их ревью тим может запросто завернуть всю эту телегу и сказать — если у вас везде юзается webview, то вы нам прилсали не прилагу, а сайт. а если вы прислали сайт — то это уже не к нам.
-
@k0st1x, UX — это, без сомнения, очень важная штука. Но реальность такова, что если вы будете пытаться всецело следовать guidelines и делать идеальное приложение для Juick, то так никогда его и не закончите. Потому что это хобби-проект, который вы делаете в свободное от работы время.
Если выбирать между "идеальное приложение, когда-нибудь, через год-два-три" и "не идеальное, но работающее, прямо сейчас" — большинство пользователей выберет второй вариант. -
@ugnich, годно же получилось с github.com почему не идти по этому пути?
-
@ugnich, да сделали давно уже и давно уже одобрили, и лента нормально без всяких WebView отображается, и люди пользуются. А тут внезапно оказывается, что зачем-то надо выбрасывать уже работающее как положено и показывать зачем-то WebView вместо ленты, а долгожданные фичи опять откладываются.
-
@ugnich, а я вот пока не понимаю, каким образом во все это можно вставить фичи. например пуш сообщения, отмечалку каких нить постов в избранное прям на телефоне, чтобы не обращаться каждый раз к серверу, да даже регистрацию непонятно, как делать, или логинилку. как я понимаю, ты предлагаешь делать так: i.imgur.com + навбар сверху + таббар снизу (ну или какая нить фиговина, вылазющая сбоку). и тогда, как ты и пишешь, получится "приложение с нативной навигацией". только в чем кармический смысл такого приложения будет, я не понимаю. вот ты говоришь, что есть некое http апи. где на его описание можно посмотреть? имхо это очень странно — вместо всей мощи мобильной операционки делать обертку для сайта./58 · Reply
-
@ugnich, да какие там десятки человеко-месяцев, можно же сделать простенький клиент за неделю, который зато будет работать полностью нативно и там будет возможность добавлять фичи планомерно, если захочется. например, хочешь ты добавить что-то прикольное, типа подсчета этих дебильных лайков, чтобы статистику замутить и чо? и нифига. или нативный поиск с нативной кнопкой из ios а не из webview — и ноу проблем. ну не зря большинство социальных проджектов имеют толстое документированное апи, с помощью которого можно вытащить практически все, что угодно. накидай лучше ссылки на все апи, которые есть
-
@ugnich, изначально обсуждали новую возможность — грузить упрощенную HTML-страницу и использовать в качестве основы для мобильных клиентов. Я как разработчик клиента для Windows Phone всего лишь сказал что в него уже вложено "десяток человеко-месяцев"(ц) и HTML-страница ему не нужна, то что нужно — перечислял, остается только ждать. Тоже самое и для iOS — есть наработки и для этой ОС, но все опять же упирается в недостаточный API. Возможно, кто-то заинтересуется, напишет такой клиент на основе WebView, я всего лишь высказал что меня такой подход не устраивает.
-
@n3lab, ну на андроид и WP пуш-уведомления есть и даже работают, но они только сообщают о новых сообщениях от тех, на кого подписан, число сообщений узнать нельзя, приватные сообщения получить нельзя, ответы на сообщения получить нельзя. Отметок прочитанности сообщений тоже нет (вроде есть в приватных сообщениях на сайте, но не в API). Кроме уведомлений в API не хватает возможности узнать состояние сообщения — приватное ли оно, readonly ли оно, есть ли оно в рекомендованных или рекомендовал ли я его. Нельзя получить ленту "обсуждения". Это то что сходу вспомнилось.
Для iOS я уже и сертификаты и пример скрипта отправлял, ждем, но похоже еще долго ждать. Для iOS я столкнулся с производительностью ленты с картинками — в API не хватает возможности получить размер картинок до их загрузки, лента дергается и перерисовывается. Ну вот типа предложили решение вместо размеров картинок грузить HTML-страницу (в которой тоже кстати нет размеров, а могли бы быть).