Androidのアプリ開発におけるStringの注意点

なんとなく普段Javaを書く感覚で開発してたところ、Eclipseに出ていたWarningが気になった。

以下、出力された渓谷

Provides more information about this issue.
Calling String#toLowerCase() or #toUpperCase()
 without specifying an explicit locale is a common
 source of bugs. The reason for that is that those
 methods will use the current locale on the user's
 device, and even though the code appears to work
 correctly when you are developing the app, it will fail
 in some locales. For example, in the Turkish locale,
 the uppercase replacement for i is not I.
If you want the methods to just perform ASCII
 replacement, for example to convert an enum name,
 call String#toUpperCase(Locale.US) instead. If you
 really want to use the current locale, call
 String#toUpperCase(Locale.getDefault()) instead.

詳細メッセージを表示してみた。

URL書いてあったので移動（ここ）。

たぶん、文字列を扱う際に英語以外の言語に注意しろと言っていると思う。

トルコ文字の"i"と”I"は違うんだ！って書いてあった。

他の事例はわからんけど、toUpperCaseとか文字列変換を気軽にやると痛い目に会うよということらしい。

USはたくさん使ってる人いるし、使いやすい。みたいなことが書いてあってすごく適当な仕様だとおもった。

普段使う文には大丈夫なんだろうけど、Locale.USをいつも指定すれば、平気かなぁなんて考えてる。

Warningが減ったので気分はすこしすっきり。

SSID毎の通信量を確認したいため、Androidアプリを作りました。

GL04PにOCNのSIMを指して一ヶ月くらいが経過しました。
通信量は足りていると思うのですが、本当に十分かどうかを確認したいことと、
利用の抑制のため、通信量を確認したいと思ってました。

OCNのエントリーDでは、どこを探しても現在の通信量を表示するページはありませんでした。

そこで、こんなアプリを作成してみました。
あくまで通信量の目安ですが、通信量を把握することができます。

突貫で作成したため、昨日は殆ど無いですが、一月分の合計が見れればいいかなと。

Wi-Fi通信量　監視ツール

モバイルデータ通信をOFFにしてパケット代を節約しようとしている人には通信量の確認としてはいいのではと思います。


追加：2013年１２月２２日
FileDir.comに追加されたと連絡がありました。海外のサイトなので日本にはあまり関係ないですが、掲載していただいたのでリンクを張ります。

CalendarContract を利用したイベントのタイムゾーンについて

取得したイベントのタイムゾーンが頭のなかで整理できなかったので書きだしてみる。

終日のイベントを取り出したところ、タイムゾーンはUTCだった。

日時データは 開始はイベント当日の09:00。そして、終了日時は、次の日の 09:00だった。

Andoroid のリファレンスには、書き込む際、終日のイベントはUTCで記載しなければならない。と書かれている。

If allDay is set to 1 eventTimezone must be TIMEZONE_UTC and the time must correspond to a midnight boundary.

次に、時間指定のイベントを取得。

タイムゾーンは Asia/Tokyo。イベントの日時はJSTでカレンダー記載通りに取得できている。

Googleカレンダーでは、終日は朝9時から次の日の9時までということなんだろうか。

しかし、なんで書き込みがUTCなんだろう・・・。

終日データの9:00ってどこから来るのだろうか。
カレンダーを記載するときに、終日。とした場合には、UTCで記載する。
多分この時、UTC時刻で00:00～次の日の00:00って書くんだろうな。

それで、取り出すときに、UTCで00:00だから・・・　+9で、9:00となる？
もしそうなら。。。格納するときもタイムゾーン指定でいいんじゃないかな・・とおもったり思わなかったり。

UTCから + の方にタイムゾーンがある場合、 UTCで当日の00:00を指せば、UTCと同じ日付になるけど　- のタイムゾーンだったら。。UTCで00:00ってことは前日になってしまうのでは？

それとも、UTCの00:00を書き込むのが間違いで、JSTの00:00をUTCに変換して格納するとか？
そしたらGoogleカレンダーの作りこみに問題があることに。。。
そんなわけはないだろうと思う。。

java.util.Dateの仕様の勘違いかな。（私の）
Date.getTime()はUTCの経過時刻を返却する仕組みとなっている。
Dateインスタンス生成のときは、GMTの経過時刻を渡す仕組み。
当然、気を利かせて現在のロケールに変換してくれるのだから、UTCで経過時刻を渡せば、
+9してくれるので、00:00ではなく、09:00となる。

こうやって考えると、納得。少しスッキリしたかも。


勝手に納得してても、あとで忘れるのでメモ。


■整理できたこと

• java.util.Date は UTC を基準とした日付を扱うクラス。ただし、自動でJavaVMの動作するタイムゾーンに合わせるので、JSTに変換される。
• CalendarContractで取得するイベントには次の2種類がある。
• 時間指定のイベント：格納するデータはJavaVMの動作するTimeZone。従って日本ではJSTとなる。
• 終日のイベント：格納するデータはUTCで時刻を指定する必要がある。

■今日、混乱していたこと

• 終日のイベントの日付を java.util.Date クラスに渡したところ、 +9時間 で表示された。原因はUTCの00:00時刻を渡したため、JSTに変換された。UTCを渡すつもりなら Timezoneのオフセットを考慮する必要がある(TimeZone#getRawOffset()など)。

間違っていなければいいんだけど・・・