Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
I proposed this which I think it is better than the actual behavior, and could let the developers work with more room to be creative.
https://code.google.com/p/android/issues/detail?id=58318
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #3
The presentation link doesn't work.
il...@google.com <il...@google.com> #4
In Custom Notification Layouts section of the Notification API Guides, it states: "The height available for a custom notification layout depends on the notification view. Normal view layouts are limited to 64 dp, and expanded view layouts are limited to 256 dp". I guess it means the width is 512 dp and the height is 256 dp (if following the 2:1 aspect ratio)?
http://developer.android.com/guide/topics/ui/notifiers/notifications.html#CustomNotification
Description
Component used: Fragment Version used: 1.3.0-alpha06
When using
setReorderingAllowed(true)
(such as when using the Navigation Architecture Component), doing areplace()
will cause the new fragment to go throughonCreateView()
,onViewCreated()
and potentially up throughonStart()
andonResume()
before the previous fragment is stopped.This means that any values that are set on a shared view model (i.e., when returning a result ) during one of those methods is immediately sent to the other fragment instead of waiting for the user to return to the previous fragment.
Ideally, the previous fragment should be stopped (but specifically not have its view destroyed) prior to the new fragment moving up through lifecycle methods.