RoboGuice или «Андроид подсел на инъекции»

[gshock]

Я бы 100% использовал эту библиотеку, но только не в простом приложении. В своем простом приложении мне пока и без DI нормально да и не сильно хочется раздувать размер приложения.
Guice хорошая CDI-реализация и вот теперь она добралась и до Android'а.
Статью прочитал на одном дыхании. Инмемориз однозначно.
Напишите все таки по поводу тестирования android-приложений

[Kipriz]

Как раз разбираюсь с тестированием. Запускать тесты на телефоне или эмуляторе получается, а вот с использованием простых unit-тестов или сторонних библиотек для тестирования под Андроид пока не очень. Как только разберусь, обязательно напишу статью.

[dax]

И был приятно удивлён простатой и изящностью подхода.

Месье знает толк в извращениях!

[Kipriz]

Из разряда «оговорок по Фрейду» =) Поправил, спасибо.

[halyavin]

Зачем нужно наследование от Robo-классов?

[Kipriz]

Robo-классы делают инъекции в методах onCreate(), setContentView() и прочих. Также они делают другие необходимые операции по инициализации инъекций.
К тому же необходимо вызывать super.onCreate() метод из своего onCreate(). Иначе инъекции не будут проинициализированы.

[halyavin]

Я всегда думал, что инъекции делают из класслоадеров — в таком случае ничего в коде кроме аннотаций менять не нужно.

[Kipriz]

Может быть. Но в случае RoboGuice используется другой подход. Может Dalvik VM не позволяет переопределять class loaders, может это сложнее в имплементации на порядок.

[SovGVD]

> и существенно облегчает жизнь разработчикам
надо в первую очередь думать о пользователях, а не о том — «ух ты как круто и удобно я могу тут запрограммить с помощью 100500 костылейштук о которых все пишут в интернетах»

[Kipriz]

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

[Tibr]

Возможно, конечно, я дико торможу, но разве нельзя проинициализировать поля класса во время их объявления?

Это по сути то же самое, что засовывать весь начальный init в onCreate(), насколько я понимаю. Таким образом мусора будет почти столько же, как и при инъекциях.

Извините, просто первый пример совершенно не произвел впечатление :-)

[Zeldan]

как бы матчасть…
setContentView(R.layout.main);
вот в этом вся фишка.В вашем варианте, вы будете пытаться получить по findbyview объект, которого нет еще в view родителя, хотя id конечно же у него есть.

соотвественно вылетит NullPointerExeption

developer.android.com/reference/android/app/Activity.html#setContentView(int)

[Fury]

А как ты их проинициализируешь? Пока не сделаешь setContentView Андроид просто не знает, где искать.

[Tibr]

Согласен, всё-таки «дико торможу» :-)

[Tibr]

А если не создавать макет из xml? Ну то есть с помощью инфлейтера сконструировать макет в коде.

Тогда, наверно, можно проинициализировать представления заранее, но всё равно кода добавится…

[Tibr]

IDE позволяет это сделать, компиляция проходит без эксцессов.

[Zeldan]

это проблемы IDE, когда в java не было generics, тоже можно было наворотить так, что компилятору пофиг…

[Ex3NDR]

А где анализы того, что происходит в реальности? Чего такого там на 500кб? Какой код он генерирует?

Как показывает практика, 90% подобных автоматических штук выходит бяка. Причем в EE это вполне нормально — там все достаточно предсказуемо и тпх, а вот в мобилках… тут производительность и поведение критичны и непредсказуемы

[jeck_landin]

Если под «бякой» вы имеете в виду особенности жизненного цикла мобильных аппов, то roboguice вполне о них знает и корректно обрабатывает.

[Kipriz]

Сам roboguice-1.1.1.jar занимает около 100 Кб и содержит «обертки» для activity-классов, некоторых других служебных классов (например Application) и имплементации инъекций специфичных для Андроида объектов (например SharedPreferences).
Остальное занимает guice-2.0-no_aop.jar, который непосредственно и отвечает за возможности dependency injection.
Никакой непредсказуемой бяки не генерируется, влияние на производительности минимально. Как для RoboGuice, так и Google Guice можно скачать исходные коды и посмотреть что и как работает. Всё открыто и доступно, никакой скрытой магии.

[ivanrt]

Джус вещь своеобразная. Использую, но только не на андроид. Моё приложение с джусом будет в 7 раз больше, что совсем не приемлемо для моих пользователей. По поводу уменьшения производительности, то её нет, кроме времени запуска, когда guice всё связывает и создаёт все объекты по цепочке! Время запуска приложения является одним из важных параметров, которые стремятся оптимизировать, в guice нужно использовать *Factory чтобы прервать цепочку загрузок в начале, что делает код уже не таким красивым. Вообщем, джус и андройд у меня в голове настолько не совместимы, что я даже не смог перейти в андройд-проект где используют эту связку.