¿Es una buena práctica usar @Inject para el Fragmento de Android en Dagger2?

Estoy usando @ContributesAndroidInjector of Dagger 2.11.

Funciona sin problemas con las siguientes fonts.
@ActivityScope también está funcionando.

 class MainActivity : AppCompatActivity(), HasFragmentInjector { @Inject lateinit var androidInjector: DispatchingAndroidInjector<Fragment> override fun fragmentInjector() = androidInjector @Inject lateinit var fragment: MainFragment @Inject lateinit var viewModel: MainViewModel override fun onCreate(savedInstanceState: Bundle?) { AndroidInjection.inject(this) super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) fragmentManager.beginTransaction() .replace(R.id.container, fragment) .commitAllowingStateLoss() viewModel.start("activity") } } class MainFragment @Inject constructor() : Fragment() { @Inject lateinit var viewModel: MainViewModel override fun onCreateView(inflater: LayoutInflater?, container: ViewGroup?, savedInstanceState: Bundle?): View? { val view = inflater!!.inflate(R.layout.fragment_main, container, false) return view } override fun onAttach(context: Context?) { super.onAttach(context) viewModel.start("fragment") } } @Module abstract class AndroidModule { @ActivityScope @ContributesAndroidInjector abstract fun contributeMainActivity(): MainActivity } @ActivityScope class MainViewModel @Inject constructor() { ... 

Pero cuando leí el documento , sentí que era correcto usar @ConstructsAndroidInjector así como también la actividad.

Y también en la respuesta aquí , está escrito como

 public class MainActivity { @Inject CoffeeFragment coffeeFragment; //no! don't do this @Inject TeaFragment teaFragment; //no! 

¿Es mi implementación problemática?
¿Qué problemas ocurrirán con mi implementación?

Los fragments son administrados por, bueno, el FragmentManager en Android.

En las subclasss de FragmentActivity , incluida AppCompatActivity , cuando se onSaveInstanceState(Bundle outBundle) en su Activity saveá el estado de sus Fragments.

Del onCreate(Bundle savedInstanceState) modo, onCreate(Bundle savedInstanceState) intentará restaurarlos. Puede hacer que esto suceda al activar Developer Options / Don't keep Activities y navegar dentro y fuera de su aplicación.

En esta situación, si solicita la inyección de su campo de Fragmento nuevamente utilizando Dagger 2, la Actividad hará reference a dos copys del Fragmento: el Fragmento restaurado y el nuevo inyectado. ¡No quieres esto! En cambio, la expresión correcta para manejar el Fragmento en su onCreate es la siguiente:

 fragment = fragmentManager.findFragmentByTag("MAIN") if (fragment == null) fragment = MainFragment.instantiate(null) fragmentManager.beginTransaction() .replace(R.id.container, fragment, "MAIN") .commit() 

donde MainFragment.instantiate(Bundle args) es un método estático en un companion object .

  • Error del comstackdor de la function de desempaquetado de Kotlin
  • Nuevo para Kotlin ... tener problemas con Opcionales y Casting
  • Kotlin enum class en el performance de Android
  • Fundición genérica en Kotlin
  • Spring Boot: Agregar @Transactional produce java.lang.ClassNotFoundException: org.aspectj.util.PartialOrder $ PartialComparable
  • Función de extensión booleana
  • ¿Puedo mezclar Ktor con Exposed?
  • Cómo get la date y hora local actual en Kotlin
  • biblioteca kotlin que puede hacer connection httpS sin verificación de certificate (como curl --insecure)
  • Kotlin Android- ¿Cómo implementar CheckBox.OnCheckedChangeListener?
  • ¿Cómo hacer AppBar universal con Anko DSL?