Jetpack Compose 「Modifierは子1つ目だけに適用する」の考え方

実際のコード例で考えてみる。


Column {
  Text(
    text = "Hello",
    modifier = Modifier.padding(16.dp)
  )
  Text(
    text = "World",
    modifier = Modifier.padding(16.dp)
  )
}


val modifier = Modifier.padding(16.dp)

Column {
  Text(text = "Hello", modifier = modifier)
  Text(text = "World", modifier = modifier)
}


Column(
  modifier = Modifier.padding(16.dp)
) {
  Text(text = "Hello")
  Text(text = "World")
}


@Composable
fun ParentLayout() {
  Column(
    modifier = Modifier.verticalScroll(rememberScrollState())
  ) {
    for (i in 1..10) {
      ListItem(
        text = "Item $i",
        modifier = Modifier.padding(8.dp)
      )
    }
  }
}

@Composable
fun ListItem(modifier: Modifier, text: String) {
  Text(
    text = text,
    modifier = modifier.background(Color.LightGray)
  )
}

共有することの意味は「統一性」だろうけども、

見通しが悪くなるので「1つ目まで」としているのだろう。

「まずは個別につけてから共通部分をホイストしていく。」

「親から渡すときは子まで影響。孫は個別に。」

そんな考え方の順番が簡単で自然だと思います。


Android Architecture Samples でみる JetpackCompose UI コンポーネントのネスト



表示されてるコンテンツまでにいくつかのコンポーネントを経由している。

👉 architecture-samples/app/src/main/java/com/example/android/architecture/blueprints/todoapp/TodoNavGraph.kt at 130f5dbebd0c7b5ba195cc08f25802ed9f0237e5 · android/architecture-samples

中心は、NavGraph として利用されている NavHost。

ModalDrawer ごと切り替えてる。


Activity
  + NavHost
    + ModalDrawer
      + 【Screen】
        + Scaffold
          + SwipeRefresh
            + 【Content】    
    + ModalDrawer
      + 【Screen】
        + Scaffold
          + SwipeRefresh
            + 【Content】
    + ModalDrawer
      + 【Screen】
        + Scaffold
          + SwipeRefresh
            + 【Content】

きっと、使いやすい理にかなった入れ子関係なのだろう。


Activity
   ↓
NavHost
   ↓ 1:*
ModalDrawer
   ↓
【Screen】
   ↓
Scaffold
   ↓
SwipeRefresh
   ↓
【Content】

参考にしたいですね。

👉 android/architecture-samples: A collection of samples to discuss and showcase different architectural tools and patterns for Android apps.


ポリシーステータス「アプリは Android 14(API レベル 34) 以降を対象とする必要があります。」が消えない

かなり遅れて、今さらなのですが。

このポリシーステータスのメッセージ。


アプリは Android 14(API レベル 34) 以降を対象とする必要があります。

アプリ自体は、

SDKのターゲットバージョン35にして

公開完了してるにこのメッセージが消えない。

なんでかな。

 

🧑🏻‍💻 すぐには消えない?

Check that all tracks are updated (even paused tracks). If they are then give it a few days for the message to disappear.

すべてのトラックが更新されていることを確認してください(一時停止したトラックも)。もしそうなら、メッセージが消えるまで数日待ってください。

👉 How can I clear this message because now my target API is 34 - Google Play Developer Community

It turned out that I need to wait for 24 hours for the message to disappear. I don't know why it's not instant even though the target api is clearly within the policy requirements. Maybe they check these manually. Anyway it's solved.

メッセージが消えるまで24時間待つ必要があることが判明しました。ターゲットAPIが明らかにポリシー要件の範囲内であるにもかかわらず、なぜそれが即時ではないのかわかりません。おそらく彼らはこれらを手動でチェックします。とにかく解決しました。

👉 i still get this warning (App must target Android 14 (API level 34) or higher) even though iupdated - Google Play Developer Community

 

🧑🏻‍💻 結果

大体6時間後に確認すると消えてました!


Android のアーキテクチャで何が Google に「強く推奨」されているか図で理解する

👉 Recommendations for Android architecture  |  Android Developers

分かりやすいドキュメントなのでさらに分かりやすくなるように図にしてみます。

 

🤔 Layered Architecture


UI Layer
  |
Coroutine
  |
DataL Layer
  |
Repository

👉 Layered architecture - Recommendations for Android architecture  |  Android Developers

 

🤔 UI Layer


UI Layer
  UDF
  AAC ViewModel
  Lifecycle
  User Event

👉 UI layer - Recommendations for Android architecture  |  Android Developers

 

🤔 ViewModel


ViewModel
  Depencencies
  Coroutine Flow
  State Holder

👉 ViewModel - Recommendations for Android architecture  |  Android Developers

 

🤔 Lifecycle


Lifecycle
  LifecycleObserver

👉 Lifecycle - Recommendations for Android architecture  |  Android Developers


 

🤔 Handle dependencies


Constructor Injection
Container

👉 Handle dependencies - Recommendations for Android architecture  |  Android Developers

 

🤔 Test


ViewModel
Data Entity (Repository + DataSource)
FakeData
StateFlow

👉 Test - Recommendations for Android architecture  |  Android Developers

 

🤔 まとめ

しれっと、公式リファレンスも分かりやすく更新されていて驚きました。

👉 【Android】アーキテクチャーとして Google が推奨していること #Kotlin - Qiita


【Mac】差出人/返信先メールアドレスの変更手順とメールエイリアスの作成方法

macOSの「メール」アプリでは、送信元または返信先のメールアドレスを簡単に変更したり、メールエイリアスを作成することが可能です。

以下に手順を紹介します。

 

🤔 送信元メールアドレスの変更

送信する際に、差出人アドレスを変更したい場合は、次の手順に従います。


1. 「メール」アプリを起動:
     Dockやアプリケーションフォルダから「メール」を開きます。

2. 新規メールを作成: 
     メール作成画面を開きます。

3. 差出人アドレスを選択:
     - 差出人欄の横にある「アドレスメニュー」をクリックすると、設定済みのメールアドレスの一覧が表示されます。
     - 希望するアドレスを選択します。

4. メールを送信: 
    選択したメールアドレスを使用して、メールを送信します。

 

🤔 メールエイリアスの作成

メールエイリアスを使うと、実際のメールアドレスとは異なる名前やドメインを利用してメールを受信できます。

以下はエイリアス作成の手順です。


1. 「メール」アプリを起動し、メニューバーから「メール」>「設定」(または「環境設定」)を選択します。

2. アカウントを選択:
   設定画面で左側に表示されるアカウント一覧から、メールエイリアスを設定したいアカウントを選びます。

3. エイリアスを追加:
   「送信メールアドレス」の欄に、新しいエイリアスを入力します。
    複数のエイリアスを使用したい場合は、カンマで区切ります。

4. 追加後、設定を保存します。

これで、メール作成時に、差出人の欄でエイリアスを選択できるようになります。

エイリアスは、プライバシーを保護したい場合や、特定のプロジェクト専用のアドレスを使いたい場合に便利です。

 

🤔 まとめ

macOSの「メール」アプリでは、差出人アドレスの変更やエイリアスの作成が簡単に行えます。

これにより、用途に応じてメールを柔軟に使い分けることが可能になります。

エイリアス機能は特に、複数のメールアドレスを活用したいときに便利です。

ぜひ試してみて、メール管理をさらにスムーズにしてみてください!

👉 Macの「メール」で差出人のアドレスまたは返信先のアドレスを設定する - Apple サポート (日本)
👉 Macの「メール」でメールエイリアスを使用する - Apple サポート (日本)