連絡先アプリ 必ず把握しておくべき全設定画面別使い方メモ- 連絡先 / コンタクトの使い方まとめ その3【Android → iPhone】

連絡先アプリの設定項目は少ないものの、すべて大事な設定となります。

iCloud や Googleコンタクト 連携の状態をきちんと把握しながら iPhone の設定を確認します。

1. iCloud連絡先 の有効化/無効化

iCloud連絡先 の有効化/無効化


[設定]

  ↓

[Apple ID]

  ↓

[iCloud]

  ↓

[連絡先 ON/OFF]

iCloud連絡先 の有効化

iCloud の連絡先をOFFにするには、[iPhoneに残す]か[iPhoneから削除]のどちらかを選択する。

iCloud の連絡先をOFFにするには、[iPhoneに残す]か[iPhoneから削除]のどちらかを選択する。

[iPhoneに残す] を選択すると、iCloud上の連絡先データが端末にコピーされ保存される。

[iPhoneから削除] を選択すると、表示されていたiCloud上の連絡先データは端末で表示されなくなる。

2. Googleコンタクト アカウントの有効化/無効化

Googleコンタクト アカウントの有効化/無効化


[設定]

  ↓

[連絡先]

  ↓

[アカウント]

  ↓

(有効化/無効化するアカウントを選択)

  ↓

[連絡先 ON/OFF]

Googleコンタクト アカウントの有効化/無効化

無効化する場合は [iPhoneから削除] するしかない。

無効化する場合は「iPhoneから削除」するしかない。

Googleアカウント をOFFにして無効化するときに、端末側にコピーして取り込むことはできない。 → 【おまけ】

3. デフォルトアカウント(新規追加保存先) の選択

新しく連絡先データを追加するときの保存先の設定。

既存データの編集は、所属アカウントに編集後保存される。


[設定]

  ↓

[連絡先]

  ↓

[デフォルトアカウント]

  ↓

(デフォルトアカウントを選択)

デフォルトアカウント(新規追加保存先) の選択

4. 表示するグループの選択

連絡先アプリ側の設定で、接続はしているものの、表示/非表示 をグループごとに設定できる。


[連絡先アプリ 起動]

  ↓

[グループ]

  ↓

(表示したいグループをチェック)

表示するグループの選択

複数アカウント/ グループが有効化されてるときだけ左上に [グループ] が表示される。

まとめ

上の4つの設定項目で、iPhone端末内連絡先アプリと連携するクラウドサービスを組み合わせる。

Phone 連絡先アプリ + Google コンタクト +

自分の設定がどの設定の組み合わせになっているのか把握しておくべし。

👉 Google コンタクト 
👉 iCloud連絡先 

 

【おまけ】 vCard(.vcf) 添付メール からの一括インポート

インポートしたい端末で受信したメールの添付ファイルからインポートして一括追加する。

vCardから連絡先を読み込む
メールまたはメッセージの.vcf添付ファイルをタップします。

👉 iPhoneでほかの連絡先アカウントを使用する - Apple サポート (日本) 


(受信したメールの添付ファイルをタップ)

  ↓

[新規連絡先を作成]

インポートしたい端末で受信したメールの添付ファイルからインポートして一括追加する。
インポートしたい端末で受信したメールの添付ファイルからインポートして一括追加する。

[***件すべての連絡先を追加] は既存カードのマージ更新。まぎらわしいので注意。

👉 連絡先をクラウド上に保存する - 連絡先 / コンタクトの使い方まとめ その1【Android / iPhone】 
👉 Google コンタクト データをAndroid と iPhone で共有する - 連絡先 / コンタクトの使い方まとめ その2【Android / iPhone】 
👉 Googleコンタクト から iCloud連絡先 へ完全移行する手順 - 連絡先 / コンタクトの使い方まとめ その4 【Android → iPhone】 
👉 iPhone連絡先アプリ だけが iCloud連絡先 のデータをエクスポートできない件 

Error: ComponentProcessingStep was unable to process 'AppApplication_HiltComponents.SingletonC' because 'DefaultActivityViewModelFactory' could not be resolved.

Releases dagger-2.34
Dagger2.34 にアップデートしたら全くビルドが通らず。

Error: ComponentProcessingStep was unable to process 'com.example.eg.AppApplication_HiltComponents.SingletonC' because 'dagger.hilt.android.internal.lifecycle.DefaultActivityViewModelFactory' could not be resolved.

なんすかねこれ。

 

androidx.hilt:hilt-lifecycle-viewmodel が不要

Hmm, the androidx.hilt:hilt-lifecycle-viewmodel artifacts were deprecated in the Dagger 2.34 release in favor of native Hilt API. The missing DefaultActivityViewModelFactory class is no longer in the Hilt codebase.

You should be able to fix this using the instructions in the 2.34 release notes to upgrade to the new HiltViewModel API.

androidx.hilt:hilt-lifecycle-viewmodel アーティファクトはDagger 2.34リリースで非推奨となり、ネイティブHilt APIに切り替わりました。

👉 ComponentProcessingStep was unable to process '*Application_HiltComponents.SingletonC' · Issue #3257 · google/dagger

New breaking changes
The alpha androidx extension @ViewModelInject is no longer supported. @ViewModelInject has been deprecated since androidx.hilt 1.0.0-alpha03 and was removed in androidx.hilt 1.0.0-beta01. Hilt now falls back to the base activity/fragment default ViewModelProviderFactory (3778ee2)

Migration steps:
Users of @ViewModelInject can migrate to @HiltViewModel which was added in Dagger 2.31.

1. Add @HiltViewModel annotation to the class
2. Replace the @ViewModelInject annotation on the constructor with @Inject.
3. Remove @Assisted from the SavedStateHandle constructor parameter, if it exists
4. Remove the old androidx.hilt:hilt-lifecycle-viewmodel dependency from your build.gradle file

👉 Release Dagger 2.34 · google/dagger 

私の場合は、上記の手順を確認して build.gradle を修正でビルド通るようになりました。削除漏れです。

androidx.hilt:hilt-lifecycle-viewmodel artifacts were deprecated in the Dagger 2.34 release in favor of native Hilt API.

build ファイルの削除漏れが影響を及ぼすことが結構多くなりました、最近。

【Playストア】今現在のアプリ更新時の審査日数を調べる方法

アプリ更新後のリリースされるタイミングをスクリプトで検知したりしていましたが。



👉 Play ストアから現在公開中のバージョンを取得する 
👉 macOS でスクリプトから通知を出す。 

この公開されるまでの時間が長くなったのは、コロナ禍の影響なのか、審査を細かく見るようになったからか、何なのか。


気になったので少し調べてみました。

アプリ名 アップロード日 ストア公開日 所要日数
YouTube 2/10 2/13 3
Amazonショッピング 2/2 2/10 8
Amazonプライムビデオ 2/8 2/10 2
ツイキャス 2/10 2/11 1
TouTubeStudio 2/3 2/10 7
Spotify 2/8 2/9 1
Googleカレンダー 2/1 2/9 8
Twitter 2/8 2/9 1
Google Keep 2/1 2/9 8
ABEMA 2/4 2/9 5
Googleフォト 2/9 2/9 0
メルカリ 2/4 2/9 5
インスタ 2/7 2/8 1
Facebook 2/12 2/13 1
Googleマップ 2/3 2/6 6
Googleドライブ 2/4 2/8 4
Google 2/4 2/7 3
Tver 2/3 2/4 1
Google Fit 1/31 2/4 4
Chrome 2/1 2/4 3
SpeedTest 1/19 2/3 15
Gboard 2/1 2/2 1
ニコ生 1/26 1/31 5

 

調べ方

Google Play ストアアプリで、右上アカウントから、


[アプリとデバイスの管理]

  ↓

[最近の更新を見る]

  ↓

[最近更新したアプリ]

たとえば、アプリ「ツイキャス」で見てみると、

【Playストア】今現在のアプリ更新時の審査日数を調べる方法

今現在が、2/15 なので、審査が終わって、ストアに公開されて、端末が検知して、更新したのが「4日前」の「2/11」。

タップして詳細画面へ。

【Playストア】今現在のアプリ更新時の審査日数を調べる方法

開発者は分かってると思うが、「最終更新」は更新内容をアップロードしたタイミング。

この場合は「2/10」。

よって、

アップロード日 : 2/10
ストア公開日 : 2/11

となり、この2つの差の所要日数の「1日間」が審査日数に近いはず。

Playストアのアプリのキャッシュの影響などもあるのだが、頻繁に手動でアプリ更新をしていれば精度は上がる。

まあ、機種、OSバージョン別パッケージなどの話はあるが、全体的な雰囲気は分かる。

 

まとめ

上の表を眺めていると、アプリのカテゴリーで審査のスピードが違うような、なんとなくだが。

SNS、動画、音楽、ライブ配信
→ 3日以内

それ以外は大体1週間前後。


しかし、私のアプリはなぜそんなに時間がかかったのか。

ゴミアプリだからですか、すいません。