なうろーでいんぐ
キーボード↑↓
でもいいぞ
旧サイト形式へ帰りたい人
デベロッパー登録
2014年03月26日15時49分
Androidの課金機能の本筋確認の為に
使い捨てクレジットのVプリカで3000円購入して
デベロッパー登録、(支払は25US$)
α版でapkを登録して、アプリ内アイテムを登録してみた。
ID使いまわしできないとの事なので適当なのを登録。

詳細の画像とかアイコン画像がまだ用意できてないので
公開までは至らなかったが課金まで詳細は掴めてきた。
課金構成の詳細は一般的な構成。
下記同様なので特には述べない。
http://www.atmarkit.co.jp/ait/articles/1104/28/news147_2.html
v3になってから大きい違いは、消費型のアイテムも
管理できるようになったってとこだろう。

アプリ側はoggファイルによる音楽とSe再生突っ込む。
特に何事も起こらず。
いよいよ素材作らなあかん時かも。
記事カテゴリ:その他
Appストアアプリ処理
2014年03月25日11時14分
朝っぱらから歯医者行った。
その後、本を引っ張り出して再確認。
サンプルはGoogle Play Billing Libraryと言う事で
SDK Managerからダウンロードする。

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

同日 15:40
静的メッセージで動作確認できた。
半分程動作は理解したが、大変面倒である。
ファイル 1030-1.png
後は運用サーバー側の購入時のデータ保存部分。

同日 18:36
実機落とし込み確認完了。
android.test.purchasedで確かに正常動作する。
ただ、さっきAndroid系記事で
全データ消失するハッキングがstring.xmlを使って
できるのではと出てたのがスゲー気になる。
http://gigazine.net/news/20140325-android-bug-app-delete-data/
記事カテゴリ:プログラム関連
ユーザー認証機構
2014年03月24日10時21分
Androidの場合、プリファレンスというxmlファイル
によるデータ保存機構があるので、初回はこれを使う。
次回以降はこのファイルを見て自動でログインする。
ログイン前にサーバー通信してユーザーを特定する。
UUIDが既存情報と違う場合はIPASSが合ってても
問い合わせ必須。

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

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

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

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

同日 23:47
非同期通信一通り実装。挙動としては悪くない。
ファイル 1029-1.png
DDMSで見る限りサーバーからの送信データも
キチンと受け取れている。
後は、別に使い道は微妙だが課金構成も実装視野に
入れるべきかね。
あれメンドクサイんだよな・・・。
記事カテゴリ:プログラム関連
一日一回試験してる
2014年03月23日16時35分
やってみたが、やっぱり8割だった。
そして5時間でも耐えられる用になってきた。
慣れは怖い。
そろそろ別作業した方がいいな、気分転換的にも。
・・・買い物行こう。

同日 21:48
Android進める。
制限時間秒数、パーティクル及びタッチ関連を
別スレッドで17ms処理させる様に改良。
後の問題はhttpRequestでのデータ同期処理。
端末データの同期をどうするかが曖昧なんで、
ちょっち考える。
ファイル 1028-1.png
そういや、スパム落ち着いてきたな。
一時期は1日10件ぐらい連続で来てたからな。

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