Architecture-samples: Providing Proper 'Up' Navigation

[AeroEchelon]

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.

[passsy]

100% agree

[JoseAlcerreca]

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

[cvoronin]

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]

@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.