Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Providing Proper 'Up' Navigation #92

Open
aeroechelon opened this issue Jun 4, 2016 · 4 comments
Open

Providing Proper 'Up' Navigation #92

aeroechelon opened this issue Jun 4, 2016 · 4 comments

Comments

@aeroechelon
Copy link

aeroechelon commented Jun 4, 2016

In TaskDetailActivity, and AddEditTaskActivity, onSupportNavigateUp() is incorrectly overriden to provide back behaviour instead. In the Android developer documentation, Providing Up Pavigation should be implemented, especially if these samples are to lead by example.

@Override
public boolean onSupportNavigateUp() {
    onBackPressed();
    return true;
}

Instead of pressing calling onBackPressed(), this method should not be overriden and instead these child activities should have their parent activities delcared in AndroidManifest.xml by adding the android:parentActivityName attribute.

<activity android:name="com.example.android.architecture.blueprints.todoapp.taskdetail.TaskDetailActivity"
          android:parentActivityName=".tasks.TasksActivity"/>

We can do even better by supporting devices pre-4.0 with a meta tag:

<activity android:name="com.example.android.architecture.blueprints.todoapp.taskdetail.TaskDetailActivity"
          android:parentActivityName=".tasks.TasksActivity">
    <!-- Parent activity meta-data to support 4.0 and lower -->
    <meta-data
        android:name="android.support.PARENT_ACTIVITY"
        android:value=".tasks.TasksActivity" />
</activity>

By doing the above work, we can rely the manifest to determine the up navigation behaviour.

Reasoning

Although subtle, providing consistency through user expected behaviour and by coding example can we have a less fragmented navigation for the Up button in the Android ecosystem when teaching and influencing other Android developers. I think it's important that in Google architecture practice that this is led through example. I've seen a lot of navigation practices overriding the R.id.home menu item or in this example simply providing incorrect back behaviour instead.

If accepted, I'd be more than happy to implement the work as necessary to the tood-mvp branch.

@aeroechelon aeroechelon changed the title Providing proper 'Up' Navigation Providing Proper 'Up' Navigation Jun 4, 2016
@passsy
Copy link

passsy commented Dec 12, 2016

100% agree

@JoseAlcerreca
Copy link
Contributor

Yep I already fixed this in the tablet variant, feel free send a PR. Thanks!

@cvoronin
Copy link

Sometimes same activity can be started from different places - in this case there is no single onBack/onUp return path.
android:parentActivityName in this case can not be used because there are different places to return.

@aeroechelon
Copy link
Author

@cvoronin On the contrary, navigating Up always moves up one screen in the information architecture / screen hierarchy, independent of how one arrived to this screen.

There would only be different places to return when Back is pressed. Not Up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants