ラベル Technical の投稿を表示しています。 すべての投稿を表示
ラベル Technical の投稿を表示しています。 すべての投稿を表示

2016年5月22日日曜日

以前書いた記事の訂正

以前書いた記事で
>これまで空文字列をチェックする際

>hoge == null && hoge.equals("")
>のような評価を行っていたが

>hoge.isEmpty()
>これで上述の式と同じ評価を行えることを知った。
>これはコードがスマートになっていい

このような記述をしたのですが、完全に誤りです。失礼しました。

hoge == null の時、hoge.isEmpty()はNullPointerExceptionとなります。
(バグを出して初めて気付いた・・・)
hoge == null && hoge.equals("") を一気に行いたい場合は org.apache.commons.lang3.StringUtilsのメソッド isEmptyを利用します。

StringUtils.isEmpty(hoge);
なおorg.apache.commons.lang3パッケージのクラスの利用にあたっては、org.apache.commons.lang3ライブラリをビルドパスに追加する必要があります。

2015年10月3日土曜日

空文字列チェック

これまで空文字列をチェックする際

hoge == null && hoge.equals("")

のような評価を行っていたが

hoge.isEmpty()

これで上述の式と同じ評価を行えることを知った。
これはコードがスマートになっていい

2015年2月14日土曜日

ネットワーク経由でADB接続した際、DDMSからデバイスが確認できない時

表題の件にてハマったので覚書として記す。

コマンドプロンプトから
adb connect ~デバイスに割り当てたIPアドレス~:5555

と打ちこみ、接続を試みるも
DDMSから確認できない。

このとき
adb devices

で接続デバイスの一覧を確認してみると、一覧に接続したはずのデバイスは無かった。
つまり接続できていなかった。

adb connect ~ のコマンドは接続が成立していなくてもコマンドプロンプト上にはエラーメッセージなどは出ないようだ。
ただ、成功メッセージが出ないという点や、eclipseのコンソールではエラーメッセージが出ていたので
初見で無ければ接続失敗の確認は可能。

adb connect ~ で上手く繋がらないときは
adb kill-server
adb start server

とした後、接続を試みると上手くいった。

2014年11月23日日曜日

アプリデータ保存用フォルダ名

アプリからデータを保存するフォルダを作成する場合、
気をつけなければいけないことに気付いた。

例えば、『写真』というAndroid標準アプリは画像データを表示する際は全てのデータの一覧を表示するが、
まずデータがあるフォルダの一覧を表示するものも多い。
有名どころだとLINEは添付画像を選択する際は、まずフォルダの一覧が表示される。

当プロジェクトでは、画像データを扱うアプリを2つリリースしているが、
画像のデータは、アプリ用フォルダを作成し、その下に保存画像用フォルダを作成してそこに保存している。

このとき保存画像用フォルダ名に同じ名前を使っていたため、
前述のLINEや、その他画像を扱うアプリからデータにアクセスする際
どちらのアプリの画像フォルダなのか分かりにくく、ユーザビリィティが良くない。

アプリデータ保存用フォルダ名はユーザーが識別しやすい名前にしておくべきだ。
今後の開発ではしっかり実施していき、先にリリース済みのアプリについては改修予定

2014年11月15日土曜日

SilentCamをバージョンアップ

バージョン 2.1での変更点は下記の通り
  • 画像の日付がずれる不具合を修正
  • 英語対応
追記
画像の日付がずれる現象については、Javaの仕様によるハマりどころでもあったので内容を記すと
画像の日付変更はCalendarクラスのsetメソッドで行っていたが、
引数の指定が、年や日時は指定したい日時をそのまま指定すればよいが
月のみ0~11で指定するという仕様になっていた。
これを知らずに日付指定を行っていたがために、
画像の日付が本来の日付より1ヵ月先となってしまっていた。

また月の部分の引数に12が入った際、エラーとならず0扱い
つまりは1月になっていた。
試してはいないが%12で取って1を加えて月としている気がする。
エラーが発生しなかった事でバグの発見が遅れる結果となった。

2014年10月1日水曜日

特定端末でのカメラプレビューの歪みの問題を解消

先の記事の通り、SilentCamについて
特定端末でカメラプレビューに歪みが出ていたのを解消した。

結論から言えば、原因は2つ。
まず一つ目が、
端末画面の横幅と縦幅を取得した際
どの側面を縦横とするかが端末によって違ったという点。
これはGALAXY S IIIで起きていた歪みの原因であった。

SilentCamの検証に使ったスマホ端末8機種の内、
7機種(日本メーカー製)はスマホを持ったそのままの方向で縦横。
残り1機種、GALAXY S IIIはその逆だった。つまり短い側が縦で長いほうが横。

これはGALAXY特別のおかしさかもしれないが、他にそういう端末もあるかも知れず
また、今後タブレットにも対応させるといった時のことも考え、どちらであっても柔軟に対応できるように実装した。


二つ目が、端末のカメラプレビューの対応サイズ。
これはCamera.Parameters..getSupportedPreviewSizes()メソッドにて取得でき、
戻り値はandroid.hardware.Camera.Sizeのインスタンスのリストとなっている。
このリストでは、概ね最初の要素がディスプレイサイズとなっている場合がほとんどで
index0をプレビューサイズをするという所謂ハードコーディングをしていたが
中にはそうではない場合もあったので、
取得した要素を全て検証し最適なものを適用するという実装にした。

以上で、把握してはいたものの修正できていなかったSilentCamの不具合を解消できた。

また今回、色々な端末のデータを取得する必要があったので、
Android端末を持っている方達にご協力いただいた。 その際、こちらで各端末をPCにつないでログを取るといったことができないため
Display Detail Checlerという
前述の事項で言及したような、端末の各値をスマホ側で確認するためのアプリを作成し
これを使ってデータを収集した。

なお、需要があればと思い、Google Playにて公開している。
ディスプレイ詳細取得 D.D.Checker

2014年8月25日月曜日

Android 2.3 Gingerbread 対応について

先日リリースした TheCompassでは、このプロジェクトとしては初めてAndroid 2.3の端末を動作対象から外した。
理由は、方位針の回転の動き(リアルタイムで回転角を付ける)がAndroid 2.3の環境では容易には作り出せなかったためだ。

踏み込めば再現できそうな感じはあったものの、この開発ではそこまでしなかった。

Android 2.3までを動作対象に含める、と言うのは実のところ開発工数・テスト及びバグフィックスの工数はかなり上がり、体感的にはリリースまでに要する時間は切り捨てた場合と比べ1.5倍に近く膨らむ。


今後の方針としては、基本的に Android4.0未満は動作対象から外すつもりでいる。
もちろん使っている方のいる限り、今後もアプリによっては可能な限り Android 2.3も動作対象させるようにするが、含めることによって開発に負担やボトルネックが生じると思われる場合は、思い切って切り捨てる。


以下のグラフはGoogleが公表している、2014年8月12日までの7日間に集計されたAndroid OSのバージョン別シェアだ。

http://developer.android.com/about/dashboards/index.html#Platform
Android 2.3 Gingerbread のシェアは13.6%となっている。
当プロジェクトで先にリリースした3つアプリはAndroid 2.3も動作対象であるが、インストールされた端末の統計を見てみると実感としてはもっと低い。
Googleのデータは全世界の統計だと思うので、日本では現役で利用されているほとんどの端末が4.0以上になっているのではないかと思う。


バージョンによる癖を把握して低いバージョンでも動作可能なようにプログラミングする、というのは プログラミングを行っている立場で言えば楽しくもある。
しかしながら、限られた人的資源の中でそこに力を入れるのは無駄である。
蓄えたノウハウも、そう遠くない将来無用のものになる。

だとすれば、どんどんと提供される新しい技術に目をやり、それを取り入れた開発にその分の労力を割り当てるというのが私たちの今後の姿勢だ。

2014年6月12日木曜日

Androidアプリの画面遷移時のアニメーションについて

当プロジェクトで開発したアプリTegakiMemoは、
スタック的に見て、ユーザーが今の画面の位置を把握しやすいよう
画面遷移を、iOSアプリの画面遷移に似せて横スライド式とした。

実装にあたっては、AndroidManifestで
Activityごとに画面遷移時のアニメーションを付与した独自テーマを指定する形をとった。

しかし、最終的に解決はしたものの
端末によっては、こちらの意図した動きにはならなかった。
動きに違いが出ていた原因は、以下の2点によるものであった。

  1. Androidのバージョン違い
  2. 端末の設定


1について
Android4.0以上と Android2.3xで同じ指定にも関わらず、動きに違いが出た。
これに関しては、動きに違いが出ているActivityのJavaソースの中で
setThemeメソッドを使い、バージョンによってテーマを振り分けることで解決できた。

━━━ 2014/11/23 追記 ━━━

setThemeメソッドを使い振り分けるにはAndroid2.3x用のテーマを作成する必要があるので、
overridePendingTransition(int enterAnim, int exitAnim)
というActivity遷移時のアニメーションを指定できるメソッドがあるのでその方が楽だった。
使い方はstart()あるいはfinish()の後にメソッドを呼び出す。

━━━━━━━━━━━━━━━


2について
特定端末で、画面遷移アニメーションが 全く生じないというものがあった。
原因はトランジションアニメーションスケールという設定がオフになっていたため。

これについては、実は結構根深い。
どういうことかといえば、
2の問題を見つけるきっかけとなった端末(以下検証端末Dとする)は、新品であったためだ。
その端末は初期設定がトランジションアニメーションスケール設定が【オフ】だということになる。
たぶん一般的なユーザーはこのような設定は触らないだろう。

またAndroid4.0以上ではこの設定は開発者向けオプションの中にある

ましてやAndroid4.2(だったと思う)からは、初期状態では開発者向けオプションは表示されていない。
いよいよ一般的なユーザーは設定を変更することは無いだろう。
初期状態においてその部分が、
アプリのプログラムに特別な干渉を加えない【1x】ではなく
画面遷移時のアニメーションを無効とする【オフ】になっている端末があるということ

ちなみに検証端末DはAndroidのバージョンが4.2.2であった。

もし、検証端末Dと同じ端末を使っている方が、このアプリをダウンロードして使ってくれたとしても
苦心して実装した画面遷移の動きは、届くことはないと思われる。

全くもって開発者泣かせな事象である。