«
»

(技術的な詳細を書くのは大変だし、セキュリティ面の心配もあるので簡略化した)

僕はPC(Linux)とスマフォ(Android)でカレンダーを共有している(Googleなどは使わず、自分のサーバで実現している)のだが、ずっと、些細だけどムカつく「アラーム重複問題」に悩まされて来た。その現象を以下に書く。

  1. カレンダーの予定の通知時刻になると、LinuxのLightningとAndroidのカレンダーアプリ(DigiCal)から、同時または順次アラームが出る(省電力機能のためか、Androidは少し遅れることが多い)。
  2. 部屋に居る場合、Lightningのアラームを先に停め、遅れて出たAndroidのを停める。
  3. これで終わりならいいのだが、1分くらいすると、Androidのアラームが再び出る。 → イラっとする。

まったく鬱陶しいこの問題を、なかなか解決出来ずに居た。

まあ、部屋に居なければ問題は起こらないし、Androidのアラームを無視して停めなければいいのだが、今は勤めていないので部屋に居ることが多いし、性格上、アラームを停めないとLEDが点滅し続ける※のを見過ごす訳にはいかないｗ

※カレンダーアプリによっては、通知時刻からある程度時間が経つとアラームやLEDが自動で(勝手に)消えるものもあるが、それだと予定に気付かずに過ごしてしまう可能性があるので、消えないものを選んで使っている。

今まで何度も試したり調べたりしたのだが、その原因が昨日ようやく分かった。一言で書けば、LightningとAndroidのカレンダーアプリ・同期プログラムの相性だ。そして、どのプログラムも他に換えることができない。Lightningは僕にしてみれば最低レベルで使えるLinuxのカレンダーアプリで、それよりまともなものを探したがない。一方、Androidのアプリも同期プログラムも他にいいものがない。それでもいろいろ試したのだが、使い勝手、機能、性能、消費電力や通信データ量などが「許せる」もので問題が解決するものはなかった。

そういう訳で、昨日は随分試行錯誤したものの、結局、「解決不能」という結論になってしまった。

以下に、昨日の調査の結果推定した問題の起こる流れと、(その流れを前提として)問題を解決するために試したことを書く。

問題の起こる流れ

  1. 予定の通知の時刻になる。
  2. Lightningがアラームを出す。
  3. 僕がアラームを停める。
  4. Lightningは、なぜか、その予定をサーバに更新する(書き込む)。: おそらく、「アラームを停めた」という状態を保存するためだろう。
  5. DigiCalがアラームを出す。
  6. 僕がアラームを停める。
  7. DigiCalとカレンダー同期プログラムは、なぜか、サーバに更新を問い合わせる。: おそらく、省電力機能のために同期間隔が設定より長くなっていて、「起きたついでに」するのだろう。
  8. カレンダー同期プログラムは、サーバにLightningが更新した予定(アラームを停めたもの)があるので、それを取得する。
  9. 更新された予定がDigiCalに伝わり、予定の通知の時刻を少し過ぎているだけなので、DigiCalは(再度)アラームを出す。: 通知の時刻を大幅に過ぎている場合は出ないはず。

試したこと

  • Lightningが更新する処理に割り込んで、更新したように見せかけて、実は(サーバ内の情報を)更新しないようにした。 → Lightningは、更新後、御丁寧にも再度その予定を取得して確認し、更新されていないことに気付くのか(パニックになるのか)、アラームを停めてもダイアログが消えない。: 失敗
  • 同じく、Lightningが更新する処理に割り込んで、サーバ内の情報を更新する時に、Lightningが使いそうな部分だけ変更する(残りは元のままにする)ようにしてみた。 → Androidのカレンダー同期プログラムは、更新内容に関わらず書き込まれただけで変更されたとみなすようで、やっぱり、DigiCalはアラームを出す。: 失敗
  • 同じく、中身を何も変更せずに更新しても、上記の理由で駄目だった。: 失敗

LightningもDigiCalとカレンダー同期プログラムも、押し付けがましい余計なお世話をしてくれるので手こずっている(しかも、そういうのを解除できる設定などない)。もっとテキトーでいいのだがｗ

他には、Lightningがサーバへの書き込み後に行なう、本当に書き込まれたかの確認の処理に割り込んで、アラーム停止後はLightningが期待するように見せ掛けるようにし※、実際にはサーバには書き込まないようにすることが考えられるが、結局、カレンダーサーバの処理の一部を作るようなもので、大変だし、いつまで動くか分からない(いずれかの要素の動作が変わったら、駄目になる可能性が高い)など馬鹿らしいので、止めた。あとは、サーバのプログラムを改造することも考えられるが、上と同様の理由で止めた。

※今朝はこの処理の準備として、Lightningとサーバ間の通信パケットを見て、Lightningはアラーム停止後にどんな処理をしている(どんな情報を取得している)のか詳しく調べようかとも思ったのだが、勝算はないし面倒なので止めた。

まあ、気にしないのが一番なんだろうな。それができれば苦労しないんだがｗ

 

(10/7 13:20 わずかに修正)

  •  2
  •  1

by れんと | 2019-10-06 17:18 | Android, Linux, 日記 | コメント / Comment

コメントを書く / Write a comment

名前 / Name    

メール / Mail 

URL