@ugnich, у меня титановая пластина в голове и я туго понимаю.
это rest api? или вот прям html страницу запрашиваешь?

@k0st1x, Запрашивается HTML.

@ugnich, ежели ты рекомендуешь всем использовать твой подход, значит ли это, что rest api заморожен?

@ugnich, Что с push-уведомлениями на iOS?
Размеры картинок? Или API теперь не нужно, нужно грузить страницу?

@k0st1x, Не заморожен и даже наоборот. HTTP API продолжает развиваться и будет более широко использоваться на сайте.

@vt, Push-уведомления на iOS сделаны настолько через жопу, что я всё никак не могу выделить время, чтобы разобраться в этом ужасе.
Размеров изображений в ближайшее время не ждите.

@ugnich, webview это, как я понял, означает, что в прилаге будет прям кусок html страницы? а апи есть, чтобы json, например, с постами забирать?

@ugnich, ну получается придется ждать и пользоваться дальше браузером, смысла делать приложение без уведомлений и показывающее внутри себя браузер я не улавливаю.

@n3lab, Какая разница, что там будет отображаться? Оно будет хорошо выглядеть и потребует у программиста минимальных затрат на реализацию.
JSON есть, но я не рекомендую.

@vt, В приложении удобнее навигация и работает быстрее браузера.

@vt, Ну и главное, что приложение — это иконка на рабочем столе. А сайт — это всего лишь сайт.

@ugnich, А документироваться?

@ugnich, сайт тоже можно поместить в иконку на рабочем столе, не показатель:) пуш — это очень важная составляющая для мобильных платформ

@ugnich, в браузере есть кнопка "создать ярлык на рабочий стол", приложение для этого не нужно.

@hohoho, Можно. Но так почти никто не делает.

@ugnich, когда внутри приложения браузер, оно не может работать быстрее ну никак, более того, приложениям дается более медленный жабаскриптовый движок чем тот, что использует сафари

@ugnich, ну в ios оно будет выглядеть не нативно и будет рендериться, как в браузере. и не очень понятно, что будет, если я, например, нажму на кнопочку комментов в этом webview? оно мне новое webview с комментами откроет? и как сделать push сообщения, тоже не очень понятно. нет, ну можно конечно использовать html парсер, чтобы вычленить весь контент в массивы. покажи, плз, кусок html, который отдается сервером

@vt, Давайте вы перестанете писать ерунду, более обстоятельно изучите вопрос, хорошо подумаете, а потом вернетесь в этот тред и тогда мы поговорим?

@n3lab, В официальном Android клиенте все ссылки с домена juick.com открываются внутри приложения. Для внешних ссылок запускается браузер.
Исключение делается для ссылок, где URL заканчивается на ".jpg" — изображения, для простоты, тоже открываются внутри клиента.
Не вижу никаких проблем с push-уведомлениями.
Парсить ничего не нужно. В этом весь смысл с заменой User-Agent: вам сразу отдается страница, готовая для отображения в клиенте.

@ugnich, обстоятельная статья, все приложения с UIWebView, включая Chrome, работают медленнее чем сафари — phonegap-tips.com
А о чем еще разговаривать, если API теперь "не рекомендовано"?

@vt, Статья не об этом, читайте внимательнее.
Кто сказал, что API "не рекомендовано"?
Ещё раз: сходите выпейте чаю, подумайте, осознайте свои ошибки, а потом поговорим.

@ugnich, я извиняюсь,
вопрос не в том, что нативнее, быстрее и т.д.
а в том, что на каждой платформе свой UX.
например, MS требует, чтобы был определенный набор подходов в UI/UX, который ну никак не реализуешь, если будешь просто webview с сайта показывать.

короче, что делать, если гайды расходятся с тем, как оно на сайте реализовано?

@ugnich, до и после использования юзер-агента, это как то не спортивно я считаю

@LL1ypuk, офигенно выглядит =/ все это — будет отдаваться по запросу? и да, кстате, если потом выкладывать клиент для ios в аппстор, их ревью тим может запросто завернуть всю эту телегу и сказать — если у вас везде юзается webview, то вы нам прилсали не прилагу, а сайт. а если вы прислали сайт — то это уже не к нам.

@k0st1x, UX — это, без сомнения, очень важная штука. Но реальность такова, что если вы будете пытаться всецело следовать guidelines и делать идеальное приложение для Juick, то так никогда его и не закончите. Потому что это хобби-проект, который вы делаете в свободное от работы время.
Если выбирать между "идеальное приложение, когда-нибудь, через год-два-три" и "не идеальное, но работающее, прямо сейчас" — большинство пользователей выберет второй вариант.

@LL1ypuk, Уточните, в чем проблема.

@n3lab, Facebook, в своё время, тоже отображал ленту через HTML5.
Сделайте хорошую native навигацию и вряд ли у кого-то возникнут претензии.

@ugnich, У меня прямо сейчас работает приложение для WP, соответствующее всем гайдлайнам, уже год стоит на месте по причине "недостаточно API".

@ugnich, а что, была плохая реализация именно отображения ленты? Вон в juick-advanced даже картинки со сторонних ресурсов грузятся в отличие от готовой html-ленты

@ugnich, годно же получилось с github.com почему не идти по этому пути?

@ugnich, Я дико извиняюсь, но, на мой взгляд, лучше получать всё в виде json и уже на клиенте вертеть это всё, как угодно. Вне зависимости, web клиент это или мобильный.

@vt, Совершенно верно. Используя новый подход, можно дать пользователям функционал наравне с сайтом, не дожидаясь API.

@FGNTFG, Много на iOS навертели? :)

@Tishka17, Было так себе, на троечку. Например, кликать по ссылкам сейчас намного удобнее.

@ugnich, Через полчаса в моей семье не будет ни одного iOS устройства. Только android, только Kit Kat

@LL1ypuk, Если бы было годно, шли бы.

@ugnich, так для сайта вообще не нужно никакое приложение, есть куча средств, позволяющих сделать сайт выглядящим как "приложение". Да и сейчас жуйк прекрасно читается и пишется в него из браузера, пусть с недочетами, но приложение с WebView их никак не исправит.

@ugnich, странно, что в век джаваскрипта API делается после сайта

@vt, Сделать хорошую HTML5 навигацию, мимикрирующую под нативный интерфейс, очень непросто. Все эти статичные панели, анимированные эффекты и прочий JavaScript часто глючит на разных версиях OS.

@Tishka17, Там, где информационная составляющая важнее сервисной, сайт всегда будет впереди API.

@ugnich, да ладно, посмотри какой нибудь ionicframework, такие вещи можно сделать, что и не снилось

@ugnich, да посмотреть тот же intel xdk, написал код, он скомпилирует под все платформы, даже внешний вид будет чем то похож на нативный

@LL1ypuk, Сделайте. Как сделаете, тогда и поговорим: легко ли это было и с какими трудностями столкнулись. :)

@ugnich, просмотр своей ленты как в standalone легко сделаю, на больше моих навыков js не хватит

@ugnich, а если его не одобрит стор, то так же приложение никогда не выйдет.
нужны пути кустомизябельности

@k0st1x, Сделайте хорошую нативную навигацию — одобрят.

@ugnich, да сделали давно уже и давно уже одобрили, и лента нормально без всяких WebView отображается, и люди пользуются. А тут внезапно оказывается, что зачем-то надо выбрасывать уже работающее как положено и показывать зачем-то WebView вместо ленты, а долгожданные фичи опять откладываются.

@vt, Судя по скриншотам с сайта Windows Phone Apps, до "нормально" там ещё пилить и пилить. Ничего личного, не обижайтесь.

@ugnich, судя по скриншотам двухлетней давности, выложенными с первой версией?

@ugnich, у меня падает, трейс сейчас сниму

@ugnich, а по-моему по скриншотам там все не сильно хуже чем в целом в винде

@vt, Что вы выложили, по тому и сужу. :)

@ugnich, ну судя по тому что в Google Play, приложение под андроид не умеет показывать общую ленту сообщений вообще.

@Kerrigan, вот трейс pastebin.com

@vt, Мы всё ещё обсуждаем Windows Phone или уже перешли на "сам дурак"?

@Kerrigan, Какой-то конфликт ресурсов пакета support. Спасибо, исправлю.

@ugnich, а я вот пока не понимаю, каким образом во все это можно вставить фичи. например пуш сообщения, отмечалку каких нить постов в избранное прям на телефоне, чтобы не обращаться каждый раз к серверу, да даже регистрацию непонятно, как делать, или логинилку. как я понимаю, ты предлагаешь делать так: i.imgur.com + навбар сверху + таббар снизу (ну или какая нить фиговина, вылазющая сбоку). и тогда, как ты и пишешь, получится "приложение с нативной навигацией". только в чем кармический смысл такого приложения будет, я не понимаю. вот ты говоришь, что есть некое http апи. где на его описание можно посмотреть? имхо это очень странно — вместо всей мощи мобильной операционки делать обертку для сайта.

@n3lab, Вы можете себе позволить выделить десяток человеко-месяцев, чтобы реализовать клиент, использующий всю мощь вашей OS?

@ugnich, да какие там десятки человеко-месяцев, можно же сделать простенький клиент за неделю, который зато будет работать полностью нативно и там будет возможность добавлять фичи планомерно, если захочется. например, хочешь ты добавить что-то прикольное, типа подсчета этих дебильных лайков, чтобы статистику замутить и чо? и нифига. или нативный поиск с нативной кнопкой из ios а не из webview — и ноу проблем. ну не зря большинство социальных проджектов имеют толстое документированное апи, с помощью которого можно вытащить практически все, что угодно. накидай лучше ссылки на все апи, которые есть

@ugnich, изначально обсуждали новую возможность — грузить упрощенную HTML-страницу и использовать в качестве основы для мобильных клиентов. Я как разработчик клиента для Windows Phone всего лишь сказал что в него уже вложено "десяток человеко-месяцев"(ц) и HTML-страница ему не нужна, то что нужно — перечислял, остается только ждать. Тоже самое и для iOS — есть наработки и для этой ОС, но все опять же упирается в недостаточный API. Возможно, кто-то заинтересуется, напишет такой клиент на основе WebView, я всего лишь высказал что меня такой подход не устраивает.

@n3lab, juick.com

@vt, ну и нормально в принципе. а логиниться как? только через xmpp?

@n3lab, все запросы работают с Basic HTTP авторизацией по логину-паролю из настроек на сайте.

@vt, а какие фичи под win mobile не получается сделать, если не секрет? я вот пока что для ios вижу проблему с пуш нотификациями, потому что там сертификаты всякие ставить надо жуйкосервер и собственно сам скрипт для яблока писать

@n3lab, с сертификатом фигня, кто серверную часть писать будет?

@LL1ypuk, ну как кто :) вон же, уже есть пуш нотификации для гуглодроида и для винды, как я понял. там стопудово только формат отдачи данных поправить

@n3lab, ну на андроид и WP пуш-уведомления есть и даже работают, но они только сообщают о новых сообщениях от тех, на кого подписан, число сообщений узнать нельзя, приватные сообщения получить нельзя, ответы на сообщения получить нельзя. Отметок прочитанности сообщений тоже нет (вроде есть в приватных сообщениях на сайте, но не в API). Кроме уведомлений в API не хватает возможности узнать состояние сообщения — приватное ли оно, readonly ли оно, есть ли оно в рекомендованных или рекомендовал ли я его. Нельзя получить ленту "обсуждения". Это то что сходу вспомнилось.
Для iOS я уже и сертификаты и пример скрипта отправлял, ждем, но похоже еще долго ждать. Для iOS я столкнулся с производительностью ленты с картинками — в API не хватает возможности получить размер картинок до их загрузки, лента дергается и перерисовывается. Ну вот типа предложили решение вместо размеров картинок грузить HTML-страницу (в которой тоже кстати нет размеров, а могли бы быть).

@vt, млин, так ты еще и клиент для ios пилишь? ) во ты молодцом!

@vt, И нет подтверждений доставки сообщения.

@n3lab, на iOS жестокое ограничение на размер уведомления, оно не должно 256 байт превышать, там надо высчитывать размер, если не укладываемся, то надо слать "у вас есть новые сообщения", например, или полностью сообщение если поместились.

@vt, с картинками я считаю можно не париться, где нибудь показывать что в этом сообщении есть картинка и при нажатии ее показывать.

@LL1ypuk, фуфуфу. так никто не любит

@k0st1x, загрузил а в 10 из 10 картинки какого то аниме и танков а ты с 3г, а так бы, прочитав описание, загрузил бы только интересное

@LL1ypuk, значит нужны миниатюрные thumbnails preview.
можно грузить только если "less than 100Kb",
если лимит исчерпан, то предлагать загрузить по тапу
(идея взята из qip'а)