はつねの日記

Kinect, Windows 10 UWP, Windows Azure, IoT, 電子工作

iOSアプリでMulticast Networkingを許可する方法

iOS14以降 & XCode 12以降では、ローカルネットワークへの通信にユーザの許可が必要になりました。
そして、マルチキャスト/ブロードキャストで他の機器と通信をするためには、Appleへの申請やentitlementsへの追記など色々必要になっています。

ローカルネットワーク通信の許可

Info.plistに対して、「Privacy - Local Network Usage Description」を追加してローカルネットワーク上の別デバイスとの通信を行うときに許可ダイアログが表示されるようにします。
ただし、Xamarinの場合、2021/07/19現在の最新版では「Privacy - Local Network Usage Description」が選択肢の中にでてきません。
f:id:hatsune_a:20210719200453p:plain
そこで、直接Info.plistファイルを編集して「NSLocalNetworkUsageDescription」を追加します。
f:id:hatsune_a:20210719200741p:plain

マルチキャスト/ブロードキャストで他の機器と通信を許可

Multicast Networking Entitlement申請

Bonjourでサービスを検索するときには不要ですが、それ以外でマルチキャストやブロードキャストをするときには、Appleに「Multicast Networking Entitlement申請」を行う必要があります。
申請方法は下記のURLに開発者アカウントでサインインして申請します。申請してから3~5営業日くらいで「Multicast Networking Entitlement」を取得できます。
https://developer.apple.com/contact/request/networking-multicast
申請時の注意するのは、「Explain why your app needs to send multicast or broadcast traffic, or browse for all Bonjour service types.」という項目の内容です。ここには、次のような内容が含まれていないと、追加情報を要求されて余計に日数がかかります。

  • Multicastなのかbroadcastなのか
  • なんの目的で通信するのか
  • 通信するIPアドレスやポート番号
  • 通信するデータ(例えば、JSON形式で端末で計測したデータなど)
Capabilitiesの追加

「Multicast Networking Entitlement」が取得できたとの連絡メールがAppleからくると、Apple Developer Programのサイトの「Identifiers」にて、Multicast NetworkingのCapabilitiesをEnableにできます。
f:id:hatsune_a:20210719203739p:plain
Enableにチェックをつけて[Save]をクリックすると確認ダイアログが出るので[Confirm]をクリックします。
f:id:hatsune_a:20210719203837p:plain

プロビジョニングプロファイルの再作成

Capabilitiesの追加確認のダイアログには「機能を追加または削除すると、このアプリIDを含むプロビジョニングプロファイルが無効になり、今後使用するためには再生成する必要があります。」と記載があるのでプロビジョニングプロファイルの再作成が必要です。
f:id:hatsune_a:20210719204227p:plain

Entitlements.plsitでエンタイトルメントを有効にする

f:id:hatsune_a:20210719205003p:plain
アプリの.entitlementsファイルに、ブール値が true のcom.apple.developer.networking.multicastエントリを追加します。

実機に転送して動作を確認する

Multicast Networkingを許可する設定がない場合でも実機でなければ影響をうけません。
実機でデバッグ実行をしてマルチキャスト通信でエラーにならないことを確認できれば、設定は終了です。

iOSアプリ作成に必要な証明書についてまとめてみた

.NET 6やMAUIなど、今年、MicrosoftがGA(一般公開)する技術では、マルチプラットフォームのXamarin.Formsよりも更に促進されることが期待されるものが多いと感じています。

そこで、じゃあC#を使ってAndroidiOSのアプリを作成しようと思ったときに、意外にネックになるのが、iOSアプリを作成するときに必要な証明書の作成です。
しかも本番用証明書の期限は1年なので、私だけなのかもしれませんが、毎年どうやったのか思い出しながら不安になりつつ作業しています。
そこで、心理的安全が欲しいということもあり、ちょっとこの辺りを自分の言葉でまとめておきたいと思います。
この分野は専門外なので、何かおかしな記述があればご指摘いただき、随時、本文に反映させていくという若干他力本願な内容となりますが、最後までお付き合いいただければ幸いです。

登場人物

  • Apple Developer Program
  • MacOS上で作成する証明書(便宜上、アカウント証明書とします)
  • Apple Development 証明書(または、iOS App Development証明書)
  • Apple Distribution 証明書(または、iOS Distribution証明書)

証明書を発行しよう

Apple Developer Programの登録/更新

iOSアプリを開発してストアで公開してとなると、Apple Developer Programに加入する必要があります。
アプリ作成するだけなら加入必須ではないという話もあるようですが、そこについては今回は触れません。
developer.apple.com
Apple Developer Programの年間メンバーシップの料金は11,800円です。iOSなどのベータ版も入手できたり、様々な情報も得られますから、実際にストアに登録する作業を別部署でやり開発する人が直接できないようなジャパニーズトラディショナルカンパニーさんだったとしても、開発している部署でも(会社のお金で)登録しておくとよいと思います。

アカウントについて

ここで重要なのは、登録するときに記入するメールアドレスです。これが、今後の様々なところで「アカウント」として一意に識別されるための情報となります。

Team IDについて

メンバーシップに登録されるとTeam IDというものが払い出されます。このIDも重要で、要はアプリの発行元IDのようなものになります。
後々作成する証明書について、どの証明書かわからなくなったらこのTeam IDを他よりに判断することになります。

年間メンバーシップの更新について

なお、年間なので1年後にはメンバーシップの更新が必要になります。近づいてくるとメールで「そろそろ期限がきれますよ」とお知らせが飛んでくる新設設計なので、メール無視せずに期限切れになるまえにちゃんと更新しておくようにしましょう。
忘れない!絶対!

アカウント証明書の作成

Apple Developer Programの登録がおわったら、Macでの作業となります。

認証局に証明書を要求

f:id:hatsune_a:20210616190711p:plain
[キーチェーンアクセス]-[証明書アシスタント]-[認証局に証明書を要求]メニューをクリックします。

f:id:hatsune_a:20210616191257p:plain

  • [ユーザーのメールアドレス]欄には、メンバーシップのアカウントに指定したメールアドレスを指定
  • [通称]欄には任意の名前を指定
  • [ディスクに保存]を選択
  • [鍵ペア情報を指定]チェックにチェック

[続ける]ボタンをクリックしてから、次のように設定されていることを確認します。

デスクトップを指定して[保存]ボタンをクリックすれば、これで、Apple Developer Programのアカウントに紐付いたアカウント証明書が作成できました。
この証明書の有効期限も、作成してから1年間となります。また、作成するときには有効な年間メンバーシップの契約が必要です。
そのため、年間メンバーシップを更新したら、アカウント証明書も再作成しておくとよいでしょう。

Apple Development 証明書の発行

アカウント証明書が作成できたならば、Apple Developer Programのサイトにいって作業します。
事前に登録したアカウントでサインイン
「Certificate, Identifiers & Profiles」のページに移動します。
f:id:hatsune_a:20210616085707p:plain

新しいApple Development 証明書の発行

Certificatesの後ろの[+]を押して、新しい証明書を発行します。
f:id:hatsune_a:20210616091338p:plain
開発用のApple Development証明書ならば、「Apple Development」を指定します。

Apple DevelopmentとiOS App Developmentの違い

XCode 11以降はApple Developmentを指定します。
それより以前のものはiOS App Developmentを指定しますが、古いXCodeを積極的に使う理由はないので、実質「Apple Development」一択です。

Maximum number of certificates generated について

「Maximum number of certificates generated」とでているのは、すでに発行しているApple Development 証明書に紐付いている「Provisioning Profile (Development)」で有効期限切れのものがあるからです。

アカウント証明書をアップロードする

f:id:hatsune_a:20210616093534p:plain
Macで作成したアカウント証明書を選択します。
これでApple Development 証明書が作成できました。
Certificatesの一覧には、Apple Developer Programのアカウント名=メンバーシップの「Account Holder」が証明書名として表示されます。

Apple Development 証明書をMacにダウンロードする

Apple Development 証明書が作成できたので、Macにダウンロードしておきましょう。

Apple Distribution 証明書の発行

アカウント証明書が作成できたならば、Apple Developer Programのサイトにいって作業します。
事前に登録したアカウントでサインイン
「Certificate, Identifiers & Profiles」のページに移動します。
f:id:hatsune_a:20210616085707p:plain

新しいApple Distribution証明書の発行

Certificatesの後ろの[+]を押して、新しい証明書を発行します。
f:id:hatsune_a:20210616094512p:plain
発行用の証明書が必要なので、「Apple Distribution」を指定します。

Apple DistributionとiOS Distributionの違い

XCode 11以降はApple Distributionを指定します。
それより以前のものはiOS Distributionを指定しますが、古いXCodeを積極的に使う理由はないので、実質「Apple Distribution」一択です。

Apple Distribution証明書の発行上限数について

Apple Distribution証明書は、合計で3つ作成できます。
Apple Distribution証明書は、基本的にアプリごとに作成するのではなく、発行者ごと、つまり、Apple Developer Programのメンバーシップごとに1つ作るような運用イメージになります。

アカウント証明書をアップロードする

f:id:hatsune_a:20210616093534p:plain
Macで作成したアカウント証明書を選択します。
これでApple Distribution 証明書が作成できました。
Certificatesの一覧には、メンバーシップの「Team Name」が証明書名として表示されます。

Apple Distribution証明書をMacにダウンロードする

Apple Distribution証明書が作成できたので、Macにダウンロードしておきましょう。

キーチューンに登録する

Apple Develoment証明書と、Apple Distribution 証明書がダウンロードできたら、キーチューンに登録しておきましょう。
登録は簡単で、証明書をダブルクリックすればキーチューンが立ち上がって追加されます。
f:id:hatsune_a:20210616221344p:plain
これで新しい有効期限の証明書がキーチューンアクセスのログイン証明書に登録することができました。
証明書の中の秘密鍵の名前は、アカウント証明書を作成するときに認証局に証明書を要求した時の通称が設定されています。
有効期限の更新で証明書を作成した場合は、この時点で古い有効期限の証明書は削除しておきましょう。

最後に

来年の年間メンバーシップの更新時に新しい証明書を作成するときや、開発機を変更するときなども、きっと、このエントリ見ながらやると思います。忘備録大切!

iOSアプリの開発環境の2台目を設定する

Xamarin.Formsを使ってiOSアプリを作っています。
Windows上でVisual Studio 16.9を使って作成して、Visual Studio for Macが入ったMacMiniとペアリングしてビルドするような開発環境となっています。
docs.microsoft.com

今月、ちょっとした事情(主に在宅勤務時に自宅で実機デバッグができるように)2台目の開発用MacMiniを入手しました。
もちろんM1 MacMiniです。

さて、ここで悩んだのが1台目と同じビルド結果となるように2台目に設定するのかということです。
1台目の開発環境を作る方法は、いろいろなblogに書かれているのですが、その作った環境と同じものを2台目として作る方法がよくわからない。。。
下手にやって1台目の環境でアプリがビルドできなくなったらストア公開しているものが更新できなくなったら本末転倒ですからね、どうしても慎重になってします。

悩んで「なんもわからーん」とホロラボ社内に聞いてみたら、即回答もらえました。
事前に1台目のApple開発者アカウントを2台目にも設定してあれば、残る手順は以下の通り。

  1. 1台目のキーチェーンでDistribution証明書とDeveloper証明書からそれぞれ「書き出す」でp12ファイルを作成
  2. 2台目にp12ファイルをコピーしてダブルクリックでキーチェーンに登録

なんとこれだけで良かったみたい。
簡単でした。

Xamarinで作成したAndroid App Bundleを端末にインストールする

2021年8月からは、Google Playに新しくアプリを登録するには、従来のapkではなくAndroid App Bundle(aab)で登録することが必要になります。
Visual Studio + XamarinでAndroid向けアプリを作成するときも、もちろん、apkだけではなくaabで作成できます。
初期のころはaab作成がVisual Studioからはできず、MSBuildを使ってコマンドラインでaabファイルをつくらなければなりませんでしたが、最近のVisual Studioではアーカイブでも可能です。

Androidオプションを設定する

aabを作成するには、Androidアプリのプロジェクトのプロパティを表示して、Androidオプション画面で設定します。
aab作成には本当に時間がかかるので、Release構成のみの設定が推奨されています。

Release構成で設定する

そのため、[構成]を「Release」にしてから設定を変更します。
f:id:hatsune_a:20210218073903p:plain
設定は簡単で、Androidパッケージ形式を「バンドル」にするとaab作成となります。このとき次の2つのチェックボックスが、値固定でグレーアウトします。

  • [選択したABIごとに1つのパッケージにします]はOFF
  • [インクリメンタルAndroidパッケージシステム(aapt2)を使用します]はON
aapt2とは

aapt2(Android Asset Packaging Tool)は、アプリのリソースをコンパイル、パッケージ化するために使用するビルドツールです。AAPT2 はリソースを解析してインデックスに登録し、Android プラットフォーム向けに最適化されたバイナリ形式にコンパイルします。

Debug構成で設定する

2つの設定が固定化されるのであれば、Debug構成でも同じ設定にしておいてデバッグしておくことが安全です。
aapt2については新規プロジェクト作成時はデフォルトONになっていますが、以前から使っているプロジェクトではOFFになっているものも多いでしょう。
それでは、[構成]を「Debug」にしてaapt2をONに設定しましょう。
f:id:hatsune_a:20210218075244p:plain
Visual Studioが至れり尽くせりだなーと思うのは、Release構成側で「バンドル」を指定すると、Debug構成側も自動的に2つのチェックボックスが同じ値でグレーアウトしていました。
もちろん、パッケージ形式は「apk」のままです。

アーカイブを実行する

構成ごとの設定がおわったら、Release構成をアクティブにしてアーカイブします。
f:id:hatsune_a:20210218080119p:plain
アーカイブが成功すると、アーカイブマネージャーにバンドル形式「aab」のエントリが表示されます。
f:id:hatsune_a:20210218080434p:plain

配布用に署名する

アーカイブができたら、[配布]ボタンをクリックして「アドホック」でファイル作成して手動でGoogle Play Consoleにアップロードするか、「Google Play」でアップロードまで行うかを選んで、署名付きaabを作成します。
実機にインストールするためには、「アドホック」を選択して署名付きaabファイルを作成しましょう。

aabを実機にインストールする

署名付きaabを実機にインストールしたいときは、adbコマンドを使って実行します。
f:id:hatsune_a:20210218100427p:plain
Visual Studioのメニューからコマンドラインを起動して、USBに実機を接続してUSBデバッグを許可したらadb installします。
f:id:hatsune_a:20210218100918p:plain
Successが出たら終了です。
実機で動作を確認してみましょう。

Google Play Consoleにアップロードする

実機確認できたら、署名付きaabをGoogle Playに登録してみましょう。
試しに、登録済のapkと同じバージョンとバージョンコードで作成して登録してみると次のようなエラーとなりました。
f:id:hatsune_a:20210218090633p:plain
当然ですが、apkとaabで同じバージョンをアップロードはできないようですね。

Google Playでアプリを署名する

ついでといっては何ですが、配布するならば「Google Playで署名されています」マークを付けておきたいですよね。
新規に登録するときは自動的にGoogle Play Consoleで次のような表示になります。
f:id:hatsune_a:20210218090543p:plain
既存登録済でこの表示がない場合は、手動で設定しないといけないのですが、次のQuitaが分かりやすかったです。
qiita.com
qiita.com
上から順番に読んでみると理解しやすくお勧めです。

それではVisual StudioでのAndroidアプリ開発、楽しんでいきましょう!

.NET 5.0リリース候補版(RC)が公開されました。

devblogs.microsoft.com

.NET Core 3.1の後継になる.NET 5.0のリリース候補版が公開されました。

Visual Studioから使いたいときは、Visual Studio 2019 (v16.8, Preview 3)をインストールするとよいみたいです。

 

.NET 5.0の良いところは、WPFWindows Form、UWP、Xamarin、Unityなどのクライアントアプリの共通フレームワークとして居続けられる点です(ASP.NETも)。

そして、生成するバイナリとしては、x86/x64/ARMに加えてARM64にも対応しており、WindowsLinuxMac向けに単一ファイルで実行可能(つまり必要な.NET 5なDLLも含んだ実行ファイル)の生成に対応している点も大きいでしょう。

長期サポート版は.NET 6.0までは提供されないようですが、いまから、.NET 5.0で動くようなコードを前提として準備しておくのがいいと思います。

 

GitHubのmasterブランチはmainブランチ?

[JP]The English translation is next to the Japanese. Please scroll down.

GitHubのmasterブランチはmainブランチ

GitHubのmasterブランチは、そのソースコードの大元のブランチです。

git-flowなどの流儀では、masterブランチは直接変更せず、developブランチを切って、更に変更内容ごとにfeatureブランチを切り、そこで変更が終わったらdevelopブランチにマージして、さらにリリースするときにはreleaseブランチにマージしリリース作業をします。

そして、リリースしたらreleaseブランチから、masterブランチとdevelopブランチにマージしてみたいな感じにします。

 

もちろん、ここでいう「master」は、masterディスクとかmasterファイルとかと同じ意味の「master」です。

マスターファイルは日本語で言えば、原簿とか基本ファイルと呼ばれているので(というかマスターファイルで通じるけどね)、あえて、masterブランチを日本語化するならば、原分岐とか基本分岐とかになるのでしょうか。

 

それくらい大切なmasterブランチですが、最近の流れでは「master」ではなく「main」と命名することがあるようです。

例:

github.com

これ、docsの方はmasterブランチで引用していて、ことごとくリンクが404になってしまうので、最近変わったようです。

 

EssentialsのShareのdocsで気づいてプルリクしたけど、これ、shareだけじゃなくて、Essemtials関係のdocs全部ですね。

docs.microsoft.com

ほぼすべてのページで、最後にAPI Source codeでgithubのmasterブランチを引用しています。

 

「main」ブランチでもいいといえばいいのですが、この「master」は、master/slaveのようなslaveと対をなすものではないので、そのままでもいいような気もしなくもないです。でも、masterからmaster/slave想像しちゃうっていうのならば変えるのがいいのかな(この部分を議論したい訳じゃないので、深追いをするつもりないです)。

ただ、私見ですが、先ほどの日本語訳からの逆翻訳した「original」ブランチの方が「main」ブランチよりもしっくりくるかなー。

あとは、「base」ブランチとかかな。

 

[EN]

From now on, will the master branch on GitHub be called the main branch?

The master branch on GitHub is the main branch in its source code.

In the "git-flow" style, you don't change the master branch directly, but instead use the develop branch, and then cut a feature branch for each change, where the change is done, and then and merge it into a develop branch, and release it when you release more. branch and work on the release.

Then, when you release, you merge them into the master branch and the develop branch from the release branch, and so on.

 

Of course, the "master" here is the same as the master disk and the master file.
In Japanese, the master file is called "original file" or "basic file", so if you were to Japaneseize the master branch, it would be "original branch" or "basic branch". 

 

Although the master branch is that important, it is sometimes called "main" instead of "master" in recent years.

For example:  

github.com

 This seems to have changed recently, as the docs are quoted in the master branch, and the links are 404 at every turn.

 

I noticed this in the Share docs in Essentials and pulled it, but it's not just share, it's all the Essemtials-related docs, not just share. 

docs.microsoft.com

Almost every page cites the master branch of github in the API Source code at the end.

 

I wish I could say that the "main" branch is fine, but the "master" is the master It's not a counterpart to a slave like /slave, so I think it's fine as is. It's not impossible. But if you're going to imagine master/slave from master, then changing it is a good idea.

If you're going to imagine master/slave from master, I'd change it (I'm not trying to argue this part, so I won't pursue it).

But in my opinion, the "original" branch, back-translated from the Japanese translation above, feels better than the "main" branch.

Then there's the "base" branch and so on.

Xamarin Forms の ListView でコンテキストサイズを変更しても行の高さが更新されない

[EN]

Xamarin Forms ListView Row Height Does Not Update When Changing Context Size

I've been having trouble creating iOS apps in Xamarin. It is.

That's why, in ListView and elsewhere, you can increase the number of characters in each element, and so on, to make the content more interesting by repetition. The problem of keeping the height of the ListView rows the same when the height is dynamic is.
This only occurs on iOS and the same XAML definition, and the same code, but on Android. This does not happen.

 

The problem is that when displaying a list with different content heights in a ListView, the This is confused with the issue of not being height per content. This problem can be solved on iOS by setting it to true with the HasUnevenRows property. 

docs.microsoft.com But the problem is when each element seems to change after it's displayed. As far back as 2015 or so, we've been asking questions in stackoverflow and Xamarin's It existed as a GitHub issue. The following is a clear description of the issue.

 

github.com

A valid method of targeting that we are currently able to see is to add an ItemSource to the ListView's The idea is to execute the following two lines when the binding element is changed (on iOS, the Only!) 

            if (this.Parent is ListView list)
            {
                list.HasUnevenRows = !list.HasUnevenRows;
                list.HasUnevenRows = !list.HasUnevenRows;
            }

However, if you use this method, when you change the HasUnevenRows property and revert back to The entire ListView is flickering.

However, there is a bit of hope for solving this problem.

You can find this as a "To do-High impact" on GitHub at Xamarin.Forms The issue was posted 5 days ago on. 

github.com

f:id:hatsune_a:20200611080913p:plain

github.com

 I hope this will help you work things out.

 

[JP]

Xamarin Forms の ListView でコンテキストサイズを変更しても行の高さが更新されない

Xamarin.FormsでiOSアプリを作成しているときにずっと困っていることがあります。

それが、ListViewなどで、各要素の文字数を増やすなどして折返しによりコンテンツの高さがダイナミックに変わるようなときにListViewの行の高さが変わらないという問題です。

これは、iOSでのみ発生して同じXAML定義、そして同じコードでもAndroidでは発生しません。

 

この問題は、異なるコンテンツの高さをもったリストをListViewで表示したときにコンテンツごとの高さにならないという問題と混同されます。この問題はHasUnevenRowsプロパティとtrueにすればiOSでも解決します。

docs.microsoft.com

しかし、問題は表示した後に各要素が変化するようなときです。古くは2015年くらいからstackoverflowでの質問やXamarinのGitHubのissueとして存在しました。その中で、問題の説明がわかりやすいものが次のものです。

github.com

現在確認できている有効な対象方法は、ListViewのItemSourceにBindingしている要素に変更があったときに次の2行を実行することです(iOSのときだけ!)

            if (this.Parent is ListView list)
            {
                list.HasUnevenRows = !list.HasUnevenRows;
                list.HasUnevenRows = !list.HasUnevenRows;
            }

しかしこの方法を採用した場合、HasUnevenRowsプロパティを変更して戻すときにListView全体がちらついてしまいます。

しかし、この問題の解決に少しだけ希望があります。

Xamarin.FormsのGitHubで「To do-High impact」としてこの問題が5日前に掲載されました。

github.com

f:id:hatsune_a:20200611080913p:plain

github.com

これで解決に向かってくれるといいですね。