Android Q beta3 で感じる Navigation Bar (ナビゲーションバー) の方向性

Android端末で、ナビゲーションバーが担当する操作は、以下の5つです。

- ホームへ (Home)
- アプリドロワー表示 (App drawer)
- アプリ切り替え (App switcher)
- 戻る (Back)
- アシスタントアプリ起動 (Assistant)

2019-05-05付で公開された Android Q beta3 では、


「設定」

  |

「システム」

  |

「操作」

  |

「System Navigation」

3タイプに分かれています。

それぞれ試してみましょう。

 

3-button navigation

これまでの、馴染みやすいレガシーなスタイルと言えるでしょう。



これが一番使いやすいと思う私は固執しすぎの保守な人間ですかね?

 

2-button navigation

実はこれが慣れると一番使えるのでは?



現在普及割合を増やしてる「Android P」 とはボタン数は同じだが、アプリ切り替えが少し違う。それがすごく良い。

 

Fully gestural navigation

問題なのはこれ。

今回、最新版の操作として登場してます。



「画面両端からの中向きスワイプ」が「戻る(バック)ボタン」という直感的でない操作に。

それ、各アプリ内ナビゲーションメニューやホームアプリなどと衝突しますし。

「薄っぺらい一つのボタン」を採用することにより、コンテンツスペースを縦方向最大限に確保できてるとはいえどうなんでしょうか。

 

まとめ

フルジェスチャーな1ボタンは辛くねえですか?




スペース空いてるんだし、2ボタンか3ボタンが馴染みやすいように思いますが、果たしてどうなるのか。

👉Android Pie から始まる「ナビゲーションバー」の混乱と操作の覚え方

👉Android Q Beta 3 hands-on: Dark theme, new gestures, and more! - Android Authority

Paging DataSourceFactory toLiveData() toObservable() が見つからない。

Javaのこのコードが、


public class ConcertViewModel extends ViewModel {
  private ConcertDao concertDao;
  public final Observable<PagedList<Concert>> concertList;

  public ConcertViewModel(ConcertDao concertDao) {
    this.concertDao = concertDao;
    concertList = new RxPagedListBuilder<>(
          concertDao.concertsByDate(), 50)
                  .buildObservable();
  }
}

Kotlinでこう書けるはずなのに!


class ConcertViewModel(concertDao: ConcertDao) : ViewModel() {
  val concertList: Observable<PagedList<Concert>> =
        concertDao.concertsByDate().toObservable(pageSize = 50)
}

Paging library overview  |  Android Developers

見つからない toObservable()。

- Added DataSourceFactory.toLiveData() as a Kotlin alternative for LivePagedListBuilder
- Added DataSourceFactory.toObservable() and toFlowable() as Kotlin alternatives for RxPagedListBuilder

Paging  |  Android Developers

どうやら -ktx のようです。


implementation "androidx.paging:paging-runtime-ktx:2.1.0"
implementation "androidx.paging:paging-rxjava2-ktx:2.1.0"

Maven Repository: androidx.paging

最近は、同じ処理でも複数の書き方があることが多くなって最初混乱したりします。

【MVVM】 ViewModel の_プロパティ記述

Android Java ではあまり見かけなかったその記述。

Kotlin では、たくさん見かけてはいましたが、
個人的な明示記述小技かと思っていました。


private val _items = MutableLiveData<List<Task>>().apply { value = emptyList() }
val items: LiveData<List<Task>>
    get() = _items




private val _dataLoading = MutableLiveData<Boolean>()
val dataLoading: LiveData<Boolean>
    get() = _dataLoading

android-architecture/TasksViewModel.kt at todo-mvvm-live-kotlin · googlesamples/android-architecture


private val _repositories = MutableLiveData<List<Repo>>()
val repositories : LiveData<List<Repo>>
    get() = _repositories

android - Kotlin: Read Only access of Immutable Type to an Internal Variable of a Mutable Type - Stack Overflow


private val _models = ConflatedBroadcastChannel<Model>()
override val models: ReceiveChannel<Model> get() = _models.openSubscription()

private val _events = Channel<Event>(RENDEZVOUS)
override val events: SendChannel<Event> get() = _events

SdkSearch/SearchPresenter.kt at JakeWharton/SdkSearch

Kotlin公式リファレンスにも書かれていたのですね!

Names for backing properties
If a class has two properties which are conceptually the same but one is part of a public API and another is an implementation detail, use an underscore as the prefix for the name of the private property:


class C {
  private val _elementList = mutableListOf<Element>()
  val elementList: List<Element>
      get() = _elementList
}

Properties and Fields: Getters, Setters, const, lateinit - Kotlin Programming Language

クラス内の処理実装に利用するのが _elementList で、
外部にただ公開するだけのが elementList。

こうやって並べてみると、自然に馴染じめてしまう不思議。

ViewModel作成時のイメージとして持っておくと良い。

👉【Kotlin】バッキング・フィールド/プロパティ
👉【MVVM】ViewModel インスタンスの取得