もう一人のY君

iPhoneアプリのレビューやアップデートレビューなどを書いています. たまに数学の記事も書きます.

もう一人のY君 MENU  MENU

【iPhoneショートカット】充電のサイクル数やバッテリー寿命チェックのレシピ2.1【iOS16】

 2.0で問題となっていたdesign_capacityの扱いについて、ある程度の解決策を講じたver2.1をリリースしました.

 その他例外処理を行うことでエラーの頻度がかなり減っています.

 

 

ショートカット

ショートカット

  • Apple
  • 仕事効率化
  • 無料

※価格は記事執筆時のものです. 現在の価格はApp Storeから確認ください.

 レビュー時のiOSバージョン : iOS16.2

 

 

スポンサーリンク

 


 

 

ダウンロードと使い方

routinehub.co

 レシピをインストールしたら編集画面に移動します.

 

 

 

 

 あとは前回と似ています.

 設定アプリから「プライバシーとセキュリティ」を開き、「解析と改善」を開きます.

 

 

 「解析データ」をタップすると色んなデータが並んでいます.

 iOS16ではサイクル数などの情報は

 

Analytics-20xx-~

 

という名前のファイルに移動したためこれを選びます.

(同じ日付のものが2つあるのはiPhoneとApple Watchのものです)

 

 「解析および改善」のページ最上部の「iPhone解析を共有」がオフになっていると対象の解析データが作成されないため利用できません.

 その場合は「iPhone解析を共有」をオンにして最低一日待つ必要があります.

 前日の解析データがその日の午前9時過ぎに追加されます.

 

 

 ページを開いたら画面右上の共有ボタンをタップし、インストールしたレシピを選択します.

 

 

 デフォルトではdesign_capacityを確定するために機種を選択することとなります.

 とはいえiPhoneやiPadすべてとなるとかなりの数となり探すのが大変のため、「デバイスの情報」アクションから取得できる機種名(Device Model)でフィルタしたものを選択肢にすることで数を減らしています.

(その結果、AppleWatchを調べる際強制的に対象のiPhoneから選ぶしかなくなります、この問題はもう少し考えます)

 

 

 選択した機種のdesign_capacityに従って計算、出力します.

 

 

 ①CycleCount:バッテリーのサイクル数です. Appleはこの数字が500を超えたとき, 本来の容量の80%を維持するよう設計している…としています.

 

 ②design_capacity:端末のもともとのバッテリー容量です.

 

 ③nomial_charge_capacity:バッテリーの名目容量で今回追加した項目です.

 

 ④raw_max_capacity:バッテリーの実質容量です. 経済や統計などのそれに従うなら, ③は「外部要因を排除して評価した値」であり, ④は「実際に計測された値(実測値)」と考えられます.

 

 

simpleモード

 配布時点では機種の選択肢が多くてやや使いづらいかもしれません.

 その場合は最初にある「辞書」アクションの「simple」キーの値を「真」にしてsimpleモードにします.

 

 

 simpleモードでは本来すべての機種から選ぶところを、上で紹介した「辞書」アクションのすぐ下にある「辞書」アクションから選ぶよう切り替わります.

 

 普通に使っている場合同一機種でもせいぜい2種類がいいとこです、そこでこの「辞書」アクションに保有している機種のみを入れておくことで機種選択が簡単になります.

 

 とくに機種の種類を一つだけにした場合は機種選択することなく計算・表示まで行うため、レシピを実行するワンタップのみで完結することが可能です.

 

 

解析データに問題がある場合

 まず一つ目に、解析データにサイクル数をはじめ必要な情報がすべて記録されていない場合があります.

 

 

 また、サイクル数は記録されていてもバッテリー容量関連の情報が欠けている場合があります.

 その場合は結果が「Null」(=情報なし)と表示されます.

 Battery Healthの上2つはバッテリー容量の情報をもとにレシピで計算する情報のため、同時に「Null」扱いとなります.

 

 

 

 実際には前回のver2.0の制作中にわかっていたことですが、上の通り解析データによってそもそも必要なデータ自体が書き込まれていない日が存在します.

 理由は不明です.

 

 その結果取り出したつもりの結果が空となり、当然JSON(辞書)からの値の取り出しに問題が生じたり、それを使った計算が成立しないため「計算式を評価できませんでした」というエラーが表示されてそこで強制的に処理が止まってしまうのです.

 

 データが無いのはもう我々にはどうしようもありません、しかし結果を出力する必要はあります.

 そのためver2.0でアクション数28個までにスッキリさせた本レシピが一気に91アクションにまで肥大化してしまいました.

 とはいえその多くは条件分岐のため、実際に処理されるアクションはこれまでと大きくは変わりません.

 

 

 いずれにしろlog-aggregated...だった頃に比べ非常に不便になってしまいました.

 design_capacityが取得できないのがそもそも苦労の種なんですが、それを解決する手段として機種名(iPhoneやiPad…でなくiPhone 8やiPad Air 3といったもっと具体的な機種名)が取得できない問題を抱えています.

 もし具体的な機種名が取得できるなら、わざわざ機種の選択を要求する必要はありません.

 しかしiPhoneやiPadといった情報では使用者のdesign_capacityを決定することは不可能です.

 結果、今回はリストとして内部に入れやむなく選択してもらい、その状況でも機種をフィルタしたり、simpleモードの導入で少しでもタップの手間を減らす工夫を施しました.

 

 

 まだAppleWatchの問題が残っていますがそこはおいおいやろうかと思います.