You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
We can do even better by supporting devices pre-4.0 with a meta tag:
<activityandroid:name="com.example.android.architecture.blueprints.todoapp.taskdetail.TaskDetailActivity"android:parentActivityName=".tasks.TasksActivity">
<!-- Parent activity meta-data to support 4.0 and lower -->
<meta-dataandroid: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.
The text was updated successfully, but these errors were encountered:
aeroechelon
changed the title
Providing proper 'Up' Navigation
Providing Proper 'Up' Navigation
Jun 4, 2016
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.
@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.
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.Instead of pressing calling
onBackPressed()
, this method should not be overriden and instead these child activities should have their parent activities delcared inAndroidManifest.xml
by adding theandroid:parentActivityName
attribute.We can do even better by supporting devices pre-4.0 with a meta tag:
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.The text was updated successfully, but these errors were encountered: