К сожалению RoboGuice заставляет производительность плакать. Из-за него время запуска приложения может достигать секунд.
Особенно печально это при обработке широковещательных сообщений. Что-бы запустить обработку сего сообщения на незапущенном приложении, необходимо создать объект Application, который потянет за собой инициализацию RoboGuice. Казалось бы, подумаешь — немного батарейки сожрет и все. А если представить что это сообщение обработка клика по виджету?
На мой взгляд, разрешать экземпляры View по id, как вообщем и распределять программу по потокам (AsyncTask), пробрасывать объекты через всю иерархию вызовов, и т.п. — это сквозная логика.
А её лучше либо отделять либо вообще избавляться. так как она затрудняет чтение кода ответственного за бизнес-логику.
Немного смутила ситуация с инъекциями. Например тот же @ViewById задекларированный в классе помеченным @EBean незаметно потащит за собой весь контекст, что может привести к утечке памяти при потери бдительности (а библиотека как раз этому способствует).
Она не лишена недостатков, однако при осторожном использовании позволит избавится от бойлерплейтного кода который уже так надоел мне.
Собственно крик души у меня был в том, что в C# эти (и далеко не только) проблемы решены, однако, по некоторым причинам .NET использовать не представляется возможности.
Руки оторвать:
— Тем кто придумал Java generic не как first class.
— Тем кто использует Integer вообще в коллекциях.
— Тем кто из-за недостатков подхода из второго пункта придумывает гибриды костылей с велосипедами.
А если придумать механизм апдейта схемы, то и загружать ничего не придется.
Особенно печально это при обработке широковещательных сообщений. Что-бы запустить обработку сего сообщения на незапущенном приложении, необходимо создать объект
Application, который потянет за собой инициализацию RoboGuice. Казалось бы, подумаешь — немного батарейки сожрет и все. А если представить что это сообщение обработка клика по виджету?Viewпо id, как вообщем и распределять программу по потокам (AsyncTask), пробрасывать объекты через всю иерархию вызовов, и т.п. — это сквозная логика.А её лучше либо отделять либо вообще избавляться. так как она затрудняет чтение кода ответственного за бизнес-логику.
Немного смутила ситуация с инъекциями. Например тот же
@ViewByIdзадекларированный в классе помеченным@EBeanнезаметно потащит за собой весь контекст, что может привести к утечке памяти при потери бдительности (а библиотека как раз этому способствует).Она не лишена недостатков, однако при осторожном использовании позволит избавится от бойлерплейтного кода который уже так надоел мне.
@ViewById.2. как указал автор, эта аннотация имеет необязательный аргумент типа int, позволяющий задать id искомого
View.Отвечу коротко: Не всегда.
UriCodec.appendEncoded. Насколько я помнюlibcoreявляется частью внутренних библиотек Android.Собственно крик души у меня был в том, что в C# эти (и далеко не только) проблемы решены, однако, по некоторым причинам .NET использовать не представляется возможности.
Byte — исключение.
— Тем кто придумал Java generic не как first class.
— Тем кто использует Integer вообще в коллекциях.
— Тем кто из-за недостатков подхода из второго пункта придумывает гибриды костылей с велосипедами.
Извините, наболело.
Скилл наточил просмотром всяких конференций, трансляций и видео курсов.