日記#283#284

#283 5月9日

今日はアラームマネージャーによるアラーム設定が上手くいった。
そして、そのアラームもアプリインストール後、初めて開いた後に1回だけ起動させ、2回目以降は起動しないように設定することができた。

これはアラームを起動させる条件を変更したからだ。
今までは専用ファイルを読んでtrueと書かれていなかったら、アラームを起動させて専用ファイルにtrueと書き込むようにしていた。
しかし、それでは上手くいかなかった。
そこで上手く発想を切り替えることができ、日付と歩数カウントを書き込むファイルがなければ、アラームを起動させ、ついでにその時の歩数も記録するということにした。
これでアラームを上手く起動させることができるようになった。

次に繰り返しアラームによる書き込みの内容を確認した。
そこでは特に歩数カウントが変わらないことが分かった。
理由を探ったところ、繰り返しアラームは毎回情報を送る側から起動するのではなく情報を受け取った側を起動させるからと分かった。
つまり歩数カウントは初回に送った情報のまま変わらないということだ。
これでは歩数計機能が破綻してしまうため、情報を受け取る側で毎回新しい値を取得できるようにした。
すると、アラームを設定した時間になるとアプリが強制停止してしまうようになってしまった。
色々なところにデバッグを仕掛けて探してみたところ、借りた歩数カウント機能の関数のgetInstance部分が原因のようだ。
もっと探ると、その中のUnityPlayer.currentActivityを受け取る部分が原因だった。
他で同じような記載で歩数カウントが取得できていることから書き方には問題がないことが分かっている。
改善記事も見受けられないため、推測になるがアラームの情報を受け取るonReceive関数ではcontextが引数になっており、その中身はUnityPlayer.currentAndroid。
そして、その引数を受け取ったonReceive内でさらにUnityPlayer.currentActivityを取得しようとしているからエラーが発生してしまうのでは無いかと考えた。
そして、ここからが問題で、getInstance関数をcontextを引数として設定し直すことで回避ができそうなのだが、これをするとUnity側での歩数カウントクラスの呼び出しが面倒なことになってしまうということが起きる。
つまり、歩数カウントクラスはUnityに合わせるとAndroidStudio側でエラーが起き、AndroidStudio側に合わせるとUnity側で面倒になるという厄介な状態になってしまっている。
そのため、contextを引数にした新しいgetInstance関数を作ることであまり面倒にならずにそれを回避することができるようになるのではないかと考えた。
上手くいくことを願う。

#284 5月10日

今日はエラーの原因の箇所を考えて終了。
実際には確認できなかったのでもやもやが募る。