「macOS Catalina 2月からAppleの公証が必要になる」とは何なの?

この方針はスムーズな移行のため、9月に一度緩和されていたが、来年2月3日から厳格に適用されるようになる。未公証の“野良アプリ”を「macOS Catalina」で実行しても、従来は警告で済んでいたが、それ以降はエラーで起動不能となるため、アプリに修正を施す必要がある。

👉 「macOS Catalina」で実行する野良アプリにはAppleによる公証が必要に ~来年2月から - 窓の杜 

どうやらこれのことらしい。

Update to Notarization Prerequisites
December 23, 2019

In June, we announced that all Mac software distributed outside the Mac App Store must be notarized by Apple in order to run by default on macOS Catalina. In September, we temporarily adjusted the notarization prerequisites to make this transition easier and to protect users on macOS Catalina who continue to use older versions of software. Starting February 3, 2020, all submitted software must meet the original notarization prerequisites.

If you haven’t yet done so, upload your software to the notary service and review the developer log for warnings. These warnings will become errors starting February 3 and must be fixed in order to have your software notarized. Software notarized before February 3 will continue to run by default on macOS Catalina.

As a reminder, all installer packages must be signed since they may contain executable code. Disk images do not need to be signed, although signing them can help your users verify their contents.

👉 Update to Notarization Prerequisites - News - Apple Developer 

Notarizing Your Mac Software for macOS Catalina
September 3, 2019

As a reminder, Mac software distributed outside the Mac App Store must be notarized by Apple in order to run on macOS Catalina. To make this transition easier and to protect users on macOS Catalina who continue to use older versions of software, we’ve adjusted the notarization prerequisites until January 2020.

You can now notarize Mac software that:

Doesn’t have the Hardened Runtime capability enabled.
Has components not signed with your Developer ID.
Doesn’t include a secure timestamp with your code-signing signature.
Was built with an older SDK.
Includes the com.apple.security.get-task-allow entitlement with the value set to any variation of true.
Make sure to submit all versions of your software. While Xcode 10 or later is still required to submit, you don’t need to rebuild or re-sign your software before submission.

👉 Notarizing Your Mac Software for macOS Catalina - News - Apple Developer 

何か勘違いしてる人多いけど、ダブルクリックで初回起動できなくなるだけでGatekeeperを無視して起動するオプションは今まで通り残るよ。macアプリ開発したことない人が書いた記事だなこれ…

👉 onimのコメント / はてなブックマーク 

こんな素人記事よりEngdgetの解説の方がよっぽど為になる

👉 takhasegawaのコメント / はてなブックマーク 

また、公証を受けていないアプリでも、Gatekeeperの例外として登録すれば、起動することは可能です。

👉 アップル、Mac App Store外アプリの「公証」要件を厳格化。2020年2月3日から - Engadget 日本版 

まとめ

『「公証」の審査基準の厳格化』ということだけで、以下 GateKeeper まわりの操作や挙動は2月以降も同様ということになりますでしょうか。

👉 Mac で App を安全に開く - Apple サポート 

公証を受けていないアプリの割合が増えることになるでしょうが、まあ大勢に影響はないということでしょうね。


PreferenceFragmentCompat に ViewModel を注入する

今現在「DaggerPreferenceFragmentCompat」はありません。

MVVMなストラクチャで、

ViewModel の Fragment プロパティ への注入。

どうしてますか?

HasAndroidInjector を使う

👉 Dagger2: 2.23に入ったHasAndroidInjectorについて - stsnブログ 


class SettingsFragment : PreferenceFragmentCompat(), HasAndroidInjector {

  @Inject
  lateinit var androidInjector: DispatchingAndroidInjector<Any>

  override fun androidInjector(): AndroidInjector<Any> = androidInjector

  override fun onAttach(context: Context) {
    AndroidSupportInjection.inject(this)
    super.onAttach(context)
  }

👉 android - Using Dagger2 with PreferenceFragmentCompat - Stack Overflow 

Dagger は Square が管理してたほうが良かったんじゃねか、と思う。

今から経緯を分からず入門は厳しいはず。


今どきの「ネット接続してるかどうか」のコード。

ググると公式リファレンスが見つかる。


val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
val activeNetwork: NetworkInfo? = cm.activeNetworkInfo
val isConnected: Boolean = activeNetwork?.isConnectedOrConnecting == true

しかし、このコードはAPI29で非推奨。

Note: getActiveNetworkInfo() was deprecated in Android 10. Use NetworkCallbacks instead for apps that target Android 10 (API level 29) and higher.

👉 Monitor connectivity status and connection metering 

Android 10 で通信状態の変更を監視するには、 ConnectivityManager.registerNetworkCallback() を使いましょう。

👉 Android 10 時代の Connectivity Monitoring - takasfz blog 

- コールバックの登録/解除のタイミングはライフサイクルに依存する。
- コールバック onAvailable()/onLost() は、非メインスレッド上で受信。

よって、MVVM上で使うとなると、LiveData化するのが良さげ。


class ConnectivityLiveData @VisibleForTesting internal constructor(private val connectivityManager: ConnectivityManager)
    : LiveData<Boolean>() {

    @RequiresPermission(android.Manifest.permission.ACCESS_NETWORK_STATE)
    constructor(application: Application) : this(application.getSystemService(Context.CONNECTIVITY_SERVICE)
        as ConnectivityManager)

    private val networkCallback = object : ConnectivityManager.NetworkCallback() {
        override fun onAvailable(network: Network?) {
            postValue(true)
        }

        override fun onLost(network: Network?) {
            postValue(false)
        }
    }

    override fun onActive() {
        super.onActive()

        val activeNetwork: NetworkInfo? = connectivityManager.activeNetworkInfo
        postValue(activeNetwork?.isConnectedOrConnecting == true)

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
            connectivityManager.registerDefaultNetworkCallback(networkCallback)
        } else {
            val builder = NetworkRequest.Builder()
            connectivityManager.registerNetworkCallback(builder.build(), networkCallback)
        }
    }

    override fun onInactive() {
        super.onInactive()
        connectivityManager.unregisterNetworkCallback(networkCallback)
    }
}

👉 ConnectivityLiveData - AndroidPub 

まとめ

ただ「ネットが使える/使えない」を判定させるだけの実装がここまでややこしいSDKてのは問題じゃねえか?!

みんな混乱してるようにみえるけども。

もっといい感じがあれば教えてね!