Android fragment setretaininstance deprecated

setRetainInstance is deprecated. What is alternative?

setRetainInstance is deprecated. What alternative?

I have a lot of fragments with many complicated object variables inside them. Today I only have one line of code: setRetainInstance . Full code example is below:

This is more than enough to forget about saving and restoring my objects when changing the configuration (for example, when changing the screen rotation).

What should I change in my code for replacing setRetainInstance ?

Please give me a short code example, if possible.

ATTENTION: I can read the documentation — so please don’t answer in a Google-style manner: «ViewModel is the best. google recommend. and bla-bla. «. And please don’t copy/paste articles from Google documentation — I can view it myself.

If you have a concrete working code solution — I will very appreciate it.

2 Answers 2

The correct solution recommended by Google, consists of using a ViewModel, where you’d not only maintain (and restore) the state, but also asyncrhonously push LiveData (or similar). There’s also now an additional simple semi-automatic solution in the form of the Saved State Module for ViewModel.

When using this module, ViewModel objects receive a SavedStateHandle object through its constructor. This object is a key-value map that lets you write and retrieve objects to and from the saved state. These values persist after the process is killed by the system and remain available through the same object.

So you should always assume your Fragment (and its UI) are temporary, and will be destroyed at the operating system’s earliest convenience. It’s up to you to ensure it doesn’t depend on state being «magically saved» (like setRetainInstance), and instead write your Fragment in a way where it restores its state based on what the ViewModel offers.

Источник

Обновление Android Jetpack: Activity Result API и рефакторинг Fragment

Привет! С вами Android Broadcast. Прошли 2 недели и очередной релиз библиотек Jetpack от Google уже с нами. Вышло долгожданное исправление множества багов в Fragment из-за рефакторинга внутри FragmentManager, Activity Result API и много другого. Все самое интересное вы найдете ниже, а все подробности на сайте

Если вы хотите узнавать про последние новости Android разработки сразу, тогда подпишитесь на Telegram канал Android Broadcast или следите за ними в формате видео на YouTube канале, а также подкасте

Activity 1.2.0

Activity Result API — новое API для получения результата вызова Activity

ComponentActivity теперь реализует ContextAware, что позволяет асинхронно получить Context до вызова Activity.onCreate() . Поддержка Coroutine уже добавлена

Backport метода Activity.reportFullyDrawn(), который теперь работает на всех версиях API, исправлены баги и добавлен трейсинг

Fragment 1.3.0

Большой рефакторинг внутри FragmentManager, который исправил множество багов в работе Fragment. Подробности читайте в статье от Ian Lake

Новое API для передачи результата между двумя Fragment

FragmentOnAttachListener — замена onAttachFragment() из FragmentActivity и Fragment , которая позволяет делегировать событие различным компонентам.

Стандартные эффекты анимаций TRANSITION_* теперь используют Animator вместо Animation

Fragment.setRetainInstance() теперь deprecated. Используйте ViewModel.

Адаптеры, использующие Fragment, для ViewPager 1 теперь deprecated. Мигрируйте на ViewPager 2.

Lifecycle 2.3.0

SavedStateHandle теперь поддерживает не parcelable классы

LifecycleRegistry теперь использует DESTROYED как последнее состояние

LifecycleRegistry теперь проверяет что методы вызываются на главном потоке, в противном случае — креш

Добавлены методы downFrom(State) , downTo(State) , upFrom(State) , upTo(State) для генерации события, чтобы перевести Lifecycle в нужное состояние необходимой последовательностью событий.

Новое API ViewTreeLifecycleOwner, которое позволяет получить LifecycleOwner and ViewModelStoreOwner , основываясь куда добавлена View. Например, это уже реализовано в Activity 1.2.0 и Fragment 1.3.0.

Kotlin расширение LiveData.observe() теперь deprecated. Оно больше не нужно из-за появления SAM для Kotlin интерфейсов.

SavedState 1.1.0

Добавлено API ViewTreeSavedStateRegistryOwner , которое позволяет получить SavedStateRegistry на основе View.

Источник

setRetainInstsance() is been deprecated #577

Comments

worldsnas commented Dec 10, 2019

Since Android team has decided to deprecate setRetainInstance() in fragments and force us to rely on ViewModel , Is there any other way we can use to avoid Controller death when config changes happen?

The text was updated successfully, but these errors were encountered:

MkhytarMkhoian commented Dec 10, 2019

setRetainInstance() still working

PaulWoitaschek commented Dec 10, 2019

Conductor is using framework fragments, not androidx fragments so it’s unaffected by that change.

soniccat commented Dec 10, 2019

@PaulWoitaschek hm, that seems even worse as framework fragments are deprecated about a year ago (API 28).

PaulWoitaschek commented Dec 10, 2019

How is that an issue? The LifecycleHandler is only delegating basic lifecycle events and I’m pretty sure it won’t get removed in a future android version.

soniccat commented Dec 10, 2019

Yes, I agree that it isn’t a critical issue as everything will work for years I suppose. But if Google deprecates something we use, in my opinion, it’s a good idea to start thinking of how we can replace this logic.

My point was that using a deprecated framework Fragment might be error prone as it might not contain fixes which androidx Fragment has. Also not using the same Fragment code might lead to problems which happens only on a particular API version.

Источник

Unable to use Fragment.setRetainInstance() as a replacement for Activity.onRetainNonConfigurationInstance()

According to the Android API documentation, Activity.onRetainNonConfigurationInstance() has been deprecated in favor of Fragment.setRetainInstance().

However, I have run into two separate situations where Fragment.setRetainInstance() doesn’t seem to be feasible to use.

If the Fragment contains a WebView. According to Diane Hackborne, you cannot re-use a WebView across configuration changes. Which I guess means that you need to allow the Fragment to tear-down and re-create the WebView when the screen rotates, and use WebView.saveState() and WebView.restoreState() to restore the web view state.

If the Fragment belongs to a layout that no longer exists after the configuration change, when the FragmentManager tries to restore the Fragment, it will throw:

This can occur (for example) if you have a two-fragment layout in landscape mode, but a one-fragment layout in portrait mode. When rotating from landscape to portrait, if setRetainInstance() set to true, neither Fragment gets destroyed, but one fragment no longer has a valid view to be re-attached to, hence the exception.

So, if you’re building a Fragment-based application, and you need to retain data (for example references to running AsyncTasks) between configuration changes, and you can’t use Fragment.setRetainInstance(), and there is no Fragment.onRetainNonConfigurationInstance(), what is the best approach to take?

2 Answers 2

Even if you use Fragment.setRetainInstance() , the Fragment will still tear down its view and recreate it following a configuration change. That is, onDestroyView() and onCreateView() will be called in that sequence. Make sure to invalidate old references to the WebView in onDestroyView() . You do not have to worry about re-using a WebView — a new WebView will be recreated with the correct Activity context. This is somewhat irrelevant because for saving WebView state, you still need to call WebView.saveState(Bundle) in Fragment.onSaveInstanceState(Bundle) , and WebView.restoreState(Bundle) in Fragment.onViewCreated(Bundle) . This just means that Fragment.setRetainInstance() is still compatible with use of WebViews.

The example you gave regarding a view container no longer existing in another orientation would mean that you do not need to retain any data — the fragment is not to be used at all after screen rotation.

Источник

Understanding Fragment’s setRetainInstance(boolean)

Starting with the documentation:

public void setRetainInstance (boolean retain)

Control whether a fragment instance is retained across Activity re-creation (such as from a configuration change). This can only be used with fragments not in the back stack. If set, the fragment lifecycle will be slightly different when an activity is recreated:

• onDestroy() will not be called (but onDetach() still will be, because the fragment is being detached from its current activity).
• onCreate(Bundle) will not be called since the fragment is not being re-created.
• onAttach(Activity) and onActivityCreated(Bundle) will still be called.

I have some questions:

Does the fragment also retain its view, or will this be recreated on configuration change? What exactly does «retained» mean?

Will the fragment be destroyed when the user leaves the activity?

Why doesn’t it work with fragments on the back stack?

Which are the use cases where it makes sense to use this method?

5 Answers 5

First of all, check out my post on retained Fragments. It might help.

Now to answer your questions:

Does the fragment also retain its view state, or will this be recreated on configuration change — what exactly is «retained»?

Yes, the Fragment ‘s state will be retained across the configuration change. Specifically, «retained» means that the fragment will not be destroyed on configuration changes. That is, the Fragment will be retained even if the configuration change causes the underlying Activity to be destroyed.

Will the fragment be destroyed when the user leaves the activity?

Just like Activity s, Fragment s may be destroyed by the system when memory resources are low. Whether you have your fragments retain their instance state across configuration changes will have no effect on whether or not the system will destroy the Fragment s once you leave the Activity . If you leave the Activity (i.e. by pressing the home button), the Fragment s may or may not be destroyed. If you leave the Activity by pressing the back button (thus, calling finish() and effectively destroying the Activity ), all of the Activity s attached Fragment s will also be destroyed.

Why doesn’t it work with fragments on the back stack?

There are probably multiple reasons why it’s not supported, but the most obvious reason to me is that the Activity holds a reference to the FragmentManager , and the FragmentManager manages the backstack. That is, no matter if you choose to retain your Fragment s or not, the Activity (and thus the FragmentManager ‘s backstack) will be destroyed on a configuration change. Another reason why it might not work is because things might get tricky if both retained fragments and non-retained fragments were allowed to exist on the same backstack.

Which are the use cases where it makes sense to use this method?

Retained fragments can be quite useful for propagating state information — especially thread management — across activity instances. For example, a fragment can serve as a host for an instance of Thread or AsyncTask , managing its operation. See my blog post on this topic for more information.

In general, I would treat it similarly to using onConfigurationChanged with an Activity . don’t use it as a bandaid just because you are too lazy to implement/handle an orientation change correctly. Only use it when you need to.

Источник