Как стать автором
Обновить

Комментарии 41

Dagger2 — пожалуй самая поллезная библиотека из этого списка.

Ретрофит — хоршо подходит если надо быстро получтиь данные из сети, наверно быстрее всегоп озволят это сделать

Dagger не нужен. Целая библиотека для инициализации полей. В мое время для этого хватало присваивания.

Пускай это прозвучит грубо, но: начнем с того когда было ваше время? Никто никого не заставляет использовать dagger2, и можно по-прежнему просто присваивать — это не запрещено, ведь вряд ли кто-то будет использовать dagger для int k = 0; это по-прежнему делают присваиванием. Но люди сами пришли к тому что им нужна такая библиотека. Большинство проектов которые выходят за грань проектов типа нажал на кнопку и поменялся текст используют dagger ведь в некоторых приложениях десятки, а то и сотни классов, и держать в голове, в конце концов код сильно нагромождается присваиванием и вы сами не поймете что и где и зачем

Аргумент типа "все так делают", конечно, просто супер.


"код сильно нагромождается присваиванием"


Не хотел бы я видеть такой проект, в котором инициализация полей занимает так много места по сравнению с остальным кодом.


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


Про сабж: https://soundcloud.com/leonid-bogolubov/android-dev-2#t=24:00

Аргумента «типа все так делают» не было. Dagger вносит в код структуру, которой нету при обычном присваивании.
Не хотел бы я видеть такой проект, в котором инициализация полей занимает так много места по сравнению с остальным кодом.


Какая разница где проходит инициализация по всему коду или в одном участке? Если вы вынесите инициализацию каждого поля в отдельную функцию(что делают не редко), то поймете что кода не намного меньше.

И если следовать вашей логике, тогда функции это бесполезный хлам, который никому не нужен, ведь они занимают так много места по сравнению с другим кодом. Но это звучит абсурдно, так как без функций ни одна программа не работает, ведь даже если и есть хоть малейшая вероятность сделать это — потом ни один здравомыслящий человек не полезет туда, так как там нету никакой структуры, и все абсолютно нечитабельно. Тоже самое можно сказать и про классы. Если всунуть весь код с огромной программы в один класс, то мы сильно сократим общее количество строк(вы только представьте себе как это будет «прекрасно»). Но так никто не делает, все хотят видеть структуру(снова будете говорить про аргумент типа «все так делают»?). И 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 интерфейса. Но пока я не посмотрел каждый и не нарисовал диаграмму на бумаге, я так и не смог понять как это все взаимодействует.

И мне кажется без даггера разорбраться было бы проще. Было бы сразу видно откуда приходит тот или иной объект и как и чем он инициализируется.
Он помогает тем что для инициализации вам всего надо написать Inject, а в других случаях у вас было куча кода из-за которого все превращалось в кашу
По поводу Butterknife
1) Вьюхи приходится располагать в самой большой области видимости
2) Annotation processing не позволяет использовать private модификатор
3) Необходимо расставлять аннотации @Nullable если вьюха не должна инициализироваться.

Имея все это, лучше уж findViewById, с 26 api даже кастовать не нужно.
В этом вы правы. Но эти недостатки не так серьезны как кажется на первый взгляд, как сказано в этой статье:
«Предвидя возможные вопросы о нарушении одного из важнейших принципов ООП, а именно — инкапсуляции, отвечу: конечно нарушает. Но сильно ли это может повлиять на ваше приложение? Ведь никто в здравом уме не будет напрямую обращаться к полю класса, а именно views, и менять его состояние. Конечно, могут быть разные ситуации, но это очень плохая практика — напрямую обращаться к полю класса. Для этого есть геттеры сеттеры.»

Тем более butterknife способен не только на инициализацию вьюх.

Честно говоря, не понимаю зачем нужен этот пост и на кого он рассчитан. Retrofit де-факто стандарт при разработке, а ButterKnife и Dagger2 чуть ли не на каждом углу упоминаются. Полной сути использования данных библиотек пост не раскрывает, а в случае с MutliDex (про который вообще есть оф.документация) еще и неверная информация преподносится.


Caution: Do not execute MultiDex.install() or any other code through reflection or JNI before MultiDex.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

Имеет право на жизнь, для тех кто сильно боится размещать view в самой большой области видимости, ведь классы которые генерирует 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.

Согласен мне не помешало бы еще добавить тот же EventBus и Picasso, но статья итак вышла средних размеров. Поэтому позже сделаю вторую часть.
Зачем нынче нужен ButterKnife, если есть нативный Data Binding, который еще сильнее сокращает код?

Датабайндинг не всем подходит. Замедляет компиляцию, утекает логику во вьюхи, в принципе билдскрипт становится неоправданно сложнее, что мешает использовать хот релоад и тп.


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

1 — не нужен
2 — норм
3 — не нужен
4 — не нужен
А что вы используете?
MVP для архитектуры и то не часто, а там где много классов. Причем без фрагментов, на активити и вьюхах. Сторонние библиотеки стараюсь не тянуть в проект, от этого и мультидекс не нужен.
Аргументируйте. Если насчет butterKnife есть хоть какая-то дискуссия, то retrofit считается самой лучшей библиотекой для создания запросов. А MultiDex вообще не заменим. Насчет MVP — это действительно крутая вещь!
Масляничный нож дает вагон оверхеда и взамен по сути ничего, ретрофит я использую сам почти везде, мульти декс нужен если вам лень писать код самому и вы затащили 100500 сторонних библиотек в проект.
Добавляете несколько Support и Google Play Services библиотек — Profit, 65К достигнуты! :)
У меня было точно также. Клиент хотел сделать вроде простенькую приложуху, думал обойдусь без multidex, но клиент захотел геолокацию и тут Google Play Services пробили лимит:)
Их сейчас уменьшают, и прогвард их хорошо режет.
Для работы с изображениями, куда же без них

Glide +2.9k методов,
Picasso 850

IcePick — генерация onsaveinstancestate

Dagger не создан гуглом, первую версию писали ребята из Square, dagger 2 форк без использование рефлексии
apply plugin: 'com.neenbedankt.android-apt'


все возможности apt уже давно встроены в Gradle plugin (начиная с версии 2.2),
используется annotationProcessor вместо apt импортировать ничего не нужно
Насчет того, что первую версию делала компания Square я знал, но где-то читал что гугл сделал на основе первой версии вторую, но все же информацию обновлю. Библиотекой Picasso пользовался, и странно как не добавил. Насчет apt — спасибо.

А кто пробовал искать View не по id, а, скажем, через getChildAt()?

У ButterKnife есть ещё одна удобная фишка. Если в Android Studio пойти в File -> Settings -> Plugins и там добавить плагин ButterKnife Inspections, то нажав правой кнопкой мыши на activity_main в setContentView(R.layout.activity_main); и выбрав Generate -> Generate ButterKnife Inspections, то можно выбирать вьюшки для инициализации прям из появившегося диалогового окна, и они сгенерируются автоматически. Помимо этого там можно ещё и onClick для них генерировать.
У меня на студию установлен плагин butterknife Zelezny можно также генерить
Вот блин, точно, плагин называется Android ButterKnife Zelezny. Injections — это про другое. Спутал, поскольку у меня оба стоят
Это не маст хев список. Все перечисленные библиотеки очень даже опциональны, за исключением, возможно, Retrofit. ButterKnife вообще перестал использовать с переходом на котлин, чему очень рад. Multidex до 21 апи — зло, которого можно постараться уникнуть, используя например Proguard, который, кстати, must have. Имхо, в этом списке должен быть Glide (или Picasso как альтернатива).
Вы правы, про Picasso и Glide я как-то позабыл, насчет того можно ли на котлине и без butterKmife я ничего сказать не могу
Возможно как-нибудь позже и до него руки дойдут :)
Must Have не мультидекс. Must Have — это ProGuard с самого момента старта проекта и постоянное его дополнение в процессе.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.