Fixed
Status Update
Comments
gg...@google.com <gg...@google.com>
il...@google.com <il...@google.com>
yb...@google.com <yb...@google.com>
at...@gmail.com <at...@gmail.com> #2
ma...@gmail.com <ma...@gmail.com> #3
> We accept pull requests! :)
Is there a public repo somewhere? I don't see any obvious repo for it inhttps://android.googlesource.com , and it doesn't seem to be inside https://android.googlesource.com/platform/frameworks/support .
Room supports final fields (yay!), which probably will suffice for many people with respect to this feature request.
Is there a public repo somewhere? I don't see any obvious repo for it in
Room supports final fields (yay!), which probably will suffice for many people with respect to this feature request.
at...@gmail.com <at...@gmail.com> #4
Room supports immutability (it can use arg constructors) but does not directly support AutoValue. It is in the schedule but not high priority :/. Idk much about its internals at this stage so I'm not sure how we would implement it but should be totally doable.
Sorry we don't have the source release yet :/.
Sorry we don't have the source release yet :/.
il...@google.com <il...@google.com> #5
"It is in the schedule but not high priority" -- completely understandable.
"Sorry we don't have the source release yet :/." -- ah, OK, I thought perhaps with the pull request comment, that meant that there was a repo somewhere that I had overlooked.
Thanks!
"Sorry we don't have the source release yet :/." -- ah, OK, I thought perhaps with the pull request comment, that meant that there was a repo somewhere that I had overlooked.
Thanks!
ma...@gmail.com <ma...@gmail.com> #6
Add autovalue support also means you can easily achieve parcelable by https://github.com/rharter/auto-value-parcel . Please consider support this.
il...@google.com <il...@google.com>
il...@google.com <il...@google.com> #7
AutoValue is really a handy way to ensure data integrity.
ap...@google.com <ap...@google.com> #8
Please add AutoValue support. AutoValue is a Google library with really good benefits such as toString() , hashCode() , AutoValue.Builder , checks at creation time if @NonNull values are null, etc.
ma...@gmail.com <ma...@gmail.com> #9
FWIW, issue 64206877 is not publicly accessible.
at...@gmail.com <at...@gmail.com> #10
@Yigit: That appears to be a private ticket. Any way we can have access to keep up with it?
il...@google.com <il...@google.com> #11
Have any updates?
at...@gmail.com <at...@gmail.com> #12
news?
at...@gmail.com <at...@gmail.com> #13
Is there any update? This is huge for app that absolutely enforces immutable entities.
il...@google.com <il...@google.com> #14
SqlDelight has out of the box support for AutoValue. Use it with SqlBrite and you've got *pretty good* parity with Room. With the lack of movement on this ticket, I'd suggest at least taking a look at those if AutoValue is important to you.
ap...@google.com <ap...@google.com> #15
Support on olways
il...@google.com <il...@google.com> #16
Sorry this used to be higher priority but other features got in the way (and to be honest, androidX migration took a lot more time than we thought).
I want to make 1 thing clear though, Room does support immutable entities. One of the reasons why this ticket lost some priority is that it is specific to AutoValue, not immutability. If you are using Kotlin, data classes give you the same power and Room supports them properly. (hence, there is an easy way to achieve immutability w/ Room).
The issue in this one is that we don't have out of the box support to discover AutoValue builders.
We still plan to do this, sorry that it is taking longer than we initially communicated.
I want to make 1 thing clear though, Room does support immutable entities. One of the reasons why this ticket lost some priority is that it is specific to AutoValue, not immutability. If you are using Kotlin, data classes give you the same power and Room supports them properly. (hence, there is an easy way to achieve immutability w/ Room).
The issue in this one is that we don't have out of the box support to discover AutoValue builders.
We still plan to do this, sorry that it is taking longer than we initially communicated.
Description
The Navigation Component has this very useful function to sync up menu items from a NavigationView with the NavController. It makes sure that the selected item is checked, can close the navigation drawer on selection if a DrawerLayout is used, or set the title of an ActionBar/Toolbar according to the current destination.
With the addition of the bottom app bar in Material Design we've also begun using the bottom navigation drawer (
public class BottomDrawerFragment extends BottomSheetDialogFragment {
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
View view = inflater.inflate(R.layout.fragment_bottom_drawer, container, false);
NavigationView navigationView = view.findViewById(R.id.bottom_drawer_navigation);
NavigationUI.setupWithNavController(navigationView, Navigation.findNavController(getActivity(), R.id.nav_host_fragment));
return view;
}
}
This works well, but because NavigationUI currently doesn't dismiss the BottomSheetDialogFragment when a menu item has been selected like it closes the DrawerLayout, the bottom navigation drawer remains open and needs to be dismissed in another way (which comes with additional code overhead and issues).
Since AndroidX is now part of AOSP, I took a look at the implementation and I think that support for this could be added with two lines of code (see '+' characters at beginning of lines below) by doing for the DialogFragment what is already done for the DrawerLayout (excerpt from androidx-master-dev/navigation/ui/src/main/java/androidx/navigation/ui/NavigationUI.java).
public static void setupWithNavController(@NonNull final NavigationView navigationView,
@NonNull final NavController navController) {
navigationView.setNavigationItemSelectedListener(
new NavigationView.OnNavigationItemSelectedListener() {
@Override
public boolean onNavigationItemSelected(@NonNull MenuItem item) {
boolean handled = onNavDestinationSelected(item, navController, true);
if (handled) {
ViewParent parent = navigationView.getParent();
if (parent instanceof DrawerLayout) {
((DrawerLayout) parent).closeDrawer(navigationView);
+ } else if (parent instanceof BottomSheetDialogFragment) {
+ ((DialogFragment) parent).dismiss();
}
}
return handled;
}
});
navController.addOnNavigatedListener(new NavController.OnNavigatedListener() {
@Override
public void onNavigated(@NonNull NavController controller,
@NonNull NavDestination destination) {
Menu menu = navigationView.getMenu();
for (int h = 0, size = menu.size(); h < size; h++) {
MenuItem item = menu.getItem(h);
item.setChecked(matchDestination(destination, item.getItemId()));
}
}
});
}
The most active owner of the Navigation Component is Ian Lake and it he's been adding support for more and more UI components to the NavigationUI class in the past months, so I think he's the person to talk to about this. Assuming this doesn't introduce any issues, he could probably get it done in a couple of minutes.
Alternatively, I could implement this and the accompanying test myself, contribute it and try to get it reviewed.