Dagger-Hilt 2.49: Activity onCreate() and onDestroy() code is generated, but our base Activity class has these final about dagger HOT 5 OPEN

Unfortunately, being able to override standard methods is going to be a requirement for using Hilt. In that BroadcastReceiver example, we inject in onReceive, so there's not much we can do if it is final. I know there is a new onMessageReceived that users are supposed to override, but there's not really going to be a good way for Hilt to know how to use that. Same for any other method we might try to use. Like for onCreate there happens to be the lifecycle as an alternative (though that changes the timing and order as of calls), but for things like getDefaultViewModelProviderFactory, we have to be able to override it. It would be too limiting to say Hilt has to deal with the possibility of any standard method being possibly unavailable to override.

The best you can do is raise issues to libraries that make these methods final and ask them to use something like @CallSuper instead. Otherwise, as a workaround, you can try to use @EntryPoint annotations to inject dependencies, though for things like Activities that have their own component that unfortunately won't help you create a component for the activity to own, it'll just help you get things from the SingletonComponent.

I'm going to leave this issue open though since we could give a better error message in these cases, rather than just generating the method and letting the compiler catch the override issue.

from dagger.

Hi, Caleb, we had to override the lifecycle methods in order to lazily provide SavedStateHandle, I'll try to improve the error message, do you have to use final for those methods?

from dagger.

Let me follow up to see if we can get our own custom activity to remove final. I have a suspicion those were added a long time ago and is now obsolete. It's honestly also a bit of an antipattern anyways.

from dagger.

@wanyingd1996 - We removed final from our base Activity classes. Can probably close this out. (That said, still wondering if there's another pattern of implementation that could avoid this, but probably another conversation to be had if this is a more common issue)

from dagger.

This effects any other abstract/custom implementation with final interface methods (like BroadcastReceivers on an SMS app using klinker logic).

https://github.com/klinker41/android-smsmms/blob/master/library/src/main/java/com/klinker/android/send_message/MmsReceivedReceiver.java#L88

from dagger.