Комментарии 76
Так как мы имеем дело с трафиком, то Wireshark — наш выбор. Не без мучений подключив телефон к интернету через стационарный компьютер, открываем приложение и смотрим на запросы… Да, всё зашифровано, а с криптографией возиться не хочется. Тогда надо смотреть внутрь самого приложения.
Для таких вещей проще использовать Fiddler, он даже https расшифрует если включите подмену сертификата
Да, вы, вероятно, правы, и я, более того, пытался заменить сертификат в Wireshark/Burp Suite, но из логов стало понятно, что в приложении есть SSL Pinning.
автору — творческих узбеков!
Да там самый главный косяк, что приложение не помнит где ты читал.
Это вообще перечеркивает весь смысл этого приложения. Оно просто бесполезно.
«Быстренько глянуть» что там за статья, я и в браузере могу.
А вот полноценно читать статьи с таким приложением просто невозможно…
Я думаю, что в приложении можно сделать список статей "в прогрессе", показывая все открытые и недочитанные статьи, таким образом ведя эффективный учет. По факту это будет аналог вкладок в браузере, только не нагружающий ничего и хранящийся на сервере.
Поиск по комментариям в статье бы пригодился.
Возможность редактировать комментарии!
Но всё же главное — как вы и сказали, уведомление о комментах в приложении с возможностью из приложения же на них и отвечать.
Ps очень хороший пример мобильного приложения — у tjournal
При том, что у них ситуация похожа: много трафика и активная дизнь в комментах под каждой статьёй
Кстати, в официальном приложении ещё очень не хватает кнопки «открыть в браузере» внутри кнопки «Share»
Приходится делать Share => скопировать ссылку => открывать браузер => вставлять ссылку
А ещё у меня почему-то при открытии статей частенько вместе со статьёй открывается баузер и в нём Syndication.twitter.com
Лично я предпочитаю не оставлять недочитанные статьи "на потом", но в любом случае, я согласен, потеря прогресса чтения угнетает. Главная проблема приложения в том, что оно просто неудобное, так подробно я расписал, чтобы подчеркнуть, что эти пункты — важные составляющие жизненного цикла статьи, а отсутствие сохранения позиции всё же не баг, а недостающая фича.
Да, история как с VK и Kate Mobile. Открыть исходники им экономически невыгодно: за эту работу они заплатили деньги cleverpumpkin.ru.
С рекламой дело другое. Явно, что как только появится клиент, ему будет нужен сервер (нормальный такой). И если мы будем считать, что данные с Хабра нам идут бесплатно (как оно есть сейчас), то нужно тратить свои деревянные на поддержку работоспособности. Да, возможно найдется пара человек, поддерживающих рублем, но на это опираться сложно.
Встраивать рекламу будет откровенным кощунством: пишут другие люди, и пишут на хабр, а деньги с рекламы разработчику приложения (ну, то есть мне, а я к текстам отношения не имею).
Вот и проблема. Скорее всего с выходом новой версии API старую отрубят, вместе с приложением.
Либо с включенным режимом разработчика и отладкой по USB, либо с рутом и приложением типа CatLog
Все эти микролаги абсолюно не нужны в продакшене.
android автоматом отрубает низкоуровневые логи после перехода 7 или 8 версию. Чтобы получить лог, его нужно сначала включить. Из-за этой особенности приходилось бить по рукам программистам, которые trace логи начинали выводить в info или error со словами «trace не работает».
— катастрофически не хватает трекера комментариев
— из списка статей нельзя перейти сразу к комментариям
— не выделяются хабы, на которые подписан, нет возможности подписаться/отписаться
Вообще, конечно, поражает:
1) хабр лучший технический портал рунета
2) больше половины трафика подобных порталов идут с мобилок
3) мобильное приложение хабра это… ну, в общем, плохое.
Но вообще да, оф. приложение очень не очень. Я думаю, что tmtm ведёт всё же разработки нового приложения. Потому как опросики про дизайн ленты уже были, даже какие-то первые идеи были. Но как-то прогресс не виден и это очень и очень печалит.
Они неоднократно открыто говорили, что приложение заброшено, активно пилят мобильный сайт. И искренне недоумевают, почему глючное приложение удобнее чем сайт, в котором больше фич поддерживается. Такие дела.
Нет, при смене имени на habr.com они сказали, что и приложением занимаются.
Почле этого что-то даже улучшилось. Чуточку.
Видимо это было давно.
В основном ситуация такая:
https://habr.com/ru/news/t/444506/#comment_19951300
https://habr.com/ru/company/tm/blog/441302/#comment_19790382
https://habr.com/ru/company/tm/blog/445940/#comment_19960130
Остальные ответы просто лень искать.
Да, действительно, часть ссылок в исходниках приложения оказалась не habrahabr.ru, а habr.com, вот и вся работа.
Т.к. мне лично не хватало возможности отсортировать статьи по рэйтингу/комментариям/звездам. Так гораздо легче найти «что почитать», сам контент я не сохраняю, только ссылки на непосредственно хабр.
Я так понимаю оно уже упало)
ПС репо тут если что: gitlab.com/YemSalat/hs-new-client
если кто-то может поправить верстку для мобильных — буду крайне признателен
Не мог понять откуда на Win10 взялось «мыло» у букв, пока не наткнулся на свойство perspective у css-класса .post-list
Читаю хабр через свое приложение. Это агрегатом типа рсс читалки. Отличие в том, что все статьи прогоняются через ридабилити плагин и скачивают я на телефон. Те работает офлайн. Вобщем, там даже комментариев нет, но мне нравится. Апи не пользуюсь, парсю рсс + контент. Написан на флаттер, но движок на go
А еще есть feedly.com — аналог google reader, к которому тоже есть офлайн клиенты.
Список источников
https://habrastorage.org/webt/pe/mp/kq/pempkqmloc1m0zhhv83ndlaj-uo.png
Вот еще пара фич.
Есть желание сделать приложение для Хабра на основе PWA.
Нет, спасибо, мне достаточно одного браузера в телефоне.
Есть тенденция запихивать приложения в браузер, которым там делать нечего. Но есть и обратная тенденция — запихивать веб сайты в приложения. не знаю даже что хуже :)
1) приложение работает быстрее — потому, что:
практически не нужно грузить вёрстку, ибо она захардкожена для этого приложения
не нужно грузить js-ники обработчики стандартных модулей конкретного сайта
2) В приложении можно (нужно!) сделать встроенные обработчики событий, типа «вам комментарий» с возможностью удобной работы с событиями (читаешь статью — получил клммент на другую статью, ответил, вернулся к читаемой статье)
3) приложение поддерживает оффлайн:
можно пролистать список заголовков статей (статьи закэшировались с контентом), потом в метро читаешь их даже в условиях нестабильного интернета
если нет интернета во время отправки комментария, приложение может подождать и отправить коммент через минуту, когда иннт ожил, и при этом не блокируется работа с остальным контентом.
4) в приложении можно удобно замутить работу с целевым контентом: вставку картинок/кода/видео и тд с преобразованием и форматированием
=======
Большую часть этих возможностей можно сделать и в браузере.
Но сайт тогда будет «скорее висит, чем работает» и жрать батарею/трафик со страшной силой
И — не всё из этого есть в прложении хабра. А жаль.
Приложение нужно не всем сайтам, а только тем, где очень большая аудитория — тут стоит заморочиться, что бы открытие статьи заняло на 1 секунду меньше, а у пользователя возникло больше удовольствия от работы с сайтом.
1) приложение работает быстрее — потому, что:
практически не нужно грузить вёрстку, ибо она захардкожена для этого приложения
не нужно грузить js-ники обработчики стандартных модулей конкретного сайта
Браузер тоже кеширует эти вещи.
2) В приложении можно (нужно!) сделать встроенные обработчики событий, типа «вам комментарий» с возможностью удобной работы с событиями (читаешь статью — получил клммент на другую статью, ответил, вернулся к читаемой статье)
Notifications api
3) приложение поддерживает оффлайн:
Service workers
4) в приложении можно удобно замутить работу с целевым контентом: вставку картинок/кода/видео и тд с преобразованием и форматированием
В браузере тоже. Ну и хабр не инстаграм, нe очень актуально на мой взгляд.
Большую часть этих возможностей можно сделать и в браузере.
Все эти возможности можно сделать в браузере.
Но сайт тогда будет «скорее висит, чем работает» и жрать батарею/трафик со страшной силой
False, как хоть одна из описанных вами фич будет давить на производительность больше чем «нативное» приложение? Браузер — тоже нативный на минуточку.
Приложение нужно не всем сайтам, а только тем, где очень большая аудитория — тут стоит заморочиться, что бы открытие статьи заняло на 1 секунду меньше, а у пользователя возникло больше удовольствия от работы с сайтом.
Ну я и говорю — что это заблуждение. каким образом реквест на апи из браузера будет занимать больше времени чем точно такой же реквест из нативного приложения?
В итоге вам придется не только добавить эти фичи, но еще и все что уже есть в мобильном сайте и в самом браузере (зум/вкладки) И кроме того — все это на нескольких платформах.
> Ну я и говорю — что это заблуждение. каким образом реквест на апи из браузера будет занимать больше времени чем точно такой же реквест из нативного приложения?
реквест занимает столько же времени.
Разница в количестве реквестов и во времени их обработки.
Браузер не знает заранее, как должен выглядеть сайт, а приложение знает.
Значит приложению не нужно проверять протух ли кэш и не нужно генерить дизан страницы сайта.
То, что браузер компилит на ходу в приложении скомпилено заранее.
Браузер собирает сайт из конструктора, приложение вставляет целевой контент в формы, заранее подготовленные под конкретный сайт.
На практике — да, это приводит к тому, что в приложении работать быстрее и удобнее.
Фичи:
> Notifications api,
Это работает, но требует дополнительных ресурсов от браузера.
> Service workers
Если я сверну браузер, поиграю в игрушку, и вернусь к браузеру когда интернета уже нет — браузер уже выгрузился из памяти и закэшированная статья или инфа о пришедших комментах вместе с ним. В приложении проблем нет.
PS Может вы меня переубедите примером?
Вы знаете примеры сайтов, где всё обсуждаемое выше успешно реализовано для работы в мобильном браузере?
Пример приложения могу предоставить.
Разница в количестве реквестов и во времени их обработки.
Браузер не знает заранее, как должен выглядеть сайт, а приложение знает.
Значит приложению не нужно проверять протух ли кэш и не нужно генерить дизан страницы сайта.
Ну вот вам пример:
Как вы видите — через 2мс браузер уже знает как будет выглядеть страница, если он на ней уже был.
Про «ощутимую разницу» между скомпилированным заранее и JIT компиляцией — туда же. Нa «обычных» приложениях — вы не не сможете этого заметить.
Notifications apи
Это работает, но требует дополнительных ресурсов от браузера.
Больших, чем от приложения?
Если я сверну браузер, поиграю в игрушку, и вернусь к браузеру когда интернета уже нет — браузер уже выгрузился из памяти и закэшированная статья или инфа о пришедших комментах вместе с ним. В приложении проблем нет.
Ну так service workers как раз и могут сделать так чтобы браузер мог не дергать интернет, а подгружал контент из кеша. Т.е. тоже «проблем нет»
Вы знаете примеры сайтов, где всё обсуждаемое выше успешно реализовано для работы в мобильном браузере?
На самом деле много где реализовано. Facebook, некоторые сервисы гугла.
Ничто не мешает сделать веб версию хабра со всеми фичами, которые вы привели в предыдущем посте.
https://youtu.be/6By9j6SaqTo
Вот сравнение времени отклика приложения и сайта.
Сайт, как видите, сперва был закэширован — и всё равно приложение быстрее.
Facebook и некоторые сервисы от гугла
У меня сайты и фейсбука, и gmail-а загружаются заново, если браузер был вытеснен из памяти. А если интернета нет — не загружаются.
У вас иначе?
У меня сайты и фейсбука, и gmail-а загружаются заново, если браузер был вытеснен из памяти. А если интернета нет — не загружаются.
Насчет фэйсбука — я перепутал, там если инет отключится — то он не «упадет» (как раз случай про метро/лифт) У гугла не помню точно на кaких сервисах, но где-то видел.
Главное в том, что добавить поддержку оффлайна — нет никаких проблем, например: www.talater.com/upup (вообще одной строкой фактически)
Насчет сравнения — у вас в приложении вроде точно так же висит пару секунд перед показом контента, только там показывает лого хабра вместо белого фона.
К тому же хабру есть что улучшить в своей веб версии: page speed insights
Talater у меня не загрузился с мобильного :(
Про анализатор скорости сайта — смешно то, что сайт гуглоаккаунта ещё медленее ;)
Для таких вещей есть Packet Capture
Публикации
(Не)официальное приложение Хабра — HabrApp 2.0: получение доступа