Setup Cappuccino

[keiji]

Issue 番号 / Issue ID

• 接触確認API バージョンアップ #300

目的 / Purpose

• 接触確認APIバージョンアップにあたりCappuccinoのパッケージを使う
  https://github.com/keiji/chino

破壊的変更をもたらしますか / Does this introduce a breaking change?

[x] Yes
[ ] No

Pull Request の種類 / Pull Request type

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

検証方法 / How to test

コードの入手 / Get the code

git clone [repo-address]
cd [repo-name]
git checkout [branch-name]
dotnet restore

コードの検証 / Test the code

確認事項 / What to check

• ビルドできるかどうか

その他 / Other information

Cappuccinoの利用に当たってXamarinバインディングを最新にする必要があることから #142 の内容を含んでいる

[kazuhiro4949]

TempNugetFeed/内のファイルって運用時には外部化される予定でしょうか？
運用時にはライブラリがバージョン管理された状態にしてビルド済みのバイナリはこの中には含めないほうがいいかなと思いました。

[keiji]

技術的には可能です。その上でバイナリ（今回リンクしているCappuccinoやEN APIのXamarin binding）をNuGet Gallery等に配置することは今のところ考えていません。

現状、バイナリをTempNugetFeedに配置すると読み込まれてパッケージの利用が可能になります。どのバージョンのバイナリを使うかはcsproj側で管理します。

https://github.com/cocoa-mhlw/cocoa/pull/307/files#diff-d6aab1d04ff67506ee4fa92b2f0ed2d72e7c65d4ec31e86fce250bcebabf2c75R69-R71

コードとバイナリの対応はChinoのリポジトリ（ https://github.com/keiji/chino/releases ）で確認することになります。

同じXamarinを採用しているデンマーク（ノルウェー）の接触確認アプリ「Smittestopp」も、TempNugetFeedにバイナリを配置してリンクする方式をとっています。

また、GoogleがAndroid向けに公開しているExposureNotificationライブラリもバイナリ（aar）を直接プロジェクトに配置する方式で、標準的なMavenCentralなどの場所では公開していません。

https://github.com/google/exposure-notifications-android/tree/master/app/libs

これは、接触確認アプリは一国一アプリの原則があるためライブラリの利用者が少なく、パブリックな場所に公開して管理するのは運用コストが見合わないためと推測します。
特にXamarin製ともなると日本とデンマーク（ノルウェー）の２国しかありません。幸いなことに現在Cappuccinoはすべてコントロールできる状況にあるので、リリースのタイミングで十分な調整は可能と考えます。

[kazuhiro4949]

@keiji 再利用するものではないので自分もNuGet Galleryなどの中央リポジトリで一般公開する必要はないと思います。
パッケージ管理システムでライブラリを入れるようにしたほうがいいと考えている理由としては、↓のように考えていました。

1. cocoaパッケージに入っているバイナリと入れたいソースコードの対応が保証されている状態にしたい
   1. チェックサムで都度比較とかでもいいですが組み込みのパッケージ管理システム使ったほうが自動化が楽そう
2. 依存によっては限界はあるけど、できる限りsingle source of truthな状態にしたい
   1. 開発時もアーカイブ時もシステム的に入れてバイナリの出元がトレースできる方が運用時に混乱が起きにくい

他の言語のパッケージ管理システムと同じようにNuGetもLocal feed自体は持てるようなので、個人的に配信するという形式でやるのが良いんじゃなかろうかと思っております。
https://docs.microsoft.com/en-us/nuget/hosting-packages/overview

心配しているフェーズとしてはリリース後の運用時や現開発者の手から離れることがあった時で、それを考えるとリリースまでにやれればいいと思っています。gitのメタデータ全体への影響も、バイナリサイズの小ささやCOCOAのgithub上での開発規模から考えても気にしなくて良さそう。

こちらのプルリクはバイナリ組み込みとして入れつつ、ちょっと上記のやり方でできないかちょっと色々試してみますね。
(NuGetのライブラリ作ったことないから具体的な実装がまだイメージできていない...)

[kazuhiro4949]

これの削除ってXamarin.GooglePlayServices.Nearby.ExposureNotificationのアップデートの影響でしょうか？

[keiji]

Newtonsoft.JsonはCappuccinoに含まれていて、バージョン違いで衝突が発生するため消しました。

[kazuhiro4949]

@keiji 一点だけ質問コメントを書きましたmm
手元でのiOS14.5端末とiOS13.5シミュレータでのビルド・CIは問題なさそうです。

[kazuhiro4949]

マージします！

[keiji]

@kazuhiro4949 ありがとうございます。ぼくもNuGetのライブラリ公開については知見がない状態なので、良さそうなやり方を考えられればと思います。オープンソースなのでCOCOAをビルドするときに複雑な手順が必要になることは避けたいところです。

開発者が変わった時の心配は尤もなので、Cappuccinoの管理者について調整することも課題としてありますね。