朝っぱらから歯医者行った。
その後、本を引っ張り出して再確認。
サンプルはGoogle Play Billing Libraryと言う事で
SDK Managerからダウンロードする。

やり取りの詳細が完全にOAuth認証思い出す訳だが、
同期と非同期メッセージの受け取り用レシーバとか
間に仲介役が入ったみたいな面倒な印象。
ただ、理解できなくは無いので、一旦進めてみる。
開発者登録とテストアカウントは別にしておかないと
後で確認作業の時に困る事だけ気に留めておく。

同日　15:40
静的メッセージで動作確認できた。
半分程動作は理解したが、大変面倒である。

後は運用サーバー側の購入時のデータ保存部分。

同日　18:36
実機落とし込み確認完了。
android.test.purchasedで確かに正常動作する。
ただ、さっきAndroid系記事で
全データ消失するハッキングがstring.xmlを使って
できるのではと出てたのがスゲー気になる。
http://gigazine.net/news/20140325-android-bug-app-delete-data/

Androidの場合、プリファレンスというxmlファイル
によるデータ保存機構があるので、初回はこれを使う。
次回以降はこのファイルを見て自動でログインする。
ログイン前にサーバー通信してユーザーを特定する。
UUIDが既存情報と違う場合はIPASSが合ってても
問い合わせ必須。

１、プリファレンスを意図的に消した。
２、他者が不正ログイン仕掛けてる。

どちらかだろうから、初回登録時にID、PASS以外に
もう一つ問い合わせ認証用の鍵を作っておいた方がいい。
つまり、最低限必要なのは４点
UUID、ID、パスワード、認証キー
こんな所か。

ログイン用のレイアウトとゲーミングスレッドは分離。
ゲーミングスレッドで処理しても意味無いし。
本格的に次は非同期通信入らななぁ。

同日　17:04
試験勉強ついでにCCENTの方にも手を出す。
ルーター本読んでたのが大活躍する。
とりあえず100ページ程読み進めて止める。
継続は力也。

同日　23:47
非同期通信一通り実装。挙動としては悪くない。

DDMSで見る限りサーバーからの送信データも
キチンと受け取れている。
後は、別に使い道は微妙だが課金構成も実装視野に
入れるべきかね。
あれメンドクサイんだよな・・・。

やってみたが、やっぱり８割だった。
そして5時間でも耐えられる用になってきた。
慣れは怖い。
そろそろ別作業した方がいいな、気分転換的にも。
・・・買い物行こう。

同日　21:48
Android進める。
制限時間秒数、パーティクル及びタッチ関連を
別スレッドで17ms処理させる様に改良。
後の問題はhttpRequestでのデータ同期処理。
端末データの同期をどうするかが曖昧なんで、
ちょっち考える。

そういや、スパム落ち着いてきたな。
一時期は１日10件ぐらい連続で来てたからな。

同日　23:00
IMEIとか端末IDとかMACアドレスとかも考えたが、
個人情報保護と管理責任の観点から、匿名性を保持して
データを作るとなると、結局結論として
UUID突合せとユーザー名及びパスワードになる。
暗号化については当然として、CSRF対策は仕様かな。
まぁ、虱潰しでも数ヶ月かかるような暗号化処理が
なされていれば問題は無いと考えていいだろう。
メンドクサイ事よ。
そもそも趣味プログラムだし、
管理側でそこまでログを取る気は無いので、
crontabで定期的にバックアップ生成するように
しておけば問題があってもユーザー毎にロールバック
できるだろうとも思う。
後はAsyncのdoInBackground処理での通信頻度。
これがネックになりそう。
アイテム使用や取得データ閲覧系統はサーバーに
情報保持してないと改竄防げないからなぁ。
結局非力なサーバーでは大きな処理は出来ない、か。

グレー企業のやる事は違う;
確定申告用の書類要求したのが今更届くとか。
この時期でまだよかったが、もう少し後に届いたら
こ　れ　は　ひ　ど　い
となる所だった。既に期間過ぎてるから
明日朝に証明書用意してチョッパヤ税務署行くしかねぇ。

同日　20:09
OpenGLぶっ続けで200ページ近く進めた。
パーティクル生成まで。

きれいなもんだ。

同日　20:43
GLSurfaceView使って、タッチ箇所に指定個数まで
パーティクル降らせる仕組み出来た。
これってRunnable使えば別スレッド化出来るんかいね。
調査が必要だがそろそろ頭が限界。