今日のトピック：.NET CoreおよびAvaloniaのTelegramのクロスプラットフォームクライアント

この記事では、クロスプラットフォームアプリケーションを.NET CoreとAvaloniaに実装する方法を説明します。 Telegramテーマは最近非常に人気があります-クライアントアプリケーションを作成することはより興味深いものになります。

この記事は、Avaloniaでのかなり基本的な開発コンセプトをカバーしています。 ただし、「Hello、World」は作成しません。 代わりに、実際のアプリケーションを検討することが提案されています。 アプリケーションの一般的なアーキテクチャと個々のコンポーネントの両方を学習します。

読者の注意を乱さないために、場合によっては、詳細を意識的に省略して、説明と実装を簡素化する必要があります。 実際のコードは、常にGitHubで表示できます 。

記事のテキストは本質的に教育的ですが、プロジェクト自体は非常に現実的です。 プロジェクトの目的は、作業ツールとして使用するように設計されたクライアントを作成することです。 多くのアイデアは他のメッセンジャーから借用され、Telegramモデルに転送されます。

このプロジェクトは開発中であり、現在、日常の使用には適していません。 特に、著者は、志を同じくする人々をこの記事の開発に引き付けることを期待しています。

はじめに

私たちのアプリケーションは、Avaloniaフレームワークに基づいています。 MVVMおよびRx.NETパターンを積極的に使用します。 XAMLは、ユーザーインターフェイスを構築するためのマークアップ言語として使用されます。 Telegram APIと通信するために、TDLibライブラリと.NET用の自動生成されたバインダーが使用されます。

リアクティブプログラミングは、開発で広く使用されます。 一般に、アプリケーションは最新のUIフレームワークで採用されているアプローチに従います。 WPFに精通している場合、Avaloniaへのアップグレードは比較的簡単です。 React.jsのようなものを知ることも、害を与えることはありません。

Avaloniaは、特定のプラットフォームに固有の開発者実装の詳細を隠しています。 プログラマは通常、トップレベルのコンポーネントを扱います。 したがって、たとえば、新しいアプリケーションを作成するには、Avalonia、Avalonia.Desktopパッケージをインストールし、Main関数に次の行を記述する必要があります。

AppBuilder .Configure(new App()) .UsePlatformDetect() .UseReactiveUI() .Start<MainWindow>(() => context);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは典型的なBuilderであり、.NET CoreおよびASP.NET Coreを扱ったすべての人によく知られています。 キーラインはUsePlatformDetectです。 Avaloniaは、プログラムが実行される環境の決定を引き受け、UIをレンダリングするためのバックエンドを構成します。 ここでのAppとMainWindowは、それぞれAvalonia.ApplicationとAvalonia.Windowから継承されたクラスであり、それらの目的は名前からほぼ明確である必要があります。後で戻ります。

VisualStudioの拡張機能を使用する場合、これらのクラスの実装を含むテンプレートが提供されます。 拡張機能を使用してプロジェクトを作成しましょう。 プロジェクトには次のファイルが含まれることがわかります。

 ./App.xaml ./App.xaml.cs ./MainWindow.xaml ./MainWindow.xaml.cs
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、これらはAppとMainWindowの同じクラスであり、前述のとおり、XAMLファイルで補足されています。 これらの各クラスには、AvaloniaXamlLoader.Load（this）という呼び出しが含まれます。 ここでは詳しく説明しません。このメソッドは、同じ名前のXAMLファイルを読み込み、それを.NETオブジェクトに変換して、引数として渡されたターゲットオブジェクトを「埋める」というだけです。

XAMLの詳細を理解する必要がある場合は、他のソースからそれらを取得できます-WPFの本ならどれでもできます。 単純なケースでは、これは必要ではありません。Avaloniaがすぐに提供するコンポーネントの使用方法を学習するだけで十分です。

同様に、Avaloniaは実装および制御（表示）します。 XAMLファイルは、階層を宣言的に記述し、アプリケーションのメモリ内の通常のオブジェクトに変換するために本質的に必要です。 このような階層の例として、フォームに埋め込まれたボタンがあります。このボタンは、ウィンドウ内に配置されています。

 <Window> <Panel> <Button> <TextBlock>Foo Bar</TextBlock> </Button> </Panel> </Window>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Avaloniaには、TextBlock、Button、Imageなどの定義済みのコントロールセットが含まれています。 より複雑な構造への構成には、グリッド、パネル、リストボックスなどのコントロールコンテナーが使用されます。 これらのすべてのコントロールは、WPFでの実装方法と同様に機能します。つまり、利用可能なドキュメントがわずかであるにもかかわらず、ほとんどの場合、WPFのマテリアルを使用することが可能です。

MVVMの実装

アプリケーションとその表示の内部状態を分離しようとします。 状態は、オブジェクトの特定の階層（ビューモデル）に保存されます。 ビューは、ビューモデルの変更に応答し、UIを再構築します。 また、ビューモデルは、ユーザーイベントまたは外部イベントという2つの要因の影響下で変更できるようになります。 ボタンをクリックすることはViewのカスタムイベントの例ですが、新しいチャットメッセージは外部イベントです。

Avaloniaでは、ビューモデルはデータコンテキストまたは単に「コンテキスト」という用語と密接にリンクしています。 すべての概念を同じ意味で使用します。

ビューモデルの階層は、多くの場合、少なくとも最初の近似ではビュー構造に似ています。 Viewを完全にAvaloniaの制御、つまり アプリケーションのロジックが状態を管理します。これらの変更に対応し、インターフェイスを再描画するのはフレームワークの責任です。

ビューモデルの最上位構造は次のようになります（擬似コード）。

 App { ... Index # int ... Auth { ... Phone # string Password # string } Main { Nav { ... Contacts # ReactiveList<Contact> } Chat { ... Messages # ReactiveList<Message> } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

親コンテキストは、子コンテキストのライフサイクルを管理します。その責任は、ネストされたコンテキストを作成および解放することです。 ルートDataContextは、MainWindowオブジェクトの作成時にBuilderに渡され（上記参照）、将来的にはビューモデル階層全体を管理します。

ビューは、バインディングメカニズムを介してネストされたコントロールのコンテキストを設定します。 実際には、これはオブジェクトのプロパティの値を設定し、その変更をサブスクライブするために必要です。

ジョブでのバインダーの使用方法に注意してください。

1. カルーセルコントロールのSelectedIndexのプロパティ（アプリケーションが表示するページを決定-承認フォームまたはチャット）
2. TextBoxのテキストプロパティ（モデルの値を電話番号とパスワード入力フォームのテキストに関連付けます）
3. すべてのネストされたコンテキスト

 <Window DataContext="{Binding App}"> <Carousel SelectedIndex="{Binding Index}"> <Panel DataContext="{Binding Auth}"> <TextBox Text="{Binding Phone, Mode=TwoWay}" /> <TextBox Text="{Binding Password, Mode=TwoWay}" /> </Panel> <Grid DataContext="{Binding Main}"> <Panel DataContext="{Binding Nav}"> <ListBox Items="{Binding Contacts}" /> </Panel> <Panel DataContext="{Binding Chat}"> <ListBox Items="{Binding Messages}" /> </Panel> </Grid> </Carousel> </Window>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、AppContextには、MainContextとAuthContextの2つの子コンテキストが含まれています。 AppContextは、ネストされたコンテキストのライフサイクルを管理します：コンテキストの初期化と解放を行います。

実際には、次のようになります。アプリケーションの起動後、AppContextはユーザーが承認されているかどうかを確認し、承認されていない場合は子AuthContextを初期化します。 アプリケーションのGUIは、AuthContextの作成に応答して、承認フォームを表示します。 ユーザーは資格情報を入力し、ログインし、承認イベント用にAppContextに署名し、AuthContextをリリースすると同時にMainContextを初期化します。 SelectedIndexは0から1に切り替わり、ログインフォームを削除してチャットを表示します。

MainContextには、さらに2つのコンテキスト、ChatContextとNavigationContextが含まれています。 ナビゲーションコンテキストは、MainContextの初期化中に作成されます。 現時点では、ユーザーが承認されていることが既にわかっているため、連絡先を読み込むことができます。

ChatContextのすべてはもう少し興味深いものです。ユーザーがナビゲーションメニューでチャットを選択すると、その作成（および以前のコンテキストのリリース）が発生します。 ChatContext自体は、メッセージの追加、編集、削除などの外部イベントにサブスクライブされます。 ディスプレイは、それぞれメッセージを描画するか削除することで応答します。 この場合、コンテキストは選択したチャットのイベントのみをサブスクライブする必要があります。 別のチャットのイベントには興味がありません。 チャットコンテキストは、新しいメッセージなどのユーザーイベントにも応答します。

ネストされたモデルには通常、親コンテキストへの参照が含まれていませんが、外部コンポーネントとやり取りしてイベントを受信したり、呼び出しを行ったりできます（例として、TDLibのラッパー）。

非同期性

ほとんどのGUIフレームワークと同様に、AvaloniaではUIストリームのユーザーインターフェイス要素のみでアクションを実行できます。 このスレッドでは、アプリケーションの応答性を維持するために最小限の作業を実行することが望ましいです。 非同期/待機により、作業を他のスレッドに委任することがはるかに簡単になりました。 RX.NETアプローチはasync / awaitと非常に似ていますが、一連のイベントを簡単に操作できるようにします。

アプリケーションはObservableを広範囲に使用して非同期性を提供します。 例を考えてみましょう-ユーザーの連絡先を読み込みます。 アプリケーションをダウンロードした後、ユーザーには連絡先のリストが表示されます。 私たちの場合、連絡先はユーザー名と彼の写真です。

ダウンロード自体は、ネットワークを介した典型的なデータ要求です。 このようなアクションは、UIストリームの外で確実に実行するのが最適です。 簡単な解決策はasync / awaitを使用することです。メインスレッドがダウンロードを開始し、終了すると通知を受信して​​連絡先を表示します。 ロード時にも、進行状況バーを表示して、バックグラウンドで何らかの作業が行われていることをユーザーに知らせることができます。

このアプローチには問題がないように思われます。 ただし、詳細に調べると、アプリケーションが連絡先リストの要求を満たしたのは時間の10％（概算）のみであり、時間の残りの90％は画像のダウンロードとデコードで占められていたことがわかります。 この間、ユーザーは待機していました。 より良いアプローチはありますか？ 最初のリクエストが完了した直後に連絡先リストを表示し、すでに「第2の波」にある画像をダウンロードしてみませんか？

原則として、このタスクはTPLを使用して解決することもできますが、Rx.NETの使用はこのようなシナリオの方が適しています。 考え方は非常に単純です。データの読み込みも別のクラスに委任しますが、今回はTaskではなくObservableを期待しています。 これにより、1つではなく一連のイベントをサブスクライブできます。最初のイベントはダウンロードされた連絡先リストであり、後続のイベントには何らかの更新（たとえば、アップロードされた写真）が含まれます。

例を使用して連絡先をロードすることを検討してください。 コンテキストタスクには、LoadContactsの実行結果のサブスクライブが含まれます。 ObserveOnメソッドの呼び出しに注意してください-これは、Rx.NETがAvaloniaスケジューラスレッドでSubscribeに渡されたコードを実行するための命令です。 この指示がないと、Contactsプロパティを変更する権利がありません。 コードはUIスレッド以外のスレッドで実行されます。

 // NavContext.cs class NavContext : ReactiveObject { private ReactiveList<Contact> _contacts; public ReactiveList<Contact> Contacts { get => _contacts; set => this.RaiseAndSetIfChanged(ref _contacts, value); } public NavContext(ContactLoader contactLoader) { contactLoader.LoadContacts() .ObserveOn(AvaloniaScheduler.Instance) .Subscribe(x => { Contacts = new ReactiveList(x.Contacts); x.Updates .ObserveOn(AvaloniaScheduler.Instance) .Subscribe(u => { u.Contact.Avatar = u.Avatar; }); }); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ContactLoaderは、ネットワーク要求の実行を担当します。 リクエストが完了すると、サブスクライバーに更新を配信する別のObservableが作成されます。 その直後に、写真が読み込まれるのを待たずに、連絡先のリストを配布する準備が整います。 更新は、ダウンロード時に配信されます。

 // ContactLoader.cs class ContactLoader { IObservable<Load> LoadContacts() { return Observable.Create(async observer => { var contacts = await GetContactsAsync(); // networking var updates = Observable.Create(async o => { foreach (var contact in contacts) { // load avatar from remote server // ... var avatar = await GetAvatarAsync(); // networking o.OnNext(new Update(avatar)); } o.OnComplete(); }); observer.OnNext(new Load(contacts, updates)); observer.OnComplete(); }) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

イベントのシーケンスを制御できます：結合、フィルター、変換など。 これは、イベントのソースとイベント自体が多数ある場合に非常に便利です。 Rx.NETを使用すると、Observableを効率的に使用できます。

簡単な例：写真をディスクにキャッシュすると、ダウンロードの速度が大幅に向上しますが、このような加速により、短時間で大量の更新が発生し、スケジューラーの作業が複雑になり、アプリケーションの応答性が失われる可能性があります。 これを回避するために、バッファリングを使用します。一度に100ミリ秒以内に発生したすべての更新を処理し、写真を含まないエントリを（何らかの理由で）フィルターで除外します。

 x.Updates .Where(u => u.Avatar != null) .Buffer(TimeSpan.FromMilliseconds(100)) .ObserveOn(AvaloniaScheduler.Instance) .Subscribe(list => { foreach (var u in list) { u.Contact.Avatar = u.Avatar; } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

1つの記事で、使用されている各テクノロジーについて詳しく説明することは不可能です。 私は最も興味深いものを選び、凝縮された形で出発しようとしました。 また、アプリケーション自体の多くのコンポーネントは影響を受けませんでしたが、すべてのコンポーネントは類似しており、同じ原則に基づいています。 さらなる研究のために、次のリンクを訪れることをお勧めします。

• プロジェクトサイト
• プロジェクトコード
• TDLib（クライアントアプリケーション用のテレグラムライブラリ）
• TDLibの.NETコアバインディング
• アバロニア
• Rx.NETの学習を開始するのに適した場所
• ReactiveUI