収録問題 70問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
新しい業務モバイルアプリの設計を始める際、最初に明確にすべきものはどれですか？
答え： 対象ユーザーと主要タスク、オフラインと安全要件
移動中、片手操作、通信断、バッテリー、端末共有などモバイル固有のコンテキストを含めてユースケースを定義すると、アーキテクチャ、データ、権限、UIの判断根拠ができます。
UIがネットワークAPIとローカルDBを直接呼び分けて複雑化した。適切な改善はどれですか？
答え： リポジトリをデータ層の入口にして集約する
リポジトリはネットワーク、キャッシュ、DB等の差を隠し、データ変更と競合解決を一箇所へ集約します。UIは表示状態とユーザーイベントに集中できます。
同じ画面状態を複数コンポーネントが独立更新して表示不整合が起きる。適切な設計はどれですか？
答え： 単一の正本と単方向データフローで分離する
状態はオーナーからUIへ流し、ユーザーイベントはオーナーへ戻して一箇所で更新します。状態遷移が追跡しやすくなり、再現可能なテストを作れます。
OSがバックグラウンド中のアプリプロセスを終了しても入力途中の下書きを失わない設計はどれですか？
答え： 下書きをローカルへ段階保存し再起動時に復元する
UIライフサイクルやプロセス寿命より長く残すべきデータは永続化します。保存頻度、暗号化、破棄条件、スキーママイグレーションも設計します。
画面回転やウィンドウサイズ変更でネットワークリクエストが重複する。適切な状態管理はどれですか？
答え： UI再生成より長寿命の状態ホルダーで要求を共有する
設定変更でUIは再生成され得ます。取得処理とUIインスタンスを分離し、ライフサイクル対応な購読とリクエスト重複排除を行います。
ナビゲーションスタックと戻る操作の設計として適切なのはどれですか？
答え： 宛先・モーダル・ディープリンクごとの戻る挙動を定義する
利用者が予測できる階層とタスク境界を設計します。ディープリンクから入った場合の親、未保存変更、認証復帰も含めてテストします。
スマートフォン、折りたたみ端末、タブレットへ対応するレイアウト設計はどれですか？
答え： サイズクラスと姿勢に応じてペイン構成を適応させる
デバイス名ではなく利用可能領域を基準に、リスト・詳細、ナビゲーションレール、2ペイン等を選びます。ウィンドウリサイズ中も状態とタスクを維持します。
Android/iOS共通ビジネスロジックとプラットフォームAPIの境界設計として適切なのはどれですか？
答え： ドメイン側のインタフェースをプラットフォームアダプターで実装する
依存方向をドメインからプラットフォーム詳細へ向けないことで、テストと置換を容易にします。ただしプラットフォーム固有UXまで無理に共通化せず、適切な差を残します。
オフラインファーストのアプリで、画面が読むデータの正本（Source of Truth）として適切なのはどれですか？
答え： 同期されたローカルデータベースを読み、通信結果も先にそこへ書く
ローカルソースを観測可能な正とすると、通信状態にかかわらず一貫したデータを表示できます。リポジトリがネットワーク同期と競合解決を担当します。
オフライン中に作成したコメントを後で確実に送信する設計はどれですか？
答え： ローカルの送信箱に永続化しバックグラウンドで再送する
プロセスの強制終了後も残るアウトボックスに操作ID、ペイロード、リトライ状態を保存します。ネットワーク条件と指数バックオフを使い、ユーザーへ保留/失敗を明示します。
複数端末がオフライン中に同じレコードを編集した。適切な同期設計はどれですか？
答え： バージョン情報で競合を検出し、マージか利用者解決を選ぶ
後勝ちが適切かはデータの意味次第です。サーバーバージョン、フィールド単位マージ、CRDT、ユーザー選択などを業務影響に応じて使い分けます。
モバイルネットワークのタイムアウト後に購入APIをリトライする際、重複購入を防ぐ中核設計はどれですか？
答え： 同じ購入意図に冪等性キーを付けサーバーで結果を再利用する
タイムアウトではサーバー処理済みか不明です。同じ操作IDで再送し、サーバー側で一度だけ副作用を適用して確定状態を返します。
無限スクロールフィードのデータ取得設計として適切なのはどれですか？
答え： カーソルページネーションとローカルキャッシュで重複を排除する
カーソルと安定IDで更新中のフィードでも重複・欠落を抑えます。キャッシュ済みアイテムを先に見せ、初期、リフレッシュ、追記のエラーを別々に扱います。
ネットワークAPIのリトライポリシーとして適切なのはどれですか？
答え： 一時エラーだけを上限付きバックオフとジッターで再試行する
リトライ可能なタイムアウト、接続断、一部5xxと、修正が必要なクライアント/Authエラーを分けます。リトライ予算とジッターでバッテリー消費とサンダリングハードを抑えます。
ユーザーが検索画面を閉じた後も古いレスポンスが戻り、新画面を上書きした。適切な対策はどれですか？
答え： 古いタスクをキャンセルし、リクエストIDで最新結果だけ適用する
非同期レスポンスは順不同です。構造化並行性、キャンセル、シーケンスIDでオーナーのライフサイクルと結果適用条件を明確にします。
アプリが閉じられても後で実行すべき非緊急同期処理の設計はどれですか？
答え： OSのバックグラウンドスケジューラへ制約と期限付きで委ねる
モバイルOSはバックグラウンド実行を制限します。WorkManagerやBackgroundTasks等へバッテリー、ネットワーク、充電条件を渡し、タスクを冪等かつ中断再開可能にします。
スクロール中にUIが停止しANRやハングが増えた。最初の設計改善はどれですか？
答え： 通信・ディスク・重いデコードをメインスレッドから外す
UIスレッドは入力と描画を処理します。トレースで長いタスク、ロック、I/O、過剰レイアウトを特定し、非同期化、分割、事前計算、キャッシュを選びます。
写真一覧でメモリ不足クラッシュが発生する。適切な画像設計はどれですか？
答え： 表示サイズへダウンサンプルし上限付きキャッシュを使う
画像のデコード後メモリは圧縮ファイルサイズより大きくなります。サムネイル、適切なPixelサイズ、再利用、プリフェッチ範囲制御でピークメモリを抑えます。
コールドスタートが遅いアプリの改善方針はどれですか？
答え： 初期表示までの時間を計測し必須処理以外を遅延化する
起動トレースでメインスレッドの初期化、DI、DBオープン、SDKを分解します。最初の有用画面を早く出し、非必須処理を遅延・並列・バックグラウンド化します。
バッテリーとモバイルデータ消費を抑える同期設計はどれですか？
答え： 更新をバッチ化し差分同期で無線の起動回数を減らす
頻繁なウェイクアップ、GPS、フルダウンロードはバッテリーとデータを消費します。鮮度要件を定義し、プッシュを同期トリガーとして使う場合も実データは必要時に取得します。
ログイン用リフレッシュトークンを端末に保存する設計として最も適切なのはどれですか？
答え： キーチェーンやキーストアなどOSの保護領域に保存する
トークンはOSのセキュアストレージへ保存し、端末アンロック後のみなど用途に合うアクセスポリシーを選びます。ログ、バックアップ、クリップボード、スクリーンショットへ流出させず、ログアウトや失効時に削除します。
ルート化検知を導入した送金アプリで、サーバー側認可をどう設計すべきですか？
答え： 端末シグナルはリスク材料とし、サーバーが毎回認可する
クライアントは改変可能で、ルート／ジェイルブレイク検知も回避され得ます。重要操作の最終判断はサーバーで行い、完全性シグナルは追加認証、制限、監視などリスクベース制御に使います。
証明書ピン留めを採用する場合の運用設計として適切なのはどれですか？
答え： バックアップピンと鍵ローテーション、緊急解除を計画する
ピン留めは証明書更新失敗で全クライアントを接続不能にするリスクがあります。脅威モデル上必要な場合だけ採用し、通常のTLS検証に加えて複数ピン留め、ローテーション重複期間、監視、復旧手段を準備します。
機密性の高いオフラインデータを端末DBに保存する場合、最も適切な設計はどれですか？
答え： 保存項目と期間を最小化し、鍵分離とバックアップ制御を行う
保存時暗号化だけでは、復号後の表示、ログ、バックアップ、キー流出を防げません。データ分類に基づき保存量を減らし、鍵管理、アクセス、保持、削除を一体で設計します。
カメラ権限を要求する最も適切なタイミングとフォールバックはどれですか？
答え： 撮影を選んだ時点で目的を示し最小限だけ要求する
Just-in-timeリクエストは利用目的を理解しやすく、不要なアクセスを減らします。権限は拒否・取消される前提で状態を再確認し、機能単位でグレースフルデグラデーションを設計します。
第三者の分析SDKを追加する前に行うプライバシー設計として最も重要なのはどれですか？
答え： 収集データと送信先を棚卸しし、ストア開示と一致させる
SDKはアプリのデータサプライチェーンです。実際のネットワーク挙動、設定、同意前送信、推移的SDKを検証し、不要データを無効化して開示と継続的に同期させます。
注文取消画面をUniversal Links／App Linksで開く場合の安全な設計はどれですか？
答え： ドメイン検証とルート許可リストに加え、ログインと注文の認可を行う
ディープリンクは外部入力です。ドメイン関連付けは入口の所有確認であり、業務認可の代替ではありません。ナビゲーションと副作用を分離し、再認証や確認を重要度に応じて加えます。
外部コンテンツを表示するWebViewの設計として最も適切なのはどれですか？
答え： システムブラウザを優先し、WebViewは表示ドメインと機能を制限する
Webコンテンツとネイティブ権限を接続すると攻撃対象領域が大きくなります。オリジンを区別し、ナビゲーションポリシー、Cookie／トークン分離、ダウンロード、TLSエラー、ポップアップの扱いまで明示します。
プッシュ通知から注文詳細を更新する設計として適切なのはどれですか？
答え： ペイロードは更新のヒントとし、認証済みAPIから最新状態を取得する
プッシュは遅延、欠落、重複、順序逆転があり、ロック画面にも表示されます。機密データを載せず、バージョン／イベントIDで重複を除き、サーバーの認可済み状態へ収束させます。
生体認証を使うモバイルアプリのセッション設計として適切なのはどれですか？
答え： 短命トークンを使い、生体認証は端末内認証情報の解錠に限定する
生体認証は通常、端末内のユーザー在席を確認してキーや認証情報を開く仕組みです。サーバーセッションの発行・期限・失効・デバイス紛失対応とは分け、重要操作には新しい認証を要求します。
画面をアクセシビリティ対応する設計として最も適切なのはどれですか？
答え： ラベル・フォーカス順・タッチ領域を整えスクリーンリーダーで試験する
アクセシビリティは後付けラベルだけでなく、情報構造、操作順、状態通知、拡大時レイアウトを含む設計品質です。実際の支援技術と複数設定で主要フローを検証します。
多言語・RTL対応を後から破綻させない設計はどれですか？
答え： リソース化した文と複数形を使い、擬似ロケールとRTLで検証する
語順、複数形、日付、数字、方向、文字幅はロケールごとに異なります。翻訳可能な意味単位をリソース化し、Start／Endレイアウトとコンテンツ拡張を早期に自動・目視確認します。
オフライン対応の一覧画面で必要なUI状態設計はどれですか？
答え： 読み込み・空・古い・オフライン・部分エラーの状態を区別して示す
モバイルでは接続性変化と部分失敗が通常状態です。データ有無、鮮度、更新中、操作結果を独立して表現すると、利用可能な情報を残しつつ次のアクションを明確にできます。
本番アプリの可観測性設計として適切なのはどれですか？
答え： リリース・OS・端末別にクラッシュと起動を秘匿化して観測する
モバイル不具合はリリース、端末、OS、ネットワーク条件に偏ります。診断可能な次元と相関IDを持たせつつ、データ最小化、秘匿化、アクセス制御、保持をテレメトリ設計に組み込みます。
リリース後のネイティブクラッシュを解析可能にするビルド運用はどれですか？
答え： ビルドごとのシンボルを保存しリリースIDでクラッシュに対応付ける
最適化・難読化されたスタックは、そのビルド固有のシンボル成果物なしでは復元できません。CIで成果物とバージョンを一意に紐付け、アップロード成功をリリースゲートで検証します。
リスクの高い新機能をモバイルアプリへ展開する最適な方法はどれですか？
答え： サーバー制御の安全側フラグで段階展開しキルスイッチを持つ
モバイルリリースは配布・審査・利用者更新に時間差があります。バイナリを戻さず停止できる制御を用意し、古い設定やオフライン時も安全側になるデフォルトと互換性を設計します。
端末DBのスキーママイグレーションを安全にリリースする方法はどれですか？
答え： サポート中の全旧バージョンからの移行経路を実データ相当で試験する
利用者は複数バージョンを飛び越えて更新します。マイグレーショングラフ、大規模DB所要時間、ディスク不足、途中終了を試験し、サーバーAPIや同期データも旧新クライアントが共存できる形にします。
リリース署名と依存関係サプライチェーンの運用として適切なのはどれですか？
答え： 署名鍵を保護されたCIで最小権限運用し依存関係を検証する
リリースキーはアプリ更新権限そのものです。人手配布せず、承認、監査、ローテーション／復旧を整えます。依存関係も再現可能に固定し、由来と脆弱性をリリース単位で追跡します。
モバイルアプリのリリース前テスト戦略として最も適切なのはどれですか？
答え： ドメイン・同期・UIを自動化し代表端末と回線条件で補う
モバイル品質はロジックだけでなくOSライフサイクル、ハードウェア、権限、ネットワーク、アップグレードに依存します。リスク別のテストピラミッドとデバイスマトリクスを持ち、すべての組合せではなく利用分布とクリティカルフローで優先します。
段階リリース直後に特定OSでクラッシュ率が急増しました。最初の対応として適切なのはどれですか？
答え： 展開を停止しフラグで無効化して証跡を保全してから判断する
最初に影響範囲を抑え、診断証跡を失わずに影響を分類します。復旧後はタイムライン、検出ギャップ、テスト不足、ガードレールを振り返り、再発防止をオーナーと期限付きで追跡します。
利用者が端末を紛失しました。モバイルアプリのログインセッションを失効させる設計として適切なのはどれですか？
答え： 端末ごとのセッションをサーバーで管理し紛失端末だけ失効する
端末ごとのセッションID、発行時刻、最終利用、デバイス表示をサーバーで管理すると、利用者が対象端末だけを解除できます。パスワード変更やリスク検知時の全セッション失効も別途用意します。
パスキー認証をモバイルアプリへ追加します。サーバー側で最も重要な検証はどれですか？
答え： チャレンジ・オリジン・署名・ユーザー検証と認証情報の紐付けを検証する
パスキーは公開鍵認証情報です。サーバーはチャレンジリプレイを防ぎ、RP境界と署名を検証して認証情報をアカウントへ安全に関連付けます。復旧と複数端末登録も設計します。
App AttestやPlay Integrityの判定が成功したリクエストなら、ユーザー認可を省略してよいですか？
答え： サーバーでノンスを検証しリスクシグナルとして認可と組み合わせる
構成証明は正規アプリ・端末環境らしさを示すシグナルであり、ユーザーの業務権限そのものではありません。リプレイ対策、サーバー検証、段階的なリスク対応とフォールバックを設計します。
機密性の高いローカルDBが端末バックアップや機種変更で別端末へ復元されるリスクを抑えたい。適切なのはどれですか？
答え： 機密データをバックアップ対象外にし端末バインド鍵で復旧する
バックアップポリシーは暗号化と別に設計します。復元後にキーが利用不能となる前提で、キャッシュ再生成、セッション再確立、利用者データの復旧範囲をテストします。
残高や個人情報の画面がアプリ切替プレビューや画面共有へ映るリスクがあります。適切な対策はどれですか？
答え： 機密画面でOSのキャプチャ保護とスナップショット用マスクを使う
プラットフォームのセキュアウィンドウ、画面キャプチャ状態、シーンバックグラウンド時のマスク等を使います。ただし外部カメラ等は防げないため、表示最小化や再認証も組み合わせます。
ワンタイムコードをクリップボードへコピーする機能を実装します。プライバシーリスクを抑える設計はどれですか？
答え： 最小限の値だけを利用者操作でコピーし機密扱いと期限を設定する
クリップボードは他アプリ・同期機能・履歴へ露出し得る共有面です。コピー範囲を狭め、短命コードにし、直接入力や自動入力などクリップボード不要の経路も優先します。
プッシュ通知が端末交換後に届かず、古い端末へ送信し続けています。トークン管理として適切なのはどれですか？
答え： トークン変更をサーバーへupsertし無効応答で削除する
プッシュトークンはローテーション・再インストール・環境変更で変わります。ユーザー、アプリ環境、デバイスセッションとの対応、ログアウト時解除、プロバイダーフィードバックをライフサイクルとして管理します。
バックグラウンドタスクを毎日9:00ちょうどに必ず実行する前提で業務処理を設計しました。適切な改善はどれですか？
答え： 遅延・省略される前提で冪等にし、次回起動やサーバー側で補完する
モバイルOSはバッテリー、利用状況、ネットワークによりバックグラウンド実行時刻を決めます。厳密な時刻が必要な業務はサーバーを正本とし、端末タスクは同期・表示更新として扱います。
プッシュ通知の承認ボタンを連打すると同じ注文が複数回承認されました。中核対策はどれですか？
答え： サーバーで再認可し、アクションIDを冪等性キーに一度だけ遷移させる
通知アクションは重複配信、連打、遅延実行が起こり得ます。サーバーでアクター、リソース、許可された遷移、期限、冪等性を検証します。
ログインが必要なディープリンクを開き、認証後に元の画面へ戻したい。安全な設計はどれですか？
答え： 許可済みルートだけを正規化して保存し、認証後に再認可して遷移する
遅延ディープリンクインテントはオープンリダイレクトや権限昇格の入口になります。ルート許可リスト、期限、使い捨て、ログイン後のリソース認可を適用します。
購入確定中に電話着信でアプリが中断され、復帰後に画面が処理中のままです。適切な設計はどれですか？
答え： サーバーの注文状態と冪等性キーを正本にし復帰時に照会する
モバイルアプリは呼び出し、画面ロック、プロセス終了で任意の時点に中断されます。副作用の状態はサーバーで永続に管理し、UIはライフサイクル復帰時に再同期します。
複数スレッド・プロセスがローカルDBへ書込み、UIが部分更新を読みました。適切な改善はどれですか？
答え： 書き込みをリポジトリへ集約し業務単位でトランザクション化する
ローカルDBも原子性と書き込み調停が必要です。単一の正本からスナップショットを配信し、拡張等の別プロセスがある場合は対応APIとファイル調整を使います。
低メモリ端末でバックグラウンド復帰時の終了が増えています。キャッシュと画面状態の設計として適切なのはどれですか？
答え： 再生成できるキャッシュは解放し必要な状態だけ永続化する
OSはメモリ圧迫時にバックグラウンドプロセスを終了できます。キャッシュと必須状態を分け、画像デコードサイズ、ライフサイクル解放、低RAMデバイスでの復元を計測します。
高速スクロール中、再利用セルに古い画像ダウンロード結果が表示されます。適切な対策はどれですか？
答え： 安定IDとリクエストを紐付け、再利用時にキャンセルして描画前に確認する
セル位置はスクロールや差分で別アイテムへ変わります。リクエストライフサイクルをビューライフサイクルへ結び付け、キャッシュキー、プレースホルダ、キャンセル、ID再確認を実装します。
文字サイズを最大にすると購入ボタンが画面外へ消えました。アクセシビリティ対応として適切なのはどれですか？
答え： フォント拡大を尊重しリフローと複数行を許可して最大サイズで試験する
文字拡大時も情報と操作へ到達できる必要があります。固定高さや省略を見直し、フォーカス順、タッチターゲット、横向き、スクリーンリーダーも同時に確認します。
共有拡張（Share Extension）からメインアプリへファイルを渡します。安全な境界設計はどれですか？
答え： 外部入力として検証し最小共有領域に置き本体側で再認可する
拡張は別ライフサイクル・プロセスで外部アプリ由来データを受け取ります。共有コンテナのデータ最小化、アトミック転送、期限付きクリーンアップ、パーサー防御を設計します。
第三者SDK更新後、ストア審査でプライバシー申告不整合が見つかりました。再発防止はどれですか？
答え： SDKと収集データを差分レビューし申告とリリースゲートで照合する
SDK変更はプライバシーとサプライチェーンの変更です。ロックファイル差分、署名、データフロー、同意、削除要求、マニフェスト生成レポートをCI・リリースチェックリストへ含めます。
数か月更新していない旧アプリバージョンが新API変更後に起動不能になりました。適切なAPI運用はどれですか？
答え： 利用中バージョンを把握し互換期間と非推奨化を設けて更新を促す
モバイルクライアントはWebと違い即時更新できません。最低サポートバージョン、猶予期間、契約テスト、機能ネゴシエーション、オフライン時の更新失敗を設計します。
障害機能をリモート設定で停止したいが、端末がオフラインで古い設定を保持しています。キルスイッチ設計として適切なのはどれですか？
答え： 安全側デフォルトと署名検証、TTL、最終正常値、段階配信を組み合わせる
キルスイッチとは、不具合のある機能をアプリの更新なしで停止する仕組みです。例えば送金機能に不具合が見つかり、サーバーの設定を「無効」に変更しても、オフライン端末には届かず、保存済みの「有効」という設定が残ります。そのため、危険な機能を有効にする設定には有効期限（TTL）を設け、期限切れや初回の取得失敗時には無効にするなど、安全側へ戻る動作を端末に実装します。最終正常値は一時的な取得失敗に備えて使いますが、期限切れの「有効」を無期限に使い続けてはいけません。署名検証は設定の出所・改ざんを確認するもので、新しさを保証するものではなく、段階配信は誤設定の影響を限定するための対策です。オフライン端末を遠隔から即座に停止することはできないため、送金などの重要処理はサーバー側でも停止を強制し、再接続後に送信される保留処理も実行前に確認します。すべてのオフライン機能を止めるのではなく、機能の危険度に応じて期限切れ時の動作を決めることが重要です。
利用者から画面フリーズ報告がありますがクラッシュログはありません。本番診断の中核はどれですか？
答え： ANR・ハングをコホートとパンくずでプライバシー制御付きで相関する
フリーズはプロセスクラッシュなしでも発生します。プラットフォームVitals、ウォッチドッグ、スレッドダンプ・トレース、リリースコホートを組み合わせ、PIIを秘匿化してサンプリングと保持を制御します。
ネイティブアプリでOAuthの認可コードフローを実装します。アプリ内WebViewへ認証画面を埋め込まずに安全な認証連携を行う基本構成はどれですか？
答え： 外部ブラウザとPKCEを使い、認可応答を検証する
RFC 8252では外部ユーザーエージェントを用いた認可を推奨し、公開ネイティブクライアントにはPKCEを要求します。リダイレクト先や要求と応答の対応も検証し、PKCEだけで全対策が完了したとは考えません。
OAuthクライアントの共通シークレットをアプリのバイナリへ埋め込み、サーバーで「正規アプリの証明」に使う案が出ました。適切な判断はどれですか？
答え： 秘密保持に頼らず、公開クライアントとして設計する
利用者へ配布するバイナリ内の共通秘密は抽出され得ます。サーバーで保持する秘密と区別し、PKCEなど公開クライアント向けのフローを使います。利用者や対象データの認可は別に必要です。
AndroidでWi-Fi接続を検知したので注文送信を成功扱いしましたが、実際には認証が必要な公衆Wi-FiでAPIへ届いていませんでした。必要な設計はどれですか？
答え： 接続とAPI結果を分け、実際の結果で状態を更新する
ネットワークへの接続は特定APIへの到達や注文確定を保証しません。状態通知は再送の契機などに使い、実際の要求結果で成功・失敗・結果不明を扱います。
大容量動画の自動ダウンロードを、Wi-Fiなら常に無制限に許可しています。従量課金のWi-Fi利用者への配慮として適切なのはどれですか？
答え： 課金属性と利用者設定で、自動取得を制御する
Wi-Fiでも従量課金の場合があります。Androidのネットワーク能力などから非従量制かを確認し、利用者の許可や通信節約設定を反映します。通信種別だけで費用を決めつけません。
Androidでプロフィール画像を1枚選ぶ機能を作ります。写真ライブラリ全体へのアクセスを不要にする方法はどれですか？
答え： Photo Pickerで選ばれた画像を取得する
Photo Pickerは利用者が選んだメディアだけをアプリへ共有するための仕組みです。1枚の選択のために全ライブラリ権限を要求せず、選択取消や利用可能性の違いも扱います。
Androidの周辺店舗検索で、利用者が正確な位置ではなくおおよその位置を許可しました。大まかな地域検索で要件を満たせる場合の適切な動作はどれですか？
答え： 許可された精度で検索し、地域の手入力も用意する
付与された精度に合わせて機能を提供します。おおよその位置を正確な測位として扱わず、店舗までの距離などの表示にも精度を反映します。精密な位置が不要なら追加要求を強制しません。
翻訳前のAndroidアプリで、文字列が長くなった場合の切れや、右から左のレイアウト不具合を早期に見つけたい。適切な検証はどれですか？
答え： 擬似ロケールを使い、文字拡張とRTL表示を確認する
擬似ロケールは文字拡張や双方向レイアウトの問題を翻訳前に見つける助けになります。ただし、実際の翻訳の意味や言語固有の表示を確認するテストの代わりではありません。
同じ端末起動中のダウンロード経過時間を壁時計の差で測ると、利用者の時刻変更で負の値になりました。Androidで適切な計測方法はどれですか？
答え： elapsedRealtimeの差分を使う
SystemClock.elapsedRealtimeは起動からの経過時間を返し、壁時計の変更に左右されずスリープ時間も含みます。再起動をまたぐ値の比較には使わず、保存済み処理の再開では別の扱いを設計します。
利用者Aがオフラインで投稿を作り、送信前にログアウトしてBへ切り替えました。未送信キューがBの認証情報でAの投稿を送る事故を防ぐ設計はどれですか？
答え： 所有者別にキューを管理し、切替時に停止・隔離する
未送信操作もアカウント境界を持ちます。所有者と認証主体を照合し、切替時の取消・保留・削除を明示します。処理中の要求や遅れて届く応答も、別利用者の状態へ混ぜないようにします。
オフライン同期アプリで削除済みの項目が、長期間オフラインだった端末から再び送られて復活しました。削除を同期する設計として適切なのはどれですか？
答え： 削除の版を残し、古い更新の拒否と再同期を設計する
削除も同期対象の状態として、tombstoneなどで版を追跡します。保持期限を超えた端末には全量再同期を要求するなど、削除記録の廃棄後に古い更新を受け入れない方針が必要です。