Comments 41
Ретрофит — хоршо подходит если надо быстро получтиь данные из сети, наверно быстрее всегоп озволят это сделать
Dagger не нужен. Целая библиотека для инициализации полей. В мое время для этого хватало присваивания.
int k = 0; это по-прежнему делают присваиванием. Но люди сами пришли к тому что им нужна такая библиотека. Большинство проектов которые выходят за грань проектов типа нажал на кнопку и поменялся текст используют dagger ведь в некоторых приложениях десятки, а то и сотни классов, и держать в голове, в конце концов код сильно нагромождается присваиванием и вы сами не поймете что и где и зачемАргумент типа "все так делают", конечно, просто супер.
"код сильно нагромождается присваиванием"
Не хотел бы я видеть такой проект, в котором инициализация полей занимает так много места по сравнению с остальным кодом.
Я считаю, что даггер любят только те, кто считают, что это синоним DI. Но ведь это не так. DI можно и нужно придерживаться и без даггера. Он, наоборот, ухудшает читаемость кода и к тому же усложняет процесс сборки, не принося никакой пользы.
Про сабж: https://soundcloud.com/leonid-bogolubov/android-dev-2#t=24:00
Не хотел бы я видеть такой проект, в котором инициализация полей занимает так много места по сравнению с остальным кодом.
Какая разница где проходит инициализация по всему коду или в одном участке? Если вы вынесите инициализацию каждого поля в отдельную функцию(что делают не редко), то поймете что кода не намного меньше.
И если следовать вашей логике, тогда функции это бесполезный хлам, который никому не нужен, ведь они занимают так много места по сравнению с другим кодом. Но это звучит абсурдно, так как без функций ни одна программа не работает, ведь даже если и есть хоть малейшая вероятность сделать это — потом ни один здравомыслящий человек не полезет туда, так как там нету никакой структуры, и все абсолютно нечитабельно. Тоже самое можно сказать и про классы. Если всунуть весь код с огромной программы в один класс, то мы сильно сократим общее количество строк(вы только представьте себе как это будет «прекрасно»). Но так никто не делает, все хотят видеть структуру(снова будете говорить про аргумент типа «все так делают»?). И Dagger только вносит дополнительную структуру точно также как это делают функции и классы.
Ничего не понял из того, что вы сказали.
Dagger вносит в код структуру, которой нету при обычном присваивании.
В код структуру вносит программист, а не библиотека.
Какая разница где проходит инициализация по всему коду или в одном участке? Если вы вынесите инициализацию каждого поля в отдельную функцию(что делают не редко), то поймете что кода не намного меньше.
Вы это вообще к чему?
Последний параграф не смог распарсить.
Про сабж: https://soundcloud.com/leonid-bogolubov/android-dev-2#t=24:00
Мда, такие себе спецы там общаются…
Первый человек говорит: "Даггер — одно из средств реализаций DI, делать Даггер только потому что ты хочешь делать DI — это значит не понимать, как ещё можно сделать DI. Самый тупой вариант — это сделать фабрики. По-сути — это тоже самое, что делает даггер. Делаете локальное поле, и вместо new Service() присваиваете ServiceFactory.create(...)".
Другой человек говорит, что "во многих проектах гугла используется самописная реализация DI, Map-like. DI на хэшмапе пишется очень-очень быстро..."
Оба "спеца" сами путают DI и IoC, ведь DI — это одна из реализаций IoC. Первый человек рассказал про ещё один вариант реализации IoC — Factory Pattern, второй — про ещё одну реализацию — ServiceLocator.
Да, всё это разновидности IoC, но DI принципиально отличается от других реализаций.
DI можно и нужно придерживаться и без даггера
Позвольте узнать, как? Не, реализаций DI много, но все они примерно одинаково выглядят. Что вы советуете использовать?
ведь в некоторых приложениях десятки, а то и сотни классов, и держать в голове, в конце концов код сильно нагромождается присваиванием и вы сами не поймете что и где и зачем
А как тут помогает даггер? Вот я открыл стандартрный пример с CoffeMaker'ом. Там классов не сотни, там 3 класса и 3 интерфейса. Но пока я не посмотрел каждый и не нарисовал диаграмму на бумаге, я так и не смог понять как это все взаимодействует.
И мне кажется без даггера разорбраться было бы проще. Было бы сразу видно откуда приходит тот или иной объект и как и чем он инициализируется.
1) Вьюхи приходится располагать в самой большой области видимости
2) Annotation processing не позволяет использовать private модификатор
3) Необходимо расставлять аннотации
@Nullable если вьюха не должна инициализироваться.Имея все это, лучше уж
findViewById, с 26 api даже кастовать не нужно.«Предвидя возможные вопросы о нарушении одного из важнейших принципов ООП, а именно — инкапсуляции, отвечу: конечно нарушает. Но сильно ли это может повлиять на ваше приложение? Ведь никто в здравом уме не будет напрямую обращаться к полю класса, а именно views, и менять его состояние. Конечно, могут быть разные ситуации, но это очень плохая практика — напрямую обращаться к полю класса. Для этого есть геттеры сеттеры.»
Тем более butterknife способен не только на инициализацию вьюх.
Честно говоря, не понимаю зачем нужен этот пост и на кого он рассчитан. Retrofit де-факто стандарт при разработке, а ButterKnife и Dagger2 чуть ли не на каждом углу упоминаются. Полной сути использования данных библиотек пост не раскрывает, а в случае с MutliDex (про который вообще есть оф.документация) еще и неверная информация преподносится.
Caution: Do not executeMultiDex.install()or any other code through reflection or JNI beforeMultiDex.install()is complete. Multidex tracing will not follow those calls, causing ClassNotFoundException or verify errors due to a bad class partition between DEX files.
Для подключения MultiDex есть 3 способа:
- Указать в манифесте у
applicationпараметрandroid:name="android.support.multidex.MultiDexApplication" - Отнаследовать свой класс
AppотMultiDexApplication - Вызвать
MultiDex.install(this);
в методеattachBaseContext(Context)своего класса App`
Retrofit де-факто стандарт при разработке, а ButterKnife и Dagger2 чуть ли не на каждом углу упоминаются.
Но в заголовке так и написано: must have для андроид разработчика. То есть самые используемые библиотеки при разработке, которые есть практически в любом приложении. И я лишь указал базовые штуки, что бы можно было сразу получить результат тем кто только начал знакомство с этими библиотеками, ведь если бы я начал описывать все на что способна каждая библиотека то пост вышел бы слишком длинным, и мало кому хватило бы выдержки дочитать до конца. Возможно позже я набросаю статьи про каждую библиотеку отдельно или вставлю ссылки по которым сам изучал.
А за Multidex — спасибо. Я впервые познакомился с Multidex когда получил Exception, и нашел это на stackoverflow. Я обновлю информацию.
1) Вьюхи приходится располагать в самой большой области видимости
Можно объявлять поля/методы как protected при использовании ButterKnife
class ExampleActivity extends Activity {
@BindView(R.id.title) TextView title;
@BindView(R.id.subtitle) TextView subtitle;
@BindView(R.id.footer) TextView footer;
@Override public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.simple_activity);
ButterKnife.bind(this);
// TODO Use fields...
}
}protected, но никто не сказал что это запрещено(как с private).1) Вьюхи приходится располагать в самой большой области видимости
Под областью видимости я имел в виду скоуп переменной, то есть где-то в коде мне нужно инициализировать вью и задать ей лисенер, но для этого мне необходимо объявлять ее полем класса.
В этом списке как-то пустовато. Не хватает RxJava2, AutoValue, Gson/Jackson ну и опционально Moxy.
Датабайндинг не всем подходит. Замедляет компиляцию, утекает логику во вьюхи, в принципе билдскрипт становится неоправданно сложнее, что мешает использовать хот релоад и тп.
А вообще, проблема с поиском вьюх сильно надумана. Она никогда больше пяти процентов времени не занимала, соответственно все эти паттерны можно коту под хвост с чистой совестью. Чистота кода важнее.
2 — норм
3 — не нужен
4 — не нужен
Glide +2.9k методов,
Picasso 850
IcePick — генерация onsaveinstancestate
Dagger не создан гуглом, первую версию писали ребята из Square, dagger 2 форк без использование рефлексии
apply plugin: 'com.neenbedankt.android-apt'
все возможности apt уже давно встроены в Gradle plugin (начиная с версии 2.2),
используется annotationProcessor вместо apt импортировать ничего не нужно
А кто пробовал искать View не по id, а, скажем, через getChildAt()?
Шпаргалка или Must have для андроид разработчика