«Правильный» html парсинг

[aspel]

отлично.

[Rivers]

Спасибо, очень полезная библиотека!
Единственное замечание — имена своих классов в java принято писать с большой буквы, уж очень в глаза бросается

[eforce]

Ок, исправимся, в посте менять уже не буду, но в будущем учту.

[eforce]

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

[WarL]

интересно, попробую!

[reality]

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

[eigrad]

Не так уж и много страницы весят, основной объем всё равно приходится на CSS, скрипты и графику. А голый HTML весит мало, даже на здоровых страницах. Парсинг на серверной стороне имеет смысл, если результаты обработки сервером одной страницы будут отдаваться множеству клиентов. Ну или хотя бы если эта самая «серверная сторона» вообще имеется в наличии.

[ilnoor]

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

Пожалуйста, прочитайте и исправьте.

[eforce]

Спасибо, мне ещё в семь утра сообщили об ошибке в личных сообщениях, исправить смог только сейчас.

[kzn]

Я бы еще упомянул JSoup. Она быстрее htmlcleaner раза в 2, по крайней мере в JavaSE.
Ее плюсы в относительной простоте кода и удобных CSS-подобных селекторах.

[seriyPS]

Все таки использовать XPath было бы логичнее, чем обходить все ссылки. Как я понял, библиотечка это позволяет.

Ну и у StackOverflow есть API blog.stackoverflow.com/2010/05/stack-exchange-api-public-beta-starts/, так что странички дергать совсем не обязательно.

[0x45455844]

как бы ни продвигали AsyncTask, мне кажется потоки + runOnUiThread ничуть не хуже, а часто и более гибко