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週間前後。


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

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


macOS でスクリプトから通知を出す。


macOS でスクリプトから通知を出します。

mac の前に座る時間が増えたコロナ期間では必須ですよね!

しょうもない確認作業はスクリプトで自動化していきましょう。

👉 Play ストアから現在公開中のバージョンを取得するワンライナー 

そのまえに通知時に使うサウンドを増やしておきます。

 

システム効果音

私の mac は今、Monterey ですが、

通知時のサウンドは以下で設定できます。


システム環境設定

  ↓

サウンド

  ↓

サウンドエフェクト

mac os system effect sounds montrey

実体ファイルは以下にあります。


~ % ls /System/Library/Sounds
Basso.aiff	Frog.aiff	Hero.aiff	Pop.aiff	Submarine.aiff
Blow.aiff	Funk.aiff	Morse.aiff	Purr.aiff	Tink.aiff
Bottle.aiff	Glass.aiff	Ping.aiff	Sosumi.aiff

少し寂しいので追加します。

stevenjaycohen
👉 Google Code Archive - Long-term storage for Google Code Project Hosting. 

ユーザー追加向けディレクトリに置きます。(インストラーでは置かれます。)


~ % ls ~/Library/Sounds
Bip.aiff		Logjam.aiff		Uh oh.aiff
Boing.aiff		Monkey.aiff		Voltage.aiff
ChuToy.aiff		Pong2003.aiff		Whit.aiff
Clink-Klank.aiff	Quack.aiff		Wild Eep.aiff
Droplet.aiff		Single Click.aiff	moof.aiff
Indigo.aiff		Sosumi.aiff		newbip.aiff
Laugh.aiff		Temple.aiff

macOS 側の GUI からは、2つのディレクトリ内の音声ファイルを合成したものが表示されます。

mac os system sound classic

 

スクリプト

スクリプトから通知にメッセージを出力するには以下のようです。


~ % osascript -e 'display notification "めっせーじ" with title "たいとる" subtitle "さぶたいとる" sound name "Bip"'

sound 部分には、先ほどの音声ファイル名を拡張子なしで記述します。

👉 RubyからMacの通知センターで通知する簡単な方法 (AppleScript) - Qiita 
👉 Display notification from the Mac command line 
👉 Google Play Console - Google Play のアプリ 


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