Fixed
Status Update
No update yet.
Comments
yb...@google.com
We're working with the material team to ensure that Navigation matches the new material design guidelines.
an...@gmail.com
Hi everyone. What is the progress or official decision on this one?
fr...@gmail.com
Hey guys, is there any progress on this issue? Can we expect these features to be implemented in the near future?"
da...@google.com
xm...@gmail.com
Any update on this?
mu...@gmail.com
We'll update the bug here when there's updates to post. Suffice it to say, there's still work to do and we're dedicated to getting it done."
wo...@gmail.com
Hey guys, any update on this?"
ya...@google.com
ap...@google.com
The two biggest issues and annoyances of this bug for our end users with the new Navigation library and Bottom navigation bar are:
- Changing tab with the bottom bar resets the state and backstack of the previous tab/fragment, so our users are completely losing their navigation history (this is correctly implemented in Google Photos app)
- Pressing back from the root of one tab shows the initial tab/fragment instead of leaving the app"
- Changing tab with the bottom bar resets the state and backstack of the previous tab/fragment, so our users are completely losing their navigation history (this is correctly implemented in Google Photos app)
- Pressing back from the root of one tab shows the initial tab/fragment instead of leaving the app"
ya...@google.com
to...@gmail.com
I'm also facing this issue. Looking forward to the update.
Description
Version used: 1.0.0-beta1
Devices/Android versions reproduced on: n/a
There appears to be no way to execute a CREATE VIEW in a way that Room will recognize. Instead, developers seem to need some icky workarounds (see
My guess is that there should be a VIEW equivalent of @Entity, where the annotation takes the SELECT statement to go after the AS in the CREATE VIEW statement, where the Room compiler then assembles the rest.
Alternatively, @Entity could be extended to support views (e.g., via a viewSelect annotation property that triggers CREATE VIEW instead of CREATE TABLE logic). Bonus points here: there's no need to figure out the right annotation for a VIEW (since @View probably has been used 28 times already in various Android annotation processors...). :-)
Thanks for considering this!