Comments 13
Аннотации хороши, когда их мало. При сложной структуре XML документа код обрастает и читаемость его сильно ухудшается. Кстати, JAXB ведь делает то же самое. Почему не использовать его?
Спасибо, нужно будет попробовать ее в одном из своих Pet-проектов
Как раз недавно тоже задавался вопросом, что есть под Android для Xml биндинга, и тоже посмотрел на эту библиотеку. Но даже не стал её пробовать из-за её размера.
Можете назвать меня старомодным (тяга к сокращению размера приложения осталась со времён J2ME:))), но добавлять к проекту либу размером в 300кб только для того, чтобы вам было удобнее парсить XML, мне кажется каким-то неуважением к своим пользователям.
Так что, как минимум, стоит добавить к минусам размер библиотеки.
Можете назвать меня старомодным (тяга к сокращению размера приложения осталась со времён J2ME:))), но добавлять к проекту либу размером в 300кб только для того, чтобы вам было удобнее парсить XML, мне кажется каким-то неуважением к своим пользователям.
Так что, как минимум, стоит добавить к минусам размер библиотеки.
Интересно было бы выслушать мнение минусующих :)
Я не минусовал, но мнение выскажу.
Компилятор ее ужмет при добавлении в итоговый apk, т.е. 300K библиотеки не значит что размер итогового пакета получится 300K + остальное.
Да и общая тенденция, что уже особенно никто не следит за размерами такого порядка, у людей высокоскоростной интернет и флэшки на гигабайты.
Но конечно нужно стремится к уменьшению итогового размеров пакета, в разумных пределах, калькулятор в 20 метров это все же не дело. ;)
Компилятор ее ужмет при добавлении в итоговый apk, т.е. 300K библиотеки не значит что размер итогового пакета получится 300K + остальное.
Да и общая тенденция, что уже особенно никто не следит за размерами такого порядка, у людей высокоскоростной интернет и флэшки на гигабайты.
Но конечно нужно стремится к уменьшению итогового размеров пакета, в разумных пределах, калькулятор в 20 метров это все же не дело. ;)
Компилятор ее ужмет при добавлении в итоговый apk
Да, пожалуй, стоит проверить. Но не думаю, что выигрыш будет больше, чем даёт повторная переупаковка, то есть ужатие до ~270кб. Ещё дополнительный выигрыш может дать обфускация, но неизвестно, не отвалится ли там чего из-за использования рефлекшена :) В любом случае, будет больше 200кб оверхеда. И очень печально, что это не считается минусом.
Да и общая тенденция, что уже особенно никто не следит за размерами такого порядка, у людей высокоскоростной интернет и флэшки на гигабайты.
Учитывая статистику распределения версий, как минимум, тридцать процентов пользователей (те, у кого версия Андроид ниже 2.2) ещё, точно, следят. Да даже я слежу, хотя у меня 2.3.3, так как даже при инсталляции на флэшку часть файлов ставится в основную память (кстати, давно было интересно, что же остаётся в основной памяти).
В общем, повторюсь — я не против самой либы (на серверной стороне сам пользуюсь аналогами без каких-либо раздумий о размере), но в контексте разработки для мобильных платформ размер всё-таки нужно учитывать, и очень хотелось бы, чтобы разработчики это понимали.
В основную память копируются распакованные далвик классы, в dalvikCache. Я пока писал свой diskusage намучился пока просёк что как считается.
Не так давно я сделал соответствующий пост в бложик, буду рад, если это объяснит. Андроид 2.3 тут сильно выигрывает более эффективным переносом (странно, что не реализовали это сразу).
Скажите, а чем это лучше/хуже XStream?
>Т.е., как мы привыкли в .NET
Ну, не все привыкли в .NET работать :)
А за обзор спасибо. Возьму на заметку
Ну, не все привыкли в .NET работать :)
А за обзор спасибо. Возьму на заметку
Sign up to leave a comment.
Разбор XML при помощи Simple Framework