つい先ごろ、PushIt!クライアントをAIR2.6向けに作り直してる間にAIR3がリリースされましたが、まあそれはさておいて。
今までAIR1.5で作ってたアプリをAIR2.6で作り直してですよ、アプリのバージョンアップをしようとしたその時！
インストールした場所に同じ名前のアプリケーションがあります。
ってそりゃそうだよ！同じアプリだもの！
だからバージョンアップしてくれって頼んでるの！
誰が新規インストールしてくれなんていったんだよ！
う～ん。。。困ったよ。。。
2.6じゃないと使えない機能を使っちゃったよ既に・・・。どーすんべ。
2011年10月3日月曜日
【備忘録】 AIRのHTMLLoaderは画面に表示しなくても使える
AIRをFlexスタイルで開発している、、、んだけど、世の中にはJavascriptの有用なライブラリがいっぱいあって、ActionScriptにはない、からJavascriptの部分だけ使いてーよー。という場合。
Javascriptを処理させるにはHTMLLoaderにJavascript（を含むHTML）ソースを食わせると良い。
HTMLLoader君は画面表示のための機能がいろいろあったりする（HTMLLoaderはDisplayObjectContainerを継承している）ので、表示しないと使えないかと思いきや、実はnewして、URLをloadさせてあげるだけでJavascriptは実行される。ナイス。
当然、AS側からコントロールできないと意味ないのでブリッジを作ってやる必要があるのだが、それもごく簡単。
AS側からJS関数を叩くなら、
var html:HTMLLoader = new HTMLLoader;
（・・・load・・・とか）
（completeイベント以降で）
html.windows.someJsFunc(x,y,z);
とかやるだけ。要はhtml.windowがJS側のグローバルスコープそのものになっている。
（ので、おなじみのgetElementByIdもAS側から呼べるぞ）
一方JS側からAS側の関数をコールバックさせたいなら、
var html:HTMLLoader = new HTMLLoader;
（・・・load・・・とか）
（domInitializeイベント以降で）
html.windows.someJsFunc = someAsFunc;
とかやっておけばよろしい。html.windowはリードオンリーではなく、オブジェクトの注入も可能だ。
JS側でsomeJsFuncを叩くと、AS側のsomeAsFuncが呼ばれる仕組み。
散々公式ドキュメント読んだんだけど、全然わからなくて泣いた。
上のを知ってからHTMLLoader.windowの説明を読むと「あ、そういうことですか」と合点が行くのだが・・・。
Javascriptを処理させるにはHTMLLoaderにJavascript（を含むHTML）ソースを食わせると良い。
HTMLLoader君は画面表示のための機能がいろいろあったりする（HTMLLoaderはDisplayObjectContainerを継承している）ので、表示しないと使えないかと思いきや、実はnewして、URLをloadさせてあげるだけでJavascriptは実行される。ナイス。
当然、AS側からコントロールできないと意味ないのでブリッジを作ってやる必要があるのだが、それもごく簡単。
AS側からJS関数を叩くなら、
var html:HTMLLoader = new HTMLLoader;
（・・・load・・・とか）
（completeイベント以降で）
html.windows.someJsFunc(x,y,z);
とかやるだけ。要はhtml.windowがJS側のグローバルスコープそのものになっている。
（ので、おなじみのgetElementByIdもAS側から呼べるぞ）
一方JS側からAS側の関数をコールバックさせたいなら、
var html:HTMLLoader = new HTMLLoader;
（・・・load・・・とか）
（domInitializeイベント以降で）
html.windows.someJsFunc = someAsFunc;
とかやっておけばよろしい。html.windowはリードオンリーではなく、オブジェクトの注入も可能だ。
JS側でsomeJsFuncを叩くと、AS側のsomeAsFuncが呼ばれる仕組み。
散々公式ドキュメント読んだんだけど、全然わからなくて泣いた。
上のを知ってからHTMLLoader.windowの説明を読むと「あ、そういうことですか」と合点が行くのだが・・・。
【備忘録】 AIR1.xから2.xへの切替
AIR1.xで作っていたアプリを2.x対応にするために、アプリケーション記述ファイルを書き換えて再コンパイル・・・するだけだとコンパイルエラーになる。
難しいことは良く分からないのだが、テーマとかいうのがHaloからSparkになったからなんだって！
今までmxmlファイルで「mx:ほにゃらら」としていたところを「s:ほにゃらら」にしなきゃいけなくって大変だ、というものぐささん（ていうか自分）の場合は、Haloを使い続けることもできる。
そういうものぐさ野郎はここを見て2.xでHaloを使い続けられるようにすべし。
難しいことは良く分からないのだが、テーマとかいうのがHaloからSparkになったからなんだって！
今までmxmlファイルで「mx:ほにゃらら」としていたところを「s:ほにゃらら」にしなきゃいけなくって大変だ、というものぐささん（ていうか自分）の場合は、Haloを使い続けることもできる。
そういうものぐさ野郎はここを見て2.xでHaloを使い続けられるようにすべし。
2011年9月22日木曜日
FlashDevelop
一個前のエントリでさらっと書いたけど、現在AIRアプリの開発環境としてはFlashDevelopを使ってます。
これがとても優秀です。
私が今まで使ってきた開発環境は、
1～3はどれもEclipseなんですが、重いんですよね（あくまで私の環境では、ですが）。
さらに2,3は今時の開発環境としてはチープで、コーディング以外はほとんどコマンドラインでやってました。
で、今使ってるFlashDevelopなんですが、
Push It!クライアントはGUIはそんなに必要ないんで、上の３つがあるだけで満足。いや、大満足。
もっと早く使っとくべきだった～。
Eclipseベースで重いことを除けばAIR GEARも期待してたんですけど（GUIビルダーも付いてるしね）、開発が止まっちゃってるみたいで、残念。
これがとても優秀です。
私が今まで使ってきた開発環境は、
- FlexBuilder（現FlashBuilder）のトライアル試用⇒Eclipseベース
- 素のEclipse＋Flex/AIR SDK（コマンドラインツール）
- Eclipse＋AIR GEAR（コード補完用として）
- FlashDevelop
1～3はどれもEclipseなんですが、重いんですよね（あくまで私の環境では、ですが）。
さらに2,3は今時の開発環境としてはチープで、コーディング以外はほとんどコマンドラインでやってました。
で、今使ってるFlashDevelopなんですが、
- 軽いです。Windowsネイティブなんで。
- コード補完効きます。
- デバッガもGUIから使えます。
ブレークポイントの設定とかコマンドラインでやると泣くんで、激助かる。 - GUIビルダー的なものはないです。
Push It!クライアントはGUIはそんなに必要ないんで、上の３つがあるだけで満足。いや、大満足。
もっと早く使っとくべきだった～。
Eclipseベースで重いことを除けばAIR GEARも期待してたんですけど（GUIビルダーも付いてるしね）、開発が止まっちゃってるみたいで、残念。
Channel APIがAIRで使えて、GAEがプレビュー卒業で
なんかもうわけわかんないタイトルですいませんね。ほんとに困ったことになったわけですよ。
前回のエントリ「GAEがプレビューを卒業します」で、Instance Hourがきつくて、無料枠が実質的に狭くなった（かなりね）ことを書いたわけなんですが、
Push It!において、ほとんどの処理って、ポーリングなんですよ。１クライアントあたり10秒間隔の。
で、こいつをなんとかやっつければ、Instance１個でもなんとかやってけるだろうと踏んでるわけです。
じゃ、どうやって、となるわけですが、ポーリング間隔を長くするのがしょぼいけど一番簡単。でも相手に届くまで時間がかかるのは嫌だ。Channel APIが使えりゃいいのになあ～。
でも、以前のエントリ「AIRでChannel APIを使う・・・続編」 で書いた通り、Adobe AIRでGAEのChannel APIが使えなかったわけですよ。
そんなことを嘆いていたところ、世界のどこかの気の効く人がこんな報告をGoogleに上げてくれてまして、9/1に修正されたっぽいです。修正されないだろうなと諦めてたんですけどね。やった！
で、遅まきながら最近試してみたところ、
あれ？以前と変わらず使えないけど・・・。
と相成りました。
困ったね～なんて思って、成功事例を探していたところ、またまたGAEのIssueTrackerですよ、あなた。
「Document that Channel API only support Air >= 2.6」というタイトルのIssueで、英語読解力のない私なので本文は読んでませんが、タイトルからして、AIR2.6以上でないとChannel APIは使えない模様。
調べてみると自分の開発環境はAIR2.0SDK。きた（なにが？）
早速2.6に入れ替えてみようと思ったけど開発環境として使ってるFlashDevelopでの入れ替え方が良く分からないのでやっぱりこれも検索してこのページを発見。いや、親切な人っているもんだね。日本もまだ捨てたもんじゃないよ。
さあやってみよー、キターッ！
AIRにてChannel API使えました！ステキ。
「AIRでChannel API使えねー（そんなタイトルだったっけ？）」の記事にリンクはってくれた「この人」もきっと喜んでいるだろう。
ということで、AIRでChannel API使えるようになったんで、これでポーリングやめてChannelに乗り換えだ！とか思った人！甘い！俺だけど！
ここで、GAEの新料金プランをもう一度おさらいだ。
Channel APIのとこ良く見て。
100 channels opened
と書いてあるから。ちなみにこれ、１日あたりね。
Channelはクライアント毎（ユーザ毎じゃないよ。ブラウザのタブ一枚毎とかそういうこと）に張る必要があります。そして１つのChannelの寿命は2Hです。
24時間PCをあげっぱでPush It!使ってる人はいなさそうなんで、仮に１クライアントあたり8H/日つないでたとして、そのクライアントは最低４回Channelを張ることになる。
すなわち100÷4で25クライアントが無料でサポートできる限界だ。
席を離れる度にスリープにしてるようなまじめな人とか、劣悪な無線LAN環境だとその度にChannelが切れるので、真の限界はさらに低い。
待て待て、本当か・・・？
サービスとして成り立ちませんけど。まあ、無料で使わせてもらってるんで文句言えないんですけど。でも今までは「8,640 Channel Create/Day」だったのにいきなり制限きつくないかと思うんですけど。
大した額じゃないんだから課金すればいいんじゃ？ってそれ趣味でやってる家族持ちには禁句だから。
困ったことだよ・・・。
前回のエントリ「GAEがプレビューを卒業します」で、Instance Hourがきつくて、無料枠が実質的に狭くなった（かなりね）ことを書いたわけなんですが、
Push It!において、ほとんどの処理って、ポーリングなんですよ。１クライアントあたり10秒間隔の。
で、こいつをなんとかやっつければ、Instance１個でもなんとかやってけるだろうと踏んでるわけです。
じゃ、どうやって、となるわけですが、ポーリング間隔を長くするのがしょぼいけど一番簡単。でも相手に届くまで時間がかかるのは嫌だ。Channel APIが使えりゃいいのになあ～。
でも、以前のエントリ「AIRでChannel APIを使う・・・続編」 で書いた通り、Adobe AIRでGAEのChannel APIが使えなかったわけですよ。
そんなことを嘆いていたところ、世界のどこかの気の効く人がこんな報告をGoogleに上げてくれてまして、9/1に修正されたっぽいです。修正されないだろうなと諦めてたんですけどね。やった！
で、遅まきながら最近試してみたところ、
あれ？以前と変わらず使えないけど・・・。
と相成りました。
困ったね～なんて思って、成功事例を探していたところ、またまたGAEのIssueTrackerですよ、あなた。
「Document that Channel API only support Air >= 2.6」というタイトルのIssueで、英語読解力のない私なので本文は読んでませんが、タイトルからして、AIR2.6以上でないとChannel APIは使えない模様。
調べてみると自分の開発環境はAIR2.0SDK。きた（なにが？）
早速2.6に入れ替えてみようと思ったけど開発環境として使ってるFlashDevelopでの入れ替え方が良く分からないのでやっぱりこれも検索してこのページを発見。いや、親切な人っているもんだね。日本もまだ捨てたもんじゃないよ。
さあやってみよー、キターッ！
AIRにてChannel API使えました！ステキ。
「AIRでChannel API使えねー（そんなタイトルだったっけ？）」の記事にリンクはってくれた「この人」もきっと喜んでいるだろう。
ということで、AIRでChannel API使えるようになったんで、これでポーリングやめてChannelに乗り換えだ！とか思った人！甘い！俺だけど！
ここで、GAEの新料金プランをもう一度おさらいだ。
Channel APIのとこ良く見て。
100 channels opened
と書いてあるから。ちなみにこれ、１日あたりね。
Channelはクライアント毎（ユーザ毎じゃないよ。ブラウザのタブ一枚毎とかそういうこと）に張る必要があります。そして１つのChannelの寿命は2Hです。
24時間PCをあげっぱでPush It!使ってる人はいなさそうなんで、仮に１クライアントあたり8H/日つないでたとして、そのクライアントは最低４回Channelを張ることになる。
すなわち100÷4で25クライアントが無料でサポートできる限界だ。
席を離れる度にスリープにしてるようなまじめな人とか、劣悪な無線LAN環境だとその度にChannelが切れるので、真の限界はさらに低い。
待て待て、本当か・・・？
サービスとして成り立ちませんけど。まあ、無料で使わせてもらってるんで文句言えないんですけど。でも今までは「8,640 Channel Create/Day」だったのにいきなり制限きつくないかと思うんですけど。
大した額じゃないんだから課金すればいいんじゃ？ってそれ趣味でやってる家族持ちには禁句だから。
困ったことだよ・・・。
2011年9月17日土曜日
GAEがプレビューを卒業します
もうだいぶ前からアナウンスされてるんですが、GAEがプレビューを卒業します。11月に。
で、その際に価格体系が変わります。（この辺）
これまでも無償の範囲、有償の範囲はあったんですが、今回の価格改定は、無償利用を相当制限しそうです。ちなみにPush It!は無償の範囲で今のところはなんとかやってます。
さて問題は、Instance Hourです。
Instanceって、まあ、アプリケーションサーバ１個ってことなんですが、これが１日あたり24時間までが無料。それを超えると有料です。
インスタンスはアクセス量に応じて増減しますが、Push It!の場合、基本的にアクセスされ続けているので、最低１つは必ず存在しています。これで24Instance Hour。
アクセスが一瞬でも集中すると、インスタンスが自動で追加されて、めでたく有料となりました。
まじか〜。
Admin Consoleってところで、自分のアプリがプレビューを卒業した後はいくら課金されるかが見れるんですが、毎日60Instance Hourは使ってる感じ。ほぼ2Instanceが常に存在して、忙しいときは3個いるくらいの感じでしょうか。
え〜、これを１個に抑えるんですか〜？
ていうか、１個しか使わないっていう設定にできるんでしょうか〜？
Push It!はですね、CPU時間で言うと、Push It!は0.3H/日しか働いてないんです。
GAE/Pythonだと1Instanceは一度に1リクエストしかさばけないので、同時にリクエストを受けると、インスタンスが１個だと、後着のリクエストは先着が終わるまで待たされることになるわけですけど、まあ、確率的には低いはず。
ブラウザからだと若干引っかかりを感じるかも知れないが、Push It!クライアントはそもそもバックグラウンドで勝手に通信してるから気にもならないだろう。
てことで、１個しか使わない設定にできるんですよね？＞Google様
勝手にインスタンスを増やしたあげくに、24Instance Hourを10時間くらいで使い切って、課金設定をしてないから残り14時間は使用できません、とかほんとやめてよね。
うむ、しかし困ったのぅ・・・。
で、その際に価格体系が変わります。（この辺）
これまでも無償の範囲、有償の範囲はあったんですが、今回の価格改定は、無償利用を相当制限しそうです。ちなみにPush It!は無償の範囲で今のところはなんとかやってます。
さて問題は、Instance Hourです。
Instanceって、まあ、アプリケーションサーバ１個ってことなんですが、これが１日あたり24時間までが無料。それを超えると有料です。
インスタンスはアクセス量に応じて増減しますが、Push It!の場合、基本的にアクセスされ続けているので、最低１つは必ず存在しています。これで24Instance Hour。
アクセスが一瞬でも集中すると、インスタンスが自動で追加されて、めでたく有料となりました。
まじか〜。
Admin Consoleってところで、自分のアプリがプレビューを卒業した後はいくら課金されるかが見れるんですが、毎日60Instance Hourは使ってる感じ。ほぼ2Instanceが常に存在して、忙しいときは3個いるくらいの感じでしょうか。
え〜、これを１個に抑えるんですか〜？
ていうか、１個しか使わないっていう設定にできるんでしょうか〜？
Push It!はですね、CPU時間で言うと、Push It!は0.3H/日しか働いてないんです。
GAE/Pythonだと1Instanceは一度に1リクエストしかさばけないので、同時にリクエストを受けると、インスタンスが１個だと、後着のリクエストは先着が終わるまで待たされることになるわけですけど、まあ、確率的には低いはず。
ブラウザからだと若干引っかかりを感じるかも知れないが、Push It!クライアントはそもそもバックグラウンドで勝手に通信してるから気にもならないだろう。
てことで、１個しか使わない設定にできるんですよね？＞Google様
勝手にインスタンスを増やしたあげくに、24Instance Hourを10時間くらいで使い切って、課金設定をしてないから残り14時間は使用できません、とかほんとやめてよね。
うむ、しかし困ったのぅ・・・。
2011年5月17日火曜日
話題を３件ほど
話題１．前回エントリのGAEのChannel APIがAIRで使えない件ですが、外国のどなたかがIssue Trackerにあげてくれてました。めでたし・・・なわけない。正直、使用者数から考えて優先度は低だろうな。だいたい、GoogleのWebAPIで、AIRだのActionScriptだの見たことないし。
話題２．GAEのSDKが、1.5.0になりました。大きく変わってるんですが、Quotaがまた変わりました。回数系の制限が取っ払われて、リソース使用量（帯域とかデータ容量、CPU使用時間など）のみになりました。APIを呼びまくってでも、いかにリソースを食わないプログラムを書くか、腕の見せ所です（前向きに捉えれば）。
話題３．すっげー久々にPush It!をバージョンアップしました。といってもサーバ側。でも有用だと思うのでぜひご活用を。
話題２．GAEのSDKが、1.5.0になりました。大きく変わってるんですが、Quotaがまた変わりました。回数系の制限が取っ払われて、リソース使用量（帯域とかデータ容量、CPU使用時間など）のみになりました。APIを呼びまくってでも、いかにリソースを食わないプログラムを書くか、腕の見せ所です（前向きに捉えれば）。
話題３．すっげー久々にPush It!をバージョンアップしました。といってもサーバ側。でも有用だと思うのでぜひご活用を。
- ニックネームを登録できるようにした。
→タグを共有/公開する際に、Googleアカウント（という名のメールアドレス）をさらさずに良くなりました。 - メールで付箋紙が登録できるようになった。
→出先などでふと思い立ったらその場でPush It!にメール！
登録:
投稿 (Atom)