この記事は、@astronaughtsさん企画の「Titanium Advent Calendar 2011」向けに書いています。
@astronaughtsさんは、この企画もそうですけど、それ以外にも関西で最大規模のTitaniumイベントTi.Developers.meetingの主催者でもあります。最初はどうしようかと思うくらいしょぼかったｗ Ti.Devs.me、諦めずに開催を繰り返して大きなイベントに育て上げた@astronaughtsに、個人的今年のTitaniumMVPを送りたいです。

さて、そんなわけでTitaniumの話題を一つ。Titaniumでは、アプリ内でブラウザが開くwebViewという仕組みを使うことができます。
これを使うと、アプリ内でWEBページを見てもらうことができるので、Titanium以外でもよく使われている仕組みです。これ、意外と怖いということはご存知ですか？

このアプリの最後に、ちょっとスパイスをかけてみます。

上野駅が蒲田駅に変わってしまいました。これで、モバイラーズオアシスの中の人は、「蒲田駅を検索したら違う位置が表示された」という謎のバグ報告に悩まされることになります。クックック。永久に悩み続けるがいい...

ご自分のアプリのWebViewに上記を仕掛けるとか、絶対やめてください。やめろってば！
冗談はさておき、技術的にこういうことが可能であることは頭においておく必要があります。今回は上野が蒲田になる程度ですみましたが、ニュースサイトの内容を書き換えられたら？ログインしたときにユーザー名とパスワードを他のサイトに送信する仕組みが入っていたら？
webViewとブラウザを同一視していると、あっと驚く手品に巻き込まれてしまうかもしれません・・・

逆に、この手法をうまく使えば、スマートフォンに最適化されていないHTMLに別のCSSを適用して要素を大きく表示させたり、サイドバーを隠してスマートフォン向けのページに見せるようなこともできるかも。
...できるかもしれないのですけど、実際は結構大変です。この記事を書くために色々試したのですけど、evalJSしたJSコードをデバッグする手段が無いので、泣きそうでした。
ちょっと複雑なJSを書くと、なぜか処理が行われなくて途方にくれます。いい思いつきだと思ったんだけどなぁ。

【おわりに】

明日は@rakiさんかな。よろしくおねがいします〜。

ブログやWEBサイトに地図を表示することが出来て大変便利なGoogleMapsAPIに関して、Googleが有料化を発表したのでビックリしました。

　Googleは、Google Maps APIの利用規約を今年4月に改定し、10月1日から同APIの利用上限を定めることを発表していた。
　現時点で利用上限を超過しても、即座に課金されることはない。利用者には、APIの利用状況を確認する期間が与えられる。その上で、利用上限を超えている場合には「2012年初めごろ」から強制的に課金されるとしている。その場合は、最低30日前に通知されるとしている。
(Google Maps API有料化の詳細発表、該当ユーザーは2012年初めに強制課金開始 -INTERNET Watch)

今一番知りたいことは「どれくらい使ったら課金されるようになるのか」だと思うのですが、自分が調べた範囲では、あまり気にしなくてよさそうです。根拠はこれだ！

(FAQ - Google Maps API Family - Google Code)

Styled Maps というのは最近出来た機能で、GoogleMapsから線路を消したり海の色を変えたりといったデザイン変更が出来る機能です。こちらを使っている場合はちょっと厳しいのですけど、そうでない場合は 25,000 map loads / Day。1ページに大量の地図を埋め込むことは普通ないので、つまり実質25,000 PV/Day ≒ 75万PV/月ということになります。
モバイラーズオアシスが10万PV程度なので、食べログさんとか、大手不動産業者さんレベルにならない限りは課金されないんじゃないかと。30min.さんあたりが微妙なラインかなぁ。

さらに上記ページを見ると、越えた場合の課金金額も書かれています。

(FAQ - Google Maps API Family - Google Code)

25,000を越えたあと、1,000usageごとに4$だそうです。例えば100万PV/月のサイトがあったとすると、約3万3千アクセス/Dayなので超過部分が8300usage＝$32。$960/月なので、76,800円/月ということになりますね。
ちなみに、Google Maps API Premier、お値段を公開している代理店を見つけました。85万円/年~だそうです。
GOGA - Google Maps API

回数は、APIライブラリの読込回数です。
ANN:Google Maps APIへの使用制限の導入について - Google-Maps-API-Japan | Google グループ

モジュールを使う

tryden/TiAdMaker - GitHub

titanium.xcconfigを開くと、TitaniumSDKのバージョンが定義されているので、これを自分の好みのものに書き換えます。1.6.1はちょっと微妙ですね。

で、build.pyを走らせるとモジュールが出来上がります。

出来上がったモジュールを解凍して、新しいプロジェクトにこんな感じで配置。

example/app.jsにサンプルがあるので、まずはこれを動かしてみるのがいいんじゃないかと思います。

AD_URL、SITE_ID、ZONE_IDはAdMakerでメディアを作るともらえます。

というわけで起動してみるとこんな感じ。

めでたしめでたし。

webviewを使う方法

　ちなみに、AdMakerの公式サイトでは、こんなふうに案内されています。

TitaniumへSDKを実装できません。どうすればいいですか？
SDKでの対応はしておりません。
Web Viewを作って頂き、そこにJavaScriptタグを実装して頂くことで表示して頂くことも可能です。
(よくあるご質問｜スマートフォン広告なら「mediba ad」｜iPhone、Androidアプリ・サイト広告)

JavaScriptと空っぽのbodyタグを書いたHTMLを用意してwebviewで開いたところ、広告はちゃんと表示されたのですけど、クリックしたあとの広告もwebviewの中で開いて、どうしてくれようかという感じになりました(当たり前ですね)。
webviewのイベントをハンドリングしてあれこれという手も考えられるのですが、あんまりやると広告に手を入れているように見えてしまうことが懸念されます。モジュールが動くのだったら、そのほうがいいんじゃないかな、と思います。

P.S: Android用はこちら。
titanium の AdMaker モジュール作ってみました(Android用) #titaniumjp - harukazepcの日記

Twitterのつぶやきを見ていたら、わりと常識に縛られないタイプの方なのに、「新人研修で覚えてもらうのはホウレンソウとプログラミングくらいかなぁ」的なことを言われていて。そういえばホウレンソウって必須でもなんでもないことは意外と知られていないなぁ、と思ったので書いてみる。

ホウレンソウに頼ったAくんの仕事の進め方

• 9:00 業務開始。朝Mtgで、その日やることをみんなの前で発表。ぼく早くプログラム書き始めたいんだけどな...
• 9:30頃 昨日の進捗報告に上司からツッコミが。詳細な説明を書いて返信する。
• 10:00頃 ようやくプログラムを書き始める。
• 12:00 お昼休み。
• 13:00 再びプログラムを書き始める。
• 14:00 今朝のメールに上司は納得しなかったらしく、呼び出された。状況を説明してようやく納得してもらう
• 15:00 えーと。何してたんだっけ。あれ。このあと進捗会議か。
• 15:00 さっき上司に説明したばっかりの状況をもう一回みんなに報告。みんな興味ないから聞いてないんだけどね。
• 18:00 延々と関係のない人たちの状況を聞かされて、ようやく終了。晩御飯食べに行きますか。
• 19:00 定時後はプログラミングの時間だ！
• 22:30 今日の進捗をメールに書いてMLに投げる。メールボックスに届いている他のメンバーからの進捗報告は、興味が無いのでまとめてゴミ箱へ。

ホウレンソウに頼らないBくんの仕事の進め方

• 9:00 業務開始。昨日思いついたアルゴリズムを猛然と書きはじめる。
• 9:30頃 マネージャさんが後ろを通った気がしたけど、猛然とプログラムを書いていたら通りすぎていった。用事があればまた来るでしょ。
• 12:00 お昼休み。
• 13:00 再びプログラムを書き始める。
• 14:00 マネージャさんが後ろから覗いた気がしたけど、猛然とプログラムを書いていたら去っていった。用事があればまた来るでしょ。
• 15:00 一休みしていたら、マネージャさんが走ってきた。手が空くのを待っていたらしい。
  「様子はどう？」と聞かれたので、進捗を説明。納得の行かないところにはツッコミが入るけど、説明したら納得してくれた。1vs1の会話だから、所要時間は15分もあれば十分
• 15:30 再びプログラムを書き始める。
• 18:00 仕事終わり。スポーツジムによって帰ろう！

進捗の把握は誰の仕事？

• Aでは、進捗を報告するのがメンバーの責務になっています。Bでは、進捗を把握するのはマネージャさんの仕事です。だってマネージャってマネジメントする人でしょ？
• 進捗会議で全員の時間を束縛するより、1vs１を繰り返したほうが、進捗把握に係る工数は少なくなります。わかりきっているところはカットできるし、わからないところはその場で聞き返せるので、マネージャさんの理解度も高いです。
• 進捗を把握するのはマネージャさんの仕事であってメンバーの仕事ではないので、マネージャさんはメンバーの仕事を邪魔しないように、忙しくなさそうな時間を見計らって進捗を聞きに行きます。「忙しいところ悪いけど、進捗を聞かせてもらえるかな？」
  とはいえ、マネージャとメンバーは同じ目標に向かって進むチームなので、メンバーも可能な限りマネージャさんがヒアリングしやすいように協力しますけどね。
• Bの問題は、マネージャさんが異常に忙しいことです。メンバーが日報を書かなくていいのも、進捗会議に出席しなくてもいいのも、マネージャさんが進捗を聞いて回っているからこそです。
  マネージャさんは大変ですけど、メンバーより多くお給料が出ているんだから、メンバーよりたくさん働くのはとても正しい姿ですよね。

メンバーはお互いの仕事の進捗を知らなくて、マネージャさんだけが全ての進捗を把握することになるので、誰かがコケたときに他の人がカバーすることはできません。
各人の責任範囲が明確で、メンバーの役割がはっきりしている欧米型の仕事の進め方だからこそやれるやり方なのだと思います。
でも、ここで書いたのは、実際にぼくがメンバーとして働いたことのある体験談なので、これで仕事が回っている職場が実在します。というか、日本以外で働いたときはたいていこのやり方でした。

日本式に、メンバーが状況を報告したり、やばい時に自発的に動く能力を持っていることは、別に悪いことではないです。やばい時に自発的にアラーム上げてくれたら、マネージャさんは進捗を聞いてまわる頻度を下げることができるし、メンバーの報告だって下手であるよりは上手なほうが嬉しいに決まってます。
でも、そうじゃないと仕事が回らない状態が常識だと思っているとしたら、世の中そうじゃないやり方もあるんだよ、という話も知っておいていただけると嬉しいです。

関連記事

• 派遣プログラマ時代の思い出 - もぎゃろぐ
• 社内公用語を英語にすると何が起こるか - もぎゃろぐ

その際の説明用サンプルとして掲示されたTKAnimationSampleがとても素晴らしかったのでご紹介。

toru0325/TKAnimationSample - GitHub

KitchenSinkみたいに、複数のサンプルが見られるようになっています。

HelloWorld.js。静止画見ても何のことだか分からないと思いますが、HelloWorldが下から飛び出してくるサンプルです。

buttons.js。ボタンが出現するサンプル。よりかっこいいbuttons_with_scale.jsというのもあります。

赤いボールが複雑な軌跡を描いて飛び回るredbox.js。「Hint」ボタンを押すことで、どういうふうに実現されているかを見ることが出来ます。

AndroidやiPadのように画面上にポップアップを出現させるInfo_view.js。iPhoneではあまりやらないことになってますが、実現させたい人はたくさんいると思うので、そういう方はこのサンプルを参考にすると良いと思います。

ゲームやかわいいアプリケーションにアニメーションが必須なのはいうまでもないですが、情報系のアプリケーションでも、ちょっとアニメーションを利かせておくことで、 ユーザーさんの目線を誘導することが出来るのでとても役に立ちます。
APIリファレンスを見て実装してもなかなか上手く動かないのですけど、TKAnimationSampleで動いているサンプルをみて実装するのなら簡単に実装できますよね。
自分はTKAnimationSampleを見て30分くらいで、今作っているアプリにアニメーションを追加することが出来ました。
とても勉強になるので、ぜひさわってみてくださいませ。

でも例えば、ブラウザでよく見る左右の三角形、forward/backボタンはsystemButtonに存在しない。
デザイナさんと一緒にお仕事をしている人はいいのですけど、プログラマが適当に作ったアプリでは、こういうのを下手に描いたせいでデザインが素人っぽくなってしまったりする。著作権的なものには目をつぶって他のアプリからキャプチャするにしても、この程度の画像をいちいち切り出すのはめんどくさいよね。

そこで、文字コードを使ってそれらしい文字をtitleに指定してみた。

// Forward and back button for browser.
var buttonForward = Titanium.UI.createButton({
    title:String.fromCharCode(0x25b6)
});
var buttonBack = Titanium.UI.createButton({
    title:String.fromCharCode(0x25c0)
});
win.setToolbar([flexSpace,buttonBack,flexSpace,buttonStop,flexSpace,buttonReload,flexSpace,buttonForward,flexSpace]);  

お、いい感じ。もしかしてもっと色々出来るかも？

// OK. more buttons!
var buttonApple = Titanium.UI.createButton({
    title:String.fromCharCode(0xf8ff)
});
var buttonCommand = Titanium.UI.createButton({
    title:String.fromCharCode(0x2318)
});
var buttonOption = Titanium.UI.createButton({
    title:String.fromCharCode(0x2325)
});
var buttonReturn = Titanium.UI.createButton({
    title:String.fromCharCode(0x23ce)
});
var buttonForward2 = Titanium.UI.createButton({
    title:String.fromCharCode(0x25c1)
});
var buttonBack2 = Titanium.UI.createButton({
    title:String.fromCharCode(0x25b7)
});
var buttonNote1 = Titanium.UI.createButton({
    title:String.fromCharCode(9833)
});
var buttonNote2 = Titanium.UI.createButton({
    title:String.fromCharCode(9834)
});
var buttonNote3 = Titanium.UI.createButton({
    title:String.fromCharCode(9835)
});
win.setToolbar([flexSpace,buttonForward2,buttonBack2,buttonApple,buttonCommand,buttonOption,buttonReturn,buttonNote1,buttonNote2,buttonNote3,flexSpace]);  

もうソースコードは省略するけど、こういうのも出せる。

WEBの世界では、エンドユーザーが持っているフォントにその文字がある保証がなかったり、フォントによってどんな文字が出るか予想ができないということで、こういう文字を使うのはご法度ということになっていた。
iPhoneアプリをTitaniumMobileで作るのであれば、クライアントのフォントは常に同じだから、かなりの数の記号を使うことができる。
残念ながらtoolbarにはフォントを指定できないみたいなので、toolbarに出せる文字はヒラギノで出せる範囲に限られるみたいだけど、labelとか普通のボタンだったら、font指定することで、もっと変な記号も出せるかもしれない。

文字と文字コードの関係を調べるには、下記サイトか、Mac標準の「文字ビューア」を見ればOK.

• わかばマークのMacの備忘録 : Macで使うHTMLでの特殊文字 
• Mac OS X 10.6 Help: 特殊文字と記号を入力する

Androidは試してないのだけれど、原理的には同じようなことができるはず。
でもAndroidの場合、インストールされているフォントが保証されないから、機種によってボタンが見えなくなったりするリスクがあるかも。

テストアプリのソースコードは下記。もちろん、画像ファイルなんて不要です:-)