2012年04月26日09:42 カテゴリprogrammingスマートフォン androidとiOSで共通で使える暗号方式 こんにちは、VOYAGE GROUPのしんばし(@shinbashi）です。 昨今何につけてもスマートフォンですよね。 かくいう僕もPDAからのW-ZERO3という王道を通って来ました。 さて、最近は特にスマートフォン対応とか、アプリ化する機会が増えてきたと思います。 android版を作ればiOS版も出すよ！みたいな話になりますよね。 「android版だけでいい」 なんて言葉を信じて設計すると、後で痛い目を見るのは火を見るより明らかです。 前フリが長くなりました。 android版だけだと信じて僕が痛い目を見たのは暗号化・復号処理の部分です。 Javaはともかく、Objective-Cをよく知らなかったのでライブラリに頼るわけですが、 Objective-Cの暗
最近気づいたんだけど、iOSで使われるアプリ内課金（In-App Purchase）では複数の課金をしてもそれぞれにレシートのバイナリができるわけではなく、複数まとめて1つのバイナリになっている。 もしかしたら同じような勘違いをしている人もいるかもしれない。そうするとサンプルコードが全然違って見えるよという話です。 Appleの公式リファレンスであるレシート検証プログラミングガイド PDFによるとレシートの構造はこんな感じらしい。 （ちなみにこの図のタイトルはレシートの構造のはずなのに後続と訳されていた） iOS7より前ではtransactionReceiptがNSDataで取得できるので、アイテムごとにレシートが作られているのかと思っていた。コードとしては次のような感じ //このメソッドはオリジナルで - (void)finishTransaction:(SKPaymentTransac
TODO:コード例を載せる Consumable なプロダクトの In-App Purchase は、クライアント側でのアプリ内課金と、サーバ側でのアイテムの付与が１対１になっている必要があります。 課金をしていないのにアイテムの付与をする、あるいは課金をしたのにアイテムを付与していない、という状況は許されません。 今回は、正しくアイテムを付与するためにはどうすればいいのかについて書きます。 正しい付与のやり方 iOS の消費型 IAP ってめんどそうだなぁとか思ってたけど、よく考えると、クライアントは正常に成功か失敗が返ってくるまでリトライする、サーバは１個のトランザクションで１回だけアイテムを増加させる、というルールさえ守ってれば何とかなりそうな気がする。 — めるぽん(ヘルニアン) (@melponn) 2013, 12月 5 本当に重要な部分は、これだけです。 iOS でアプリ内課
はじめに Unity で iOS のアプリ内課金をした際に、サーバーサイドでの課金内容チェックをしたメモ。 Unity でのアプリ内課金には prime31 の iOS StoreKit In App Purchase Plugin を使用。 サーバーサイドは PHP を使用。 Unity 側 prime31 の iOS StoreKit In App Purchase Plugin を購入してインポート Asset の Plugins/StoreKit/demo/StoreKitEventListener.cs の課金成功時コールバックメソッドに、サーバーへのレシート検証リクエストのコードを追加。 void purchaseSuccessfulEvent( StoreKitTransaction transaction ) { Debug.Log( "purchaseSuccessful
先日、着信メロディーズをリリースした訳ですが、このアプリはアプリ内課金（In App Purchase）で着信音をダウンロードできます。 実はアプリ内課金を実装するのは初めてだったのですが、その際にAppleから度重なる洗礼（リジェクト）を受けました。 そこで、アプリ内課金でのハマりどころを共有したいと思います。 アプリ内課金といっても幾つかの種類がありますが、着信メロディーズは下記の様な感じでした。 着信音は購入後に自サーバーからアプリ内にダウンロードしている。（サーバープロダクトモデル） 着信音は一度購入すれば同一のiTunesアカウントでデバイス間で共有できる。（Non-consumable（非消耗型）） ダウンロードした着信音はPCのiTunesとファイル共有するため、アプリ内のDocumentディレクトリに保存。 基本的にはAppleが提供しているIn-App Purchaseプ
概要 「iPhone」や「iPad」でのアプリ内課金（In-App Purchase）の実装方法について書きました。 iOSアプリ内で特定の機能を有料販売するための準備・開発・テストの説明中心です。 全体的な作業時間としては、1日は覚悟したほうが良さそうです。 (課金のタイプによってはサーバー側の開発がないから、APNsよりは少し楽かも？？) In-App Purchase プログラミングガイド(50ページくらい) iTunes Connect In-App Purchase 設定ガイド(50ページくらい) 開発環境 OS : OS X 10.9.2 Xcode : 5.1.1 前提条件 プロダクト(次の２つ)が作成されていること。 iOS Developer Centerでアプリの登録（Identifiersの登録時に「In-App Purchase」にチェックする（デフォでチェック入っ
カヤック時代の恩師 maaash 氏 *1 が、IRKitという新デバイスを個人で開発（！）して、本日よりAmazonで販売を開始しました。 IRKitposted with amazlet at 14.01.14maaash.jp Amazon.co.jpで詳細を見る このIRKitをつかうと、家電を操作するiOSアプリを好きなようにつくることができます。つまり、自分好みのリモコンアプリをつくれます。 対応している家電は・・・という制約はとくになくて、普通のリモコン（赤外線リモコン）で操作できるものなら何でもOKです。 しくみ IRKit（デバイス）が赤外線信号を送る機能を持っていて、IRKit SDK（を組み込んだアプリ）から「どういう信号を送るか」を制御する、という感じです。ざっくり。 学習リモコンやPlutoやiRemoconとどう違うの？ 学習リモコンは、もともとあるリモコンの赤
AppBank の主任です。 Apple は2013年5月1日から、App Store での公開を申請するアプリについて、以下の条件のいずれかに該当する場合はリジェクト（申請を却下）すると発表しました。 アプリの新規公開の申請・アップデート申請の両方でこのルールは適用されます。 UDID にアクセスする iPhone 5 の4インチ液晶（Retina）に最適化されていない 「4インチ液晶に最適化されていない」アプリとは、iPhone 5 や iPod touch（第5世代）で利用した場合、アプリの上下に黒い帯が表示されるものです。 iPhone 5 や iPod touch（第5世代）ユーザーが増えていること・Apple の最新機であることからこのルールが適用される理由は容易に想像できます。 UDID にアクセスするアプリが5月1日からリジェクトされるのは何故でしょうか？ UDIDを使うア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く