混沌雑記帳






時計Widgetを更に更新。
スクリーンON/OFFに連動した更新ON/OFFを再実装した。

一度はずした理由は
・スクリーンOFFの状態(Widget更新OFF)でサービスが死ぬと復活が難しい
・AlarmMagaer.RTCなら端末スリープでは実行されないので問題ない
といったところ。

ただまあ、電池消費を考えると
・サービスを殺してしまうような使い方は考慮する必要なし
・メモリ圧迫などでサービスを止めざるを得ないときは仕方ない
という考え方でもいいかと。
RTCの場合、確かにスリープならOKなんだが
スクリーンOFFだけど無線LANなどを維持してると動いてるっぽい気も。

スクリーン検知は時刻読み上げでも使用してる。
時刻読み上げの都合上毎0分はスクリーンOFFでも起動したい。
ので0分だけRTC_WAKEUPにしておけばそこでサービスが復活する。

これで夜間など放置時の消費は最小限になるはず。
あとはONだけどWidgetが見えていないときの対応かなぁ。
アクティブなアプリがHOMEなら、とかやればいいのかな?
モバイル | Comments:0
(2011/12/02(Fri) 17:45:43)

Androidの実装って現場から考えたら抜けが良くあるのは珍しくないんだが、その一例。
センサー関連が標準APIで充実してていいなぁ、と思うとそこに罠がある。

センサーの扱い方は以下の通り。
1.SensorManagerを取得
2.SensorManagerから目的のSensorがあるか取得
3.SensorManagerに目的のSensorのListenerを登録
4.Sensorの値に変化があるとListenerが呼び出される
5.必要なくなったらSensorManagerから登録を解除

ちょっと見にはポーリングとかしなくていいなと思う。
いや実際、これでも実動作次第では問題ないともいえなくは無いんだが…。
問題になるのは4の"変化があると"という点。
センサーを起動してから変化があるまでは状態がわからないという問題がある。
別に取得関数もあれば問題ないけど照度センサーとかはそんなものないし。
というか単に、登録されたら即現状の値を通知するという動作をしてくれればで問題ないんだ。
(登録した側は数値を知らないんだから、当然"不定→何らかの値"に変化となる)

この挙動がTAB固有なのかAndroid全体なのか判らないが
そういうケースに回避できるルートが用意されて無い時点でちょっと検討足りてないんだろうなと。
MediaPlayerの不足とかWidgetProviderの不足とか見るにつけ誰もそこで疑問に思わないのかと。
まあ仕事でやってるわけでもない言語の壁の外の趣味プログラマじゃこんなところで愚痴るしかないんだがw
モバイル | Comments:0
(2011/12/02(Fri) 09:07:17)

201201のログ 201111のログ

Copyright © 混沌雑記帳. All Rights Reserved. [PHPウェブログシステム3 FLEUGELzネットマニア + 独自改造]