琴線探査

先日、SafariとOperaのファイル保存問題を解決する糸口を見つけた。 琴線探査: 「Downloadify」Safari・Operaのファイル保存問題解決の糸口 一言で言ってしまえば、FlashのExternalInterfaceを使ってJavaScript内のデータをFlashに送り込み、Flashのファイルダイアログで保存できないか？という話。 結論から言うと、すぐに頓挫した。試したのはこんなコード。 package { import flash.display.Sprite; import flash.external.ExternalInterface; import flash.net.FileReference; public class FileSaver extends Sprite { public function FileSaver() { ExternalInterface.addCallback("toSWF", toSWF); } public function toSWF(text:String):void { try { var fr:FileReference = new FileReference(); fr.save(text, "ファイル.txt"); } catch (err:Error) { ExternalInterface.call("alert", err.toString()); } } } } 確かにブラウザからFlashにデータを送り込むことはできた。しかし、ブラウザ側（JavaScript）からtoSWF()を呼ぶと、保存しようとしたところでエラーになる。 一体、このエラーコード「#2176」とは何か？ ランタイムエラー - Adobe ActionScript® 3（AS3 ）API リファレンス 2176 ポップアップウィンドウを表示するアクションなどの特定のアクションは、マウスをクリックしたりボタンを押したりするユーザー操作によってのみ...

昨日、こんな記事を書いた。 琴線探査: HTML5のクライアントサイドで作ったデータをサーバーを介さずにファイル保存できるか？ この記事の中で、FileSaver.jsの評価をしていた。 確かに現在のところオンラインデモでは元の通りの評価だが、最新のライブラリを使って実際に自分でデモ作ってみると、結果は以下のようになった。 eligrey/FileSaver.js · GitHub デモ： FileSaver.js demo HTML5 Image File Save Example Safari：新しいタブを開いてデータを表示。保存ダイアログは出ない。（ボップアップブロック解除時） Chrome：サクッとダウンロードして、ファイル名も完璧 Firefox：保存ダイアログが表示され、ファイル名も完璧 Opera：新しいタブを開いてデータを表示。保存ダイアログは出ない。（ボップアップがブロックされたとの通知をクリック） IE10：保存ダイアログが表示され、ファイル名も完璧 つまり、SafariとOperaさえ何とかすれば、かなりいける！ どうにかならないか？とさらに調べていると、このようなライブラリを見つけた。 dcneiner/Downloadify · GitHub このライブラリはFlashを使うことで保存ダイアログの表示を実現している。 その仕組みは、 ・External Interfaceを使って ・HTMLからFlashにbase64データを流し込む ・Flashでbase64をデコードする ・Flashの保存ダイアログでデコードしたバイナリを保存する というもの。 そうか！その手があったか！Flashを使うのでiOSのブラウザは犠牲になってしまうけれど、デスクトップのSafariとOperaは救える！ しかし、実際に使おうとよく見ていくと、ダウンロードボタンをFlashで作っているので通常のHTMLのボタンなどに保存処理を関連付けることができない＿|￣|○ う～ん、何とかならんもんかのぉ。。。 External InterfaceはHTMLからもFlashからも双方向にメソッドを呼んだりデータを受け渡したりできるはず。 ExternalInterface - Acti...

画像の一部にモザイクをかけてGIFアニメにする - 音の鳴るブログ … 全部ブラウザでやっている。 CanvasからGIFアニメを作るライブラリ があって、試してみたら結構重かったので、インターフェイスはそのままでWebWorkerで処理するように改造したやつ を使っている。 ブラウザだけでアニGIFを作れるようになったんだなー、素晴らしいなーと思って、それを実現するライブラリがどんなものなのかをチェックしたらas3gif（GIFPlayer）のJSポートだった。 antimatter15/jsgif · GitHub 筆者の方は「処理が重い」とおっしゃっている。実際に試してみたところ、確かに重い(^^); as3gifは前にAS3で使ったことがあるライブラリなのだけど、その処理の重さはAS3でも同じだった。 検証の結果、その処理の遅さの大きな原因は、減色アルゴリズムの org.bytearray.gif.encoder.NeuQuant.as にあると分かった。どうもNeuQuantは色の再現性は高いのだけど処理が重いようだった。 そこで、色の再現性は多少犠牲にして速度優先で・・・とmediancutやoctreeのアルゴリズムを試したらかなり速くなったことを覚えている。特にmediancutは単純なだけに高速で、色の再現性もそれほど悪くはなかった。 ブラウザだけでアニGIFのエンコードができるのは画期的だと思うので、そのうちmediancutをJSに移植してみたい。 やる気が出たら(^^); 数値計算部分に最近話題のasm.jsを使ったらさらに速くなるかも？ Firefox22が「asm.js」採用へ、JavaScriptがネイティブアプリに近い実行速度まで高速化 - GIGAZINE

先ほどFP10レベルだと画像のサイズ制限があることを書いた。 琴線探査: Flash Player 10レベルで1辺2880ピクセル以上の画面キャプチャーを撮るには？ しかし、この制限を受けるのは画像だけではなかった。BitmapFilter系にも関係するということを思い出した・・・ 問題が出ると、このような警告がコンソールに表示される。 警告 : Filter はレンダリングされません。描画するには DisplayObject のフィルターサイズ (4109, 4109) が大きすぎます。 4,109 * 4,109 = 16,883,881 確かに、FP10の最大ピクセル数16,777,215を僅かにオーバーする(^^); なら正方形だとどこまで大きくできるのか？ 16,777,215のルートを取ればいい。つまり4,095だ。これなら、 4,095 * 4,095 = 16,769,025 なのでオーバーしない。 BitmapFilter系にはBevelFilter, BlurFilter, ColorMatrixFilter, ConvolutionFilter, DisplacementMapFilter, DropShadowFilter, GlowFilter, GradientBevelFilter, GradientGlowFilter, ShaderFilterがある。 BitmapFilter - ActionScript 3.0 言語およびコンポーネントリファレンス 影響デカイ。早いとこFP11レベルに上げないと、これ以上のスペックアップはもう無理ポ。

Flexで画面のキャプチャーを撮るにはこうするだろう。大抵はこれで上手くいく。 var bmpSrc:BitmapData = ImageSnapshot.captureBitmapData(this, null, null, null, null, true); しかし、1辺が2880ピクセルを超えるキャプチャーを取ろうとすると、なぜか2880ピクセルに縮小されてしまう。 原因は間違いなく、ImageSnapshotだ。ソースをみると、こんなコードがあるんだ・・・ ・・・ public static const MAX_BITMAP_DIMENSION:int = 2880; ・・・ // Cap width to BitmapData max of 2880 pixels if (scaledWidth > MAX_BITMAP_DIMENSION) { reductionScale = scaledWidth / MAX_BITMAP_DIMENSION; scaledWidth = MAX_BITMAP_DIMENSION; scaledHeight = scaledHeight / reductionScale; matrix.a = scaledWidth / width; matrix.d = scaledHeight / height; } ・・・ それなら、ImageSnapshotをextendsしてオーバーライドするか・・・と思ってこうしてみた。 public override static const MAX_BITMAP_DIMENSION:int = 8191; しかし、コンパイルが通らない。そういえば、「AS3では、staticメソッドを継承することもオーバーライドすることも出来ません。」だった＿|￣|○ AS3では、staticメソッドを継承することもオーバーライドすることも出来ません。 - hirossy javaとFlex2と。 こりゃダメかな・・・と思ったが、extendsするのではなく、このように新しいクラスを作って必要なメソッドを移植して定数の部分に適当な値を与えてやると、とりあえず1辺が2880を超える画像をキャプチャーできるようにはなった。 ...

AS3のYouTubeアプリでセキュリティエラーが出始めたら、このようにドメインのポリシーファイルをロードしてみよう Security.loadPolicyFile("http://lh3.googleusercontent.com/crossdomain.xml"); Security.loadPolicyFile("http://lh4.googleusercontent.com/crossdomain.xml"); Security.loadPolicyFile("http://lh5.googleusercontent.com/crossdomain.xml"); Security.loadPolicyFile("http://lh6.googleusercontent.com/crossdomain.xml"); 作者の情報のロードをする時になぜかエラーが出る。Google+とYouTubeの作者プロフィールの統合による影響だと思われる。 問題はこれだけロードすれば十分かどうかだけど、分からない。lh1,lh2は無し。lh7-lh10も無かった。それ以上は調べていない。 Google+のおかげで面倒なことになったもんだ(^^); ちなみに、これまでに読み込んでいる他のポリシーファイル。 Security.loadPolicyFile("http://i.ytimg.com/crossdomain.xml"); Security.loadPolicyFile("http://i1.ytimg.com/crossdomain.xml"); Security.loadPolicyFile("http://i2.ytimg.com/crossdomain.xml"); Security.loadPolicyFile("http://i3.ytimg.com/crossdomain.xml"); Security.loadPolicyFile("http://i4.ytimg.com/crossdomain.xml"); Security.loadPolicyFile...

Flash Playre 11.4 と Adobe AIR 3.4 ベータ版公開 - akihiro kamijo ・・・Camera.copyToByteArray/Camera.copyToVector Camera のビデオフレームのピクセルデータを、Video オブジェクト経由で BitmapData 化することなく、ByteArray や Vector にコピーできる・・・ なるほど。Flash Player 11.4ベータ版でCameraのフレームを直接ByteArrayにできるようになったらしい。 以前こんなことを調べていた。 琴線探査: FlashでWEBカメラを使ってビデオ録画、音声録音はできるのか？ この時は結局断念した。 しかし、今回のベータのFPでついに映像の部分では可能になったようだ。歓迎すべきことだ。 けど遅い。遅すぎる。これやりたかったの2009年の話だから。

Android向けFlashの提供を一切停止へ　既存端末のサポートのみ | ガジェット速報 ・・・Android 4.1（Jelly Bean）向けにFlash Playerを対応させないことに加えて、8月15日以降はAndroid 4.0系以下の端末に対しても新規ダウンロード＆インストールが出来ないようにすると発表・・・アドビは、Android 4.1にアップグレードする前にFlash Playerを削除することを推奨しています・・・ まじかよ(*´Ð”｀) ということで、アドビの発表。 An Update on Flash Player and Android « Adobe AIR and Adobe Flash Player Team Blog ・・・There will be no certified implementations of Flash Player for Android 4.1・・・August 15th we will use the configuration settings in the Google Play Store to limit continued access to Flash Player updates to only those devices that have Flash Player already installed. Devices that do not have Flash Player already installed ・・・ will no longer be able to install it from the Google Play Store after August 15th.・・・We recommend uninstalling Flash Player on devices which have been upgraded to Android 4.1.・・・ いや。まじだね。 何と幕引きの速いこと。モバイルFPの開発、本当にサジを投げたんだな。 もう、とっととAndroidのFlash Playerを世の中から消し去りたいとしか思えない。 きっとHTML5関連に開発リソースを集中させるためなんだろうなと思われ。 もうWEBでFlashを使う...

Windows 8 の Metro スタイル IE10 と Flash Player に関する記事 - akihiro kamijo ・・・ デスクトップ環境の　IE10 は、どのサイトの Flash コンテンツも再生できるが、Metro スタイルの IE では、互換表示一覧 （CV リスト） 上のサイトの Flash コンテンツのみを再生する 最適なユーザ体験を提供する Flash コンテンツのサイトであれば CV リストに追加する タッチによる操作性 オンスクリーンキーボードとの相性 バッテリー消費への影響 Metro スタイルガイドラインへの準拠 Metro スタイルで提供されない機能 （ロールオーバー、P2P等） に依存するサイトはデスクトップ環境の Flash を使用すべき Metro スタイルでは HTML5 コンテンツを表示する、ユーザにサイトをデスクトップ環境で表示するように促す、という対応が可能 ・・・ まず、よりハッキリしたことは、Metro版IEでは互換表示一覧（CVリスト）に載る選ばれたFlashコンテンツしか表示できないということ。これは「Metro版IEはFlashに対応している」とは言い難い。 もう一つ分かったことは、もしCVリストに載りたければ、タッチインターフェース・モバイルを考慮して作り直さなければならないだろうということ。 これからはFlashもタッチインターフェース・モバイルを初めから意識して作らなければならないということか。 ていうか、そこまでしてFlashで作り続けるのかどうか・・・それが問題だ。 やっぱり、もし可能であるなら、HTML5でUIをリデザインするべきなんだろうな・・・

Microsoft、Windows 8 リリース・プレビュー版を公開―対応アプリも多数Windowsストアに - Tech Crunch Japan ・・・タッチスクリーンをサポートするIEのMetro版はやっとAdobe Flashプレイヤーをサポートした・・・ これまでのMetro版IEはFlashに対応していなかったので、これからFlashはさらに旗色が悪くなるのか？と思っていたけど、結局サポートされたらしい。 これは良い判断だったのかどうか・・・微妙なとこだけど、現実を考えればやっぱりこうなるかなという気もする。 Adobe的にもMetro版IEでのFlash対応を宣言しているもよう。 Flash ランタイムロードマップの更新 - akihiro kamijo ・・・「Flash Player の通常版およびデバッグ版は、Windows 8 のデスクトップと Metro スタイルを、x86/64 と ARM プラットフォームの両方でサポートする予定です」・・・CV ビューリストに無い Flash コンテンツは、Windows 8 の Metro スタイルの IE では表示されません。・・・ ただし、Metro版IEで全てのFlashコンテンツが動くという保証もなさそう。 追記12.06.05 ：よりハッキリした 琴線探査: Metro版IEで動作させるためにUIをリデザインしてまでもFlashで作り続けるかのかどうか・・・それが問題だ

環境移行Q&Aガイド：どのように購入したらいいの？ - Adobe Design Magazine ・・・2012å¹´5月には、CS6が発売になります。従来通りの単体・Suiteの製品版や、アップグレード価格ももちろん用意されていますが、CS6からは新たなSuite製品の利用方法として「Adobe® Creative Cloud™ メンバーシップ」がスタートし、クリエイティブに必要なすべての製品やサービスを月額料金で利用していただくことができるようになります。・・・月額5,000円（年間プランの場合）。さらに2012å¹´8月31日までの発売記念版ではCS3以降のいずれかの単体製品もしくはSuite製品をお持ちのお客様に、月額3,000円となる特別価格も用意されています・・・ CS6発売の発表があり、まず気になったのはFlash Builderの扱い。 調べてみると、どうやら一番高い Master Collection にのみ含まれるようだ＿|￣|○ その他には含まれていない。 グラフィックデザインソフト | Adobe Creative Suite 6 Design Standard インタラクティブデザイン | Adobe Creative Suite 6 Design Web Premium 映像編集統合ソフト | Adobe Creative Suite 6 Production Premium CS5.5 Web Premiumには含まれていたのにぃ。 では、Master Collectionを買うしか無いのか？ 「買う」のならそれしか無いだろう。もう一つの選択肢は「Creative Cloud」だ。CCにはFlash Builderが含まれているようだから。 環境移行Q&Aガイド：どのように購入したらいいの？ - Adobe Design Magazine となると、今後FBを入手するには、Master Collectionを買うか、割高なFB単品を買うか、CCに加入するか、ということになる。 となれば、もうCCに加入するしか無いだろぉ〜とまんまとAdobeの戦略に乗らざるを得なくなるわけだ。 確かに、CCに加入すれば全てのアプリが使えるようになるし、8月31日までなら初年度月額3000円にして...

Flash Player 11.3 と Adobe AIR 3.3 ベータ版の公開 - akihiro kamijo ・・・ iOS アプリの USB デバッグ ・・・ ADT コマンドから iOS シミュレータ用にアプリをパッケージ可能。実際のデバイスが無くても、iOS アプリの動作確認ができる ・・・ Mac App ストアの新要件への対応 ・・・ お？AIRでiOSアプリのUSBデバッグができるようになった？お〜。

Flash Player プレミアム機能についての補足 - akihiro kamijo ・・・次のバージョンとなる Cyril の機能が 1 つ追加されていました。 ・Mac App Store のアプリケーションサンドボックスに関する要件への対応 ということで、Cyril が予定通り公開されれば、今年の前半には AIR アプリを Mac App Store に出しやすい状況になりそうです ・・・ プレミアム機能を使ったゲームの一部を無償でティザーとして公開する場合 ・ティザーから直接収入があると （広告など） 課金対象に含まれる ・ただし、ティザーが AIR ゲームのものである場合、ゲーム自体の売り上げは課金対象にならない ・・・ AIRでMacのAppStore用のアプリを作れるようになるらしい。 しかしなぁ、今のAIR速度とメモリ食いの状況では、ユーザーからしてみれば2級市民扱いだろう。 以前TweetDeckはAIRで実装されていたけど、最近では結局「脱AIR」したことを見ても、やっぱり様々な意味でネイティブにはかなわないということを示していると思うし。 実際にAIRでiPhoneとAndroidのアプリを作ってみた経験から言っても、その結論はやはり「急がば回れ」だった。 さらに、記事の後ろの方では先日発表されたFPの有償化についての追加の話があった。 もう早速、「if 〜 なら 〜。ただし if 〜 なら 〜。」という面倒な話が出始めてきているようだ。 今のところAIRは課金対象にならないと言っても、ずっとそうである保証は無い。現にFPがそうだったように。 WebではまだFlashのプラットフォームでしかできないことが少なくない。しかし最近は、徐々にfadeoutしていかなければならないと強く感じている。

YouTube API Blog: Minimum embeds: 200px x 200px ・・・embedded players smaller than the minimum size might not support all player features, we haven’t defined what that size is・・・200px by 200px・・・This change will take effect beginning late April 2012・・・ YouTubeのエンベッドプレイヤー（Flash）の最低サイズが決まったようだ。これまでは確か、「小さすぎたらダメよ」くらいにしか言ってなかった。 「ならどのサイズよ？」と聞きたかったわけだけど、その答えは 200px x 200px と決定したそうだ。スッキリしたね。 この変更は4月下旬に行われるようだ。気をつけておかないと。

Flash Player プレミアム機能の発表 - akihiro kamijo ・・・ プレミアム機能の商用利用にはライセンスが必要になります。ただし、これは Flash Player 向けのコンテンツのみに適用され、同じ機能でも AIR アプリ （デスクトップもデバイスも） では自由に利用できます。また、売り上げが 5 万ドル以下のコンテンツは対象になりません。 ・・・ まとめると、 プレミアム機能のライセンス料が発生する条件は、以下の 3 点が揃うこと ・Stage3D とドメインメモリの両方を使用して ・Flash Playre 向けにパブリッシュして ・売り上げが 5 万ドルを超える ・・・ FPが一部有料になるというから何かと思ったら、主にブラウザで動く3Dゲームに対するものらしいので、WEB界全体としては今のところそれほど影響はなさそう。 Alchemyがドメインメモリを使っているかもしれないので一瞬焦ったけど、「Stage3D とドメインメモリの両方を使用して」という条件があるので大丈夫だろう。 しかし、プレイヤー自体に課金するなんて・・・Adobeは一体どうしちゃったんだ？ たとえ一部の機能であったとしても、FPに課金してうまくいくならビジネスとしてはもっと早くやっておくべきだったじゃないか。むしろFPはそうしないことによってうまくいってきたわけで。 これで開発者には「FPは完全無料ではない」というイメージがついてしまうだろう。そして開発者たちは徐々にFlashプラットフォームを離れて行ってしまうだろう。 今のところAIRは完全無料と言ったって、いつFP同様に有料になるかわからない。そして多くの開発者はこんなリスクは負わない。 ハッキリ言って、凶と出ると思う。

AndroidにおけるAIRアプリとネイティブアプリの最低メモリ使用量の差を調べておきたい。 感覚的にはもちろんネイティブアプリの方が少ないだろうと思うのだけど、どれだけ違うのかをハッキリさせておきたい。 今回つくるアプリは、画面にボタンを表示するだけのアプリ。最低限の機能にすることで、より最低メモリ使用量に近い値を得たいため。実機はGalaxy Tabを使った。 まずはネイティブアプリ。APKは約13Kバイト。実行画面はこんな感じ。 メモリ使用量は？ なるほど。2.86MBか。CPUの使用率もしばらく見てたけど、ずっと0%だった。 次はAIRアプリ。「Flex モバイルプロジェクト」で作成し、Captive Runtimeなしでリリースビルドした。APKは約538KBバイト。実行画面はこんな感じ。 メモリ使用量は？ 24.37MBも食っている。CPU使用率は0.33%〜0.66%を行ったり来たりして、0%になることはまれだった。何やってるんだろ？ まとめると ＜ファイルサイズ＞ AIRアプリはネイティブの約41倍（AIR：538KB - ネイティブ：13KB） ＞AIRアプリはネイティブアプリよりもファイルサイズが大きくなる傾向 ＜メモリサイズ＞ AIRアプリはネイティブの約8.5倍（AIR：24.37MB - ネイティブ：2.86MB） ＞AIRアプリはネイティブアプリよりもより多くのメモリを消費する傾向 ＜CPU使用率＞ AIRアプリはバックグラウンドでも微妙にCPUを食っている ＞AIRアプリはネイティブアプリよりもバッテリーを消費するかもしれない傾向 やっぱり感覚は正しかった。 残念ながら、AIRアプリはいわゆる「重い」と言わざるを得ない。

Flash Player の 2012 年以降のロードマップ公開 - akihiro kamijo ・・・Flash Player 11.2 ・・・iOS と　Android での Stage3D によるハードウェア描画 （AIR により実現） ・・・Flash Player 11.2 の後には "Cyril" とよばれるバージョンが予定・・・今年の前半 ・・・フルスクリーン再生時のキーボード入力 ・・・今年後半には "Dolores" ・・・ActionScript workers （同時に複数のスクリプト実行を可能にするスレッド機能） ・・・iOS 上での ActionScript パフォーマンスの改善 ・・・Flash Player "Next" ・・・Flash Player のコードのリファクタリングと現代化 ・・・AVM （ActionScript Virtual Machine） の改良 ・・・スクリプトの実行パフォーマンスを "著しく" 向上させるためのもので、2013 年以降の公開が予定 ・・・ モバイルのFlashは速度的にまだまだだけど、今年中にもある程度速くなりそうか？ ネイティブに近い機能やかなりの処理速度が必要なアプリの開発は向かないけど、ダッシュボード的な業務アプリなど、モバイルFlashが向くケースは結構あると思う。だから、モバイルFlashが速くなってくれると助かる。ハマるケースだと、開発スピードが何倍にも上がるから。 マルチスレッド化もされそうだし、AVMの根本的なテコ入れによって今後もさらに速くなってくれそうだ。そして、デバイスの性能もドンドン上がってきている。 かつてのJavaのように、もはやVMの速度が問題にならなくなるのもそう遠くないかもしれないね。

モバイルFlash（MF）の開発で使われるSparkのViewNavigatorでの画面開始・終了時の処理をどのイベントのタイミングでするべきだろうか？ 特に画面開始時の処理のタイミングが問題だ。このタイミングが適切でないと画面の遷移がスムーズに行われず、ユーザーとしては「一瞬画面が止まる」「遅い」「重い」という風に感じてしまうから。 通常のFlex開発だと画面開始時の処理は主にCREATION_COMPLETEイベントのタイミングで行なってきたので、ViewNavigatorでも同様にしてみたけれど、どうも画面遷移が重い気がする。 そこで、Viewのライフサイクルを詳しく調べることにした。このあたりはドキュメントにまとめられていた。 Adobe Flex 4.6 * モバイルアプリケーションでのビューの定義 ドキュメントのフロー図を見ると、どうやらCREATION_COMPLETEではなく、 VIEW_ACTIVATEの時点で行うのが良さそう だ。 なぜなら、CREATION_COMPLETEからVIEW_ACTIVATEまでの間には ・ActionBarの更新 ・トランジション ・元のVIEWを削除 など、様々な処理が行われることになっているから。 これだけ様々な処理が入っている時に、サーバーへのリクエストだのデータのパースだのをしていたら、それは画面遷移が重くなるわけだ。 どれだけ速くなるかはCREATION_COMPLETEイベント時の処理の重さにもよるのだろうけど、実際にやってみたら結構速くなった気がする。 画面終了時の処理はVIEW_DEACTIVATEで行うのが良さそう だ。

Flash Builder 4.6でiOSアプリの開発を試してみた。 適当なアプリを作ってデバッグしようとすると、早速つまづいた(^^); 証明書とプロビジョニングファイルの設定 ターゲットでiOSを選んだら、デスクトップ上かデバイス上かを選ぶ。デスクトップ上は何も問題なく起動できる。やはり問題はデバイス上だ。早速「パッケージ化設定がされていません」とエラーが。 そこで「設定」をクリックすると、証明書とプロビジョニングファイルが必要なようだ。 証明書は、「キーチェーンアクセス」を開く＞「ログイン」キーチェーンを開く＞「証明書」分類で表示される「iPhone Developer: xxx xxx(xxx)」という証明書を右クリックして「書き出す」＞「p12」ファイル形式を選んで保存という感じで用意する。 証明書についてはここが参考になる。 Adobe Flash Platform * P12 ファイルへの開発用証明書の変換 プロビジョニングファイルはAppleから発行してもらったXcodeでいつも使っているプロビジョニングファイルでいい。 App IDの設定 とりあえずパッケージ方法で「高速」を選んで起動させようとするとまたエラー。ちなみに、ここで「標準」を選ぶと誇張でなくホントに数分待たされることになる。 プロビジョニングファイルで指定した「App ID」にアプリの設定のどこかを一致させる必要があるらしい。 ならエラーメッセージで教えてくれよと(^^); ホントにエラーダイアログって使えたためしがない。自分も気を付けないと。 一致させるべきは、$PROJECT_HOME/src/XXX-app.xmlの次の箇所。 もしプロビジョニングに「jp.co.xxx.*」とワイルドカードで指定してたなら「jp.co.xxx.Test」など、最後は適当なアプリ名でいい。もしプロビジョニングに「jp.co.xxx.Test」と固定で指定していたなら、その通りに入力する。 IPA（アプリ）をiTunesにインストールして同期(ﾉ∀`) すると今度はこんなウインドウが出てくる。 要するに、アプリをデバッグするには、まずコンパイル済みのIPAファイルをiTunes＞ライブラリ＞Appに...

FlexでSharedObjectにデータを保存する時に、ある程度のデータサイズまでは特に問題はない。 しかし、大きなデータを保存する時には、こんな感じでユーザーに許可を求めるダイアログが自動的に表示される。 これが厄介。 例えばこんなコード。 function saveByteArray(ba:ByteArray):void { var so:SharedObject = SharedObject.getLocal("config", "/"); so.data.bytearray = ba; //ByteArrayが50MB程度と仮定 so.flush(); //この段階でユーザーにローカルストレージに保存する許可を求めるダイアログが表示される } flush()した時点でユーザーにローカルストレージに保存する許可を求めるダイアログが表示される。 ここでユーザーが「拒否」した場合は仕方ない。しかしユーザーが「許可」した場合は保存できるものと期待した。しかし、その期待はハズれた。保存されない！ ただ、絶対か？と言われるとそうでもない。調べた限りでは、FP11系ではたまに保存できるし、FP10系ではごくごくたまに保存できる。しかし、この不安定さは保存できないと言っていいと思う。 つまり、 大きなデータを保存する時に、まだユーザーの許可を得ていない状態で保存をすると保存できない ということだ。 逆に言うと、 予め許可を得ていれば保存できる ということでもある。実際、２回目にはちゃんと保存できるのだ。 そこで、 まずはflush()メソッドの引数を使ってわざと大きなデータを保存する「フリ」をする 。許可をもらったら実際に保存する。という処理をすることにした。 書いてみると、意外と('A`)ﾏﾝﾄﾞｸｾな処理だった。 function saveByteArray(ba:ByteArray):void { Alert.show("ローカルストレージへの保存許可をチェックします", "ローカルストレージ保存許可チェック", Alert.OK, null, savePermissionCheck); ...