The recommended substitute for clearTask of popUpTo with popUpToInclusive only works from start destination actions [116831650]

Fixed

Bug

Status Update

No update yet.

Description

[Deleted User]

created issue #1

Sep 28, 2018 10:32AM

I was previously using clearTask in my navigation actions to make sure that the user could not navigate back to the previous destination (useful for splash screens and login screens). After it was deprecated I decided to try the recommended approach of instead setting popUpTo pointing to the root of the graph together with setting popUpToInclusive="true", but this didn't have the effect I wanted.

This approach only seem to work on actions originating from the graph's start destination, and fails on actions between any other destinations. I created a sample project which reproduces the issue:

https://github.com/hsson/android-navigation-component-alpha06-bug

Here is the project's README detailing the issue:

# Bug in Android Navigation Component (alpha06)
(Note: I have only verified this in alpha06, I don't know if it exists in
previous versions)

## The problem
Basically the problem is that the NavOption "clearTask" was removed in
alpha02, and the recommended substitute was to use app:popUpTo pointing to
the root of the graph/the graph ID, together with app:popUpToInclusive="true".
However, this method does not work. It only seems to work for actions
going from the graph's start destination. If we have the following graph:

x y
A ---> B ---> C

Where A, B, and C are fragments, A is the start destination of the grapg,
and x, y are actions going from A to B and B to C respectively. Let's say
the graph's ID is "@+id/graph"

Then, if both actions x and y have
app:popUpTo="@+id/graph"
app:popUpToInclusive="true"

Then when navigating from A to B through x, and then hitting the back button
will exit the app (as expected). But if navigating from A to B to C through
x and y, and then hitting the back button we will navigate back to B — this
is not what was expected. The expected behavior with this graph is to always
exit the app when clicking the back button

## Environment
This was verified using:
Android Studio 3.2 RC 3
Build #AI-181.5540.7.32.4987877, built on August 31, 2018
JRE: 1.8.0_152-release-1136-b06 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.13.6

Comments

[Deleted User] <[Deleted User]> #2Oct 1, 2018 08:14AM

My guess is an AutoValue extension is what's needed here:

http://ryanharter.com/blog/2016/05/16/autovalue-extensions/

We accept pull requests! :)

il...@google.com <il...@google.com> Oct 1, 2018 10:56PM

Assigned to il...@google.com.

[Deleted User] <[Deleted User]> #3Oct 10, 2018 09:20AM

> We accept pull requests! :)

Is there a public repo somewhere? I don't see any obvious repo for it in

https://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.

il...@google.com <il...@google.com> #4Oct 18, 2018 06:05PM

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 :/.

[Deleted User] <[Deleted User]> #5Oct 19, 2018 11:44AM

"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!

mi...@gmail.com <mi...@gmail.com> #6Oct 19, 2018 12:22PM

Add autovalue support also means you can easily achieve parcelable by

https://github.com/rharter/auto-value-parcel. Please consider support this.

[Deleted User] <[Deleted User]> #7Oct 19, 2018 12:24PM

AutoValue is really a handy way to ensure data integrity.

il...@google.com <il...@google.com> #8Oct 19, 2018 03:36PM

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.

mi...@gmail.com <mi...@gmail.com> #9Oct 19, 2018 03:50PM

FWIW,

issue 64206877

is not publicly accessible.

il...@google.com <il...@google.com> #10Oct 19, 2018 04:13PM

@Yigit: That appears to be a private ticket. Any way we can have access to keep up with it?

mi...@gmail.com <mi...@gmail.com> #11Oct 19, 2018 04:16PM

Have any updates?

dc...@gmail.com <dc...@gmail.com> #12Oct 23, 2018 05:19PM

news?

da...@gmail.com <da...@gmail.com> #13Oct 26, 2018 10:58PM

Is there any update? This is huge for app that absolutely enforces immutable entities.

il...@google.com <il...@google.com> #14Nov 30, 2018 11:21PM

Marked as fixed.

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.