はつねの日記

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

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な腕時計です。

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

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

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

MAVIC AIRにも使えるDJI SDKを入手しよう

SDKの入手

現在のSDKはいろいろな種類がでていますが、MAVIC AIRで使うのであればMobile SDKに注目です。

https://github.com/dji-sdk/Mobile-SDK-Android

https://github.com/dji-sdk/Mobile-SDK-iOS

SDK自体はどこにあるかといえば、Mobile-SDK-Android-master\Sample Code\gradle\wrapper\gradle-wrapper.jarがSDKになります。

Xamarin.AndroidSDKを利用する

jarファイルをXamarinから呼び出すためには、バインディングライブラリを作成してjarファイルをまるっとXamarinのクラスライブラリでラッピングしてあげる必要があります。

image

jarファイルの追加

プロジェクトが生成できたら、Jarsフォルダを右クリックして[追加]-[既存の項目]メニューを選択します。

image

ダイアログが開いたらgradle-wrapper.jarを指定して、Jarsフォルダにgradle-wrapper.jarを追加します。

jarファイルのプロパティ指定

image

jarファイルに対するビルドアクションとして「EmbeddedJar」をしてしてdllにjarファイルを埋め込むようにします。

バインディングライブラリのビルドエラー対策

この状態でバインディングライブラリをビルドしてあげてエラーなくビルドできれば、バインディングライブラリのdllが完成します。

しかしながら、ここでエラーが出ないもののほうが少なく、gradle-wrapper.jarも当然のようにビルドエラーが発生します。

ビルドエラーは3件、すべてCS0535「〇〇はインターフェイスメンバー△△△を実装しません」です。

image

解決方法はいくつかありますが、今回出ているエラーは、「AbstractCommandLineConverter」、「AbstractCommandLineConverterInvoke」、「DownLoad」なので、主要な部分ではなさそうで使わないでもアプリ作れそうですから、とりあえずはなかったことにしてしまって、後日、必要だったらまた考えることにしたいと思います。

そのためには、Metadata.xmlに次の定義を入れておきます。

<remove-node path="/api/package[@name='org.gradle.wrapper']/class[@name='Download']" />
<remove-node path="/api/package[@name='org.gradle.cli']/class[@name='AbstractCommandLineConverter']" />

 

次回に続きます。

AndrodでGoogle Playに公開するときのSDKバージョン制限について

android-developers.googleblog.com

2018年8月以降

新規登録は、ターゲットSDKとしてAPIレベル26 (Android 8.0以上) が必須となります。既存アプリについては従来通りでもまだ大丈夫です。

2018年10月以降

上記に加えて、既存アプリのアップデートもターゲットSDKとしてAPIレベル26 (Android 8.0以上) が必須となります。

 

アップデートしないときはお目こぼしのようですが、現在提供中のアプリの更新を行わないというのも考えられませんので、既存アプリの名前を変更するなど(だとしても10月までにやらないといけない)して提供をキープして、主流派APIレベル26でということになるのでしょうか。

Androidアプリの有識者の方、ぜひ、教えてください。

 

2018年8月:APIレベル26(Android 8.0以上)をターゲットにするために必要な新しいアプリ。
2018年11月:APIレベル26以上をターゲットにするために必要な既存のアプリのアップデート。