この記事は私の WeChat 公開アカウントでも同時公開されています。記事の下部にある QR コードをスキャンするか、WeChat で Guo Lin を検索してください。記事は毎日更新されます。
みなさんこんにちは、今日はオリジナル作品です。
Android 15 は間もなく正式にリリースされますが、今年の新しいシステムのいくつかの変更については私が最初に知りました。
どう言えばいいでしょうか？これまで私たちは、Android テクノロジーの変化が速すぎて、新しく学んだ知識の多くがすぐに捨てられてしまうと不満を抱いてきました。さらに、Google は新しいテクノロジーを導入し続けるため、開発者はもう学ぶことができないとよく言います。 。
Android 15 は非常に小規模なバージョン アップデートと言え、あまり目を引く点が多くないため、この問題を心配する必要はもうありません。
私も今年の Google I/O を見てきましたが、もはや Android は Google I/O の大きな舞台に立つことはできず、Android 15 の新機能を紹介することしかできません。小さな部屋。
Android テクノロジーは減速し、人気も低下しました。それが良いか悪いかは誰もが知っています。
Android 15 の新機能に関する今年の記事に関して、私は主な動作の変更を何度かレビューしてきましたが、非常に言及する価値のある変更は、強制的なエッジツーエッジのフルスクリーン エクスペリエンスであると感じています。この変更の内容は非常に単純ですが、すべての Android アプリケーションに影響する可能性があるため、全員が知っておくことをお勧めします。
実際、エッジツーエッジのフルスクリーン エクスペリエンスは新しい機能ではなく、Android 15 より前からサポートされていました。
しかし、この機能は何年も前からリリースされており、まだ全画面エクスペリエンスに適応していないアプリケーションが多数存在します。したがって、この Android 15 アップデートで、Google は最終的にこの機能を推進して、すべてのアプリケーションがより良いエクスペリエンスを実現できるようにすることを決意しました。
Android 15 では、アプリの targetSdkVersion が 35 以上に指定されている場合にのみ、エッジツーエッジ機能が強制的に有効になることに注意してください。したがって、単に適応したくない場合は、targetSdkVersion バージョンをアップグレードしないでください。
それでは本題に入りますが、まず、エッジツーエッジのフルスクリーン エクスペリエンスとは何なのかをご紹介します。
実際、簡単に言うと、アプリのインターフェイスを携帯電話の画面全体に拡張することで、より没入型のユーザー エクスペリエンスを実現できます。
実際、ほとんどのアプリはインターフェイスを電話画面の全領域に拡張していないため、より良いユーザー エクスペリエンスを提供できる可能性があります。
ここでいう携帯電話の画面全体とは具体的に何を指すのでしょうか？下の図を見ればすぐに理解できます。
ほとんどのアプリは実際には緑色のスペースのみを使用します。画面上部のステータス バーと画面下部のナビゲーション バーは、使用されていない 2 つの空白スペースです。あなたが作成したアプリも同様に使用するかどうか考えてみてください。
エッジツーエッジのフルスクリーン エクスペリエンスでは、次の図に示すように、すべてのスペースが利用されます。
上の 2 つの写真の比較から判断すると、エッジツーエッジ効果によってユーザー エクスペリエンスがそれほど向上しているとは感じない友人もいるかもしれません。実際、これは主にアプリのインターフェイス設計に依存します。異なるインターフェイスに対応するエッジ間の効果は完全に異なります。
ここでは、フォト ウォール アプリを使用してデモをしてみましょう。フォト ウォール機能は実際には非常にシンプルで、RecyclerView を使用して簡単に作成できます。この部分は、今日紹介する内容とは関係がないため、ここには掲載しません。ソース コードに直接アクセスするには、以下の GitHub リンクをクリックしてください。
https://github.com/guolindev/Edge2EdgeTest
最初にプロジェクトの targetSdkVersion を 34 に指定したことに注意してください。これは、エッジツーエッジ機能がデフォルトで強制的に有効化されないことを意味します。
Android 15 デバイスでプロジェクトを実行すると、次の図に示すような効果が得られます。
もちろん、このフォトウォールの効果が悪いとは言えず、かなり満足のいくものであるとしか言えません。結局のところ、エッジツーエッジの全画面エクスペリエンスが実現されるまでは、すべてのアプリがこの効果しか実現できません。
では、エッジツーエッジ機能が利用可能になったらどうなるでしょうか?比較して効果を見てみましょう。アプリをエッジツーエッジにサポートさせるのは非常に簡単です。targetSdkVersion を 35 以上に指定するだけで、次の図に示すように、自動的にエッジツーエッジのフルスクリーン効果になります。
この比較はどうでしょうか。フォト ウォールの没入感はすぐに向上しますか?そして、エッジツーエッジの効果を長時間見た後は、前の UI 効果に戻ることはできません。
さらに、エッジツーエッジのフルスクリーン エクスペリエンスについて詳しく説明します。フォト ウォールをスクロールすると、スクロールに応じて画面下部のナビゲーション バーの色が変化することがわかります。
これは、エッジツーエッジの全画面エクスペリエンスを有効にした後、背景のせいで下部のナビゲーション バーが認識しにくくならないようにするために、Android システムに付属している機能です。
この現象を発見した後、注意深い友人はすぐに気づいたかもしれませんが、携帯電話の下部にあるナビゲーション バー モードがこのジェスチャ ナビゲーション バーではなく、従来の [戻る]、[ホーム]、および [タスク] の 3 ボタン ナビゲーション バー (エッジツー) だったらどうでしょうか。 -edge 全画面表示はどのようになりますか?
この結果はおそらくほとんどの人には理解できないので、結果のスクリーンショットを直接見てみましょう。
ご覧のとおり、ナビゲーション バーは半透明の効果になり、不透明度はデフォルトで 80% に設定されています。
また、この効果から、3 ボタンのナビゲーション バーがエッジツーエッジの全画面エクスペリエンスという点で完全に後れを取っており、このモデルは Android システムによって徐々に疎外されることになることがわかります。
同時に、ステータス バーとナビゲーション バーの色設定に関連する API もいくつかありますが、これらの API は端から端までの全画面エクスペリエンスと競合するため、使用できなくなりました。いずれにしても、この記事を読んだ後は、次の API を使用しないことをお勧めします。
Window#setStatusBarColor
Window#setStatusBarContrastEnforced
Window#setNavigationBarColor
Window#setNavigationBarContrastEnforced
この記事のこの時点では、エッジツーエッジの全画面エクスペリエンスが正常に有効になっていますが、まだコードを 1 行も書いていません。
では、エッジツーエッジの適応には本当に 1 行のコードを記述する必要はないのでしょうか?
もちろん、追加のエッジツーエッジ適応作業が必要かどうかは、主にインターフェイスがどのようなものであるかによって決まります。
先ほどのフォト ウォール インターフェイスのように、携帯電話の画面のスペース全体を埋めるのに非常に適しているため、調整を行わなくても、ユーザー エクスペリエンスは依然として非常に優れています。
ただし、別のインターフェイスではそうでない場合があります。
ここでは、 「コードの最初の行、第 3 版」の第 4 章にあるベスト プラクティス プロジェクトを例として使用します。これを見た読者は、これがチャット ボックス インターフェイスであることがわかるはずです。
同様に、インターフェイスの作成はこの記事の焦点ではないため、チャット ボックスのソース コード実装はここには投稿しません。ソース コードを参照したい友人は、「コード バージョン 3 の最初の行」をチェックするか、上記の GitHub リンクにアクセスすることもできます。
エッジツーエッジの全画面エクスペリエンスでチャット ボックスのインターフェイスがどのように見えるかを見てみましょう。スクリーンショットを直接撮ってみましょう。
ご覧のとおり、今回の効果はあまり理想的ではありません。チャット内容がステータスバー領域に入り込んでおり、一部のテキスト内容がステータスバーに重なって読みにくくなっています。入力ボックスや送信ボタンがナビゲーションバー領域に入り込んでおり、入力ボックスやボタンの操作に影響があります。 。
これらは、最も一般的なエッジツーエッジのフルスクリーン エクスペリエンスによって引き起こされる問題であり、これに適応する必要があります。
実際の適応コードは比較的単純です。主に ViewCompat.setOnApplyWindowInsetsListener() 関数を使用して、特定の指定されたビューをオフセットし、システム ステータス バーやナビゲーション バーによってブロックされないようにします。
現在のインターフェイスに対応して、上部のチャット コンテンツはステータス バー領域に入らないようにし、下部の入力ボックスと送信ボタンはナビゲーション バー領域に入らないようにします。コードは次のとおりです。
class ChatActivity : AppCompatActivity(), View.OnClickListener {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
...
ViewCompat.setOnApplyWindowInsetsListener(chatRecyclerView) {
v, insets ->
val stateBars = insets.getInsets(WindowInsetsCompat.Type.statusBars())
v.setPadding(stateBars.left, stateBars.top, stateBars.right, stateBars.bottom)
insets
}
ViewCompat.setOnApplyWindowInsetsListener(inputTextLayout) {
v, insets ->
val navigationBars = insets.getInsets(WindowInsetsCompat.Type.navigationBars())
v.setPadding(navigationBars.left, navigationBars.top, navigationBars.right, navigationBars.bottom)
insets
}
}
}
ここでは、chatRecyclerView と inputTextLayout の 2 つの View に対して Insets 監視を設定しています。 chatRecyclerView はチャットの内容に対応する View、inputTextLayout は入力ボックスと送信ボタンを含むレイアウトです。
したがって、チャット コンテンツをステータス バー領域に入れたくないため、ここで WindowInsetsCompat.Type.statusBars() を呼び出してステータス バーのインセットを取得します。たとえば、ここで取得したステータス バーの高さは 50 です。次に、chatRecyclerView に 50 を設定します。パディングにより、チャット コンテンツがステータス バー領域に入らないようにすることができます。
同様に、入力ボックスと送信ボタンをナビゲーション バー領域に入れたくない場合は、WindowInsetsCompat.Type.navigationBars() を呼び出してナビゲーション バーのインセットを取得し、同じメソッドを使用してパディングを設定します。
このコードを追加した後、プログラムを再実行すると、次の図に示すように理想的な結果が得られます。
WindowInsetsCompat.Type.statusBars() と WindowInsetsCompat.Type.navigationBars() に加えて、実際には他にも多くのタイプのインセットから選択できます。
たとえば、ビューがステータス バー領域にもナビゲーション バー領域にも入らないようにする場合は、WindowInsetsCompat.Type.systemBars() を使用できます。
ビューがカットアウト領域に入らないようにしたい場合は、WindowInsetsCompat.Type.displayCutout() を使用できます。
カットアウトの概念は Android 9 システムで導入されました。当時、Google はさまざまなノッチに対応するために、ノッチ スクリーンを導入しました。
ただし、その後、携帯電話メーカーはあらゆる種類の奇妙な前髪を作成するのではなく、基本的に前髪をステータス バーに配置することを選択したため、現在では、displayCutout() API の効果は statusBars() の効果とそれほど変わりません。
Liu Haiping についてさらに詳しく知りたい場合は、「Liu Haiping デバイスに適応する Android 9 の新機能」の記事を参照してください。
さらに、Android 10 以降、Google はジェスチャー ナビゲーションを導入しました。これにより、携帯電話画面の左側と右側を使用して戻るキー操作をトリガーでき、携帯電話画面の下部を使用してバック キー操作をトリガーできるようになります。ホームキー操作は下図の黄色の部分に表示されます。
つまり、設計したインターフェースでこの部分のジェスチャー操作がまったく同じだと、ジェスチャーの競合が発生し、ユーザーの操作が正常に進行できなくなります。
このとき、WindowInsetsCompat.Type.systemGestures() を使用して黄色の領域の Inset を取得し、イベント競合のある View をこの領域からずらすためにパディングを設定できます。
基本的に、エッジツーエッジのフルスクリーン適応について説明する必要があるのはこれだけです。適応コードは比較的単純です。ただし、これはすべてのプロジェクトに影響し、各プロジェクトの UI インターフェイスの複雑さは異なるため、全員に与える具体的な影響は全員で評価する必要がある場合があります。
最後に、記事の冒頭で述べたように、エッジツーエッジのフルスクリーン エクスペリエンスは実際には新しい機能ではありません。これは Android 15 よりも前でもサポートされていました。Android 15 ではこの機能が強制的にオンになっただけです。
したがって、すでにエッジツーエッジの全画面エクスペリエンスに適応している場合、Android 15 でのみそれを有効にする理由はありません。もちろん、有効にするデバイスが多ければ多いほど良いです。
Android 15 より前のデバイスでエッジツーエッジの全画面エクスペリエンスを有効にするには、必要な追加手順は 2 つだけです。
最初のステップは、次のライブラリの依存関係をプロジェクトの build.gradle ファイルに追加することです。
dependencies {
// For Java
implementation 'androidx.activity:activity:$activity_version'
// For Kotlin
implementation 'androidx.activity:activity-ktx:$activity_version'
}
2 番目のステップは、アクティビティの onCreate 関数に次のコードを追加することです。
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
enableEdgeToEdge()
super.onCreate(savedInstanceState)
...
}
}
EnableEdgeToEdge() は、古いバージョンの Android システムを搭載したデバイスでエッジツーエッジの全画面エクスペリエンスを有効にするために使用される Kotlin 拡張関数です。プロジェクトでまだ Java コードを使用している場合は、代わりに次のコードを使用できます。
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
EdgeToEdge.enable(this);
super.onCreate(savedInstanceState);
...
}
}
上記の 2 つの手順を完了すると、Android 15 より前のデバイスでエッジツーエッジの全画面エクスペリエンスを有効にすることができ、Android 6.0 以降のデバイスをサポートできるようになります。
さて、これでエッジツーエッジのフルスクリーン エクスペリエンスについての紹介は終わりです。また次のオリジナル記事でお会いしましょう。
Kotlin と Android の最新の知識を学びたい場合は、私の新しい本「The First Line of Code 第 3 版」を参照してください。詳細を表示するには、ここをクリックしてください。