Комментарии 45
Хм, под Android модно писать IoC фреймворки :)
У вас проблемы с классом org.droidparts.model.Entity:
1. Он должен быть абстрактным
2. HashCode не должен включать имя класса
3. Equals должен делать instance of вместо o.getClass() == this.getClass()
1. Он должен быть абстрактным
2. HashCode не должен включать имя класса
3. Equals должен делать instance of вместо o.getClass() == this.getClass()
ModelUtils просто так хавает Exception
try {
//...
} catch (Exception e) {
L.d(e);
}
Называть имена классов своих классов также как и имена стандартной библиотеки — плохой тон:
class ListActivity extends android.app.ListActivity
Вы уверены, что хранить Context полем в AsyncTask — хорошая идея?
Что произойдёт если Activity закончит своё существование до завершения задачи?
Это я всё к тому, что перед тем как выкладывать библиотеку в открытый доступ (читать — делать публичный API), нужно сто раз подумать.
А в чём собственно проблема — натянуть зависимостей? Ну будет размер приложения ~ несколько МБ, это разве критично?
Зато — оттестированные, широко используемые библиотеки, которые скорее всего обновляться будут чаще…
protected final Context ctx;
Что произойдёт если Activity закончит своё существование до завершения задачи?
Это я всё к тому, что перед тем как выкладывать библиотеку в открытый доступ (читать — делать публичный API), нужно сто раз подумать.
А в чём собственно проблема — натянуть зависимостей? Ну будет размер приложения ~ несколько МБ, это разве критично?
Зато — оттестированные, широко используемые библиотеки, которые скорее всего обновляться будут чаще…
Классическая ошибка создания синглетона;
Почитайте, например, это
Понятно, что в однопотоковой среде проблем не будет, но если вы решили сделать синглетон, то почему бы не сделать его правильно? =)
Я за простоту и написал бы:
public static Injector get() {
if (injector == null) {
synchronized (Injector.class) {
if (injector == null) {
injector = new Injector(new InjectorDelegate());
}
}
}
return injector;
}
Почитайте, например, это
Понятно, что в однопотоковой среде проблем не будет, но если вы решили сделать синглетон, то почему бы не сделать его правильно? =)
Я за простоту и написал бы:
private static final Injector injector = new Injector();
> Неправильно это, тянуть зависимостей на несколько размеров приложения.
Обфускатор на ура отсекает неиспользуемый код, в результате чего размер приложения становится минимальным, сколько бы зависимостей ни тянул проект.
Обфускатор на ура отсекает неиспользуемый код, в результате чего размер приложения становится минимальным, сколько бы зависимостей ни тянул проект.
Можете подсказать, где именно реализован асинхронный http-загрузчик с кэшированием? Недавно проводил небольшое исследование на эту тему, на удивление — готовых решений не нашёл. Или самоделки на IntentService или AsyncTask, или допиливание Loader-ов, которые сами гугловцы считают сырыми.
Пожалуйста:
В первую очередь это утилита для загрузки
org.droidparts.util.ImageAttacher.В первую очередь это утилита для загрузки
ListView-картинок.Откуда информация, что «гугловцы считают сырыми»?
Много раз смотрел в сторону анотаций, но все же жду FP на Android.
lazy val button = findView(R.id.button) куда лучше смотриться :) Scala не подошла, из-за скорости сборки, и видимо не улучшиться в скором, Kotlin пока что подбирается все ближе и ближе. Но идея оптимизации кода и убрать много лишнего достойна похвал. Уверен библиотека найдет применение.
автор, расскажите плз, почему в AndroidHttpClientWrapper вы используете рефлексию для создания AndroidHttpClient?
Т.к.
AndroidHttpClient появился в API 8, а минимальная для библиотеки — 7.так так так, а если мы на 7-м апи запустим, оно же просто IllegalArgumentException выкинет выше. это ок? может быть, стоило в таком случае DefaultHttpClient создать? и ещё один вопрос — зачем минимальная версия 7?
и вообще я что-то не понимаю, где у вас этот враппер используется
API 7 — необходимый минимум. Т.к. 5% устройств с Android 2.1 ещё остаётся.
Единственный вызов
Единственный вызов
AndroidHttpClientWrapper закомментирован в RESTClient с //TODO, так что по факту DefaultHttpClient и используется. Исправлю, т.к. судя по описанию, AndroidHttpClient стоит использовать.
Насколько я понял из их блога они забили болт и на Default и на Android httpclient и теперь рекомендуют всюду пихать их модный urlconnection: android-developers.blogspot.com/2011/09/androids-http-clients.html
В котором есть пара багов на старых версиях, но по ссылке выше даны рекомендации как их зарефликсить для старых версий. Тем не менее лично мне как то ближе и гибчее и документированней Default клиент.
За либу — спасибо, по крайней мере буду подглядывать как люди пишут, хотя использовать и не буду.
У меня немного другой джентельменский набор утилит:
— свой акшен бар (на базе не помню чьего) либо ставлю шерлок + компатибилити лайбрари если размер не имеет значаения
— враперы над асинктасками на базе активити и фрагментсактивити (обе либы были на хабре)
— выдранныйе из greendroid набор утилит для работы с изображениями типа скалить, маски + асинкимаджвью
— виджеты скроллинг техтвью и акшенбар
— рестфул http слиент на базе intenyservice
Инжектами не пользуюсь, а с бд пока не сталкивался
Плюс в том, что все это независимо — просто папка утилс с набором утилит, легко закинуть только нужные для данного проекта и никаких депенденси, волшебных непонятных штук и прочей магии — весь код на ладони, легко модифицировать если в конкретном проекте что-то надо поменять.
Минус в том что все это как не оформлено в единном стиле чтоли, нет фабрик и всяких абстрактных враперов, просто набор кода. Но для меня плюс более критичен
В котором есть пара багов на старых версиях, но по ссылке выше даны рекомендации как их зарефликсить для старых версий. Тем не менее лично мне как то ближе и гибчее и документированней Default клиент.
За либу — спасибо, по крайней мере буду подглядывать как люди пишут, хотя использовать и не буду.
У меня немного другой джентельменский набор утилит:
— свой акшен бар (на базе не помню чьего) либо ставлю шерлок + компатибилити лайбрари если размер не имеет значаения
— враперы над асинктасками на базе активити и фрагментсактивити (обе либы были на хабре)
— выдранныйе из greendroid набор утилит для работы с изображениями типа скалить, маски + асинкимаджвью
— виджеты скроллинг техтвью и акшенбар
— рестфул http слиент на базе intenyservice
Инжектами не пользуюсь, а с бд пока не сталкивался
Плюс в том, что все это независимо — просто папка утилс с набором утилит, легко закинуть только нужные для данного проекта и никаких депенденси, волшебных непонятных штук и прочей магии — весь код на ладони, легко модифицировать если в конкретном проекте что-то надо поменять.
Минус в том что все это как не оформлено в единном стиле чтоли, нет фабрик и всяких абстрактных враперов, просто набор кода. Но для меня плюс более критичен
Спасибо за ссылку, завёл issue.
И за опыт тоже, поищу здесь информацию о
Кстати, про работу в фоне.
Для разовых ad hoc задач я использую простые враперы над AsyncTask, для повторяющихся — SimpleIntentService. В обоих есть поддержка
И за опыт тоже, поищу здесь информацию о
враперы над асинктасками на базе активити и фрагментсактивити (обе либы были на хабре)
Кстати, про работу в фоне.
Для разовых ad hoc задач я использую простые враперы над AsyncTask, для повторяющихся — SimpleIntentService. В обоих есть поддержка
Exceptions для выполняемого в фоне (идея из RoboGuice) и Listener для сообщения о результате. С Loaderами пока не сложилось.Асинк на фрагментах: habrahabr.ru/post/131560/
Асинк на активити: habrahabr.ru/post/114570/
Мой вариант IntentService (спер из чьегото клевого туториала): pastebin.com/TxEhndEm
Асинк на активити: habrahabr.ru/post/114570/
Мой вариант IntentService (спер из чьегото клевого туториала): pastebin.com/TxEhndEm
Предпочитаю использовать google http client, а не самописные решения. Библиотека использует ту или иную реализацию http клиента в зависимости от версии платформы и предоставляет удобный апи для разбора ответа. Ну и множество других плюшек, разумеется.
Как показывает практика с тем же urlconnection — как раз решения от гугла — самописные поделки с багами в самых неожиданных местах. Апачевскому коду лично у меня больше доверия.
Вообще конкретно заебало уже постоянно латать гуглОвские недоработки в андроиде. То они табактивити депрекейтят, то в асинктаске связь с активити теряют то память в урлконнектион течет то сука неожиданно вместо мультитрединга в сингтрединг тот же асиктаск переключают на ICS. Да что уж там — за хрен знает сколько лет так и не удосужились нормальных виджетов нарисовать, чтоб я уже не говорю о уровне эпл, хотя бы на уровне htc выглядели кнопки из коробки. Чтобы сука не стыдно было в приложения дефолтные контролы вставлять. Чтобы тени были, скругления, а не как в 90-х годах. Пишут они на редкость небрежно. Непродуманно. Без перфекционизма. Хотя вроде есть и нормальные библиотеки у них, тот же протобаф или там gson, но к андроиду, в целом, это к сожалению не относится.
Отсюда и появляются вские враперы типа выше или тот же шерлок, гриндроид и иже с ними.
Вообще конкретно заебало уже постоянно латать гуглОвские недоработки в андроиде. То они табактивити депрекейтят, то в асинктаске связь с активити теряют то память в урлконнектион течет то сука неожиданно вместо мультитрединга в сингтрединг тот же асиктаск переключают на ICS. Да что уж там — за хрен знает сколько лет так и не удосужились нормальных виджетов нарисовать, чтоб я уже не говорю о уровне эпл, хотя бы на уровне htc выглядели кнопки из коробки. Чтобы сука не стыдно было в приложения дефолтные контролы вставлять. Чтобы тени были, скругления, а не как в 90-х годах. Пишут они на редкость небрежно. Непродуманно. Без перфекционизма. Хотя вроде есть и нормальные библиотеки у них, тот же протобаф или там gson, но к андроиду, в целом, это к сожалению не относится.
Отсюда и появляются вские враперы типа выше или тот же шерлок, гриндроид и иже с ними.
Шелрлок нужен для обратной совместимости.
Для обратной совместимости не обязательно ставить шерлок, можно поставить compatibility-library, шерлок основан на ней
developer.android.com/sdk/compatibility-library.html
developer.android.com/sdk/compatibility-library.html
Шерлок — имплементация ActionBar для пре 11-го андроида. Сompatibility-library не содержит ActiobBar. Рекомендация от Google — использовать Action Bar Compatibility
Да,
Хочется надеяться, что с 4.0 у них сформировалось долгосрочное видение как по пользовательскому интерфейсу, так и по API.
@Deprecated TabActivity без адекватной Fragment-based замены — это жесть.Хочется надеяться, что с 4.0 у них сформировалось долгосрочное видение как по пользовательскому интерфейсу, так и по API.
Ну есть запутанный туториал от Великих Программистов из Гугл:
developer.android.com/resources/samples/Support4Demos/src/com/example/android/supportv4/app/FragmentTabs.html
Но я с ним не разобрался. Я так понял в фрагментактивити на онкреэйт стоит как раз та самая заглушка которая должна подымать фрагмент из памяти при открытии таба. Однако в таб получается добавить только класс фрагмента, а фрагментактивити на фрагмент не кастится и весь кайф пропадает, получается что раньше при клике на табе все заново онкреэйтилось, что сейчас, на новых модных фрагментах — все онкреэйтится при каждом клике(
developer.android.com/resources/samples/Support4Demos/src/com/example/android/supportv4/app/FragmentTabs.html
Но я с ним не разобрался. Я так понял в фрагментактивити на онкреэйт стоит как раз та самая заглушка которая должна подымать фрагмент из памяти при открытии таба. Однако в таб получается добавить только класс фрагмента, а фрагментактивити на фрагмент не кастится и весь кайф пропадает, получается что раньше при клике на табе все заново онкреэйтилось, что сейчас, на новых модных фрагментах — все онкреэйтится при каждом клике(
О да, я тоже начинал разбираться с этим чудом инженерной мысли и быстро понял, что такое я в проектах использовать не хочу.
В итоге написал TabbedFragmentActivity. Вкратце: каждый таб — это набор фрагментов, которые при переходе между табами скрываются/отображаются.
В итоге написал TabbedFragmentActivity. Вкратце: каждый таб — это набор фрагментов, которые при переходе между табами скрываются/отображаются.
ну а чем ваше решение отличается/лучше стандартного API для табов в ActionBare?
Оно дополняет. Из доков:
Этим
To switch between fragments using the tabs, you must perform a fragment transaction each time a tab is selected.
Этим
TabbedFragmentActivity и занимается. По аналогии с прежней TabActivity.ну этот костылек для того и написан, чтоб совать фрагменты в tabhost. TabActivity а с ним и ActivityGroup потому и сделали deprecated, чтобы люди не совали Activity/FragmentActivity в табы. Теперь вместо них лучше юзать фрагменты.
По умолчанию относительно удобный режим табов есть для ActionBara. Он нормально выглядит и подстраивается под разные конфигурации UI. если вам нужен именно tabhost, то по вашей ссылке решение для tabhosta.
По умолчанию относительно удобный режим табов есть для ActionBara. Он нормально выглядит и подстраивается под разные конфигурации UI. если вам нужен именно tabhost, то по вашей ссылке решение для tabhosta.
Интересное самописное решение от Google. :)
А что в качестве ORM используется? что-то самописное или уже готовый ORM взяли?
«Но не типичных для Google Play, написанных, очевидно, задней левой mНогой, а приложений корректных и элегантных.» т. е., по-вашему, приложение, не использующее плюшек типа ioc, orm, и прочего мусора по-умолчанию считается написанным некорректно, неэлегантно, и вообще г*вно?
Не обязательно.
А звучит именно так. «Написанные стандартными SDK средствами приложения — говно, а разработчики, старающиеся выжать последнюю каплю производительности, скажем, используя курсор, bulkInsert с инсерт хелпером, компилирующим statement единожды для вставки, скажем, 10000 записей за 200мс на самом деле просто лохи, т. к. не используют навороченный ORM.»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DroidParts — библиотека для Android 8-in-1