Приложение LOR для Android

нормальная авторизация

Должно легко реализовываться через куки

гораздо меньшая нагрузка на сервер

Ну, это к макскому, хочет меньшую нагрузку - пусть ревьюит пуллреквесты. Но он просто может не хотеть этого делать, и винить его нельзя. P.S. Вон, скоро новый сервак подвезут. Как раз для допнагрузки :3

расширяемый и менее костыльный код

В принципе, если не считать вероятность поломки парсинга при смене верстки (при этом приложение не упадет), то особых костылей нет, все обернуто в суперкласс. Поправить правила легко, можно предусмотреть конфигурационный файл.

должна быть хотя бы уверенность в том, что CI отлавливает p0 и p1 баги, после этого можно уже думать о приеме коммитов. в честь возвращения собирался как раз заняться этим

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

В принципе, если не считать вероятность поломки парсинга при смене верстки (при этом приложение не упадет), то особых костылей нет, все обернуто в суперкласс. Поправить правила легко, можно предусмотреть конфигурационный файл.

а потом, например, перетаскивать всю эту логику в приложение для iOS? звучит не очень. мне кажется, имеет смысл предусмотреть возможность дешевого перехода с парсинга на API

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

станет гораздо проще ревьюить пуллреквесты, не только APIшные.

перетаскивать всю эту логику в приложение для iOS?

99 USD per membership year

С текущим курсом как-то не очень хочется. Плюс для этого нужен Mac.

имеет смысл предусмотреть возможность дешевого перехода с парсинга на API

Верно, но на какие платформы переносить? Судьба Windows UWP тоже непонятна.

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

а про иосное приложение вроде моно говорил что мог бы взяться, если API будет

Ребят, а вы не пробовали тупо накидать API к стандалон-парсеру и не выносить моск?

ПО ходу, а какое API уже есть?

С текущим курсом как-то не очень хочется. Плюс для этого нужен Mac.

Всё есть. Но лично я парсить HTML не буду.

Начатое мной и заброшенное за отсутствием прогресса над принятием кода апи приложение тут https://github.com/Anakros/LinuxOrgRu-iOS.

Вот тут суперкласс для парсера. Придется заменить метод с 41 строки и методы в child классах.

Уходить от парсинга стоит, когда появится необходимость в фиче, которую реализовать им невозможно. Пока что все, что приходит в голову, реализуемо. С другой стороны, если вдруг что-то понадобится, через API это будет реализовать проще. И здесь получается интересная вещь. Поскольку заранее знать, что понадобится, невозможно, то даже если принять в репозиторий API, то все равно к тому моменту придется снова отправлять пуллреквесты и ждать. Возвращаемся к вопросу о кураторе PR.

Поскольку заранее знать, что понадобится, невозможно, то даже если принять в репозиторий API, то все равно к тому моменту придется снова отправлять пуллреквесты и ждать. Возвращаемся к вопросу о кураторе PR.

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

Почему никто раньше не отписал, что заняться всем этим пока некому?

Уходить от парсинга стоит, когда появится необходимость в фиче, которую реализовать им невозможно.

а потратить кучу времени на обходные маневры заранее зная что любые изменения DOM могут привести к былинному отказу а не анализ и реализацию API того стоило?

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

Уходить от парсинга стоит, когда появится необходимость в фиче

Серьезно? На куцем устройстве молотить страницы - хорошая перспектива оставить пользователя без батареи через некоторое время.

Поскольку заранее знать, что понадобится, невозможно,

Серьезно? Записывай:

1. Выделяешь базовые сущности: - Пользователь - Пользовательские роли - Пост - Комментарий

2. Для каждой сущности определяешь правила сериализации 3. К каждой сущности добавляешь дельта-лог 4. ???? 5. PROFIT

На куцем устройстве молотить страницы - хорошая перспектива оставить пользователя без батареи

Без пруфов это пустые слова, тем более, что основной потребитель энергии - дисплей.

Не трать время на споры с пуристами. Абстрактно — они правы, но и только.

Без пруфов это пустые слова, тем более, что основной потребитель энергии - дисплей.

Объясняю еще раз. Интенсивное использование проца повышает его напрягу == батарея расходуется интенсивней. Это раз, второе - какие ты пруфы хочешь? Того что питание у проца зависит от интенсивности использования? Или что?

Интенсивное использование проца повышает его напрягу == батарея расходуется интенсивней.

Интенсивное использование проца

Интенсивное

А теперь пруф, что парсинг HTML через Jsoup, даже не регекспами, интенсивно нагружает процессор. Хотя о чем я прошу, пруфов же не будет.

Хотя о чем я прошу, пруфов же не будет.

Первый и последний раз: http://imgur.com/OYY6obq

1. Посмотри на память, при том, что твое приложение не делает практически ничего - каждый запрос грузит проц на ~40%, а так как у тебя ни функционала, ни локального стораджа, ну вот от слова вообще, оно уже насосало 12 метров.

2. Посмотри на красные всплески - это твои запросы.

Видимо когда мы говорили о приложении - мы говорили о совсем разных вещах. Так что дерзай. Тебе еще пилить и пилить.

И чуть не забыл - убери это говно ака «рендер в память» из build.gradle - не у всех пользовательские процессы имеют права писать в рутовый темп.

в честь возвращения

Хорошо, когда хорошие люди возвращаются.

собирался как раз заняться этим

Можно в этом как-то поучаствовать? Мне для саморазвития.

ну первый этап не особо распараллеливается: скачиваешь код, ставишь jacoco или cobertura (хотя лор вроде на 8й жаве, а её кобертура не саппортит), прогоняешь тесты, смотришь репорт. а дальше этот репорт можно анализировать и покрывать тестами нужные куски, попутно делая ревью существующих тестов, а то в моей практике слишком часто встречались тесты, которые не тестировали вообще ничего. тут по идее можно параллельно работать.

Отлично, ключевые слова для гугления есть. Спасибо.

Раз уж появилась какая-то активность, может быть стоит сделать под это дело канал в ирке рядом с #lor для заинтересованных?

Спасибо.

грузит проц на ~40%

Меньше.

а так как у тебя ни функционала, ни локального стораджа, ну вот от слова вообще, оно уже насосало 12 метров.

Не вижу связи. Что подразумевается под «локальным стораджем»?

Не вижу связи.

Твое приложение должно хавать 5-6 метров со всем про всем. Нет локального хранилища ни постоянного (локальной базы или тупо json - файла) ни временного (массив моделей в памяти), значит что тут у нас? Оно течет. Вобщем ставь канарейку и смотри. 70% вероятности у тебя течет recycleradapter.

когда ждать версию для windows?

Все это конечно ништяк, но почему не в Google Play?

Приложение еще не готово к релизу, см. GitHub.

По крайней мере после того, как будет сделано API.

По крайней мере после того, как будет сделано API.

ОК, я просто от ведра как-то отказался. Желаю успехов и терпения)

Никогда не пользовался, там хоть можно посмотреть, что писали, пока был в офлайне? Приватная беседа в любом случае нужна.

Без бота, который сохраняет историю или баунсера нельзя.

Тогда это очень неудобно. Может Slack/что там из опенсорсных аналогов?

г-ди, да чятик на j.ru и всего делов. логи чятика хранятся на chatlogs.jabber.ru

Мне всё равно, хоть Slack, хоть телеграм, хоть опенсорсный Mattermost.

Несекьюрно.

Хотя, может это и надуманно. Все равно все где-то хранится.

то есть исходники на гитхабе - это секьюрно, а обсуждение этих самых исходников в чятике - несекьюрно? :)

Да, у меня произошел сегфолт :)

Вспомнил про статью: https://m.habrahabr.ru/post/230735/

Вобщем ставь канарейку и смотри. 70% вероятности у тебя течет recycleradapter.

Поставил. GC стабильно идет после ~12.7 МБ и снижается до 5. Причем адаптер явно течет, так как использование памяти возрастает при прокрутке даже без загрузки данных. Но утечка не показывается. Я что-то не так делаю? Просветите, пожалуйста.

Запилил чатик lor-api на jabber.ru. Сегодня опять отвалился парсер :(

vostrik, не начинал еще?

Так будет api?

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

Кроме тебя кто-нибудь этим занимается?

тестами насколько я знаю нет

Можно понаглеть и попросить собрать apk? Ссылка битая, сам собрать может и смогу, но нужно вникать (не занимался android приложениями). Просто посмотреть хотелось.

http://fracton.rgho.st/7fLPtLzbK. Прошу прощения за rghost.

Спасибо!