2014年4月30日水曜日

【AndEngine】onAreaTouchedが動かない

もしかして:SceneにregisterTouchAreaしていない

【AndEngine】スプライトのドラッグ

AndEngineで遊び始めている.
ツールを何種類か公開してみてゲームも作りたいと思い
当初はUnityをやろうかなと思ったのだが
クラス構造がいまいちよくわからなかったので
eclipse上でそのままAndroidプロジェクトとして使えるAndEngineに逃げてきた.

そこで,まず動作の確認として
Spriteを表示してタップ&ドラッグを実装しようとしてみた.
つまり画像を指で動かすということだな!

オブジェクト指向のナチュラルな考え方として
スプライトごとに動作をつける.
Sprite.setOn~~~
なんてのがあればこれが一番と思ったが
とくになさそう.

その代わり
Spriteが継承するShapeクラスにonAreaTouchedメソッドがある.
Sprite範囲内をタッチされていると呼ばれるメソッドだ.
Spriteを匿名クラスとして実装すればコレが使えるので

(_touchX, _touchYはクラスフィールド)
(sceneはSceneのオブジェクト)

こんなかんじにできあがった.
setTouchAreaBindingOnActionDownEnabled (true)がなければ ドラッグの速度が速いときにSpriteの範囲から外れてしまい
Spriteが追従してくれないことになる.

2014年4月6日日曜日

【Android】消費税計算機リリース

Android用アプリ"消費税計算機"をリリースしました.

消費税計算機はその名の通り,消費税を計算するためだけに開発されたアプリです.
税抜⇔8%税込
税抜⇔5%税込
8%税込⇔5%税込
の計算が相互に可能!

文字で見るより絵で見たほうが早いのでスクリーンショットを添付!
値段を入力すると自動的に消費税計算されて出てきます.
上段が税計算前で下段が税計算後です.
スクリーンショットで「税抜 → 8%込」と書いてあるところをタップすると
税計算の方法が選択できます.

また,小売店によっては小数点以下の扱いが
切り捨てなのか,四捨五入なのか,切り上げなのかまちまちなのですが…
本アプリではそれも心配ゴム用.設定で小数点以下の扱いをどうするか変更できます.

世の中の消費税計算機が四則演算機能がついてないものも多い中
このアプリでは四則演算ももちろんカバー!


実際に消費税が変更されてこのアプリの構想を思いついてから
苦節4日…
長く苦しい戦いだった…

他のアプリがあるだろうけど見てしまったら影響されてしまうので
全く調べずに作成,
たぶん独特なモノができたと思います.

消費税計算機
対応OS:Android 2.1以上
価格:無料

漸く公開できた"消費税計算機"よろしくお願いしました!

2014年4月2日水曜日

【Android】設定画面

PreferenceActivityとか
PreferenceFragmentとか
Androidには設定画面を簡単に作るための仕組みが存在する.

XMLで記述して(Javaを使わず)設定画面を作れるのだ.

だが,私はそれらを使ったことがない.
使おうとしたことは何度かあるのだが.


第一の理由として
PreferenceActivityはAPI Lv.11(Android3.0)でDeprecated
つまり使うなと.
PreferenceFragmentはAPI Lv.11未満では使えない.
今でもAPI Lv.7(Android2.1)を基準としてアプリを作っているため
PreferenceFragmentは論外なのである.
FragmentActivityやDialogFragment,FragmentPagerAdapterなどのFragment群は
android-support-v4サポートライブラリに含まれており
API Lv.4(Android1.6)以降で使用可能なのだが,
PreferenceFragmentはそこに含まれていない.
つまり使うなと.

使えないじゃん.
PreferenceActivityをDeprecatedにもかかわらず使う
というのが一般的なようだが.

Deprecatedをあっさり使用不可にされることが多々あるので
(そのための死の宣告としてのDeprecatedなのだが)
Deprecatedは使わないほうが宜しい.


第二の理由として
PreferenceActivity,PreferenceFragmentともに
PreferenceScreenというタグ(もといクラス)を使ってXML上で記述することになるのだが
XMLで書くということはJavaソース上のpublicでstaticなフィールドにアクセス出来ない.

設定を保存・呼び出しするためのキー
(例:背景色をKEY_BACKGROUNDというキーに保存し,KEY_BACKGROUNDを指定して設定を取得する)
を設定保存側のXMLと呼び出し側のソースコードとで別々に書くのは避けたい.
一文字スペルミスがあれば呼び出せなくなるし
キーを変更しようとしたらその文字列をコーディングしているところ全て書き換えないといけない.
キーは全て同一のオブジェクトを参照したいのだ.
仕様変更で設定そのものを消したい場合にもキーのオブジェクトを消せば
参照先が全てエラーになるのでそこを修正していくこともできる.

XMLで使うためのリソースファイルなのだろうが,
ストリングリソースはContext継承クラスからでないとアクセスできない.
設定はActivityやServiceからしか取得しないと言い切れる場合はそれでいいかもしれない.
規模にもよるが経験上,まずそんなことはないので
ストリングリソースをキーには使えない.

PreferenceScreenというタグ(もといクラス)と書いたとおり,
これはJavaソースコード上でも書けるのだが,
ソースコードで記述するならもうPreferenceScreenを使うメリットは薄いんじゃない.


他の理由としては使えるコンポーネントが限られていることか.


などという理由により設定画面はいつも通常のActivityで作っている.
これまではアプリごとに設定画面を作っていた.

自前でよくつかうコンポーネントをまとめて設定UIライブラリを作ったほうがいいと思う.