SKNodeからSKSpriteNodeへ変換SKViewからnodeAtPointで取得したノードはSKNodeとして受け取るため、それをSKSpriteNodeにキャストする。下記コードはSKNodeからSKSpriteNodeへ変換・・・しているというわけではない。SKSpriteNodeであると確信があるので決め打ちしてキャストしているだけ。centerで下準備は済ませているものとして。コードの実装部分のみ。課金の商品は1度きりの購入のよくある広告非表示の商品をイメージ。処理の流れとしては、viewDidLoadにて初めの画面表示の時に製品IDで商品情報を取得して、ボタンを押したら購入処理を開始するというもの。商品が一つだけなら下記のような感じにできるが、普通は複数でテーブルビューなどに表示して配列で商品管理をやっている模様。app内課金の実装にコメントtouchesBeganとtouchesEndedの間にある遅延についてiOSでtouchesBeganイベントが呼ばれてtouchesEndedが呼ばれるまでの間に約0.4秒ほどの遅延があることがわかった。(マシンの調子が悪い時は0.5秒ほど)touchesBeganからtouchesMovedイベントまでの遅延はほとんど気にならない程度。この0.4秒の遅延は体感ではまあ普通のアプリでは反応悪いなと許容できる範囲の時間ではあるけれども、応答の即時性が求められるアプリではちょっと長すぎる。この時間をなんとかゼロにできないものかといろいろ調べてみたが、見つからなかった。touchesEndedイベントに必要なディレイ時間として設定されていてプログラミングでプロパティを変更とかできないものかもしれない。画面をポンッとタップしてその結果がすぐにわかる必要があるような実装をする場合、処理をtouchesEndedに書いていたら0.4秒の遅延が発生するので使えない。この操作だとtouchesMovedイベントも呼ばれない。仕方がないのでtouchesBeganだけで完結するような実装にすることにした。四国銀行が振り込みと振替をオンラインバンキングでする場合にはワンタイムパスワードを必須にする様子。ハードウェアで短時間だけ有効なパスワードを生成する仕組みで、はっきりいうとジャパンネット銀行のパクリである。ハードウェアトークンの見た目もシール張り替えただけのそのままのように見える。ワンタイムパスワード(ハードウェアトークン)とはパスワード生成機(ハードウェアトークン)により生成・表示される1分ごとに変化する使い捨てのパスワードです。ワンタイムパスワードは1分後には使えなくなることから、第三者に遠隔操作等で不正にログインされるリスクを低減することができます。振り込みの時にこのワンタイムパスワードを使うらしいから不正ログインのリスクとは関係がないような気がするが・・・。個人的には四国銀行のオンラインバンキングでこんなハイテクそうなことをやって大丈夫なのかという心配がある。昔の四国銀行のオンラインバンキングのUIは素人丸出しで絶対ホームページ・ビルダーで作ってるだろこれと思いながら私は使っていた。それを知っているからか残高照会以外の取引を四国銀行のオンラインバンキングでやるのはちょっと怖い。ジャパンネット銀行みたいなオンライン専門の銀行じゃないんだからあまり無茶はしないほうがいいとおもうんだけれども。それにしても、ジャパンネット銀行をオンライン決済で利用している私はこのトークンをすでに使っていて、さらに四国銀行のトークンも管理しなければならないというのは、なんかセキュリティのためとはいえ馬鹿っぽい気がする。私は他にゆうちょ銀行や楽天銀行の口座も持っているが、それらの銀行がもしもトークンの利用開始を始めてしまったらたまったもんではない。財布に溜まっていくコンビニや量販店のポイントカードじゃあるまいし。未分類四国銀行がオンラインバンキングでハードウェアトークンを始めた様子にコメントメインビューとサブビューの座標の違いメインビューでaddsubviewにてuiviewを追加して、ボタンを押したら別のビューが下からビョーンって出てくるようなものを考えていたが、座標の問題で困った。メインビューの座標とサブビューの座標はそれぞれ存在しているため、メインビューでタップしたポジションでサブビュー上のパーツを動かそうとしたら、当然おかしなことになる。このサブビューを下から少しだけ飛び出すような使い方だと座標の変換が多分必要になる。あと、サブビューのパーツを画面外のメインビューへ飛び越えるような使い方は、多分無理な予感。試してはないけれども、普通の感覚では不自然。下からビューを飛び出してきてその上のパーツをいろいろ動かすのは、擬似的にすることにした。下から表示して、その上のパーツはメインビューにaddsubview()するということ。見た目の上ではテクニカルなことをなんかやっているように見えるだけ。場合こういうのは設計が悪くて他にもっとスマートな解決方法があるはず。なんか無理やり実装してる感が出てきたら経験上よろしくない。後々のメンテナンス性が劣悪になったりとか。Server12.04が突然フリーズして上記エラーを起動時に表示するようになり、そこから進まなくなった。directoryの部分を見て直感でこのエラーはかなりまずいかなと思ってググってみたら、LiveCDでfsckを実行すれば治るとかあったので、参考に自分もやってみることにした。atomという低スペcpuでサーバー稼働していて、復旧作業が長くなりそうな気がしたので)で、載せ替えた後に念のためもう一度起動してみたところ、起動時にHDDのアクセスランプが長いこと点灯したままになってなかなか画面が表示されない現象が発生。待ってたら画面が表示されて、さっきとは違う画面が表示されて、一瞬だったから覚えていないがblockがなんとかあってfsckが実行されたような感じになった。(この時はまだLiveCDは挿入していない)その後は、ログイン画面が表示されて前と変わらないように稼働できるようになった。さっきのエラーがなかったかのように。古いHDDを使っていたので壊れちゃったかなと完全にあきらめモードで作業していたが、実際にやったことといえばHDDを別の高性能なマシンに載せ替えて起動してみただけ。したら、HDDが熱暴走気味になっていて、交換作業中に冷めて正常になったという可能性も、なくはない。(排熱が十分とはいえないマシンを使っていたのは事実)上記のBusyBoxというようなエラーが出た時、あまりごちゃごちゃいじらない方がいいかもしれない。落ち着いて(あきらめモードで)、HDDの熱が冷めるのを待ってもう一度起動するなど気長にやる。完全に故障なら復旧作業はそれなりに時間がかかるのだから。directoryというエラー文は怖すぎる。サーバー管理者を絶望させるに十分なインパクトがある。翌日また不具合が起こった。こんどは上記のようなエラーが発生した。yesみたいな確認が膨大な量出てきた。なんかわからないがyesにするしかないよなぁ・・・と思いながらエンターキーを連打していてちょっと多すぎるからキャンセルしてやり直すかと画面みたら/varとか/etcとかのフォルダに対してdeleteとかrewriteとか実行してしまっていた。directoryが出て進まなくなった。私の致命的なミスは、昨日、幸運にもエラーから復旧できた時にHDD内の必要なデータをバックアップするなどの作業を怠ったこと。買ったばかりのHDDはともかく、古いHDD使ってて上記みたいなエラーが出だしたらもう交換の目安かもしれない。いや、すぐ交換すべき。この種エラーが出たらもう長くないと思ってHDDが生きている内にデータバックアップとリプレース作業を済ましておく(私が使っていたHDDはもう7,8年は使っていた)その後、取り外してcrystaldiskinfoで調べてみた。健康状態は当然、注意の表示が出た。使用時間は51000時間で約6年間稼働している。