モバイルアプリ設計 問題集・練習問題クイズ

新しい業務Mobile Appの設計を始める際、最初に明確にすべきものはどれですか？

答え： 対象User、主要Task、利用Context、Offline要件、Security・成功指標

移動中、片手操作、通信断、Battery、端末共有などMobile固有のContextを含めてUse Caseを定義すると、Architecture、Data、Permission、UIの判断根拠ができます。

UIがNetwork APIとLocal DBを直接呼び分けて複雑化した。適切な改善はどれですか？

答え： RepositoryをData Layerの入口にし、Source統合とBusiness Ruleを集約する

RepositoryはNetwork、Cache、DB等の差を隠し、Data変更と競合解決を一箇所へ集約します。UIは表示StateとUser Eventに集中できます。

同じ画面Stateを複数Componentが独立更新して表示不整合が起きる。適切な設計はどれですか？

答え： Single Source of TruthとUnidirectional Data FlowでStateとEventを分離する

StateはOwnerからUIへ流し、User EventはOwnerへ戻して一箇所で更新します。状態遷移が追跡しやすくなり、再現可能なTestを作れます。

OSがBackground中のApp Processを終了しても入力途中のDraftを失わない設計はどれですか？

答え： 重要DraftをLocal Storageへ段階保存し、再起動時に復元できるようにする

UI LifecycleやProcess Lifetimeより長く残すべきDataは永続化します。保存頻度、暗号化、破棄条件、Schema Migrationも設計します。

画面回転やWindow Size変更でNetwork Requestが重複する。適切なState管理はどれですか？

答え： UI再生成より長く生きるState Holderへ取得状態を置き、同一Requestを共有する

Configuration ChangeでUIは再生成され得ます。取得処理とUI Instanceを分離し、Lifecycle-awareな購読とRequest Deduplicationを行います。

Navigation StackとBack操作の設計として適切なのはどれですか？

答え： Top-level Destination、Modal、Deep Linkの期待Back挙動を定義して一貫させる

利用者が予測できる階層とTask境界を設計します。Deep Linkから入った場合のParent、未保存変更、Authentication復帰も含めてTestします。

Phone、Foldable、Tabletへ対応するLayout設計はどれですか？

答え： 利用可能Size Classと姿勢に応じてPane構成・情報密度・Navigationを適応させる

Device名ではなく利用可能領域を基準に、List-detail、Navigation Rail、Two-pane等を選びます。Window Resize中もStateとTaskを維持します。

Android/iOS共通Business LogicとPlatform APIの境界設計として適切なのはどれですか？

答え： Domain側にInterfaceを置き、Notification・Storage・Location等をPlatform Adapterで実装する

依存方向をDomainからPlatform詳細へ向けないことで、Testと置換を容易にします。ただしPlatform固有UXまで無理に共通化せず、適切な差を残します。

Offline-first Appで画面が読むDataのSource of Truthとして適切なのはどれですか？

答え： 同期されるLocal Databaseを読み、Network結果も先にLocalへ反映する

Local Sourceを観測可能な正とすると、通信状態にかかわらず一貫したDataを表示できます。RepositoryがNetwork同期と競合解決を担当します。

Offline中に作成したCommentを後で確実に送信する設計はどれですか？

答え： Local Outboxへ永続化し、OS管理のBackground Workで再送して状態を表示する

Process Kill後も残るOutboxにOperation ID、Payload、Retry状態を保存します。Network条件と指数Backoffを使い、UserへPending/Failedを明示します。

複数端末がOffline中に同じRecordを編集した。適切な同期設計はどれですか？

答え： Version情報と業務Ruleで競合を検出し、自動MergeまたはUser解決を選ぶ

Last-write-winsが適切かはDataの意味次第です。Server Version、Field単位Merge、CRDT、User選択などを業務影響に応じて使い分けます。

Mobile NetworkのTimeout後に購入APIをRetryする際、重複購入を防ぐ中核設計はどれですか？

答え： 同一IntentへIdempotency Keyを付け、Serverが結果を再利用する

TimeoutではServer処理済みか不明です。同じOperation IDで再送し、Server側で一度だけSide Effectを適用して確定状態を返します。

無限Scroll FeedのData取得設計として適切なのはどれですか？

答え： Cursor Pagination、Local Cache、重複排除、RefreshとAppend状態を分ける

CursorとStable IDで更新中のFeedでも重複・欠落を抑えます。Cached Itemを先に見せ、Initial、Refresh、AppendのErrorを別々に扱います。

Network APIのRetry Policyとして適切なのはどれですか？

答え： 一時Errorだけを上限付き指数Backoff・JitterでRetryし、LifecycleとCancelを尊重する

Retry可能なTimeout、接続断、一部5xxと、修正が必要なClient/Auth Errorを分けます。Retry BudgetとJitterでBattery消費とThundering Herdを抑えます。

Userが検索画面を閉じた後も古いResponseが戻り、新画面を上書きした。適切な対策はどれですか？

答え： Lifecycleや新Queryで旧TaskをCancelし、Request IDで最新結果だけ適用する

非同期Responseは順不同です。Structured Concurrency、Cancellation、Sequence IDでOwnerのLifecycleと結果適用条件を明確にします。

Appが閉じられても後で実行すべき非緊急同期処理の設計はどれですか？

答え： OSのBackground Task Schedulerへ制約・期限・再試行を指定して委ねる

Mobile OSはBackground実行を制限します。WorkManagerやBackgroundTasks等へBattery、Network、充電条件を渡し、TaskをIdempotentかつ中断再開可能にします。

Scroll中にUIが停止しANRやHangが増えた。最初の設計改善はどれですか？

答え： Main ThreadからNetwork、Disk、重いDecode・計算を外し、Frame単位で計測する

UI ThreadはInputと描画を処理します。Traceで長いTask、Lock、I/O、過剰Layoutを特定し、非同期化、分割、Precompute、Cacheを選びます。

写真一覧でMemory不足Crashが発生する。適切な画像設計はどれですか？

答え： 表示Sizeに合わせてDownsampleし、Lazy Load、Bounded Cache、Cancelを使う

画像のDecode後Memoryは圧縮File Sizeより大きくなります。Thumbnail、適切なPixel Size、Reuse、Prefetch範囲制御でPeak Memoryを抑えます。

Cold Startが遅いAppの改善方針はどれですか？

答え： Time to Initial/Full Displayを計測し、必須処理だけ残して他をLazy化する

Startup TraceでMain Threadの初期化、DI、DB Open、SDKを分解します。最初の有用画面を早く出し、非必須処理を遅延・並列・Background化します。

BatteryとMobile Data消費を抑える同期設計はどれですか？

答え： 更新をBatch化し、差分同期、Cache、適切な制約と頻度でRadio Wakeupを減らす

頻繁なWakeup、GPS、Full DownloadはBatteryとDataを消費します。Freshness要件を定義し、Pushを同期Triggerとして使う場合も実Dataは必要時に取得します。

ログイン用Refresh Tokenを端末に保存する設計として最も適切なのはどれですか？

答え： Keychain／KeystoreなどOSの保護領域を使い、利用可能条件とAccess Scopeを必要最小限にする

TokenはOSのSecure Storageへ保存し、端末Unlock後のみなど用途に合うAccess Policyを選びます。Log、Backup、Clipboard、Screenshotへ流出させず、Logoutや失効時に削除します。

Root化検知を導入した送金Appで、Server側Authorizationをどう設計すべきですか？

答え： 端末Integrity SignalはRisk判断の一材料とし、ServerがUser・Action・Objectごとに毎回Authorizationする

Clientは改変可能で、Root／Jailbreak検知も回避され得ます。重要操作の最終判断はServerで行い、Integrity Signalは追加認証、制限、監視などRisk-based Controlに使います。

Certificate Pinningを採用する場合の運用設計として適切なのはどれですか？

答え： Platform TLS検証を維持し、Backup Pin・Key Rotation・緊急解除経路をRelease計画に含める

PinningはCertificate更新失敗で全Clientを接続不能にするRiskがあります。Threat Model上必要な場合だけ採用し、通常のTLS検証に加えて複数Pin、Rotation重複期間、監視、復旧手段を準備します。

機密性の高いOffline Dataを端末DBに保存する場合、最も適切な設計はどれですか？

答え： 保存項目と期間を最小化し、必要なら暗号化と鍵分離を行い、Backup・Log・Logout時削除も設計する

At-rest暗号化だけでは、復号後の表示、Log、Backup、Key流出を防げません。Data Classificationに基づき保存量を減らし、Key Management、Access、Retention、Deletionを一体で設計します。

Camera Permissionを要求する最も適切なTimingとFallbackはどれですか？

答え： 撮影機能を選んだ時に目的を示して必要最小限を要求し、拒否・取消後も代替入力を提供する

Just-in-time Requestは利用目的を理解しやすく、不要なAccessを減らします。Permissionは拒否・取消される前提で状態を再確認し、Feature単位でGraceful Degradationを設計します。

第三者Analytics SDKを追加する前に行うPrivacy設計として最も重要なのはどれですか？

答え： 収集Data・送信先・目的・Consent・Retention・削除・SDK Versionを棚卸しし、Store Disclosureと実装を一致させる

SDKはAppのData Supply Chainです。実際のNetwork挙動、Configuration、Consent前送信、Transitive SDKを検証し、不要Dataを無効化してDisclosureと継続的に同期させます。

注文取消画面をUniversal Link／App Linkで開く場合の安全な設計はどれですか？

答え： Associated Domainを検証し、RouteをAllowlist化してParameter Validation・Login・対象注文のAuthorization・確認を行う

Deep Linkは外部入力です。Domain Associationは入口の所有確認であり、Business Authorizationの代替ではありません。Navigationと副作用を分離し、再認証や確認を重要度に応じて加えます。

外部Contentを表示するWebViewの設計として最も適切なのはどれですか？

答え： 可能ならSystem Browserを使い、WebViewが必要ならDomainを制限し、不要なJavaScript・Bridge・File Accessを無効化する

Web ContentとNative権限を接続するとAttack Surfaceが大きくなります。Originを区別し、Navigation Policy、Cookie／Token分離、Download、TLS Error、Popupの扱いまで明示します。

Push通知から注文詳細を更新する設計として適切なのはどれですか？

答え： Push Payloadを信頼せず更新のHintとして扱い、認証済みAPIから最新状態を取得して重複処理を防ぐ

Pushは遅延、欠落、重複、順序逆転があり、Lock Screenにも表示されます。機密Dataを載せず、Version／Event IDで重複を除き、ServerのAuthorized Stateへ収束させます。

生体認証を使うMobile AppのSession設計として適切なのはどれですか？

答え： 短命Access Tokenと安全なRefresh／失効を用い、生体認証は端末内Credentialの利用許可に使い、高Risk操作は再認証する

生体認証は通常、端末内のUser Presenceを確認してKeyやCredentialを開く仕組みです。Server Sessionの発行・期限・失効・Device紛失対応とは分け、重要操作にはFresh Authenticationを要求します。

画面をAccessibility対応する設計として最も適切なのはどれですか？

答え： Semantics・Label・Focus順・十分なTouch Target・Dynamic Type・Contrastを整え、Screen ReaderとSwitch操作で試験する

Accessibilityは後付けLabelだけでなく、情報構造、操作順、状態通知、拡大時Layoutを含む設計品質です。実際のAssistive Technologyと複数設定で主要Flowを検証します。

多言語・RTL対応を後から破綻させない設計はどれですか？

答え： Resource化した文とPluralを使い、Locale Format・RTL・文字伸長・Font Fallbackを擬似Localeと実機で検証する

語順、複数形、日付、数字、方向、文字幅はLocaleごとに異なります。翻訳可能な意味単位をResource化し、Start／End LayoutとContent Expansionを早期に自動・目視確認します。

Offline対応の一覧画面で必要なUI State設計はどれですか？

答え： Loading・Empty・Stale・Offline・Partial Error・Retryを区別し、既存Contentを保ちながら更新状態を示す

MobileではConnectivity変化と部分Failureが通常状態です。Data有無、鮮度、更新中、操作結果を独立して表現すると、利用可能な情報を残しつつ次のActionを明確にできます。

Production AppのObservability設計として適切なのはどれですか？

答え： Release・OS・Device・Feature Flag別にCrash、Hang、Startup、Networkを観測し、PII／SecretをRedactしてSamplingとRetentionを管理する

Mobile不具合はRelease、端末、OS、Network条件に偏ります。診断可能なDimensionとCorrelation IDを持たせつつ、Data Minimization、Redaction、Access Control、RetentionをTelemetry設計に組み込みます。

Release後のNative Crashを解析可能にするBuild運用はどれですか？

答え： BuildごとのdSYM・Mapping・Native Symbolを安全に保存してCrash Serviceへ対応付け、Release IDとBreadcrumbを付与する

最適化・難読化されたStackは、そのBuild固有のSymbol Artifactなしでは復元できません。CIでArtifactとVersionを一意に紐付け、Upload成功をRelease Gateで検証します。

Riskの高い新機能をMobile Appへ展開する最適な方法はどれですか？

答え： Server制御のDefault-safe Flag、Cohort段階展開、Guardrail Metric、Kill Switch、Cache期限とFallbackを用意する

Mobile Releaseは配布・審査・利用者更新に時間差があります。Binaryを戻さず停止できる制御を用意し、古いConfigやOffline時も安全側になるDefaultと互換性を設計します。

端末DBのSchema Migrationを安全にReleaseする方法はどれですか？

答え： Support対象の旧Versionからの経路を実Data相当で試験し、Transaction・Rollback方針・前後Version互換を設計する

利用者は複数Versionを飛び越えてUpdateします。Migration Graph、Large DB所要時間、Disk不足、途中終了を試験し、Server APIや同期Dataも旧新Clientが共存できる形にします。

Release SigningとDependency Supply Chainの運用として適切なのはどれですか？

答え： Signing Keyを保護されたCI／Key Serviceで最小権限運用し、Lockfile・SBOM・署名検証・Dependency ScanとBuild Provenanceを管理する

Release KeyはApp Update権限そのものです。人手配布せず、Approval、Audit、Rotation／Recoveryを整えます。Dependencyも再現可能に固定し、由来と脆弱性をRelease単位で追跡します。

Mobile AppのRelease前Test戦略として最も適切なのはどれですか？

答え： Domain Unit、RepositoryのOffline／同期、UI／Accessibility、API Integration、Upgradeを自動化し、代表OS・Form Factor・性能・Network条件を実機で補う

Mobile品質はLogicだけでなくOS Lifecycle、Hardware、Permission、Network、Upgradeに依存します。Risk別のTest PyramidとDevice Matrixを持ち、すべての組合せではなく利用分布とCritical Flowで優先します。

段階Release直後に特定OSでCrash率が急増しました。最初の対応として適切なのはどれですか？

答え： Rolloutを停止し、可能ならFlagで機能を無効化し、Release／OS CohortとSymbolicated Stackを保全してRollbackまたはHotfixを判断する

最初にBlast Radiusを抑え、診断Evidenceを失わずに影響を分類します。復旧後はTimeline、Detection Gap、Test不足、Guardrailを振り返り、再発防止をOwnerと期限付きで追跡します。