Save frame refactor part 6 (8) - fix glitch on static background frames #256
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This builds on #255.
This PR fixes a problem when the currently selected frame is a static background frame, and pressing SAVE (Next) would make the added Views disappear and not appear again until the user switches to another frame and then switches back again to that frame.
Internally, the
saveFrame()
algorithm removes and adds the user-added Views to each ghost offscreenPhotoEditorView
, and finally removes the addedViews so these can be added back to the actual PhotoEditorView being shown on the screen. But, theFrameSaveManager
is never passed the actual screen'sPhotoEditorView
, so we can't really re-add the views for the selected frame once things are finished (as a matter of fact theFrameSaveManager
doesn't even know which frame is selected, as that's responsibility of theStoryViewModel
).So, this PR introduces a small workaround to refresh the selected frame and re-add the views by calling
storyViewModel.setSelectedFrameByUser()
on the current index once the saveStory() method has returned.To test: