サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
nantekottai.com
最近妙に目立つ位置にアプリ内課金用のRestoreボタンが追加されたアプリが多いなと思ったら、どうもアプリ内課金で購入したプロダクトのリストアに関する審査が少し変化してきているようです。 In App Purchase Programming GuideのMaking a Purchase > Restoring Transactionの項には、下記の一文があります。 However, if your application supports product types that must be restorable, you must include an interface that allows users to restore these purchases. リストア可能なプロダクト(Non consumableプロダクトと購読型のプロダクト)に関しては、ユーザがデバイスを買い替
Hookの機構を使うと、GitHubに変更がプッシュされたタイミングで自動的にJenkinsのジョブが走るようにすることができます。ポーリングに比べて、プッシュからビルドまでの時差が減り、無駄な通信も減りますが、アクセス制御が有効になっている場合の設定で少しはまってしまったので方法を書いておきます。 Hookをトリガーにしたビルド Gitには、コミット直前やプッシュ完了時など、任意のタイミングでスクリプトを実行できるHookという機構があります。この機構を利用すると、レポジトリに変更がプッシュされたタイミングでJenkinsのジョブを実行させることができます。 GitHubの場合は、レポジトリのAdmin -> Service Hooksページ内でHookの設定ができます。幸い、Jenkinsと連携させるための項目が最初から用意されています。ここでJenkins内のジョブ実行用のURLを指
最近のiOS / OS Xでは非同期処理はGCDを使って行うのがトレンドなので、AsyncUDPSocketよりもGCDAsyncUDPSocketを使ったほうが良いだろうと思って使ってきたのですが、一部プロジェクトでは結局AsyncUDPSocketを使う形に戻すことになりました。 処理の優先度と安定さ UDPではパケロスが発生したりパケットの順番が入れ替わったりします。パケロスや順番の入れ替わりが発生する要因は様々ですが、パケットの受信キューの「詰まり」もこれの原因となります。 特にリソースにそこまで余裕がないiOS端末で大量のUDPパケットを送受信しようとすると、処理が追いつかずに受信キューが詰まって不安定になることが珍しくありません。従って、UDP通信の安定性が求められる場合、UDP関連の処理の優先度をあげておかないとプログラムがうまく動作しないことがあります。 スレッドとGCD
WWDC開幕で、話題の中心はもっぱらiOS 6、Mountain Lion、Retina対応Macですが、気にせずテストについて書きます。 2012年6月現在、純正のSenTestingKit以外にも多数のiOSアプリ用テストフレームワークが存在します。今まで試してきた中で、おすすめのテストフレームワークをいくつか紹介します。 標準のテストフレームワーク SenTestingKit / OCUnit Xcodeに標準で付属しているテストフレームワークです。iOSアプリのテストを初めて学ぶには、素直にSenTestingKitから始めた方がよいと思いますが、非同期処理やUIを含むテストは面倒・困難です。Google Toolbox for Macを使って少し拡張することもできます。 長所 標準で用意されているので導入が楽。 シンプルなので理解しやすい。 他のフレームワークのメリット・デメリッ
Jenkinsを使ったiOSアプリ開発へのCI導入のうち、標準的な構成のアプリのビルドの自動化、テストの自動化についての説明が完了したので、一度ここでまとめておきます。 Jenkinsの導入はそこまで難しくない。少なくともここまでは。 今まで見てきたようにプラグインがとても充実しているので、標準的な構成のプロジェクトであれば導入は比較的簡単です。後に説明するようにUnity等を使っている場合は一筋縄ではいきませんが、そうでない場合はJenkinsの導入コストを懸念するべきではないでしょう。 自動化を前提とした開発への頭の切り替え 問題はこれからで、単にJenkinsを導入してアプリのビルドとテストを自動化しただけでは、実際のところチームの生産性は多分変わりません。大事なことは、自動化を前提とした開発フローに切り替えることです。Jenkinsに任せられることは任せ、任せられない創造的な仕事に
iTunes Connectにアップロード可能なpkgファイルをコマンドラインから作れるようになったら、今度はそのpkgファイルをコマンドラインからiTunes Connectにアップロードしてみよう。 “macOSアプリのCI事情7 – deliverでpkgファイルをiTunes Connectにアップロードする” の続きを読む
Test After Buildの仕組みを利用して、実際にテストを実行してみましょう。 テスト用ターゲット Xcodeビルドの設定で、テスト用のターゲットを設定します。 iOSの標準のテスト(SenTestingKit)はシミュレータ上でしか走らせる事ができないので、SDKには明示的にiphonesimulatorを指定します。iphonesimulator5.1のようにバージョンを指定することもできます。これを指定しないとデバイス用のSDKが使われる事になるので、エラーが発生します。 この状態で一度ジョブを実行してみましょう。コンソール出力を確認して、テスト実行のログが残っているか確認しましょう。 Test Suite '/Users/foo/.jenkins/jobs/bar/workspace/build/Debug-iphonesimulator/bar.octest(Tests)
Jenkinsを使ってビルドを自動化することができました。この後、ビルドしたアプリをTestFlight経由でいつでも簡単にインストールできるようにしていきたいのですが、手順の都合から先にテストの自動化について確認しておきましょう。 継続的なテスト SQLiteのテストコードは実に9000万行を超えているそうです。バグを早期に発見しつぶすためにテストは重要ですが、一方で開発が進むにつれて増大していくテストコードを、プログラマがコードをコミットする前に毎回全部実行するのは、時間がかかり非効率的です。 そこで、プログラマは自分のコミットに影響があると思われる部分(この見積もりは大事だけれど)のみコミット前にテストを実行し、後はコミットした後でJenkinsにテストさせていくようにして、バグの早期発見とスピードのバランスをとっていきましょう。 Xcode Pluginを使って実行できるテストの制
まずは難しい事を考えずに、一度JenkinsからXcodeを使ってプロジェクトをビルドしてみましょう。Jenkinsを使ってiOSアプリをビルドするには、最初にいくつか設定をする必要があります。 必要なもの 最新のXcode 最新版のXcodeが必要です。ちなみに、JenkinsはXcode.appではなくxcodebuildコマンドを使ってiOSアプリケーションをビルドします。xcodebuildはXcodeをインストールすると使えるようになるコマンドです。 プロビジョニング類 実機用のビルドを行うには、通常の実機用ビルド同様、ビルドに使うProvisioningファイル類(秘密鍵・証明書・プロビジョニングファイル)が必要です。シミュレータでテストを行うだけであればこれらはなくても大丈夫です。 プラグイン シェルスクリプトでビルド用のコマンドを書いてもよいのですが、プラグインを使うと設定
手始めに、Jenkinsを使ってプロジェクトの最新のソースコードをGitレポジトリから取得してきてみましょう。Jenkinsは標準でCVSやSVNに対応していますが、残念ながらGitに対応していません。Gitを使うには別途プラグインをインストールする必要があります。 Gitプラグインのインストール JenkinsのプラグインはWeb UI上でインストールできます。 Web UI(localhost:8080)の左上のメニューから「Jenkinsの管理」を開きます。 「プラグインの管理」を選びます。 プラグイン管理画面が開いたら、「利用可能」タブを選択します。しばらく待つと、利用可能なプラグインの一覧が表示されます。待っても表示されない場合はリロードしてみるとうまくいったりします。 「Git Plugin」というプラグインにチェックを入れて、「再起動せずにインストール」します。 以上でGit
Cronでビルド用のスクリプトを定期的に実行するだけでも、完全自動のCIを実現できますが、CIツールを使うとより簡単に実現できます。今回はiOSアプリ開発(とくにUnityを使ったゲーム開発)で最近よく使われているJenkinsというCIツールを試してみます。まずはインストール。 Jenkinsを使うとなにがよいのか 「レポジトリから最新のソースコードを一式取得してきて、テストする。また、ビルドしてTestFlightにアップロードする」一連の流れをゼロからスクリプトで記述するのはかなり面倒です。エラーハンドリングを含めると、コードはどんどん長くなり導入コストが大きくなってしまいます。 JenkinsをはじめとするCIツールでは、これらの各処理をパラメータを指定するだけで実行できるようになっており、自動ビルドの導入コストが大幅に圧縮されます。また、スクリプトだけでは実現が難しい過去の履歴の
エクストリーム・プログラミングのプラクティスの一つに、継続的インテグレーション(CI)があります。iOSアプリ開発のフローにもCIを取り入れてみましょう。ここではJenkinsというツールを使って具体的にiOSアプリのビルド・テストの自動化を試みながら、iOSアプリ開発にCIを取り入れる上でのメリットや課題について見ていきます。 バグの早期発見 実際にチームでプロジェクトを開発していると、バグは勿論、ビルドできないコードがコミットされてしまうことがあります。継続的にビルド・テストをしていると問題があるコードがコミットされた時にすぐに気がつきます。 ノンエンジニアへのビルドの共有 TestFlight等と組み合わせると、開発環境を持っていないノンエンジニアの人がいつでも開発中のアプリの最新版を自分の端末上にインストールできるようになります。これはエンジニア・ノンエンジニア両方にとってストレス
長い事Macの環境を新しく作っていなかったので知らなかったのですが、XcodeのCommand Line ToolsはPreferences画面のDownloadsタブから手動でインストールしなければいけなくなっていたようです。これをインストールしないとccなどのコマンドが使えないためrvmなど各種ソフトウェアのビルドに失敗してしまうので、注意が必要です。
5年程前にブラウザ上で音響合成をする方法を模索していて、当時はレイテンシや負荷の問題を解決できず断念してしまったのですが、最近Web Audio APIがアツいという話を耳にして、早速試してみました。その中でもsink.jsを使うと、かなり簡単にブラウザ上での音響合成を楽しめます。まさに夢がひろがりんぐ。 Web Audio APIとは Web Audio APIは音楽アプリケーションをJavaScript上で作るためのAPIです。2010年にW3Cによって提唱されていて、最新版のChromeや開発版のSafariで既に利用可能になっています。まあ、とにかくこれを使うとブラウザ上で音楽アプリケーション(シンセサイザーとか)を作れる、というわけです。 sink.jsとは Web Audio APIを直接叩いて音響合成プログラミングをしてもいいのですが、手っ取り早くその面白さを理解するには、ラ
その4までで、一応窓関数も使った高速フーリエ変換が実現できました。しかし実際にオーディオのリアルタイム解析などで使おうとすると、このままでは使いにくいし効率も悪いので、後々使いやすい形に実装しなおします。 “vDSPを使う(高速フーリエ変換編 その5)” の続きを読む
簡単な高速フーリエ変換ができるようになりましたが、なにも考えずに信号をフーリエ変換すると周波数特性がきれいにでない場合があります。これは信号に含まれる成分の波長がフーリエ変換する長さに会わなかった場合に発生するのですが、「窓」と呼ばれるものを使うとこの問題を低減できます。「窓」を作る機能もvDSPには用意されているので使ってみます。 「窓」を作る前に、どういう問題なの? 離散フーリエ変換では、特性上信号(配列)の長さにぴったりおさまる波形はキレイに解析できるのですが、 波長が信号(配列)の長さにおさまらない波形はキレイに解析できません。 前の記事で最初に作った波形は30回振動する周期(つまり、波長が配列の長さの1/30になっている)ので、波形がぴったり配列におさまりキレイな周波数特性がでるのですが、これの周期を中途半端な少数などにしてしまうと、キレイな周波数特性はでなくなってしまいます。現
StoreKitのトランザクションには、トラブルが発生した際に重要になる情報が多く含まれています。SKPaymentTransactionオブジェクトに含まれる情報と、それらの挙動について確認していきましょう。なお、複雑になるのでNon-Consumableプロダクトのリストア関連の項目については、基本的に省略しています。 SKPaymentTransactionの要素 SKPaymentTransactionに含まれる主なプロパティは以下の通りです。(Non-Consumableプロダクトのリストア関連の要素は除いています) error payment transactionState transactionIdentifier transactionReceipt transactionDate 各要素について、挙動や使い方を確認していきましょう。 transactionState ト
今作っているソフトの関係でUDPサーバーを用意したくなり、せっかくなのでnode.jsを使って作ってみました。node.js自体はHTTPサーバーをたててみて遊んでみたことはありますが、UDPで使うのははじめてです。 開発環境を作る Mac上に開発環境を作る手順はこちら。 UDPパケットの受信 node.jsでUDPサーバーを作る方法についてこんな記事を見つけました。どうやらdgram(Datagram)なるものが用意されていて、これを使うとUDPソケット関連の処理を実装できるみたいなので、まずは受信側から試してみます。 UDPの受信はものすごく簡単で、createSocket関数をsocketのタイプとコールバックの内容を記述して呼ぶだけです。 dgram.createSocket(type, [callback]) typeにはudp4, udp6, unix_dgramが指定可能。コ
OAuthConsumerの基本的な使い方を説明します。 OAuthConsumerの基本的な使い方 OAuthConsumerは公式のドキュメント類が少なく、使い方について書かれたドキュメントもUsingOAuthConsumerくらいしか見当たりません。残念ながらこのチュートリアルも若干説明が不十分な部分があったり、サンプルコードはメモリーリークしまくりのコードになっているので、参考程度にみてあとは実際にコードを読むか使ってみて使い方を覚えていくしかありません。 上記チュートリアルを参考に、メモリーリーク等の問題を直したプログラムは下記のような形になります。 #import "OAuthConsumer.h" ... // サービスからアプリ用に割り当てられたKeyとSecret NSString* consumerKey = @"12345"; NSString* consumerS
11月末にAsyncUdpSocketのGCD対応版であるGCDAsyncUdpSocketが公開されていました。 過去に記事を書いたAsyncUdpSocketクラスを使うと、Cocoaアプリで簡単にUDP通信を実装できるのですが、今回はそれのGrand Central Dispatchに対応したバージョンが公開されていました。(TCP版であるGCDAsyncSocketは既に大分前にリリースされていました)2012年1月13日現在のリビジョンでは、ARCには対応していません。 GCDAsyncUdpSocketの入手 GCDAsyncUdpSocketはcocoaasyncsocketというプロジェクトの一部として開発されています。github上で開発/管理されているので、最新のソースコードをgithubからcloneしてきましょう。 git clone https://github.
iOS4以降、iOSアプリを作る場合はマルチタスク(Fast App Switching)の対応を考慮しなければいけなくなりました。バックグラウンドに入ったらアプリを終了するようにして、マルチタスクをサポートしないようにすることもできますが、AppStoreでリリースされている多くのアプリがマルチタスクをサポートしており、ユーザがマルチタスクに慣れていることを考えると、できるだけマルチタスクをサポートしておきたいものです。 Fast App SwitchingのハンドリングはAppDelegateで行っている人も多くいると思いますが、コードの再利用性を考えるとNotificationCenterを使った方が効率的な場合があります。 アプリをFast App Switchingに対応させるには、以下の実装が必要です。 アプリがバックグラウンドに切り替わった時の対応(ゲームをポーズ状態にする、
久しぶりにStoreKitについての記事です。In-App Purchase Programming GuideやStoreKit Framework ReferenceにはFast App Switchingやスリープに関する説明がありません。しかし、購入手続きの途中にアプリ切り替え(Fast App Switching)が発生すると、アプリケーションは正しくトランザクションの状態変化を把握できなくなってしまいます。そこで、この問題についての対策を考えます。 ※2012/05/22追記 この部分の挙動が変更になったようです。再検証を行ったのでこちらの記事を参照してください。 注意 この記事は、Apple公式ドキュメント類では説明/推奨されていない実装方法についての考察です。挙動や実装は将来的に大きく変わる可能性があり、動作は一切保証できません。参考にする程度にとどめ、もし下記に書かれてい
最近妙に目立つ位置にアプリ内課金用のRestoreボタンが追加されたアプリが多いなと思ったら、どうもアプリ内課金で購入したプロダクトのリストアに関する審査が少し変化してきているようです。 “Non consumableプロダクトとRestoreボタン” の続きを読む Twitterで@naokitsさんに教えていただいたので検証してみました。以前この記事に書いた通り、今まではトランザクションが進行中にアプリがバックグラウンドに移行してしまうと、トランザクションオブザーバーがトランザクションのアップデート通知を受け取れなくなってしまうという問題があったのですが、最近この挙動に変更があったようです。幸い手元にiOS 5.1.1, 5.0, 4.3.3の端末があったのでそれぞれで検証してみました。 “StoreKitのバックグラウンド時のトランザクションの挙動が少し変わった件” の続きを読む
支払いは完了したのにアイテムがアンロックされない、等の問題が起きないように、StoreKitにはトランザクションの機構があります。トランザクションの機構は絶対に必要なのですが、これがStoreKitによるアプリ内課金の組み込みを複雑にする大きな要素となってきます。基礎から見ていきましょう。 StoreKitにおけるトランザクション SKPaymentTransactionクラス トランザクションを扱うクラスはSKPaymentTransactionです。基本的にPaymentがキューに積まれたタイミングで生成され、購入の一連の流れを管理するのに用います。最後はアプリケーション側からfinishTransaction:というトランザクション完了のメソッドを投げる形で完了になります。 SKPaymentTransactionObserverプロトコル アプリケーション側がPaymentリクエス
トランザクションが複数できると面倒なことになると前回のポストで書きました。特に購入手続きの途中でアプリケーションが終了してしまったような場合は、アプリケーション側で少し面倒ですが対策をいれないと問題を回避できません。 発生するケースについての確認 実際の対策を見る前に、発生するケースについて確認しておきます。 ユーザがアプリケーション上で特定のアイテムを「購入」しようとする。 アプリケーションからStoreKitのキューにPaymentリクエストが積まれる。 トランザクションが生成される。 トランザクションが完了する前にアプリケーションが終了。 アプリケーション再起動。 前回のトランザクションが再開/完了するより前のタイミングでユーザが再び「購入」しようとする。 この問題は、前述の通りアプリケーション起動から未完状態のトランザクションが再開されるまで若干のラグがあるために発生しうる問題です
というわけで、StoreKitの挙動について細かく検証してきましたが、少なくとも組み込みプロダクトモデル編については、ここから先はかなり細かい話になってきてしまうので一旦ここでまとめておきます。 なお、この情報は2011年11月現在のiOS 5.0におけるもので、将来的に仕様が変わっている可能性があります。また、公式ドキュメント等には記載されていない独自の検証に基づく見解が含まれます。参考程度に読んでください。そして気づいた点を躊躇せず指摘してください。 StoreKit 組み込みプロダクトモデルに関するポイント 1. オブザーバーをアプリケーション起動直後に登録する 組み込みプロダクトモデルにおいて、最も厄介なのは6. の購入手続きが同時に複数走ってしまう場合です。中断されたトランザクションをなるべく早く再開させるためにも、オブザーバーはアプリケーション起動直後に登録しましょう。公式ドキ
トランザクションの中断と再開について、もう少し詳しく見ていきましょう。 トランザクションの中断と再開に関する基本的な挙動の復習 購入の確認ダイアログが表示された後、アプリケーションから正しくfinishTransaction:を実行されなかったトランザクションは未完状態となり、次回アプリケーションが起動した時に再開されます。 実験 前のポストに書いた通り、トランザクションはApple IDと紐づいています。なので、複数のデバイスで同じApple IDを使っていて、なおかつ未完のトランザクションがあった場合にどういった挙動になるのか、実験をしてみます。※この内容は、2011年10月時点で最新のOS 5.0を用いて行った結果です。状況/アップデートにより挙動は変わる可能性があるため、十分に注意してください。 Consumableプロダクトの場合 まず、あらかじめ二つのデバイスA, Bで同じAp
購入トランザクションは、アプリが最後にfinishTransaction:を呼んだタイミングで完了となりますが、そこにたどり着く前にアプリケーションが終了してしまったりネットが切断してしまう可能性があります。その場合、トランザクションは未完状態になり、次回アプリケーションが起動したタイミングで再開されます。これを適切に処理しようとすると、結構厄介なことに気がつきます。 トランザクションを意図的に未完状態にする方法はいくつかあります。購入ダイアログがでた直後にアプリケーションを終了してしまってもいいし、もっとシンプルにPaymentをキューに積んだ後、finishTransactionを呼ばなければそのトランザクションは未完状態のまま残る事になります。 トランザクションの再開 未完状態のトランザクションは、次回アプリケーションが起動した後でStoreKitからSKPaymentTransac
「iOSアプリの売り上げの72%はアプリ内課金から来ている」(このタイトルは若干誇張されていて、正確には「iOSアプリの売り上げの72%はアプリ内課金を搭載したアプリから発生したもの」です)というニュースがあるほど、近年アプリ内課金の存在は大きなものとなってきました。iOSの場合は規約の関係からアプリ内課金を実現する場合にはStoreKitを使うことになりますが、このStoreKitがなかなかの曲者で、僕は未だに取り扱いに苦労しています。 StoreKitの概要 iOSアプリでアプリ内課金を実現するための唯一のフレームワーク iOS 3.0で初登場 OS X 10.7 LionからMacでも使えるようになった ポイントは1で、AppStoreの規約上iOSアプリでアプリ内課金を実現する方法は事実上StoreKitを使う以外にありません。iOS 3.0で登場し、現在はOS X 10.7 Li
次のページ
このページを最初にブックマークしてみませんか?
『なんてこったい – スマホアプリとmacアプリ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く