IssueTracker

Project: platform/frameworks/support
Branch: androidx-master-dev

commit c60f33e229e31ab328ef6b59dab63b264954831c
Author: Alexandre Elias <aelias@google.com>
Date:   Fri Jul 10 16:23:09 2020

    Semantics no-op cleanups
   
    Partly in response to lmr's broad code review, I did a pass of
    superficial API/implementation cleanup.  The main changes are:
   
    - I changed each Boolean SemanticsProperty where false is equivalent to
      not being present to take "Unit" instead.  This is conceptually
      clearer: it avoids questions like "can I cancel out a semantics from a
      merged child by setting it to false?"  Because "property = Unit" looks
      weird, I also changed the style of these to "property()".
   
    - I moved the Semantics id generator closer to where it's used, in
      SemanticsModifierCore.  I made it internal and an AtomicInt.
      (Note that integer ids are heavily used in the Android
      AccessibilityNodeInfo APIs so I can't simply remove them entirely.)
   
    - I deleted dead code.  Some examples include SemanticsHintOverrides,
      a public API not connected to anything, and SemanticsPropertyKey
      merge() open method which is never called.  (In both cases I have
      a different plan in mind for accessibility.)
   
    Fixes: 145951226
    Fixes: 145955412
    Test: existing tests
    Relnote: "Single-value semantics properties now use a calling style.
    For example, 'semantics { hidden = true }' is now written as:
    'semantics { hidden() }'."
   
    Change-Id: Ic1afd12ea22c926babc9662f1804d80b33aa0cfc

M       ui/integration-tests/benchmark/src/androidTest/java/androidx/ui/benchmark/test/LayoutNodeModifierBenchmark.kt
M       ui/ui-core/api/0.1.0-dev15.txt
M       ui/ui-core/api/current.txt
M       ui/ui-core/api/public_plus_experimental_0.1.0-dev15.txt
M       ui/ui-core/api/public_plus_experimental_current.txt
M       ui/ui-core/api/restricted_0.1.0-dev15.txt
M       ui/ui-core/api/restricted_current.txt
M       ui/ui-core/src/androidAndroidTest/kotlin/androidx/ui/graphics/vector/VectorTest.kt
M       ui/ui-core/src/androidAndroidTest/kotlin/androidx/ui/semantics/SemanticsTests.kt
M       ui/ui-core/src/androidMain/kotlin/androidx/ui/core/AndroidActuals.kt
M       ui/ui-core/src/androidMain/kotlin/androidx/ui/core/AndroidComposeView.kt
M       ui/ui-core/src/androidMain/kotlin/androidx/ui/core/AndroidComposeViewAccessibilityDelegateCompat.kt
M       ui/ui-core/src/androidMain/kotlin/androidx/ui/core/AndroidPopup.kt
M       ui/ui-core/src/commonMain/kotlin/androidx/ui/core/Expect.kt
M       ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsConfiguration.kt
D       ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsHintOverrides.kt
M       ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsModifier.kt
M       ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsNode.kt
M       ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsOwner.kt
M       ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsWrapper.kt
M       ui/ui-core/src/commonMain/kotlin/androidx/ui/semantics/SemanticsProperties.kt
M       ui/ui-foundation/api/0.1.0-dev15.txt
M       ui/ui-foundation/api/current.txt
M       ui/ui-foundation/api/public_plus_experimental_0.1.0-dev15.txt
M       ui/ui-foundation/api/public_plus_experimental_current.txt
M       ui/ui-foundation/api/restricted_0.1.0-dev15.txt
M       ui/ui-foundation/api/restricted_current.txt
M       ui/ui-foundation/src/main/java/androidx/ui/foundation/Clickable.kt
M       ui/ui-foundation/src/main/java/androidx/ui/foundation/Dialog.kt
M       ui/ui-foundation/src/main/java/androidx/ui/foundation/Scroller.kt
M       ui/ui-foundation/src/main/java/androidx/ui/foundation/selection/Selectable.kt
M       ui/ui-foundation/src/main/java/androidx/ui/foundation/selection/Toggleable.kt
M       ui/ui-foundation/src/main/java/androidx/ui/foundation/semantics/FoundationSemanticsProperties.kt
M       ui/ui-material/src/androidTest/java/androidx/ui/material/ButtonTest.kt
M       ui/ui-material/src/androidTest/java/androidx/ui/material/CardTest.kt
M       ui/ui-material/src/androidTest/java/androidx/ui/material/CheckboxScreenshotTest.kt
M       ui/ui-material/src/androidTest/java/androidx/ui/material/RadioButtonScreenshotTest.kt
M       ui/ui-material/src/androidTest/java/androidx/ui/material/ScaffoldTest.kt
M       ui/ui-material/src/androidTest/java/androidx/ui/material/SnackbarTest.kt
M       ui/ui-material/src/androidTest/java/androidx/ui/material/SurfaceTest.kt
M       ui/ui-material/src/androidTest/java/androidx/ui/material/ripple/RippleIndicationTest.kt
M       ui/ui-material/src/androidTest/java/androidx/ui/material/textfield/TextFieldScreenshotTest.kt
M       ui/ui-material/src/main/java/androidx/ui/material/AppBar.kt
M       ui/ui-material/src/main/java/androidx/ui/material/TextFieldImpl.kt
M       ui/ui-test/src/androidTest/java/androidx/ui/test/AssertsTest.kt
M       ui/ui-test/src/androidTest/java/androidx/ui/test/CallSemanticsActionTest.kt
M       ui/ui-test/src/androidTest/java/androidx/ui/test/ErrorMessagesTest.kt
M       ui/ui-test/src/androidTest/java/androidx/ui/test/FindersTest.kt
M       ui/ui-test/src/androidTest/java/androidx/ui/test/PrintToStringTest.kt
M       ui/ui-test/src/androidTest/java/androidx/ui/test/ScrollToTest.kt
M       ui/ui-test/src/androidTest/java/androidx/ui/test/TextActionsTest.kt
M       ui/ui-test/src/main/java/androidx/ui/test/Actions.kt
M       ui/ui-test/src/main/java/androidx/ui/test/Filters.kt
M       ui/ui-text/api/0.1.0-dev15.txt
M       ui/ui-text/api/current.txt
M       ui/ui-text/api/public_plus_experimental_0.1.0-dev15.txt
M       ui/ui-text/api/public_plus_experimental_current.txt
M       ui/ui-text/api/restricted_0.1.0-dev15.txt
M       ui/ui-text/api/restricted_current.txt
M       ui/ui-text/src/commonMain/kotlin/androidx/ui/text/CoreTextField.kt
M       ui/ui-text/src/commonMain/kotlin/androidx/ui/text/TextSemanticsProperties.kt

https://android-review.googlesource.com/1360099

Any updates on this? Have you been able to reproduce it? It's a release blocker on our end — any resonable workaround would be appreciated.

I think I have an idea of what is going on. Do you see a Log.INFO message saying: "Ignoring popBackStack to destination __ as it was not found on the current back stack"? If so, that means we're doing exactly what you said - popping id/graph off the stack - but not actually what you want (the parent graph to continue to be around if you are navigating forward as well)

If so, one workaround is to use popUpTo="@+id/a" and popUpTo"@+id/b" for action x and y, respectively - if you know that x is always clearing A off the stack, then popUpTo B is enough.

Alright, interesting! So that means there is no generic way to say that "clear everything of the backstack before moving to this next destination"? Rather, you need to keep track of every individual case? What if, for example, you have to following graph:
    x         y       z
A --> B --> C --> D

Where
  - A could be a splash screen and the start destination of the graph
  - B could be some welcome screen, prompting the user to sign in
  - C could be the actual login screen where the user enters his/hers details and signs in
  - D could be the main content screen

Obviously the user should not be allowed to click the back button from B to go back to the splash screen, and neither should the user be allowed to click the back button from D to go back to the login screen. In both of these cases the user should instead exit the app. However, it's perfectly fine for the user to click back from C and go back to the welcome screen B.

Now, to the problem; with your suggested workaround we can indeed set popUpTo="@+id/a" on x, but if we set popUpTo="@+id/c" on z then the user can still click the back button, but they will go to B instead. The desired behaviour is for the user to exit the app when clicking back when in D. The workaround stops working as we don't pop the back stack when going from B --> C, as we want to allow the user to navigate back to B from C.

It would be interesting to have a "popAll" option, where the whole stack will be erased, so we don't have to keep track who's on the stack to be popped or not. It would speed up things and bring less confusion as well.

I agree completely, similarly to how clearTask worked before it was deprecated.

A couple of points:
1) There really is a bug here - app:popUpTo="@+id/graph" should work as well - that's why I said 'workaround' above, not solution. We will be fixing that bug.

2) Popping everything off the stack is always a sign that you've built your graph incorrectly. That's on us though as we haven't documented well enough how to do conditional navigation (for example, the B->C sign in flow). https://issuetracker.google.com/issues/111762510 is our tracking bug for updating the conditional navigation page (https://developer.android.com/topic/libraries/architecture/navigation/navigation-conditional).

For example, in the example raised in #5, your start destination should be D.
- Splash screen should be using a splash theme (e.g., https://www.bignerdranch.com/blog/splash-screens-the-right-way/) and not be in your graph at all
- B+C should be handled as conditional navigation from D - D starts B and if you return to D without logging in, D calls finish().
- Having D as your startDestination is critical to having the right back stack when deep linking to somewhere in your graph

I realize that this is a bigger mental shift from how you've structured your apps and is a big reason why improving the documentation is an important focus for Navigation over the next few months.

So if I understand this correctly, D is a Fragment and it should call its Activity (the one and only one in the app) finish(), in case there's something wrong, like going back from the login screen?

I find this complicated and can lead to issues that resemble "callback hell", having multiple checks and flags everywhere, to know if we already navigates to some destination and if we are back and without a proper value... Can't we come up with a more streamlined solution?

D can do whatever it needs to if the user chooses not to log in, be it finishing the activity (if you know it is the root of your whole graph), calling navController.popBackStack(), or showing an inline prompt for the user to sign in. This is core business logic for your app.

One thing that you need to keep in mind is that the user can hit the home button at any point then come back to *exactly that same destination in your app* an arbitrary amount of time later. If your logins expire or if users can delete their accounts (just to offer two examples), then *every* login required destination needs to handle this exact case - punting users to your login flow then handling whether they log in or not before showing their protected content. By making that the *only* flow for handling invalid login cases in your app, you can do things the right way just once.

Good point.

About your comment on #8 (mentioned bellow):

 >>> - B+C should be handled as conditional navigation from D - D starts B and if you return to D without logging in, D calls finish().

Basically D needs to know the outcome of a task that was accomplished in B, meaning D needs to know if it was reached through opening the app (since it's a startDestination) or through pressing back in B (meaning the user canceled the login process).

Wouldn't this be a break in abstraction? My understanding was that a destination should receive it's arguments and this should be enough for it to work but in this example D needs to detect it was reached through a BACK press in B.

I don't even know how I would implement such a thing unless I start passing arguments between destinations to know about my navigation history.

I made this work, kind of: splash to main activity; starting destination D. It inflates a layout only to save state and go to the back stack as I bounce to B. If I press back, I go through the steps of restoring D--which briefly makes an appearance on screen--only to finish the activity.

I actually like the thought of an incorrect graph if it lets me handle this stuff precisely without some of the overhead needed to make a generic solution.

I've confirmed that this is fixed in alpha08 as a result of https://android-review.googlesource.com/833717 and a number of other internal changes.

app:popUpTo="@+id/graph" should always work now.