androidinject | Android 全平台注入源码 | Android library

HasActivityInjector is a part of dagger.android. You can but not have to use it. You can easily live without this thing and still use everything that dagger offers. That's why it is in some guides but not all of them.

You should read this guide to undestand the purpose of it. It will help you decide if you want it or not. Here's the most important part.

Why Dagger on Android is hard

One of the central difficulties of writing an Android application using Dagger is that many Android framework classes are instantiated by the OS itself, like Activity and Fragment, but Dagger works best if it can create all the injected objects. Instead, you have to perform members injection in a lifecycle method. [...]

This has a few problems:

1. Copy-pasting code makes it hard to refactor later on. As more and more developers copy-paste that block, fewer will know what it actually does.
2. More fundamentally, it requires the type requesting injection (FrombulationActivity) to know about its injector. Even if this is done through interfaces instead of concrete types, it breaks a core principle of dependency injection: a class shouldn’t know anything about how it is injected.

dagger.android

The classes in dagger.android offer one approach to simplify the above problems. This requires learning some extra APIs and concepts but gives you reduced boilerplate and injection in your Android classes at the right place in the lifecycle.

I'm pretty sure Kotlinx.Serialization is not OOB compatible with Bundle's putSerializable. However, you could just stringify your SavedState, send it via putString and on the receiving end deserialize string back to your class.

So you should probably provide the AuthService through a module, one for the normal app and one for the android test, which supplies the mocked version. That would mean removing the Dagger annotations from the AuthService class. I don't use Component.Factory but this example should be enough to for you to use as a guide.

In androidTest folder :

Create test module :

Dagger like compile-time dependency injection tools need once run application. Then it will create automatically if there is no error.

So after going through the source of ViewModelProvider, ViewModelProviders, FragmentActivity and yes the dagger2 documentation I have an answer..

Feel free to correct me if I'm wrong..

We must not inject ViewModel directly, we should inject factories instead.

I am facing this issue due to this line AndroidInjection.inject(this).

As per the dagger authors

It is crucial to call AndroidInjection.inject() before super.onCreate() in an Activity

Let's see what is going wrong here at very high level..

Activity will retain it's ViewModel on rotation using onRetainNonConfigurationInstance and will restore it in onCreate()

As we are injecting before the call to super.onCreate(), we will not get the retained MainViewModel object but the new one.

If you want details, read on..

When dagger tries to inject MainViewModel it calls provideMainViewModel() method of MainModule, which invokes following expression (keep in mind super.onCreate() is not yet called)

I solved the problem.

It's because I didn't add a placeholder image to Picasso in the adapter.

Before:

You can't use an object before you initialize it.

Most likely problems arise from the fact, that you are passing your coroutine exception handler (lets name it CEH) directly to your launch blocks. Those launch blocks are creating new Jobs (important - plain Jobs, not Supervisor ones), which become children of the Job in scope (MainScope in your Scoped Activity).

Ordinary Job will cancel all its children and itself, if any of its children raise an exception. CEH will not prevent this behaviour. It will get those exceptions and do, what it was told to do with them, but it will still not prevent cancellation of Job in scope and all its children. Most importantly IT WILL PROPAGATE EXCEPTION UP THE HIERARCHY TOO. TLDR - crash will not be handled.

In order for your CEH to do its job, you need to install it inside a context with SuperVisorJob (or NonCancellable one). SupervisorJob assumes, that you are supervising exceptions in its scope, so it will not cancel itself or its children, when exception is raised (however, if exception is not handled at all, it will propagate it anyway up the hierarchy).

For example in your ScopedActivity Scope:

Appwidget provicer can be injected the same way a broadcast receiver is injected. By looking at your provided code you can do some thing like this. Create an abstract function