Skip to content

{ Category Archives } 技術

「iOSアプリ内課金+広告」の本を共著で書きました

「アプリ内課金+広告 iPhoneプログラミング」という本を、酢酸センセーこと和田健司さん(@ch3cooh)と共著で書きました。秀和システムさんから2014年1月下旬に発売予定です。

私は主にアプリ内課金に関するパートを、和田さんは広告パートを執筆しました。iOS 7にも対応していますし、アプリに広告を載せてチョットでもお小遣い入ったら嬉しいという方や、アプリ内課金を初めて実装したいという方にオススメできる1冊です。
目次
目次はこんな感じです。

Chapter 1 アプリ内課金と広告を理解する
アプリ内課金とアプリ内広告が存在する背景を紹介しつつ、それぞれについて説明をします。またアプリ内広告とアプリ内課金を組み合わせる魅力についても説明しつつ、この組み合わせを採用しているアプリを紹介します。
Chapter 2 アプリ内課金を実装するための準備
アプリ内課金をアプリに実装する前に準備が必要です。開発者向けに提供されている Web サイト、iOS Developer Portal、iTunes Connect を使って事前準備を行うための説明をします。
Chapter 3 アプリ内課金の実装:単一の非消耗型
アプリ内課金を実装するうえで理解をしておくべきポイントとして、アプリ〜 Store Kit 〜 App Store の関係性、各クラスの位置づけ、実装の基本ポイントを説明します。
Chapter 4 アプリ内課金の実装:単一の消耗型と自動更新購読型
アプリ内課金でよく使われている「消耗型」と比較的使われている「自動更新購読型」 について、実装のポイントを説明します。
Chapter 5 さまざまなタイプの広告を実装する
アプリ内広告を掲載するには、広告を配信する各種広告会社との契約、SDKの導入 が最初に必要です。またアプリ内での広告の見え方(見せ方)も実装の前に知っておい た方がよいでしょう。契約、SDKの導入、アプリ内広告の実装について説明します。
Chapter 6 アプリ内課金+広告タイプのアプリを作る
広告とアプリ内課金を組み合わせた(開発者にとって)魅力のあるアプリについて、 実装方法を具体的に解説します。
Chapter 7 複数の課金パターンを提供するアプリを作る
1 つのアプリ内に複数のアプリ内課金パターンを入れることで、アプリの魅力を広げることができます。このようなことを実装するにあたってのポイントを解説します。
Chapter 8 アプリ内課金をテストする
アプリ内課金はエンドユーザが支払いをする性質上、課金処理をしっかり作った上で動作確認をしておく必要があります。動作確認のポイントを説明します。
Chapter 9 アプリ内課金と広告のトラブルシューティング
アプリ内課金、アプリ内広告の実装以外に、意外なところで落とし穴が出てきたりします。多くの人が経験するであろうトラブルについて、その原因と対策について説明します。
苦労したこと
執筆当時にリリースされたiOS 7ですが、アプリ内課金のレシート確認方法がiOS 7からややこしい方法に変わっていることに気がつきました。それの解決方法について当時は日本にも海外にも情報が皆無でしたが、なんとか方法を探り当て記事にすることができました。苦労の過程はコチラに書き残しています。
謝辞
仕事として和田さんと共同作業したのは今回が初めてでした。また私は秀和さんとも初めてで、進め方の勝手が分からない中、最初から最後まで和田さんにフォローして頂き本当に助かりました。そういえば原稿生成システム(原稿をMarkdownで書いてgithubにpushしたらPDFが降ってくる)を構築してくれたのも和田さんでしたね。これが無かったらきっとスムーズに進まなかったでしょう。何から何まで感謝です!
最後に
書籍タイトルに「iPhoneプログラミング」ってありますけど、iPadにも対応してます!あとアプリ内課金に興味があっていろいろ聞きたいという方がいらっしゃいましたら、直近は関西の勉強会でアプリ内課金のお話をする予定ですので、関西圏にお住まいの方はぜひそちらにいらしてください。
【第3回】がりっち勉強会 in 関西
それでは!

Tagged , , ,

iOS 7/In-App Purchase/ローカルレシート検証

これの続きです。
iOS 7 + Auto-renewable + TransactionReceipt
これで有効期限が取れたのは取れたのですが(値も正しかった)、これで良いのかわかりません。素直にOpenSSL使って、ローカルレシート確認にする方がいいのかしら…
2013/11/4 追記:
このやり方はAppleのドキュメントに書いてないからダメっぽい。
OpenSSL使ってローカルレシート認証にするのが正解だと思われる。
引き続き検証中。
元の話は、iOSのアプリ内課金(In-App Purchase)でレシートの確認を行う場合、SKPaymentTransaction#transactionReceiptが、iOS 7からDeprecatedになっており、さてどうしたらよいのやら…ということでした。そしてこれに対する回答は、Appleのドキュメントに”超”概要が書いてありました。
レシート検証 プログラミングガイド

P.5
レシートをローカルで検証する
ローカルでの検証には、PKCS #7署名を読み込んで検証するコードと署名されたペイロードを解析し て検証するコードが必要です。

P.7
iOSで(システムが古いために)appStoreReceiptURLメソッドが使用できない場合は、App Storeを使用してSKPaymentTransactionオブジェクトのtransactionReceiptプロパティを 検証するためにフォールバックすることができます。

ふむふむ…「appStoreReceiptURLメソッドが使用できるのならレシートをローカルで検証しなさい」というように読み取れます。何故なら「フォールバックする」=「SKPaymentTransactionオブジェクトのtransactionReceiptプロパティを使う」=「Deprecated」だからです。
ではレシートをローカルで検証するにはどうするか…ドキュメントを読むと次のようにありました。
・ローカルのレシートは、Appleの証明書に署名されたPKCS #7コンテナである
・PKCS #7を読みほどいていくにはOpenSSLを使えば出来るけど、ヒントはドキュメントに書いておく
・まぁそんな感じで実装は開発者にまかせた、頑張れ
お、おう…頑張って実装を…無理や!と思ったら、ここら辺をやってくれている方がいらっしゃいました。ファンタスティック!次の3つを使っていけば、レシートをローカルで検証することが出来ます。
・x2on / OpenSSL-for-iPhone
https://github.com/x2on/OpenSSL-for-iPhone
・rmaddy / VerifyStoreReceiptiOS
https://github.com/rmaddy/VerifyStoreReceiptiOS
・Apple Root Certification Authoirty
http://www.apple.com/certificateauthority/
以下手順。
==========
1. OpenSSL-for-iPhoneの中に build-libssl.sh があるので、ターミナルから叩いて暫く待てば出来上がりです。これを使ったビルドにarが必要なのですが、自分環境にarがなかったので

sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ar /Applications/Xcode.app/Contents/Developer/usr/bin/ar

こんな感じでシンボリックを張ったら通りました。
2. 1で作ったOpenSSLのlibrary2つ、VerifyStoreReceiptiOSの.hと.m、AppleのROOTサーバ証明書(Apple Inc. Root Certificateの方)を、レシートを検証するアプリのプロジェクトに突っ込みます。AppleのROOTサーバ証明書だけプロジェクトのルートに配置してください。他は任意の場所でOKです。それからプロジェクトの設定について、OpenSSLのヘッダが読み取れるようにSearchPathを足すのと、OpenSSLのライブラリをStatic Linkするように変更してください。
3. VerifyStoreReceipt.m の以下行をアンコメント、さらに自分のアプリに合わせて変更してください。

// const NSString * global_bundleVersion = @"1.0.2";
// const NSString * global_bundleIdentifier = @"com.example.SampleApp";

4.  レシートの検証ロジックを、VerifyStoreReceipt.mを使ったものに変更してください。

NSURL *receiptURL = [[NSBundle mainBundle] appStoreReceiptURL];
BOOL [...]

Tagged ,

iOS 7 + Auto-renewable + TransactionReceipt

iOS 7のIn-App Purchase(アプリ内課金)で、Auto-renewable Product(自動更新購読型)の話です。
Auto-renewableなプロダクトが購入されたとき、それの有効期間を確認するために
paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
からレシート情報を取得しApp Storeへ送ると、次のようなJSONが返ってきます。

{
"latest_receipt" = <latest_receipt_infoのBASE64値>;
"latest_receipt_info" = {
bid = "APPID";
bvrs = "1.0";
"expires_date" = 1383368349000;
[...]

Tagged ,

楽しいアプリ制作の会#13でMVVMをしゃべってきた

たのアプ#13を開催し無事に終了してきました。
今回は「はじめてのMVVM」というセッションをやりました。
・MVVM概要
・MVVMで重要なViewModelの役割
・バインディング
・MVVM Light Toolkit
というポイントを説明してきました。
バインディングの利点は説明だけだと分かりにくいのではないかと思い、擬人化デモ(寸劇)しながら
説明したところ割と評判よかったですw
資料はこちらです。
楽しいアプリ制作の会#13 はじめてのMVVM
View more presentations or Upload your own.

Androidカスタムコンポーネントのススメ

はじめに
Androidアプリケーションの機能実装のアプローチとして、コンポーネント(Component / Control、Widgetと称すこともあります)を拡張していく方法があります。特にコンポーネントの振る舞いに紐づく機能は、それをActivityクラスに実装するよりコンポーネントに実装する方が、全体的にシンプルなコードになることがあります。
例として、必須入力チェック機能付きEditTextコンポーネントを作成してみます。
※いつもの如くeclipseは英語版のままなので、適宜日本語に置き換えてください

開発手順

Androidプロジェクトを作成します。プロジェクト名は「CustomComponent」、パッケージ名は「jp.tworks.android.customcomponent」としました。パッケージ名は後に使いますので覚えておきましょう。

EditTextに必須入力チェック機能を付けるために、必要な属性を考えてみます。EditTextが必須チェックを行うか否かのフラグ(boolean)と必須チェックエラーを検出したときのエラーメッセージ(String)があれば良さそうですね。

さっそく属性を定義します。/res/values/attrs.xml を追加します。
/res/values からコンテキストメニューを開き、[New] –> [Other...] を選択します。

Android XML Values Fileを選択します。

ファイル名に「attrs.xml」を入力したらFinishをクリックします。

attrs.xmlを以下のように編集します。

1
2
3
4
5
6
7
8
9
<?xml version="1.0" encoding="utf-8"?>
<resources>
 
<declare-styleable name="ValidEditText">
<attr name="required" format="boolean" />
<attr name="required_message" format="string" />
</declare-styleable>
 
</resources>

declare-styleable name=”xxxxxxxx” のxxxxxxxxは、これから作成するカスタムコンポーネントのクラス名を指定しておきましょう。

次にカスタムコンポーネントのクラスを作成します。プロジェクトにクラスを追加します。srcからコンテキストメニューを開き「New」–>「Class」をクリックします。

Package名を「jp.tworks.android.customcomponent.widget」、クラス名を「ValidEditText」、継承元クラスをAndroid標準の「android.widget.EditText」としました。

ValidEditTextクラスのコンストラクタを定義しましょう。widgetには3タイプのコンストラクタがありますが、ここではそのうちの1つ(引数が2つのバージョン)を定義します。

1
2
3
4
5
6
7
public class ValidEditText extends EditText {
 
public ValidEditText(Context [...]

Tagged

双方向Bindingが可能なAndroid Binding v0.45を使ってみた

前置き
Android Bindingが0.45にバージョンアップしていたので試してみたところ、何と双方向Bindingに対応しているではないですか!…とTwitterにつぶやいたら@nakajiに「blogに書け!」と言われたので、纏めてみようと思います。
はじめに
Android Bindingって何?ですが、一言で言うと「ViewとModel層を祖結合にしてくれるライブラリ」ってところです。これを使うとどう素敵になるの?という前置きは、@nakajiがコチラに書かれていますのでご参照ください。@nakajiの記事にもある通り、昔はView–>Modelへの片方向Bindingのみがサポートされていましたが、v0.45ではView<–>Modelの双方向Bindingが実現出来ていました。スバ、ラッシィ。
事前準備

Androidの開発環境(eclipse+Android SDK)を整えておく
Android Bindingのサイトから android-binding-0.45-update.jar をダウンロードしておく

開発手順

Androidプロジェクトを作成します。AndroidBindingSampleと名付けました。

事前にダウンロードしておいた android-binding-0.45-update.jar をプロジェクトの外部ライブラリとして参照追加します。プロジェクトの「Property」ダイアログを開き「Java Build Path」を選択し「Add External JARs…」ボタンを押下します。

android-binding-0.45-update.jar を選択します。

プロジェクトに参照が追加されました。

次に画面を作り…たいのですが、その準備として、画面に表示する文字情報をリソース(string.xml)に定義します。

<!–?xml version="1.0" encoding="utf-8"?–>
 
Android Binding
Enter your Height
Enter your Weight
Calc BMI

画面を作りましょう。…とその前に何のアプリケーションを作るかを決めていませんでした。@nakajiの記事と比較しやすいように、入力された身長と体重からBMI値を計算し表示するアプリケーションにします。画面に身長(EditText)、体重(EditText)、計算ボタン(Button)、BMI計算結果(TextView)を貼り付けます。貼り付けついでに、EditText:hintプロパティとButton:textプロパティに、string.xmlで定義した文字列を設定しておきます。

layout.xmlの内容はこんな感じです。

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:binding="http://www.gueei.com/android-binding/"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
[...]

Tagged

「はじめてのWindows Phoneプログラミング」執筆しました

参考書「はじめてのWindows Phoneプログラミング」を執筆しました。蜜葉たんと共同執筆です。

http://www.kohgakusha.co.jp/books/detail/978-4-7775-1661-2

タイトルの通り、これから”はじめて”Windows Phoneプログラミングをする方向けの内容になっています。
アプリを出している人が読む本じゃないんだからねっ!
さておき、立ち読みして良かったら買ってくださいねー。

Tagged

アプリ内テーマのすすめ

Windows Phone Advent Calendar 20日目の記事です。
■はじめに
 Windows Phoneのアプリケーションに、アプリ内テーマを適用する方法を紹介します。参考文献はコチラです。
 
 複数の画面を持つアプリケーションで、各画面に配置しているボタンやチェックボックスなどの配色をカスタマイズしつつ、全体で統一したいということがあります。画面毎/コントロール毎にプロパティを編集してもできますが、色味を変えたくなった時に、その都度すべてのコントロールのプロパティを編集しなければならないのは大変なことです。
  
 Androidは自身のアプリケーションの外観を統一させるために、Style Resourceという機能があります(Android UI前身のSWINGがその機能を持っており、それを継承していると思われます)。Style Resourceにデザイン要素を定義し、それを参照している画面はStyle Resourceのデザイン定義に従って描画を行います。
 
 Windows Phoneで同じことができないかと調べたところ、冒頭の文献を見つけました。
■開発手順

アプリ内テーマを適用したいプロジェクトに「Theme」フォルダを追加します。

Themeフォルダに「System.Windows.xaml」と「ThemeResources.xaml」を追加します。

ファイルは以下からダウンロードしてください。
System.Windows.xaml
ThemeResources.xaml

「System.Windows.xaml」と「ThemeResources.xaml」のビルドアクションを「Resource」に設定します。

App.xamlを編集します。

1
2
3
4
5
6
7
8
<!–アプリケーション リソース–>
<Application.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="Theme/System.Windows.xaml"/>
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</Application.Resources>

App.xaml.csを編集します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
using System.Collections;
 
public App()
{

InitializeComponent();
 
// 以下を追加する
MergeCustomColors();
 
InitializePhoneApplication();

}
 
// テーマをマージするロジック
private void MergeCustomColors()
{
var dictionaries = new ResourceDictionary();
 
[...]

Tagged