iOSユーザーのプロマネとエンジニアとアプリを開発していて、
Android のアプリでバックボタンを押下した時、おかしな挙動をしました。

普段iOSデバイスを使用している、プロマネに伝えたところ、

iOSユーザー ： 「バックボタンてなんですか？ 」

普段、iOSデバイスを使用している、iOSエンジニアさんやデザイナーさん、テストエンジニアさんも
バックボタンについての挙動はちゃんと確認してませんでした。。。

ここから、いろいろやり取りするのに苦労したので、簡単ですがまとめました。

1. バックボタンというものを意識したことがない?

Androidデバイスには、ホームボタン、マルチタスクボタンのほかに、バックボタン があります。
iOSデバイスが同じ（似たような）挙動を示す対応は下記になります。

Android	=>	iOS
ホームボタン	=>	ホームボタン
マルチタスクボタン	=>	ホームボタン2回押し
バックボタン	=>	?

ホームボタンや、マルチタスクボタンの挙動は、説明しやすいんですが、バックボタンの説明が難しかった。

2. iOSの戻るボタンについて

iOSの 戻るボタン は、画面左上 に実装します。
iOSを使用している全てのデザイナーさんがそうではないですが、出来上がったデザインは、
Androidにも画面左上に 戻るボタン が配置されていることが多いです。

果たして、これは正しいのか？？

3. Androidの画面左上のボタン

Androidの developer サイトにあるBack ボタンと Up ボタンを使用したナビゲーションを読んでみます。

Androidのアクションバーに設置する画面左上のボタンは、正式にはアップボタンといい、
バックボタンと区別します。

4. アップボタンと、バックボタンの定義

アップボタン

アップボタンは、画面間の階層関係に基づいてアプリ内を移動するために使います。
画面がアプリのトップレベル（アプリのホーム）であれば、Up ボタンを表示する必要はありません。

バックボタン

システムの Back ボタンは、最近使用した画面をさかのぼって順番に移動する場合に使用します。
通常、このナビゲーションはアプリの階層ではなく、画面を表示した順番に基づいています。

画面を表示した順番 がポイントです。

5. アップボタンと、バックボタンの違い

基本原則

Up ボタンではユーザーの移動がアプリ内に限られるのに対して、Back ボタンではホーム画面や、別のアプリにも戻れます。

アップボタンの例外

参照リストで結び付けられていない関連詳細ビュー間をブラウジングする場合は例外です。
たとえば Play Store で同じデベロッパーのアプリや同じアーティストのアルバム間をブラウジングする場合です。
この場合、各リンクをたどると履歴が作成され、Back ボタンで以前に表示した各画面に戻ることになります。
Up ボタンを使用するとこれらの関連画面をバイパスして、直前に表示したコンテナ画面に移動します。

iOSの 戻るボタン は、 Androidの アップボタン と挙動に似ているので、
Androidの左上にボタンを設置すること自体は、間違いではないようにも思えます。
(iOSと挙動を合わせるという仕様でなければ。。)

6. Android アプリケーション品質ガイドライン

iOSの戻るボタンは、Androidのアップボタンと似たような挙動で要件を定義したとして、
では、Androidのバックボタンの機能は、「一つ前の画面に戻る」ボタンと伝えて良いのかと言われると、
そうではないですね。

Androidのバックボタンは、様々な機能を持っています。

バックボタンの期待する動作

Back ボタンは、画面間を直接ナビゲーションするだけでなく、次のような動作にも対応しています。
・　フローティングウィンドウ（ダイアログ、ポップアップ）を閉じる
・　コンテキストアクションバーを閉じて、選択したアイテムのハイライト表示を解除する
・　画面上のキーボード（IME）を非表示にする

また、Android アプリ品質ガイドラインでは、

・アプリはシステムアイコンの予想機能（[戻る] ボタンなど）を再定義しません。
・すべてのダイアログは [戻る] ボタンを使用して取り消すことができます。

にあるように、ダイアログも取り消すようにしなければ本当は良くないなんですね。
(なにも実装しなければ消すようになっているのですが。。)

あと、Webviewでは、意識しないとブラウザバックのような挙動をしないです。。
この部分は、Webviewで表示するコンテンツをきちんと検討して、定義していくしかないのかなと思ってます。

ダイアログについても、必要ならバックボタンを押下しても反応しないようにして、
ユーザーにダイアログのボタンをちゃんと意思決定させてもいいかなと思います。
(バックボタンを押下するのも意思決定と言われると。。。)

個人的には、メイン画面でバックボタンを押下すると、
「バックボタンをもう一回押すと・・・」ダイアログ
はいらないと思うんですけどね。

7. 結論

今回の問題は、担当エンジニアが、画面遷移時に、finish()を呼び出さず、
バックボタンでstartActivtiy()を呼び出して、画面が二重表示してしまったんですよね。。

本題の件ですが、バックボタンの機能が多く、
一画面ごと検討して、提案していくしかないかなーと思いました笑

ガイドラインを知っている上で、より良いのユーザー体験を提供できそうであれば、
ガイドラインに沿わなくても、良いのかな〜と思います。

バックボタンについて、デザイナーやエンジニアに知識を求めるのではなく、
Androidエンジニアが、要件を定義してもらうためのアドバイスができるように
ガイドラインを精読して、知識を深めておこうという話でした。