ハトネコエ Web がくしゅうちょう

プログラミングやサーバー・Web制作、チームマネジメントなど得た技術のまとめ

Xamarin の後継? .NET MAUI で Windows 用メトロノームアプリを作ってみたよ!

楽器の練習するときって、まずはゆっくりのテンポから始めて
少しずつ速くしていくってことをよくやるんですよね。

だからメトロノームのテンポを +10 や -10 する機能って
楽器の練習のことを考えたら大事なんですけど、
Windowsストアで探しても意外とないんですよね。

Windowsストアでの「metronome」での検索結果

というわけで、作りました!

1. .NET MAUI とは

Xamarin (ザマリン)という、
Windows, iOS, Android へマルチに展開できるフレームワークがあるんですが、
これが来年2024年5月でサポート終了してしまうということで、
おそらくその後継として作られているものだと思います。

.NET MAUI はシングルコードで
Windows, macOS, iOS, Android へのビルドができる、クロスプラットフォーム フレームワークです。

Xamarin と比較して macOS のサポートが増えていますが、
これは Mac Catalyst を活用して実現されているとのことなので、
iOS 向けアプリを経由して macOS アプリを生成しているようです。
macOS での開発時に、iOS Simulator を立ち上げなくても動作確認できるのがよさそうですね。

2. 開発時に苦労した点

.NET MAUI での開発でつらかったことをまとめます。

2-1. Visual Studio を使わないといけない

Visual Studio Code ならふだん使っているわけですが、
Windowsアプリを作るにはやはり、統合開発環境として Visual Studio を使わないといけません。

参考: https://learn.microsoft.com/ja-jp/dotnet/maui/get-started/installation

Visual Studio Code と比べるといろいろ気になっちゃいます。
拡張機能を有効にするにはアプリケーションの再起動が必要だったり、
改行コードをLFに統一できなかったり、
.editorconfig をコードとして開けなかったり、
デバッグ中はエディタのレイアウトが変わる&一部使えない機能が生まれるなど、小さくストレスがかかります。

まあ、iOS 開発者が Xcode への怨嗟の声を上げるのと同じ問題ですよね。
ある程度は慣れていって妥協できるようになります。

JetBrains が好きな方は Rider を使うことも視野に入れるといいかと思います。

2-2. 情報が少ない

.NET MAUI の正式リリースが2022年5月と、ちょうど1年前のため、
情報が比較的少ないです。

幸いなことに、.NET MAUI でメトロノームアプリを作ろうとしていた人が他にいたおかげで、
以下の Stack Overflow に大きく助けられましたが、
何かやりたいと思ったときに手探りになることが多いです。ロギング(ログ出力)すらわからず苦戦しました。

公式ドキュメントがわりと充実しているんだけれど、
びみょーに何言ってるかわからないことがあります。公式ドキュメントあるあるですね。

2-3. OSに依存する部分の対策で苦労する

他のWindowsストアにあるアプリだと、
DAWDTM用ソフト)を立ち上げるときに一時的にオーディオインターフェイスを専有されたあとや、
オーディオインターフェイスが切り替わったあととかでずっと音声が再生されなくなるという問題があったんですよね。

自分のアプリではこの問題をなんとかしたかったんだけれど、これのスマートな解決方法が出来ませんでした。

この問題を解決するには Windows 特有の世界に入り込む必要がありそうですが、
.NET MAUI がクロスプラットフォームフレームワークである都合上、それは難しそうでした。
音楽再生のためのパッケージ Plugin.Maui.Audio を拡張するくらいの度胸が必要そうです。

結局、再生停止ボタンを押したタイミングで AudioPlayer(Windows の世界では MediaPlayer) の Dispose をおこなったのちに
AudioPlayer を生成し直すということで問題を回避しましたが、
本当はオーディオインターフェイスの変更に関して検知して、MediaPlayer の出力先を調整するような挙動を実装できるとよかったです。

このようなOSの挙動にこだわりをもった実装をするためには、
最初から .NET MAUI での実装をおこなうのでなく、
Windows 向けのアプリケーションとして作り始める方がもしかすると簡単だったかもしれません。

ただまあ、Windows アプリを作るためには WPF, UWP, WinUI 3 (Windows App SDK) の選択があったり、
それらがどう違うかの理解に頭を悩ませただろうし、
テンプレートファイルが .NET MAUI のものほどわかりやすくないので、いっそう苦労した可能性があります。

3. .NET MAUI の優れていた点

優れていたこともいろいろありました。

3-1. テンプレートアプリがよく出来ている

テンプレートの「.NET MAUI アプリ」なのですが、これがよく出来ています。
ファイル数が必要最小限でありながらも、データバインディングアクセシビリティについて触れていて、
なにが出来るのかがわかりやすくなっています。

ファイル数が少ないため App > AppShell > MainPage の構成で作られていることがわかりやすく、
ナビゲーションバーや画像表示、複数の文字サイズ、ボタンについて理解することが出来ます。上手い作りです。

WinUI 3 などのためにある Template Studio で作られるテンプレートアプリは
ファイル数が多く複雑で、こちらを最初に触れていたら理解まで時間がかかったことでしょう……。

3-2. コード補完が適切に働く

Visual Studio を使うことの利点と言えるでしょうか。

C#XAML ファイルでの編集時のオートコンプリート(入力補完)が、
なにも拡張機能を入れない状態で適切に働いてくれます。

また、IntelliSense によるコード補完も便利です。

例えば上の画像のように、途中まで書いたところで、
黄色い四角で囲んだ部分を候補として提示してくれます。Tabキーを押すとこの内容が挿入されます。

ほどよく単純作業を軽減するお手伝いをしてくれます。

……これを書いていて、GitHub Copilot って Visual Studio で動くのかな? と思ったらしっかり拡張機能ありますね

3-3. ホットリロードのおかげもありレイアウトが組みやすい

XAMLというXMLベースのマークアップ言語でレイアウトを組んでいきます。
Android と同じような形式ですね。

Flutter のようにレイアウトがコードと一体化されているものは、
書きやすさがある一方、ロジックとテンプレートがいっしょに書かれて混沌となる場合があるので、
テンプレートファイルがはじめから分かれているものは、スッキリしていて扱いやすいです。

VerticalOptions などのコンポーネントアトリビュートに関しても
Visual Studio の入力補完が効いてくれるので、初心者でもレイアウトの設定をしていきやすくありがたかったです。

とはいえ、「なんでこの書き方で中央寄せになってくれないんじゃー!」っていうのは普通にありましたw
レイアウト書くのはいつだって難しい……。

4. 作ってみての感想

つらいところはありましたが、C# .NETWindowsアプリケーションの作成に詳しくない中、
数日でアプリを完成できるのですから、入門しやすくよく出来ているフレームワークなのだと思います。

Flutter でも Windows アプリを作れるので、そのどちらかを選ぶなら Flutter の方がいい気がしつつも、
今回のように、Windows OS の複雑な部分に触れるような実装をしたくなったときに、
途中まで書いた .NET のコードを使い回せるという点で、 .NET MAUI は優れていると思います。

それにしても、今回詰まったことでライブラリ(Plugin.Maui.Audio)のソースコードをじっくり読んで思いましたが、
インターフェースのメソッド1つごとに各プラットフォーム用の実装を書いて動作確認もしないといけないんだから、
ライブラリを作る側は大変すぎますね……。 クロスプラットフォームフレームワークのライブラリは、メンテナンスを続けるのが難しそうだあ。