はつねの日記

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

iOSアプリビルド用のプロビジョニングプロファイル(Provisioning Profile)が設定できなかった件

iOSアプリを作成するときに、開発用証明書、配布用証明書に加えて、アプリごとのプロビジョニングファイルを開発環境のMacOS上に登録しなければなりません。

それぞれのファイルはダウンロードしてダブルクリックすれば所定のアプリに連携されて、キーチェーンストアに登録されていきます。

それぞれ1年という期限もあるので、毎年同じ時期にApple Developerのサイトで再作成してダウンロードしなければなりません。

ちょうど6月が更新タイミングだったので(いつも手順を忘れかけたころにやってくる)作業していたのですが、どうしてもプロビジョニングファイルだけが登録されません。

プロビジョニングファイルはXcodeが登録を担うので、Xcodeを入れなおしたり、手動で登録しようとしたりしましたが、上手くいきません。

サイトを調べてみてもプロビジョニングファイルをダブルクリックすれば、キーチェーンストアに登録されるという簡単仕様である以上の情報はなかなか見つかりませんでした。

 

もう、ダメで元々と、プロビジョニングファイルを作り直そうかとしていたときに気づきました。

f:id:hatsune_a:20200609232040p:plain



なんど、Certficatesに「Xcode11以上」という選択肢があるではありませんか。

急いで、そちらに変更してセーブしてダウンロードしてダブルクリックしたところ、無事に登録されて、また、Visual Studio for Macでビルドができるようになりました。

Xamarin.Androidで必要なXamarin.Android.Supportライブラリが大幅に少なくなった件

事の発端は、Xamarin.Forms 4.4だったXamarin.AndroidなプロジェクトをXamarin.Forms 4.6に上げたときにエラーが発生したことでした。

なお、Xamarin.iOSなプロジェクトはすんなりとXamarin.Forms 4.6にビルドエラーなく移行できておりましたので、本当になぞで2日ほど(途中、ACE COMBAT 7やWorld of Warshipなどをやりながら)かかりっきりでした。

そもそもとして、Xamarin.Forms 4.4まではTargetFrameworkとしてAndroid 8.1が指定できましたが、Xamarin.Forms 4.5以降ではTargetFrameworkの最小値がAndroid 9.0に変更になっていたため、もろもろの関係でしばらく上げられずにいたのですが、準備が整ったのでXamarin.Forms 4.6にnugetでさっと上げてみたのです。

するのなんということでしょう。さらに多くのライブラリを入れる必要を示唆されるではありませんか。

f:id:hatsune_a:20200531183731p:plain

でも必要だっていうのだから仕方がありませんね。[OK]を押して追加しましょう。

GItの機能を使って修正前の状態に何度も戻しながら試しました。

しかし。

クリーンしてからリビルドしてもビル度エラーは取れません。

Visual Studioを終了して、プロジェクト配下のbinフォルダとobjフォルダを削除してプロジェクトを再度開いてビルドしてもビル度エラーは取れません。

これは、TargetFrameworkをAndroid 9.0(ビルドエラー調査の途中で4.4のまま9.0にする分にはビルドエラーにならないことは発見)にするだけで、Xamarin.Formsは一生4.4で生きていくしかないのかとあきらめかけました。

しかしそんなとき、滝沢先生の「お前ら4.4か!4.4な人間なのか!いつ何をやるのもいい加減にして、一生4.4のまんま終わるのか!それでいいのか!お前らそれでも男か!悔しくないのか!」と叱咤される声が脳裏に響きました。

「くやしいです!」「よーし!何がんでも4.6にしてやるぞ!」「でもどうしたらいいだ」

そうだ、初心だ!。私たちにはVisual Studioの新規プロジェクト作成のテンプレートがあるじゃないか!

しかし、ここで問題が発生しました。Xamarin.Formsプロジェクトは共有プロジェクトとしてXamarin.iOSプロジェクトとXamarin.Androidプロジェクトから共有したかったのですが、Visual Studio 2019の新規プロジェクト作成では、以前はあったPCLプロジェクトか共有プロジェクトかの選択チェックボックスがありません。

f:id:hatsune_a:20200531191141p:plain

しかたがなしにこのまま進めると、Xamarin.Forms部分はPCLではなく.NET Standard 2.0プロジェクトとしてソリューションが作られます。

しかし、希望もありました。明らかにXamarin.Android.Support関連のライブラリが少ないのです。でも、油断は禁物です。もしかしたら、共有プロジェクトではないからそうなっているのかもしれません。

Xamarin.Formsなテンプレートではなく、Xamarin.Androidなテンプレートで作成し、後から共有プロジェクトとしてXamarin.Formsプロジェクトを確認してみましょう。

するとどうでしょう。あれだけあったXamarin.Android.Support関係のライブラリがたった2つだけになってしまったではありませんか。

Xamarin.Formsをいれても、たったの3つ。

最初、Xamarin.Forms 4.6に上げたときに要求された追加のライブラリも必要ありません。 

f:id:hatsune_a:20200531184442p:plain

もちろん、デザインによっては追加でnugetするものも増えるかもしれません。

しかし、Xamarin.Formsを使ってそれなりのデザインを作っていた元のソリューションに移植してみて実機動作を確認してみても、この3つだけで、きちんと実機で動作確認ができました。

意図せずnugetで取得必要なライブラリの整理もできて(つまり実行モジュールサイズが小さくなって)無事に意図したXamarin.Forms 4.6化も完了しました。

やはり、時々はミニマムサンプルで最新のお作法を振り返ってみる必要がありますね。

 

追記:

なお、重要なのは新しく作ったXamarin.Androidプロジェクトのcsprojファイルの内容を使うことになります。つまり、(既存と同名で別フォルダに)新しいXamarin.Androidプロジェクトを作成して、既存のXamarin.Androidプロジェクトから要素をコピーして新しい状態をつくり保存したら、csprojファイルを既存のプロジェクトフォルダの方の同名ファイルに上書き保存することです。

 

 

 

Everything you need to know about WinUI

Microsoft Build 2020からの引用

https://mybuild.microsoft.com/sessions/7d5b56db-d367-43ac-9163-44de4e3919e8

 

UX Frameworkの統一化を進めているMicrosoftですが、現行のWin UI 2の次のWin UI 3では、MFC、WinForms、WPF、UWP XAMLから共通に使えるようになるようです。

f:id:hatsune_a:20200520225426p:plain

動作フレームワーク的にはDesktopとUWPなので、恩恵をうけそうな感じとしては、WPFにUWP XAMLライクなFluentデザインのコントロールとか使えるようになったらいいかなー。

 

ロードマップは次のような感じだそうです。

f:id:hatsune_a:20200520225700p:plain

本番システムに使っていいよという「go live」には2020年10月、Ignite 2020あたりを目標にしていた感じですね。

Ignite 2020もBuild 2020と同様にオンラインイベントのようですから、「さあ!そろそろ使おうか!」的な目線でセッションを受講出来たらよさそうです。

そして、来年の3月にはGAですね。来年のMicrosoft MVP Global Summitはどうかなー。現地開催できるような情勢だといいですね。

 

さて、みんな大好きuno platformもWinUI 3.0をサポートするそうです。

platform.uno

ということは、Desktop AppsとUWP Appsに加えて、Xamarin AppsもWin UIでUXプラットフォーム部分は共通化できそうですね。

https://s3.amazonaws.com/uno-website-assets/wp-content/uploads/2020/05/19120251/howitworks_new.png

 

 

WinUI 3.0ですがPreview 1はもう使えます。10月までの半年しかないですから、始めるには早すぎるってことはなさそうですよね。

microsoft.github.io

Humans of IT Blogに寄稿しました

techcommunity.microsoft.com

Microsoftが最近取り組んでいるHumans of ITのブログにブログ記事を寄稿しました。

他のゲストブログの方が、困っている当事者である開発者がITで問題解決する内容なのでちょっとだけ異色かもしれませんが、音声認識アクセシビリティをブーストするよという取り組みの紹介となります。

お時間のある時にご一読いただけると幸いです。

Xamarin.Androidで、Could not determine the installation pathというエラーがでたときの対処方法

XamarinでAndroidアプリを実機デプロイして試していたら、何かのタイミング(多分、実機で直接アプリをアンインストール)でビルドは成功するけれど

Could not determine the installation path com.companyname.programname

のようなエラーがでて実機デプロイができなくなりました。

AndroidManifest.xmlのなかのTYPOみたいな情報もあったのですが、今回のケースでは下記が原因でした。

個人用からはアプリをアンインストールしたけれど、仕事用の方からアンインストールしていなかった 

仕事用からもアンインストールすることで無事に実機デプロイが可能になりました。

 

 

MessagePack for C#始めました

以前から使おう使おうと思って(実際は使ってみようとして上手くいかなくてを何回か繰り返して、最近の状況で在宅でがっつり集中できるようになったので)いたneueccさんの素敵ライブラリMessagePack-CSharpを既存アプリに組み込むことができました。

github.com

いくつか、DataContractJsonSerializerから書き換えるうえで迷った点がありましたので、まとめておきたいと思います。

MessagePack-CSharpは、非常に高速なC#用シリアライザーです。例えば構造体⇔Byte配列、構造体⇔Byte配列⇔JSON文字列あたりの変換が多数あるような例えば多端末間メッセージ送受信のデータシリアライズなどに適用するとシステム全体の快適さが増すかもしれません。

GitHubで公開されている測定結果を見ると、まさに桁が違う処理速度です。

https://cloud.githubusercontent.com/assets/46207/23835716/89c8ab08-07af-11e7-9183-9e9415bdc87f.png

 

PublicクラスじゃなくてInternalやPrivateなクラスを使う場合

MessagePack-CSharpでは、デフォルトでは指定する構造体はPublicクラスじゃないと実行時エラーが発生します。ネットで検索してみると「Publicクラスでなければならない」という解説もありましたが、本家のneueccさんの説明ではそのような説明がありませんでした。ということはきっとできる方法が用意されているのだろうと考えてドキュメントをもう一度よんでみるた次のような方法の記載をみつけました。やっぱり原典をみないとですね。

InternalやPrivateなクラスを指定したいときは次のようにします。

gist.github.com

 MessagePackSerializerOptions.Standard.WithResolverの引数にStandardResolverAllowPrivate.Instanceを指定してオプション指定をつくり、それをSerialize<プライベートクラス>メソッドの第二引数に指定してあげれば、Privateクラスでも実行時エラーなくシリアライズできます。

便利ですね。

クラスのプロパティ名をJSON文字列の項目名に使う場合

これは簡単で、クラスに[MessagePack.MessagePackObject(true)]属性をつけてあげればOKです。

JSON文字列上の項目名を、クラスのプロパティ名とは別の名前にしたい場合

JSONに指定する項目名が"message-id"などが必要でプロパティ名に指定が難しいような場合には、Key属性で項目名を指定することができます。

まずはダメな例

gist.github.com

クラスに[MessagePack.MessagePackObject(true)]属性をつけて、変更したいプロパティにだけ[MessagePack.Key("message-id")]属性でJSON項目名を指定してみましたが、これでは変更されませんでした。

OKな例。きちんとすべてにKey属性をつけてクラスの属性ではkeyAsPropertyNameをfalseつまり指定しないようにします。

gist.github.com

これでいままで悩んでいた点が解決できたので、リリース版に反映&テストフェーズに入りたいと思います。

米国に旅行にいくなら、Amazon Lockerを活用しよう

Amazon.comで買い物したものを日本に送ってくれたりしますが、まだまだ(特に電池が入っているものなど)すべてがという訳にはいきません。

米国に旅行に行く機会があったとしても、送付先にホテルを指定してうまく受け取れるか、そもそも滞在期間中に届くようにするにはどうしたらいいのかなどの不確定要素が付きまといます。

 

そんなとき、オースティンに出張に行ったときに街中で見かけたのがAmazon Lockerです。

Amazon.comのサイトを見てみると

  • 配達及び返品に使える
  • 利用時間帯も長く
  • 追加料金なし

というAmazon公式ロッカーのようです。

image

 

ためしにMicrosoft MVP Global Summitで宿泊する近くをさがしてみるといくつかあるようです。

image

郵便番号にホテルの98004という郵便番号を入力して検索すると、

image

ベルビュースクエアの東南ブロックにいくつかありますね。高速の近くは not public lockerなので住民専用とかでしょうか。

希望するロッカーの場所の[Select]ボタンをクリックすれば送付先リストに、そこのAmazon Lockerが指定できるようになります。

日曜日も受け取れる「Amazon Locker ? Bery!」か「Amazon Locker ? Frannie」が良さそうですね。

ここで注意することは、Amazon.comでの配達は基本的にbusiness dayつまりは平日のみとなっています。

ですので、日曜日に現地着だから日曜日に受け取ろうと思うと金曜日着になるように早め早めに行動するのがいいでしょう。

もしくは、Amazon Primeのお試しに入って、月曜日の朝の9時までに申し込みをしてSame Dayかone business dayで配達してもらうのもいいかもですね。

 

それでは実際にAmazon Lockerから品物を受け取りましょう。

Amazon.comで購入してAmazon Lockerに荷物がはいると取り出しようのパスコードが書かれたメールが来ます。

画像に含まれている可能性があるもの:テキスト

宿泊場所からはだいたい10分くらい歩いたところにAmazon Lockerはありました。

空港に戻るときに乗るバスターミナルのちょっと先ですね。

画像に含まれている可能性があるもの:空、夜、木、屋外

expediaビルの地下駐車場に設置されていまいた。

写真の説明はありません。

写真の説明はありません。

ロッカーの液晶画面のところでメールに書かれたコードを入力するとロッカーのドアが開きます。

画像に含まれている可能性があるもの:テキスト

無事、ゲットできました。簡単ですね。

写真の説明はありません。

今回購入したのはWear OS by Googleな腕時計です。

写真の説明はありません。

技適も通ってますし、日本語化もされているので良い感じです。

写真の説明はありません。