Ответ 1
После полудня борьбы, наконец, переместившись в Кинжал 2.7, исправлена проблема.
compile "com.google.dagger:dagger:2.7"
apt "com.google.dagger:dagger-compiler:2.7"
Недавно я попытался перенести приложение, над которым я работаю, от GCM
до FCM
. При этом я обнаружил, что, когда я ранее использовал Dagger 2 (2.0.2)
, чтобы предоставить экземпляры моих API-интерфейсов Retrofit
и других менеджеров пользовательских данных внутри службы (без проблем), я больше не мог этого сделать для FirebaseMessagingService
.
Всякий раз, когда я пытаюсь скомпилировать с подклассом FirebaseMessagingService
, указанным в моем интерфейсе Dagger 2 Component
, я бы получил IllegalArgumentException
. После копания через некоторый код кажется, что исключение возникает, когда Dagger 2
пытается проверить имя класса и обнаруживает, что первая буква не является прописной. FirebaseMessagingService
, по крайней мере, на моем конце, наследуется от укрупненной/минифицированной кодовой базы, а ее ближайший суперкласс - zzb
(public class FirebaseMessagingService extends com.google.firebase.iid.zzb
).
Мое лучшее предположение, что это преступник. Если это действительно проблема, я не уверен, что делать с этим в стороне от stick до GCM
. У кого-нибудь есть идеи или аналогичный опыт?
EDIT: у меня появилась возможность спросить одного из разработчиков Firebase об этой проблеме: https://www.reddit.com/r/androiddev/comments/4upj1o/beware_of_the_new_firebase/d5tdbk3 - Без разрешения. Я, вероятно, собираюсь избегать прямого впрыска и консолидироваться у поставщика статического API.
После полудня борьбы, наконец, переместившись в Кинжал 2.7, исправлена проблема.
compile "com.google.dagger:dagger:2.7"
apt "com.google.dagger:dagger-compiler:2.7"
У нас была та же проблема, Кинжал делает какую-то глупую проверку для класса uppercase classname и встречает запутанное имя класса, которое на самом деле выглядит как
public class FirebaseService extends xxab {
}
( xxab - просто случайное имя, которое proguard плюет в обфускационном проходе, и я могу запомнить точное)
Мы делали глупые обходные пути, а не изящные, но работали:
public class FirebaseServiceProvider { //not real provider, though
public FirebaseServiceProvider(...params){
mInstance = ...
}
public FirebaseService getService(){
return mInstance;
}
}
В @Module
:
@Singleton
@Provides
public FirebaseServiceProvider providesFirebaseServiceProvider(){
return new FirebaseServiceProvider(.....);
}
Инъекции:
@Inject
FirebaseServiceProvider mFirebaseServiceProvider;
Использование:
mFirebaseServiceProvider.getService().doStuff();