mcpField
A
android-workmanager-notifications

android-workmanager-notifications

github.com/krutikjain開発1478 回インストール31 週間前に更新
リポジトリ

android-workmanager-notifications について

android-workmanager-notifications は、Android のバックグラウンド処理と通知配信を計画・レビューするスキルです。WorkManager、フォアグラウンドサービス、アラームの選択を支援し、再試行や重複登録、権限、プラットフォーム制約を確認します。

主な機能

  1. 01処理に適した実行 API を選択
  2. 02一意な処理・再試行・キャンセルを定義
  3. 03制約条件と優先実行を確認
  4. 04通知チャンネルと権限拒否時の動作を考慮
  5. 05再起動・プロセス終了・重複登録を確認

活用シーン

  1. 01永続的なリマインダーの設計
  2. 02バックグラウンド同期処理のレビュー
  3. 03通知権限が拒否された場合の動作確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/krutikjain/android-agent-skills --skill android-workmanager-notifications

インストール後、Claude Code で/android-workmanager-notificationsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
official-links.md
patterns.md
scenarios.md
scripts/
run_examples.sh

詳細

Android WorkManager 通知

使用する場面

  • 次のような依頼でこのスキルを使用します:Android WorkManager のジョブ、Android のバックグラウンドリマインダー通知、WorkManager による確実な再試行。
  • 主な目的:WorkManager と Android の実行制限を考慮して、信頼性の高いバックグラウンド処理、リマインダー、通知配信をスケジュールします。
  • WorkManager、フォアグラウンドサービス、アラームの使い分けを示す API 選択マトリックスが必要な場合は、references/patterns.md を参照してください。
  • 一意なワーク、通知権限、リマインダー配信の確認手順については、references/scenarios.md を参照してください。
  • 対象範囲が広がる場合は、次のスキルに引き継ぎます:
  • android-permissions-activity-results
  • android-performance-observability

ワークフロー

  1. まず適切な実行 API を選択します。延期可能で確実な処理には WorkManager、ユーザーに表示され続ける処理にはフォアグラウンドサービスを使用し、正確な時刻指定とポリシー上の要件が本当に必要な場合に限って正確なアラームを使用します。
  2. 明示的な名前、入力データの契約、バックオフポリシー、キャンセル動作を定義して、処理を冪等にし、一意に識別できるようにします。
  3. 制約、優先実行の処理、再試行のセマンティクスは、ユーザーにとっての価値とプラットフォームの制限に合致する場合にのみ適用します。
  4. 通知チャネル、重要度、タップ時のアクション、実行時の権限処理、通知が拒否された場合の適切な動作を含め、通知配信を機能の契約に組み込みます。
  5. パフォーマンスや権限に特化したフォローアップ作業に引き継ぐ前に、重複スケジュール、再起動やプロセス終了、縮退状態を検証します。

ガードレール

  • バックグラウンド処理は冪等にし、キャンセルに対応させます。
  • 1 つの論理的なリマインダーや同期パイプラインを表す機能では、一意なワークまたは一意な定期ワークを使用します。
  • 優先実行の処理は希少でユーザーにとって価値のあるものとして扱い、汎用的な優先キュー用フラグとして使用しないでください。
  • ワーカーがネットワーク制約を使用する場合、最新の Android バージョンでその制約に必要な権限をアプリが宣言していることを確認します。
  • ユーザーが POST_NOTIFICATIONS を拒否した場合も通知の価値を損なわないようにします。アプリには、ユーザーが状況を回復できる明確な手段が必要です。

アンチパターン

  • ディスクやネットワークの呼び出しでメインスレッドをブロックする。
  • WorkManager に、アラーム API のような正確な時刻での実行を期待する。
  • 一意なワークポリシーを使わず、リマインダーワークを重複して再登録する。
  • 通知チャネルを作成しない、または通知権限が拒否された場合の処理を行わない。
  • フォアグラウンド処理や正確なアラームに関する重要なポリシー上の前提を、コードやドキュメントではなくコメントに隠す。

レビューの重点

  • このワークロードに WorkManager は適切な API ですか?
  • 一意なワークのポリシー、制約、再試行、キャンセルが明示されていますか?
  • 通知が拒否された場合でも、リマインダーと通知の経路は適切に機能しますか?
  • 優先実行、フォアグラウンド、正確なアラームの動作には根拠があり、ポリシーに準拠していますか?

例

期待どおりのケース
  • シナリオ:スケジュールの変更を提案する前に、バックグラウンド処理と通知の関連箇所を探します。
  • コマンド:rg -n "WorkManager|Worker|enqueueUnique|PeriodicWorkRequest|NotificationChannel|POST_NOTIFICATIONS" examples
エッジケース
  • シナリオ:プラットフォームの影響を受けやすい動作について、正確なアラーム、優先実行、ネットワーク制約付きの処理を確認します。
  • コマンド:rg -n "setExpedited|setRequiredNetworkType|AlarmManager|ForegroundInfo" examples
失敗からの復旧
  • シナリオ:WorkManager のリクエストと、権限プロンプトやパフォーマンス関連の作業を区別します。
  • コマンド:python3 scripts/eval_triggers.py --skill android-workmanager-notifications

完了チェックリスト

  • 選択した実行 API は、ワークロードのタイミングと可視性の要件に適合しています。
  • 一意なワーク、再試行、キャンセル、制約の動作が明示されています。
  • 通知チャネルと権限の動作が、機能の契約の一部として処理されています。
  • プロセス終了、再起動、重複スケジュールの動作が考慮されています。

Official References

コメント