bluelinelabs / bluelinelabs/Conductor
RestoreViewOnCreateController restoring hierarchyState after onCreateView provides viewState
- Dominant language
- Java
- Stars
- 3.9k
- Forks
- 338
- PR merge metrics
- No merged PRs in 30d
Description
The attractiveness of `RestoreViewOnCreateController` comes from the fact that `onCreateView` signature includes a saved view state parameter. The provided `Bundle` is the one saved under the key `KEY_VIEW_STATE_BUNDLE`. This is called **viewState**.
There is an additional `Bundle` related to the view state and saved under `KEY_VIEW_STATE_HIERARCHY` - this one attempts to hold what `View.saveHierarchyState()` wants to persist. This is called **hierarchyState**.
The issue is that if Conductor allows for view related data to be persisted in **viewState** and then this is provided when the view is created (in `RestoreViewOnCreateController.inCreateView()`), then it shouldn't restore later the **hierarchyState**, because values automatically persisted in **hierarchyState** will overwrite values restored at creation time from **viewState**.
Simple, random example: a `TextView` that will be initialized in `RestoreViewOnCreateController.inCreateView()` based on a value stored in **viewState**, but then, later (at `Controller.onRestoreViewState()` time) it will be overwritten by the value automatically stored in the **hierarchyState**.
One proposal would be to restore **hierarchyState** inside `RestoreViewOnCreateController.onCreateView()` and set `hasSavedViewState= false` so that no more restoring will happen later.
What do you think?
Contributor guide
Research direction
Start by reading RestoreViewOnCreateController.inCreateView() and onCreateView(), then trace Controller.onRestoreViewState() to compare when viewState and hierarchyState are applied. Confirm the overwrite sequence described for TextView state and determine the intended lifecycle change; done means hierarchyState no longer overwrites values restored from viewState.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, java
- Domain
- mobile
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100