android / android/architecture-samples
Providing Proper 'Up' Navigation
- Dominant language
- Kotlin
- Stars
- 45.8k
- Forks
- 11.9k
- PR merge metrics
- No merged PRs in 30d
Description
In [TaskDetailActivity](https://github.com/googlesamples/android-architecture/blob/todo-mvp/todoapp/app/src/main/java/com/example/android/architecture/blueprints/todoapp/taskdetail/TaskDetailActivity.java#L73), and [AddEditTaskActivity](https://github.com/googlesamples/android-architecture/blob/todo-mvp/todoapp/app/src/main/java/com/example/android/architecture/blueprints/todoapp/addedittask/AddEditTaskActivity.java#L81), `onSupportNavigateUp()` is incorrectly overriden to provide back behaviour instead. In the Android developer documentation, [Providing Up Pavigation](https://developer.android.com/training/implementing-navigation/ancestral.html) should be implemented, especially if these samples are to lead by example.
``` java
@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.
``` xml
```
We can do even better by supporting devices pre-4.0 with a meta tag:
``` xml
```
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.
Contributor guide
Research direction
Start with TaskDetailActivity.java and AddEditTaskActivity.java at the onSupportNavigateUp() implementations, then inspect AndroidManifest.xml for these activities. Remove the back-navigation overrides and declare each parent activity with android:parentActivityName and the support-library metadata for older devices. Done means Up navigation follows the manifest hierarchy on supported Android versions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, java
- Domain
- mobile
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 38/100