Skip to content

MS_DotNetAndSmartphone

nishi_74322014 edited this page Sep 11, 2026 · 2 revisions

.NETとスマホ

概要

下記リンク先に記載。

詳細

GUI開発

移行メモ(Xamarin はサポート終了): Xamarin
2024 年 5 月 1 日にサポートが終了した。
現在の .NET でのモバイル GUI 開発は
.NET MAUI(Xamarin.Forms の後継)が公式の手段である
ネイティブ vs クロスプラットフォーム)。

【.NET でのモバイル GUI の選択肢(現在)】
   ・.NET MAUI                … 公式。単一プロジェクト構成 ★
   ・.NET MAUI Blazor Hybrid  … UI を Blazor で書く(Web と共有)
   ・[Uno Platform](MS_UnoPlatform) … XAML。Web/デスクトップも
   ・Avalonia                 … XAML。デスクトップ中心

プッシュ通知

Android では FCM を、iOS では APNs を使用する。

  • FCM は APNs と連携可能なので、ココでは、FCM との連携手順を書く。

  • コードを見ると、APNs へのプッシュ通知の実装は難易度が高そう。

  • FCM 経由にすると APNs の複雑さも、サーバー側でブラックボックス化される。

補足(この判断は今も正しい): 「FCM 経由にすると APNs の複雑さが
ブラックボックス化される
」——この設計判断は妥当である。
なぜ APNs が難しいのかを補っておく。

【APNs(Apple Push Notification service)が難しい理由】

 ① 【証明書または認証キーの管理】★
     ・p12 証明書方式: 【年 1 回の更新が必要】。失効すると通知が止まる
     ・p8 認証キー方式(現在の推奨): 失効しない。Team ID / Key ID が要る

 ② 【環境が分かれる】
     開発(sandbox)と本番でエンドポイントが違う
     → 「開発では届くのに本番で届かない」の典型的な原因

 ③ 【HTTP/2 が必須】(旧バイナリ プロトコルは廃止済み)
     → クライアント ライブラリが HTTP/2 に対応している必要がある

 ④ エラーの扱いが独特(トークン失効の検出など)

【FCM 経由にすると】
   ・Firebase 側に APNs の認証キーを登録しておけば、
     アプリからは【FCM の API だけ】を叩けばよい ★
   ・Android / iOS を【同じコードで】扱える
   ・トークン管理も統一される

一方、FCM 経由の代償も押さえておく。

・Google のサービスに依存する(障害・仕様変更の影響)
・中国本土の Android 端末では Google Play 開発者サービスが
  使えないことがある ★
・通知の遅延が APNs 直よりわずかに増える
・Firebase の利用規約・データの所在(データ主権)

クライアント側の手順

フロントエンドの手順は、

  • プラットフォーム毎に別々になる。

  • 詳しくは、個々のフロントエンドの項を参照。

サーバ側の手順

  • ここでは、.NET で実装する、サーバ側の実装について言及する。

  • 必要なパッケージを NuGet からインストール(FirebaseAdmin)

  • FCM のコンソールから秘密鍵
    (serviceAccountKey.json)をダウンロード

  • プッシュ通知のプログラムを実装する。

    • 秘密鍵を読む
    • メッセージの作成・指定
    • トークンの指定
    • プッシュ通知の送信

※ トークンは、ネイティブ・アプリのインストール時に生成される。
 従って、サーバは事前に、このトークンを入手しておく必要がある。

補足(実装例と、運用上の要点): 手順は正確なので、
コードと注意点を補う。

// NuGet: FirebaseAdmin
FirebaseApp.Create(new AppOptions
{
    Credential = GoogleCredential.FromFile("serviceAccountKey.json"),
});

var message = new Message
{
    Token = deviceToken,                       // ← 端末ごとのトークン
    Notification = new Notification { Title = "件名", Body = "本文" },
    Data = new Dictionary<string, string> { ["orderId"] = "12345" },
};
var id = await FirebaseMessaging.DefaultInstance.SendAsync(message);

① 秘密鍵(serviceAccountKey.json)の扱い

【これは極めて機微な情報である】
   ・持っていれば【誰にでも通知を送れる】
   ・Firebase の他の機能にもアクセスできうる

【やってはいけない】
   ・リポジトリにコミットする
   ・アプリと一緒に配布する(クライアントに置かない)

【正しい置き場】
   ・【Key Vault / Secrets Manager】★
   ・マネージド ID(Google なら Workload Identity)
   → [*.configの暗号化](MS_ConfigEncryption) /
     [FaaS config](MS_FaaSConfig) と同じ指針

② トークンの管理が実務上の主要な課題

【トークンは変わる】★ 原文の※の補足
   ・アプリの再インストール
   ・端末の初期化
   ・一定期間の未使用
   ・アプリ データの削除
     → 【古いトークンに送ると失敗する】

【設計】
   ・アプリ起動時に毎回トークンを取得し、サーバへ送る
   ・サーバは【ユーザー × 端末】でトークンを保持する
      → 1 ユーザーが複数端末を持つ
   ・送信結果が Unregistered / InvalidArgument なら
     【DB から削除する】★
      → 溜め込むと、送信のたびに無駄なエラーが積み上がる
   ・ログアウト時はトークンを無効化する
      → しないと【他人の端末に通知が届く】(情報漏洩)★

③ 通知の内容に個人情報を入れない

【ロック画面に表示される】ことを前提にする
   ✗ 「田中様の検査結果が出ました(陽性)」
   ○ 「新しいお知らせがあります」+ data で ID だけ渡し、
      アプリを開いてから API で取得する ★

④ 大量送信

・FCM には【マルチキャスト送信】がある(最大 500 トークン/回)
   SendEachForMulticastAsync
・トピック配信(購読者全員へ)も使える
・レート制限・リトライ(指数バックオフ)を実装する
・【送信は非同期のバックグラウンド処理にする】★
   → Web リクエストの中で同期送信しない

OTA アップデートをサポートするためのプラットフォーム

移行メモ(CodePush / App Center は終了): Microsoft の
Visual Studio App Center は 2025 年 3 月 31 日にサービスを終了
した。
App Center 上で提供されていた CodePush も同時に終了している
Visual Studio App Center)。

【現在の代替】
   ・React Native  → 【Expo Updates】、またはセルフホスト版 CodePush
   ・Capacitor     → Capacitor Live Updates(Ionic Appflow)
   ・.NET MAUI     → 【OTA の仕組みは標準にない】★
                      → ストア経由の更新が基本

【留意点】([ネイティブ vs クロスプラットフォーム](MS_NativeVsCrossPlatform) にも記載)
   ・OTA でアプリの主要な機能を変えることは
     ストアの規約上リスクがある
   ・バグ修正・コンテンツ更新の範囲に留める

参考

プッシュ通知

FCM

APNs

移行メモ(APNs の参考リンクは古い): 挙げられている 2 つは
2013 年頃の記事であり、
当時の「バイナリ プロバイダ API」は 2021 年に廃止されている。
現在 APNs へ直接送るなら、
HTTP/2 ベースの Provider API + p8 認証キーを使う。

// 現在の APNs 直送の骨格(HTTP/2 + JWT)
var jwt = /* p8 キーで ES256 署名した JWT(Team ID / Key ID) */;
var http = new HttpClient { DefaultRequestVersion = HttpVersion.Version20 };
var req = new HttpRequestMessage(HttpMethod.Post,
    $"https://api.push.apple.com/3/device/{deviceToken}");   // 本番
//  https://api.sandbox.push.apple.com/... ← 開発(環境の違いに注意)★
req.Headers.Add("authorization", $"bearer {jwt}");
req.Headers.Add("apns-topic", "com.example.myapp");
req.Content = JsonContent.Create(new { aps = new { alert = "本文" } });

とはいえ、原文の判断どおり
FCM 経由にする方が実装・運用とも容易
である。

開発基盤部会 Wiki

Microsoft Learn

補足(Azure Notification Hubs という選択肢): .NET 開発者向けに
補足しておく。

【Azure Notification Hubs】
   APNs / FCM / WNS 等を【まとめて抽象化する】マネージド サービス
     ・複数のプラットフォームへ 1 つの API で送れる
     ・タグによるセグメント配信
     ・大量配信のスケーリングを担う
     ・【トークンの管理を任せられる】★

【FCM 経由との比較】
   FCM 経由           … Google に寄せる。無償。実装が単純
   Notification Hubs  … Azure に寄せる。有償。大規模・多媒体向け

 → 既に Azure を使っており、大量配信が要るなら検討に値する

Tags: 移行, プログラミング, ASP.NET, ASP.NET Web API, ASP.NET SPA, JavaScript

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally