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

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

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

Месье знает толк в извращениях!
Из разряда «оговорок по Фрейду» =) Поправил, спасибо.
Зачем нужно наследование от Robo-классов?
Robo-классы делают инъекции в методах onCreate(), setContentView() и прочих. Также они делают другие необходимые операции по инициализации инъекций.
К тому же необходимо вызывать super.onCreate() метод из своего onCreate(). Иначе инъекции не будут проинициализированы.
Я всегда думал, что инъекции делают из класслоадеров — в таком случае ничего в коде кроме аннотаций менять не нужно.
Может быть. Но в случае RoboGuice используется другой подход. Может Dalvik VM не позволяет переопределять class loaders, может это сложнее в имплементации на порядок.
> и существенно облегчает жизнь разработчикам
надо в первую очередь думать о пользователях, а не о том — «ух ты как круто и удобно я могу тут запрограммить с помощью 100500 костылейштук о которых все пишут в интернетах»
Несомненно, что о пользователях надо думать в первую очередь. Однако чем проще писать программы, тем больше возможностей и времени у разработчиков облегчить жизнь тем самым пользователям.
Возможно, конечно, я дико торможу, но разве нельзя проинициализировать поля класса во время их объявления?

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

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

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

developer.android.com/reference/android/app/Activity.html#setContentView(int)
А как ты их проинициализируешь? Пока не сделаешь setContentView Андроид просто не знает, где искать.
Согласен, всё-таки «дико торможу» :-)
А если не создавать макет из xml? Ну то есть с помощью инфлейтера сконструировать макет в коде.

Тогда, наверно, можно проинициализировать представления заранее, но всё равно кода добавится…
НЛО прилетело и опубликовало эту надпись здесь
IDE позволяет это сделать, компиляция проходит без эксцессов.
это проблемы IDE, когда в java не было generics, тоже можно было наворотить так, что компилятору пофиг…
НЛО прилетело и опубликовало эту надпись здесь
А где анализы того, что происходит в реальности? Чего такого там на 500кб? Какой код он генерирует?

Как показывает практика, 90% подобных автоматических штук выходит бяка. Причем в EE это вполне нормально — там все достаточно предсказуемо и тпх, а вот в мобилках… тут производительность и поведение критичны и непредсказуемы
Если под «бякой» вы имеете в виду особенности жизненного цикла мобильных аппов, то roboguice вполне о них знает и корректно обрабатывает.
Сам roboguice-1.1.1.jar занимает около 100 Кб и содержит «обертки» для activity-классов, некоторых других служебных классов (например Application) и имплементации инъекций специфичных для Андроида объектов (например SharedPreferences).
Остальное занимает guice-2.0-no_aop.jar, который непосредственно и отвечает за возможности dependency injection.
Никакой непредсказуемой бяки не генерируется, влияние на производительности минимально. Как для RoboGuice, так и Google Guice можно скачать исходные коды и посмотреть что и как работает. Всё открыто и доступно, никакой скрытой магии.
Джус вещь своеобразная. Использую, но только не на андроид. Моё приложение с джусом будет в 7 раз больше, что совсем не приемлемо для моих пользователей. По поводу уменьшения производительности, то её нет, кроме времени запуска, когда guice всё связывает и создаёт все объекты по цепочке! Время запуска приложения является одним из важных параметров, которые стремятся оптимизировать, в guice нужно использовать *Factory чтобы прервать цепочку загрузок в начале, что делает код уже не таким красивым. Вообщем, джус и андройд у меня в голове настолько не совместимы, что я даже не смог перейти в андройд-проект где используют эту связку.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.