カテゴリー別アーカイブ: 仕事

毎回そうだが、FlashBuilderはバージョンアップすると前のバージョンで作った物がすんなりインポート出来ない。 ANEを扱ってみようと思い、ついでにFlash Builder4.5から4.6へバージョンアップしてみたのだが、今回も4.5で作ったプロジェクトで問題が発生した。 毎回、更新すると、取り敢えず前バージョンで開発終了しているAIRプロジェクトで直近で重要なプロジェクトを読み込んで、チラホラと問題が出た箇所(ネームスペースの問題やsdkのパスやら何やら主にFlash Builderの問題と言われる箇所）を修正して動作確認をしているが、今回気がついたのは、mxコンポーネントの　imageコンポーネントで同じsrc以下にある画像を動的に読み込んで表示させているが、これが失敗すると言うやつ＝読み込まずにリンク切れの状態で表示される。 ViewはImageコンポーネントで View.load(“hoge.png”);　と言う単純なものだが、 これは、具体的にはサーバに画像が無い場合に代替として表示する画像なのですが、実はサーバから読み込んだイメージは同じ形で表示する。 当然、4.5では何の問題も無く、こんな単純な箇所なので全く原因が分からない。 ネットで色々調べてみたがそれらしい話も載ってない様で、例によってFXUGへ尋ねてみた。 ちなみに、ボタンに利用しているアイコン等が、@Embedを指定しないと表示しないと言う修正（デザイン画面で、Embedへチェックを入れる修正）も必要だった。 取り敢えず、代替画像を@Embedしたimageコンポーネントとサーバからの画像を表示するimageコンポーネントの二つを重ねて配置して、それぞれの表示を制御することで逃げたが、他のプロジェクトでも同様の方法で画像を使っている場所があるので、今のうちに原因か対処方法を確認したい。 4.6は、他にもエディターでカーソルが消えるという怪しい現象も発生した。 これ以外にも、データとサービスを利用している場合、ファイルをインポートすると既に実稼動サーバへデプロイ設定をしているsrc以下のservicesにあるasファイルのendpointが勝手にlocalへ変更される様だ。 やっとわかってきたが、バージョンアップした場合は、ひとまず、旧バージョンのワークスペースからプロジェクトをコピーして、そのプロジェクトをインポートし、必要なservicesのファイルを旧バージョンから新パージョンへ上書きコピーすると言う作業が必要な様だ。 でなければ、WEBルートの関係で自動的にlocalhostへ書き換えられてしまう。 余計なお世話と言う機能だし、以前も書いたが、このデプロイに関する情報が少ないので方法が良くわからないのも困る。

良くある、DateFieldコンポーネントの日付設定。 グリッドを選択した時にその行の内容やら日付やらを表示する処理を作った。 たいていはこんな感じでsplitで元のDBのフォームをバラして _val=col.rp_date.split(“-”); こんな感じで最設定する _date.selectedDate=new Date(_val[0]+”/”+_val[1]+”/”+_val[2]); しかし、ちゃんと設定される時とされない時（日付が変更されない）場合がある。 されない時と言うのは、その前にDateFieldを開いて何処かの日付を選択した後。 原因が分からずに暫くネットでそれらしい話を探したが情報がない。 あれこれやってみて偶然だが、日付を選択した後に、他のコンポーネントを触って同様の処理をやったらちゃんと設定された！ つまりDateFieldへフォーカスがある間は、プログラムでselectedDateを行なっても設定されない様なのだが、グリッドをクリックする段階で既に自身からフォーカスがグリッドへ移っているはずなのだが、そうはならない様だ。 もしかすると、グリッドのデータ選択のイベントで処理している間はFocusの移動は後回しにされている可能性がある。 この辺がシングルタスクの悲しいところだ。 そこで、試しにDateFieldの_changeHandlerイベントで、次の項目へ強制的にsetFocus()してみたら、ちゃんと設定されるようになった(-_-) う～ん。。でも、なんかこれってコンポーネントのバグなんじゃないの？？

現在開発中のAIRアプリも開発終了に近くなったので、そろそろ本格的にリモートサーバーへデプロイしようとしているが上手く行かない。 先に書いた方法で、デバッグレベルではリモートサーバでの利用が可能なのだが、リリースビルドの段階で引っ掛かる。 あれこれやってるうちに プロセスが予期せず終了しました。 invalid application descriptor: invalid application identifier なんてのが出るので、調べたら <!– A universally unique application identifier. Must be unique across all AIR applications.  Using a reverse DNS-style name as the id is recommended. (Eg. com.example.ExampleApplication.) Required. –>  <id>hoge_Application</id> のように、IDへアンダースコアを使うとエラーが出ると言う情報があった。 … 続きを読む →

DataGridなどでいずれかの行を選んで修正したり削除したりする場合、selectionChangeイベントを利用するが、処理をキャンセルした場合、行の選択状態もキャンセルしておかないと、データが1行しか無い場合に一度選択してキャンセルを行いもう一度選ぶと、当然だが、selectionChangeは発生しない。 その為、処理をキャンセルした場合は必ず　selectedIndex=-1と言う具合に選択も解除しておく、これならば必ずselectionChangeは発生する。 うっかりしておくと見逃す処理だ。

今更ながらだが、Flash　Builderのカスタムイベントの使い方がわかってきた。 一般的にアプリケーションの構造が大きくなるとコンポーネント別に作っていき、ViewStack等を使って、機能別にコンポーネントを表示して動かすが、その場合、カスタムイベントを利用すると、子どものコンポーネント内の処理を他のコンポーネントや自身の次の処理へ繋げるなど、任意の処理のイベント終了を管理する事ができる。 例えば、Aと言うコンポーネントで、A１と言う処理（例えばデータベースのデータの更新）を行った後、Bと言うコンポーネントの別の処理、B1（例えばデータベースのリスト更新）を行いたいと言う場合に有効だ。 Aのコンポーネントのメタタグで <fx:Metadata>   [Event(name="A1_END", type="flash.events.Event")]  </fx:Metadata> と言うイベントを用意しておき、Aの中で必要な時に呼べば良い。 データベースの更新等場合、通常はCallResponderなどで戻りの処理を書くが、その場所で protected function  A1_END_Handler(event:GridSelectionEvent):void    {     var eventObject:Event=new Event(“A1_END”);     dispatchEvent(eventObject);    } とすれば、これでデータベス更新が終わったイベントを親へ伝える事が出来る。 親から見れば、Aのメタタグで、A1_ENDと言うカスタムイベントを作成すると <local:　A1 id=”Child_A1″ A1_END=”Child_A1_A1_END_Handler(event)”></local:driver_list>  と言う感じでA1_ENDと言うイベントが参照出来るので、これに対して任意のハンドラを当てて、その中でBコンポーネントのB1と言う処理を行うメソッドを呼び出せば良い。 実際の処理はBコンポーネント内で書けば良い訳で、親は全体の管理をするだけで良い。 特にFlashBuilderの様に、イベントドリブンで非同期なアプリケーションの場合は何かの処理が終わる事を確実に把握しないと、値を読みに行った時まだ処理が終わってなくてエラーと言う場合が多々ある。 それも、テストの時は良かったけど、実機になると入っていた筈の値が入ってないと言う現象になったりする。 特に、データベス関連の処理をする場合は、一度の呼び出しで処理が終わら無い場合もあり、前の処理が終わって、次の処理をすると言う事が良くあるし、連続して他の処理を行いたい場合もある。 データを追加した後の、件数の更新などは一度で出来るが、リストの更新となるとその更新から戻ったタイミングでやる必要がある。 コンパイラ系のプログラムだと、その辺を気にしないでプログラム出来るのだが、この辺がFlash系のプログラムの面倒なところで、コンパイラ系から変わって少し複雑なプログラムを書く時に最初に戸惑う部分だ。 そう言う意味で、このカスタムイベントと言うのは、複数のコンポーネントに分けるような大きなプログラムを書く場合、非常に便利で、これを使うことで複雑な処理もスッキリ書ける。

その後、このsparkのComboBoxに textInputがある事を発見！ と言うのも登録済みのデータを修正したい場合に、データベースからのデータをこのComboBoxへ設定する為にはどうしたら良いのか？とハタと困ったわけだ(笑) このsparkのComboBoxと言うのはどうやら、文字をテンプレート的に設定したい場合に使う様な意図があるらしい。 基本的には通常のtextInputコンポーネントの感覚で使い、幾つか文字列をリストへ仕込んでおけば、それを参照して、textInputへ設定してくれると言うものらしく、これは僕の使いたい方法と一致している。 一方で、DropDownListの場合は、これまでのComboBoxと同じ感覚で、「その選択肢の中から選びなさい」と言う場合に使う為の物で、検索などに利用する場合でコードと対応している様な物の場合はこの方が良い様だ。 修正の場合、このtextInput.textへ値を設定すれば良いなら、そもそもの登録の時も、これが空かどうかを参照すれば良さそうだが、データベースへの値の設定は上記の処理でも問題無いので確認してない。

MX系とSpark系ではコンポーネントが色々違うが、今回ComboBoxでハマった。 MX系のComboBoxは編集に関するフラグがあるがSpark系はこれが無い。 どうも、editable=falseのComboBoxはDropDownListを使うらしい。 そして、このComboBoxの編集を利用する場合、例えば初期設定で、labelに りんご、みかん、いちご と言う3項目を用意しておいて、それを選択しても良いし、直接「ぶどう」と書き込んでも良い様にしておいた場合、この値をDBへ渡す為にはどうしたら良いか？ 色々試行錯誤して落ち着いたのが以下の方法 ※dataはPHPサービスへ渡すオブジェクトでhoge_comboがComboBoxだ。 var data:Object=new Object; var temp:*;     temp=hoge_combo.selectedItem;     if (temp is String)     {      data.hoge_name = hoge_combo.selectedItem;     }     else     {      data.hoge_name = hoge_combo.selectedItem.label;     } つまり、編集して入力した場合と、選択した場合では渡す物が異なるのでこの二通りに対応してく必要があると言うことだ。表示欄のtextのプロパティを用意しておいてくれれば良いのにと思うが何故かこれが無いので、こう言う方法になる。 逆に、今回初めて、「prompt」と言うプロパティがあって、これに「-選択又は入力-」と入れておくと、空の時はこれを表示してくれると言う便利な機能がある事を知った(笑) 習うより慣れろだ。

ZendAMFを使ったPHPとFlashBuilderの連携もなんとか手懐けて来た。 結局、データとサービスを利用してデータベースの構造から自動的にPHPサービスを作成する方法は止めた。 これでサービスを作るとわけわからんASのクラスが沢山できるのと、PHP側のスクリプトの出来が悪いからだ。 通常、mySQLを利用する様になっているのだが、自動的に作られるPHPサービスはmysqliを利用するようになっている。 これがイマイチ使い勝手が良くないし、せっかく、ZendFrameworkを利用しているのに、高機能なDB廻りのコンポーネントが利用出来ない。 ということで、自身でZend_DB辺りを使ったPHPサービスを作ったが、これが非常に簡単。 基本的にはZend_Db::factory(‘Pdo_Mysql’,$this->params)と言ったDB関係の初期化を行うクラスを作り、それを継承する形でサービスのクラスを用意すれば良い。 アンダーバーのあるファイル名は駄目な様だ。 このクラスの中に必要なメソッドを書けばOK。 例えば、下の3行でtblで設定したテーブルからデータを検索してくれる。  public function getAllhoge_Master()  {   $sql=’select * from ‘.$this->tbl;   $this->db->setFetchMode(Zend_Db::FETCH_ASSOC);   return $this->db->fetchAll($sql);  } この様な形でサービスクラスを用意すれば、FlashBuilder側のデータとサービスで新規PHPサービスから利用すれば自動的にAS関係のクラスを用意してくれるので、適当にバインドすれば良い。 以前、WEBORBでRemoteObjectを設定したり、もっと前のPHPOBJECTを利用していた時代を考えると構築の早さと手間は格段に違う。 簡単な動作確認ならばFlashBuilderの「操作をテスト」である程度の事は出来るし、場合によってはPHP側で以下の様なログファイル作成メソッドを用意しておいて必要に応じて渡された変数を確認するなどすれば簡単にデバッグ出来る。 function logMe($var)  {   $filename = dirname(__FILE__) . ‘/__log.txt’;      if (!$handle = fopen($filename, ‘a’)) { … 続きを読む →