Comments 12
отлично.
Спасибо, очень полезная библиотека!
Единственное замечание — имена своих классов в java принято писать с большой буквы, уж очень в глаза бросается
Единственное замечание — имена своих классов в java принято писать с большой буквы, уж очень в глаза бросается
интересно, попробую!
Я похожую задачу решал немного по другому, для парсинга тяжелых страниц написал небольшое веб приложение, которое отдает JSON на андроид, потому что тянуть на мобилку тяжелые страницы, да еще потом парсить их слишком тяжелый труд для аккума ) в учебных целях то оно конечно все равно, но в реальном приложении мне кажется это уже играет существенную роль
Не так уж и много страницы весят, основной объем всё равно приходится на CSS, скрипты и графику. А голый HTML весит мало, даже на здоровых страницах. Парсинг на серверной стороне имеет смысл, если результаты обработки сервером одной страницы будут отдаваться множеству клиентов. Ну или хотя бы если эта самая «серверная сторона» вообще имеется в наличии.
Я бы еще упомянул JSoup. Она быстрее htmlcleaner раза в 2, по крайней мере в JavaSE.
Ее плюсы в относительной простоте кода и удобных CSS-подобных селекторах.
Ее плюсы в относительной простоте кода и удобных CSS-подобных селекторах.
Все таки использовать XPath было бы логичнее, чем обходить все ссылки. Как я понял, библиотечка это позволяет.
Ну и у StackOverflow есть API blog.stackoverflow.com/2010/05/stack-exchange-api-public-beta-starts/, так что странички дергать совсем не обязательно.
Ну и у StackOverflow есть API blog.stackoverflow.com/2010/05/stack-exchange-api-public-beta-starts/, так что странички дергать совсем не обязательно.
как бы ни продвигали AsyncTask, мне кажется потоки + runOnUiThread ничуть не хуже, а часто и более гибко
Sign up to leave a comment.
«Правильный» html парсинг