Skip to content

MS_MobileDevelopment

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

モバイル系開発

概要

モバイル系（と言うかフロントエンド系）
開発に関する情報リンクを纏めています。

詳細

  • 昨今、広告系のフロントエンド界隈では、
    ユーザー・エージェントと言う指標が重要視されるようです。

  • そうではない業務系では、GraphQL, Apollo GraphQL, Apollo Client
    などを導入して、開発していこうとしているケースもあるもよう。

補足（挙げられている 2 つの潮流）: 一見脈絡がないが、
どちらも「フロントエンドがどうデータを取るか」の話である。

① ユーザー エージェントについて

【広告系で重視された理由】
   ・端末・ブラウザを判別してコンテンツを出し分ける
   ・トラッキング（フィンガープリンティング）の材料になる

【現在の状況】★ 大きく変わった
   ・【User-Agent 文字列の凍結・削減】が進んでいる
      → Chrome は詳細な版番号を出さなくなった
      → プライバシー保護のため
   ・代替として【User-Agent Client Hints】
      Sec-CH-UA / Sec-CH-UA-Platform / Sec-CH-UA-Mobile
      → 【必要な情報だけをサーバが要求する】方式

【業務システムでの指針】
   ・UA での分岐は【できるだけ避ける】★
      → 端末が増えるたびに条件が増え、破綻する
   ・【機能検出】（その API があるか）で分岐する
   ・画面幅は【CSS のメディア クエリ】で扱う

② GraphQL について

【REST の課題（モバイルで顕著）】
   ・過剰取得（Over-fetching）
       1 画面に必要な項目は 3 つなのに、30 項目返ってくる
   ・過少取得（Under-fetching）
       1 画面を描くのに API を 5 回叩く必要がある ★
       → モバイル回線では往復が重い

【GraphQL の解】
   クライアントが【必要な項目だけをクエリで指定する】
     → 1 回の往復で、必要な形のデータが返る

query { order(id: 5) { id total customer { name } items { name qty } } }
【GraphQL の代償】★ 採用前に必ず検討する
   ・【任意のクエリを受ける】＝ 重いクエリを投げられうる
       → 深さ制限、複雑度制限、コスト分析が必要
   ・N+1 問題が起きやすい（DataLoader で解決）
   ・キャッシュが難しい（すべて POST /graphql になる）
       → CDN・HTTP キャッシュが効かない（[CDN](MS_CDN)）
   ・認可が【フィールド単位】で必要になることがある
   ・監視・ログが読みにくい（URL でエンドポイントを識別できない）

【現在の評価】
   ・「REST の上位互換」ではなく【トレードオフのある別方式】
   ・画面ごとに必要なデータが大きく異なる場合に効く
   ・そうでなければ【REST + BFF】でも十分なことが多い ★
      → BFF（Backend For Frontend）：
        画面に合わせた API をサーバ側で用意する

.NET での GraphQL:

・HotChocolate（最も使われている）
・GraphQL.NET
 → いずれも .NET で GraphQL サーバを立てられる

選択肢

ネイティブ（DNET_SmartphoneNative.md）

SPA（Single-page Application）

クロスプラットフォーム開発ツール（DNET_CrossPlatformDevTools.md）

比較

ネイティブ vs SPA（Single-page Application）

ネイティブ vs クロスプラットフォーム

補足（.NET 開発者から見たモバイル開発の現在地）: 選択肢の一覧に
.NET 固有の事情を補っておく。

手段 .NET との関係 現況
.NET MAUI 公式。Xamarin の後継 現行 ★
Blazor Hybrid MAUI の器に Blazor の UI Web と共有できる ★
Blazor WebAssembly + PWA ブラウザで動く（WebAssembly） インストールも可
Uno Platform XAML で多方面 サードパーティ
Avalonia XAML。デスクトップ中心 サードパーティ
SPA（React 等）+ Web API .NET は API のみ 最も一般的 ★
Xamarin 2024 年 5 月サポート終了 移行が必要 
【業務システムでの現実的な判断】

 ① まず【Web（SPA / MPA）で足りないか】を検討する ★
     → ストア審査が不要、更新が即時、端末を選ばない
     → [ネイティブ vs SPA（Single-page Application）](MS_NativeVsSPA) の
       「ストアの存在が障害になる」参照

 ② 足りない場合、何が足りないのかを特定する
     ・オフラインが必須 → PWA で足りるか検証
     ・カメラの連続利用 → ネイティブ寄りへ
     ・プッシュ通知が中核 → ネイティブ寄りへ
     ・バックグラウンド処理 → ネイティブ一択

 ③ ネイティブ寄りにする場合、
     ・C# の資産・人材を活かすなら → 【.NET MAUI / Blazor Hybrid】
     ・Web の資産・人材を活かすなら → Capacitor / React Native
     ・UI にこだわるなら → Flutter またはフル ネイティブ

参考

OSSコンソーシアム

開発基盤部会 Wiki

  • スマホ（DNET_Smartphone.md）

  • JavaScript（DNET_JavaScript.md）

  • クロスプラットフォーム開発ツール（DNET_CrossPlatformDevTools.md）

開発基盤部会 Blog

Microsoft Learn

Tags: 移行, プログラミング, .NET開発, モバイル系開発

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally