フクの非日常

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

iPhoneアプリから本を検索する方法

iPhoneアプリから本を検索する方法について調べてみた。幾つかのアプリでは実際にISBNやキーワードから本を検索しているものがあるので不可能ではないはずだ。むしろカンタンにできるのではなかろうか。。。とさえ思われたが?

検索といえばインターネット。今回やりたいことはインターネットに接続して情報を引っ張ることになる。書籍をいろいろひっくり返して調べると、どうやらNSURLを使うことでサーバへのリクエストを受け取ることができるようだ。リクエストの方法はURLの後ろにパラメータをくっつけて問い合わせることで要求が掛かる。リクエスト仕方はiPhoneアプリというより検索サービスを提供するサーバー側の仕組み。つまり、サーバーにアクセスするのはスマートフォンでなく、PCからでも同じ結果が帰ってくる。

それでは、どの検索エンジンを使えば良いのか。本といえばやっぱりAmazon。そしてAmazonは開発者向けに商品検索のAPIを公開している。なるほど、アフィリエイトを使ったWebサイト向けのサービスで準備されているわけだ。Amazonならば鉄板だろうと思いきや、色々調べてみるとAmazon APIはセットトップボックスを含むスマートフォンからのアクセスを禁止しているということだ。うーん、トラフィックが高くなることを懸念しているのだろうか。とにかくiPhoneからAmazonへの検索は現在のところ禁止されている。

次の検索エンジンの候補は図書館。図書館も蔵書を検索するAPIを公開している。これは使えそうかと思いきや、どうやらキーに図書館とISBNを指定したAPI仕様の模様。やはり図書館利用者向けの用途と考えておいたほうが良いだろうか。

次なる候補は楽天。楽天もAmazonと同じように商品検索のAPIを提供している。しかも書籍検索の専用APIを持っているのでこれは期待できそう。まず楽天会員になり、開発者登録を行う。開発者IDが発行されるので検索するURIのパラメータに追加するだけでカンタンに書籍の情報を取得することができた。試しに本(洋書)のタイトルで検索を掛けるとどうも和書ばかりヒットしてしまう。よくよく調べると、洋書検索用のオペレーションが別に準備してありこっちを使えば洋書ばかりヒットした。う~ん、楽天は開発側のニーズを良く分かっているなぁ。。。と関心してしまった。今度から楽天を応援しよう。

というわけで、iPhoneから本をキーワード検索する方法は「楽天を使う」ということで決まり。後は受領したXMLデータをパーサーで解析して画面に出せばOK。複数件ヒットしたときのために配列で受けてリスト形式で出すことになりそう。このへんは書籍にあたればサンプルは多いのでなんとかなると思われる。

カンタンそう、と思った割には意外と手こずって、やり方が分かってしまえばカンタンだったというお話。
スポンサーサイト

iPhoneアプリ レビュー中

開発中のiPhoneアプリ1本目、コーディングとテストの目処がつき、次はApple Storeへ登録という運びになる。しかしその前に控えているのがAppleによるレビューである。Androidのアプリケーションとの違いはiPhoneアプリはAppleによる審査を挟むことにより一定の品質が確保されるという点だ。利用者にとっては有り難く、開発者にとっては頭が痛い話のようであるが、悪いばかりの話ではない。第一に、iPhoneアプリは審査済みという保証が受けられること。そして、開発者側の意識が向上するという利点がある。特に、個人による開発の場合は品質レベルが低くなる恐れがあるのでリリース前にこういったハードルが設けられているときちんと支度するモチベーションになるということだ。

アプリの開発と一口に言うが、リリースに至るまでにはかなりのステップがあった。

・コーディング
・テスト
・サポートページの準備
・AppStore用のiconの準備
・スクリーンショットの準備

などなど、コツコツと準備を重ねた上でようやくAppStoreへの登録申請をすることにした。ここまで準備しても登録の段階でなにかと引っかかる。アプリの公開とはずいぶんと根気が必要な仕事であった。

【トラブルその1】Bundle IDのエラー
アプリケーションの情報を登録していく時に、Bundle IDでエラーが出た。xcode側のInfo.plistの記述と一致させれば通るようだが一致させているにも関わらずエラーになる。よくよく調べてみると、com.yourcompanyname.~というデフォルトの値を設定していることがエラーの原因のようだ。「yourcompanyname」のところを自分で付けた名前に変更することでエラーは解消した。

【トラブルその2】プロビジョニングファイルのエラー
アプリの情報を登録した後、次にリリース用ファイルの転送となる。しかし、ファイルの転送チェックで早速エラーが起きた。プロビジョニングファイルの不正。結論から言えば、開発用と配布用でことなるプロビジョニングファイルを持たなくてはならなかった。開発用のプロビジョニングでリリース用ファイルをビルドしたことが原因であった。Developer Centerに行って配布用のプロビジョニングを生成し、再度ビルドを行うことで問題は解消した。一つ気になったのは、配布用のプロビジョニングでビルド&実行を行うと、実機にロードすることができないことである。というのは、配布用のプロビジョニングを確認すると、ターゲットデバイスが全く登録されていない状態であった。しかし、配布用のビルドなのでこれでも良いのか。。。疑問は残ったがとにかくプロビジョニングを差し替えることでファイル転送のチェックはパスした。

【トラブルその3】BackgroundModeのエラー
BackgroundModeで動作させるつもりはなかったが、Info.plist内でコンフィグの項目が追加されているためにエラーとなった。これはコンフィグ項目を削除することでエラーは解消した。

以上のようなエラーを解消しつつ、何度かのリトライをすることでようやくアプリケーションの転送が完了した。現在のステータスは「レビュー中」。これからAppleによるレビューが行われ、問題があればReject、通れば晴れてApp Store に公開となる。一度でパスすることは期待していないが、早くApp Store にアプリが出ないものかと楽しみで仕方が無い。

語数電卓

申請中のアプリが公開された! 先週の週末に公開依頼を出してAppleによるレビュー中のステータスだったが 「Ready for Sale」に変わった。つまり、リジェクトされずに審査OK。Apple Storeに並びますよと。

アプリの名前は「語数電卓」。ペーパーバックの概算語数を数えるためのアプリケーション。知り合いに「iPhoneアプリを作ったんだよ~」と話をするのはいいのだが「どんなアプリ?」と聞かれると説明が大変なのが難点。ペーパーバックの語数を数えたいときに、1行あたりの単語数と、行数と、ページ数を入れて計算するんだよ、と説明すると「???」となる。何故もっと分かりやすいテーマのアプリにしなかったんだろう。。。少なくとも最初の1本は。と思わないでもないが。「ペーパーバックの語数を知りたい」という人向けのアプリ。

語数電卓_ss1

リリースだ!やったやった~と喜んでいるのもつかの間、さっそく不具合がぽろぽろと見つかる。App Storeに表示されるタイトルにスペルミスが。。。そもそも「語数電卓」というアプリにしたかったのだが、「WordCal(i)culator」と出ているではないか。確かに、アプリケーションを登録するときにアプリのタイトルにそれっぽい名前を入れたのだが、そこの入力項目がApp Storeのタイトルに行くと思っていなかった。他にも、「著作権表示」のつもりで入力した項目がApp Storeでは「会社」に割り当てられることが判明。その辺も修正したり。。。早速Ver1.1の仕事である。こういったメンテナンスもアプリケーション公開のサイクルの1つということかな。

アプリケーションに不具合があったときに開発者に連絡が取れるような手段を準備することが公開にあたり要求される。そこで作ったのが語数電卓のサポートページ。こういったサポートページで問題を吸い上げてBug Fixするのもアプリのライフサイクル。公開して終わりではなく、むしろこれからがスタートという感じがする。

iPhoneアプリを出すまでに掛かった時間

iPhoneアプリを作ったよ!と話をすると、「時間はどれくらい掛かったの?」ということを聞かれる。「時間」で言えば、アプリケーションの大きさによるものが大きい。一方で「期間」という言い方にすれば、なんとなくどれくらいの準備期間が必要なのかイメージが湧くと思う。これは自分でもとても興味がある質問なのでタイムライン上で振り返ってみることにする。

Mac購入 :2010.12.05
第一期勉強中 :2011.04.19
Magic Mouse購入:2011.05.29
第二期勉強開始 :2011.10.14
アプリ公開申請 :2012.02.12
リリース :2012.02.16

最初にMacを買ったときには「何か作りたいな」と思っていたが、最初の半年はなんとなく過ぎていった。Macの操作にも慣れていないし、開発言語、環境もはじめてでそのへんの操作習得に使っていたようだ。夏場は仕事が忙しくて4~5ヶ月は休止。昨年の10月から再開して最初のアプリ完成に歩を進めることができた。Macを買ってから数えると1年2ヶ月になるが、やはり時間を掛けて取り組み始めた10月以降が「準備期間」として数えるのに適切のようだ。

都合4ヶ月。

数字にしてみると思ったより長い。といっても、教本を見ながら「写経」していた期間が2ヶ月、「自分のアプリ」に向けて動き出したのが2ヶ月という感じだったろうか。0を1にするにはとてもエネルギーが必要だ。しかし、1から2、2から3はそれほど大変ではない。これから先は新しいことに挑戦するにも、最初に貯めたノウハウの上で考えることができるので楽になるはずだ。この先どれくらいの期間でリリースできるようになるのかを計っていくのも面白そうだ。

Kindleの語数カウント

洋書のペーパーバックの語数を数えるにはおおよそのアプローチ方法がわかっている。1ページあたりのだいたいの語数を出して、ページ数を掛けると一冊の語数が計算できる。それをKindleでやろうとすると同じ手段が使えない。なぜか。。。?

Kindle上の本はページを持たず、location番号という概念を採用している。このため、本と同じように「ページ」を扱うアプローチではうまくいかない。なんでそんな面倒なことを・・・と思うのだがそれには理由があるそうだ。KindleはKindle FireやiPhone, iPadのように異なるプラットフォームの上で動作している。このため、1画面に表示できる文字数がそれぞれ異なり、同じ1ページを捲ってもプラットフォーム毎に異なる進み方をしてしまう。そもそも、1つのメディアの中でもフォントサイズを変えることができるから、1ページの文字数は可変になってしまい、何ページという表現ができない。このような理由でlocation番号を持っているようだ。

location番号がページに変わる概念であることは間違いない。では、なぜ同じように1ページ→1locationとして語数を数えることができないのか?理由は、locationの定義が良くわからないからである。byte数、文の数などなど諸説あるが、場合によっては挿絵1ページが1つのlocationに割当てられる場合などがあり、きっちり1location=xx wordとはいかないようだ。

それでもlocation番号をページを数えるのに使わない手はない。そこで1つ、試しに考えてみた方法がある。まだサンプル数が少なくて色んな種類の本で検証はできていないのだが、ペーパーバックにはなんとか使えそうな感触がある。その方法とは、次のようなものである。

(1) 最初に文字の大きさを固定する。例えば、最小の文字サイズにする。
(2) 1画面に表示される文字数の平均値を求める。
iPhone/iTouchの場合、文字を最小にすると120~140 wordになる。
これはやはり会話文が多いと改行が多く、文字数が少なくなるため複数ページでサンプリングをする。
(3) 1画面進めると、location番号が幾つ進むか計算する。
(1画面でlocationが1進むわけではないところが問題!)
計算の仕方として、10画面進めてlocation番号の進みを数え、10で割った数を1画面あたりのlocation数とする。
(4) 全体のlocation数を(3)で出したlocation数で割り、全体の画面数を出す。
全体の画面数に(2)で出した1画面の文字数を掛けて、全体の語数を出す。

精度のほうは検証できていないが、他の方法で調べた数字に比べると、10%程度の差がでている。大づかみの数は出せそうな感触がある。工夫のしかたとしては、(1)で固定する画面を、文字を大きくした方が精度が高いか、小さくした方が良いのか。(2)の画面内の文字数の数え方などがある。まだまだ試行が必要である。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。