今月に入って、VS2019を立ち上げると、VS2019はサポート外ですとのメッセージが表示されたので、そのままVS2022のリンクをたどってインストールしました。（表示、インストールがあまりにもスムーズに済んだのでスクリーンショットを撮るの忘れました）
既存のソースコードを、早速アップグレードしコンパイルができることを確認。
最近増えつつある、NuGetのDependencyやライブラリのリンクもうまくいっている。いつものことだけど、一度開発環境をアップグレードすると前のバージョンに戻れなくなるのも慣れてきました。
一応、GITでアップグレード前にバックアップはしてるけど。
開発風景は、TwitchでBGM配信しながら画面共有しているので、よろしければ覗いてみてください。
リンクはこちら nGameMusic – Twitch
手順はこちらを参考にしました。
Xamarin.Formsでカスタムレンダラーを使って、AdMobのバナー広告を表示する(iOS/Android)
nuGetでXamarin.Google.iOS.MobileAdsを追加。Google.MobileAdsネームスペースが使用可能になる。（バージョンは常にアップデートされているので注意）
サンプルでは、iOSとAndroidでNativeレンダラーをそれぞれに作って、違うコードで書くようになっている。
ポイントは、PCLの共有部分で空のContentViewの派生クラスを作って、PCLのUI上にコントロールを配置し、レンダラーをExportからオーバーライドしている点。
iOS Nativeのコードはまだ、理解不能だけれどこういうやり方は参考になる。
少々愚痴っぽいことを書いてみる。
個人的な事情で約3週間自宅を離れてマシンを起動しない状況でした。帰ってきて、マシンを起動して、設定を変えたか何かの理由でマシンを再起動が必要になり、スタートメニューの再起動欄にアップデートして再起動の選択肢しかない。
仕方なく、アップデートして再起動する。そしてアップデートが始まりそのまま、5分くらいアップデートがはじまる。さらにマシンが起動後、アップデートが10分くらい続く。
今のメインマインがBIOSブートということもあり、OSのディスクからの読み込みに時間がかかる。C:ドライブがSSDなのに、起動が遅い。早くUEFIに乗り換えたいが今はそんな暇はない。とにかくWindowsストアアプリをリリースして、確認することが山ほどある。
クロスプラットフォームでC#がどのくらい使えるのか、そしてダウンロード数はどのくらいなのか。
そして、VisualStudioの起動も試してみたけれど、案の定こちらもアップデートあり。インストーラーを起動してアップデートを起動するがこちらもダウンロードが遅い。OSのアップデートと、開発環境のアップデートでまた1日取られてしまう。
VisualStudioのアップデートがされてしまうと、ターゲットのOSバージョンまで新しい環境が要求される訳で、開発側とユーザー側の両方でアップデートをしないといけない。
アンドロイドでは、アプリのアップデートのためにOSすべてのアップデートを要求されるというのを聞いたことがあるけれど、Windowsもそのうちそういう状況になるのだろうか。
なにもしていないのに、時間だけが過ぎていく・・・
投稿が、日記のようになってきているが、日を追って進んでいるというで。一般的には進捗とか言うんだろうけど、そうなると仕事っぽく報告とか嫌いな感じになっていくのでそういう話はやめて書きたいことだけ書く。
C#プロジェクトのテンプレートに”Shared Project”というものがあり、どのくらいクロスプラットフォーム間でコードが共有できるか試してみました。
結局のところC#で書いたクラスをネームスペース上で使えるようになるというもの。
Desktop Appなり、UWPなり、Androidなり、iOSに依存したコードは書いた時点で、プロジェクト側がエラーを検知するようになっている。
一つのソリューション内に違うプラットフォーム用にプロジェクトを作っておいて、同じコードを使いまわすという想定なのだろう。
C#を中心にコードを書くのに、悪くない環境だ。下にあるスクリーンショットは書くプロジェクトのアイコンを示したもの。
この中でCSSharedProject1というのがShared Project。ちなみに、CPPSharedというのはWin32 C++のShared Project。それぞれ同じ言語でしか共有はできくなっている。Win32でDLLを書いて.NET側からDllImportなりでAPIを取り込むのとどちらがいいのかは、この時点では不明。
Win32で書かれた共有コードをC＃に共有するためにはC++CLRでも書けるので、それぞれのクロスプラットフォームではコードレベルでの共有が有効かもしれない。
この共有プロジェクトを今回、VisualStudio2017 Communityに含まれることになった、XamarinでAndoidとiOSで共有ができることが確認できた。
注意が必要なのは、XamarinでiOSプロジェクトを書くときは、ネットワーク上にXCodeとVS2017がインストールされたMacが必要になる。しかもXCodeはiOS用にライセンスが必要。幸いiOS用のライセンスはあったのでVS2017 Community for Macをインストールしてサンプルをデバッグしてみた。
Windowsマシンからデバッグをスタートさせ、デバイスにiOS Simulatorを選ぶ。
その時点ではMacにVS2017がインストールされたいなかったので、リモートデバッグができないメッセージがでる。さらにXamarinのガイドでMac側のリモートログインを有効にしないといけないとのこと。（SSHを有効にする）
さらにSSHを有効にし、VS2017をインストールしたところで、デバッグを走らせると今度はXCodeのSDKのバージョンが古い。
今日はここまでで作業終了。
なんという長い手順だ。しかし、MacにVisual Studioをインストールして、リモートデバッグとはMSFTの好むやり方だ。
最近話題になっている、IoTデバイス（ラズパイ）のデバッグも同じ形式。ラズパイにIoT版Windowsをインストールして、デスクトップのVisualStudioからコードを書いてデバッグするという方法をとっている。もともとラズパイはスタンドアローンでパソコンとして動作するものをどうしてもう一台のパソコンを使ってプログラムを書かないといけないのか。Windowsをラズパイにインストールすればそれでいいはずなのに。
コードの共有ができたところで今日はここまで。C#で一度書けば、今のところ考えられる全てのデバイスで使えるのは良いところであろう。で？Arduinoは？やらないの？
さて、さっそくUWPアプリを作ってみる。
最近のプログラミングの入り口はUIを作るところから入るのだけれど、今までのWPFとは勝手が違い、UWPの場合にはフルHD(1920×1080)用の画面をPC用に作ってから、それぞれのデバイスでも動くようにコントロールのサイズ、配置をしていくのが手順のようだ。
しかし、画面のフォーマットを横長（1920×1080）で書いて、ウィンドウズモバイルの5インチ、6インチに縦画面（1920×1080の250%表示）に最適化していくのだけれど、PC用の横長で表示しているものを同じXAMLを使ってモバイル用の小さい画面に表示できるフォーマットを考えるのに一苦労。C#の処理部分はさっと書いてしまえるのに、これに時間を取られてしまっている。
画面のサイズが違うデバイスで見る画面を一つのXAMLで書くのはちょっとやりにくい。デバイス一つ一つにXAMLを用意してほしかった。しかも画面サイズによって違う処理をするというのもできないみたいだ。
結果から言うと、画面のフォーマットが限られてくるようにしか思えない。Flyoutとか、Popupとか静的に画面に見えていない要素があると操作を覚えにくい。昔から思うけれど、ソフトウェアを起動してマニュアルを見ないと操作がわからない様なUIはクソだ。
UWPに開発者側が以降しない訳が、わかってきた。
けれど、Windows１０は死なない。ストアという市場は思ったよりも大きいが、使えるアプリが少ない。ここを狙うのは間違いではないはず。使えるアプリを作るとしよう。
エディタやメモアプリ、日々生活で使うアプリを考えて行くことにしよう。
PS.素直にデスクトップアプリを作って、UWPアプリのパッケージに添付させるデスクトップブリッジで行く方法もありそうだ。