実験メモ(Toru Inoue@KISSAKI)
自分用に書き連ねる実験レポート。(Toru Inoue@KISSAKI)。
用意したり設定したりする上での前提が、端から見て不鮮明だとおもうが、まあ実験用なので、出来てる部分と出来てない部分と実験の成功率を上げ記録するためのファイルですので気にしないでください。
万が一、御用の場合のご連絡は sassemblaアットマークhotmail.com か、KISSAKI worksのメールフォームまで。
Toru InoueのTwitterはtoru_inoueです。 * 1.JavaScriptからの外部へのアクセスポイント = APIの出力
* 2.インターフェースクラスの作成
* 後述するラッパークラスの宣言
* 3.実装クラスの作成
* Javaのラッパークラス
* javaScriptを呼び出すJSNIクラス
* 4.テスト
*
* これらを行いたい。
* 出来ると、凄く楽になるし、他の物も使えるようになるかもしれない。
*
* オブジェクトへの名前空間のアタッチは不明だがな！
* その辺りは、JSNIで作成する段階でID化されていたような気がしないでもない。
* &wndからの取得部分を外部化するのも、読み出しを事前チェックするように出来そうだ。
編集工学
直感の言葉化
遊びと人間 (単行本)R・カイヨワ (著), 清水 幾太郎 (翻訳), 霧生 和夫 (翻訳) ジェジェック 遊び 遊学（松岡正剛）
※※編集工学の分類法…編集の場合
☆■収集（分けると分かる） 収集・選択・分類・流派・系統
Ａ■編定（縮めて伝える） 編定・要約・凝縮・翻訳・結合
Ｂ■原型（型にして見る） 原型・模型・適合・列挙・配置・意匠・装飾・図解
Ｃ■順番（繋げて較べる） 順番・規則・交換・競合・比較・共鳴
Ｄ■暗示（含みを持たせる） 暗示・相似・擬態・象徴
Ｅ■引用（盗んで補う） 比喩・推理・引用・例示・補償
Ｆ■注釈（付け加える） 注釈・付加・削除・拉致・保留・代行
Ｇ■模擬（測って調べる） 模擬・測度・強調・変容
Ｈ■焦点（ニュースにする） 焦点・報道・統御
Ｉ■境界（区切りを変える） 境界・場面
Ｊ■周期（リズムをつける） 周期・曲節
Ｋ■諧謔（おおげさにする） 歪曲・不調・輪郭・諧謔
Ｌ■形態（構造を見つける） 構造・形態・生態
Ｍ■劇化（物語で遊ぶ） 筋道・脚本・劇化・遊戯
JavaScriptからfunctionを抽出する
概要
JavaScriptからfunctionの一覧を取得する作業を自動化する
取得した一覧に対してGWTのラッパを作成する作業を自動化する
手法
なんてものを作るのは嫌なので、EclipsePluginのJSDTから拝借。
ロジックだけでも還元できるか？
→シンタックスハイライトがもっと軽量な事に気がついたorz。
Vaadin GWTGraphics + Processingを使ってみる
概要
SVGとかが使いやすいようにしてくれているライブラリがある。
利用者コミュニティもそれなりに大きいようだが、さて？
日本人の使用者いねーーーーーーー。
内容
前提として、GWTでのGraphicsを行う GWTGraphics ライブラリと、 Processing.jsを独自拡張したものの連携物らしい。
GWTGraphics
GoogleCoce
ライセンスはApache2.0
で、Processing.jsの改造物本体
Processing GWT Graphics Component
情報はここ(Vaadin Wiki)
ダウンロードはここ
テーマは、ProcessingをGWTで使えるように、、、なのだけれど、悲しいかな、Vaadinの本体との組み付きっぷりがちょっと固い。
コンポーネントの拡張クラスから依存してしまっている。
こういう時、Guice使って切り分けてほしくなる。
ていうか単体でも動かせるようにしたい。。ほんと、ただのインターフェース希望。
Vaadin自体がGWTGraphicsを拡張する方向に動いているグループみたいね。
いろんなサンプルがある。すべて組み付いていると思うと、ちょっと「ぞっとしない」
非常にいいと思うところ&怖いところ
GWTIncubatorが無くてもキャンバス描画できる。 というか出来てしまう。
Incubatorとは異なるCanvas実装をしている。
（事実、Canvasよりも上位のクラスからコンポーネントを作成している。）
IncubatorがGoogle公認という認識なので、とりあえずこの時点でバイバイ確立がガっと上がる。
現在の進行度
デモが実行できねえ。。
とおもったらデモはオンラインでないと機能しないのか、、、
問題点
デモではオンラインで無いと挙動しない、みたいな部分があったけど、
ダウンロードが終われば自由になったりするのかな。
その意味であれば、価値はあるかと思われる。
ただ、すべて描画されないとかそういうのは、勘弁な。
現状のステータスは、お見送り。
教訓としては、他の要素と組み付く部分での自由度の支点（力点作用点）が、他のモジュールとダブってないかを
確認するリストを作った方がいいかも、ということか。
今回の場合、キャンバスオブジェクトの扱いが主なポイントになる気がする。
Widgetの実装深度？まだ言葉がまとまらない。
Processing.js + GWTでの描画
前提
processing.min.js/processing.jsを使用。
→対応範囲から、やりたい事をリストアップする。
→最新バージョンを使用するように変更
最新版への変更に伴って、いろいろ仕様変更を確認した。
インターフェース次第だねえ。
利点と考えているポイント
Javaで作成されているProcessingを、JavaScriptに移植したもの（途中）がProcessing.js。
国内はそうでもないけど、国外での利用度はなかなかの物。
JavaScriptということは、アクセッサをGWT側から作れるため、モジュール化が楽。
外部モジュールであるため、切り離しと利用が楽
問題点としては、GWTのブリッジが中途半端になりそうなこと。
メモリとして持てばまあ大丈夫かな。
初期化時にそのメモリを持つクラスを設計するか。
→Processingを内容したクラスできた。
インターフェースをいろいろ出力するか。
クラス構造を規定しよう。
0.カメラ
概要
カメラメソッドなんて面白そうなものを（そして簡単で効果高そうなものを！！）見つけたので使ってみる。
現状のメモ
p.lights();でエラーをはく。
内容はminでは無理、という領域 + jsだと無理、なのだろうな。
まあ、描画の基礎を行うモジュールのみで十分有効範囲なのだから、
Canvasでそれらが使えるだけで凄いでしょう。
＊GWTでは、まだ、直接Javaでは描画できないんだぜーw
さてはて。
1.画像描画
概要
画像を描画する
注目すべき点としては、
１、Webからのダウンロードと描画が１行で書ける事
２、ダウンロード元には、DevelopmentモードのGWTが使える事
３、変形を掛けるのが超簡単そうな事
現状のメモ
var path = "http://127.0.0.1:8888/resource/4.jpg";
var imgS;
imgS = p.loadImage(path);//ここまでは通過
p.image(imgS, 0, 45);//image自体が未定義みたい。
2.文字描画
概要
GWTと連携させたProcessing.jsで文字を描画
現状のメモ
フォント指定用のローディングが失敗しているようだ。
p.text("",100,100);//描画されない、デフォルトのフォント指定は無いようだ。 エラーも出ない。
3.SVGの描画
概要
ProcessingでSVGを使って描画を行う
移植中。。。
うーん、芳しくないなあ、
Processing.js自体で、まだサポートしてない内容になる。
まあでも、何だ、ここでデータを放り込むのには、Javaが使えるなあ。
4.Bezierの描画
概要
描画と動くものを作ってみよう。
おおむね動きそうな感覚！ 後は、、実装の内容の問題。多分OK
結論
ラッパーが用意できれば使える
確認できた点としては、
1.まあ使えない事も無い
2.ライブラリ化が凄く楽なので、過去の資産流用としてはアリ
3.権利関係もOK
というところか。
jsライブラリを使う上で、vaadinあたりと競り合うには、ちょっと時間がないかも。
かんたんな表示なら、最速。
アンチエイリアス付きでの描画でも、最速。
Vaadinだと、ライブラリが大きすぎる印象があるんだよな、、、
Webサーバ側に準備がいるし。
バージョン差の不安
Processing.js、 Ver0.8でのみ発生している現象だが、
JavaScriptオブジェクトを作る段で、以前は必要なかった引数aCode（本来は実行コードをぶち込んで動かすためのもの！）に翻弄されて、
以前動いた物が全く動かなくなってた。
Processingオブジェクトを生成する際に使用するファンクション
function Processing(aElement, aCode)
なのだが、
aCodeにはProcessingに食わせるコード（実行コードの文字列）が入る。
以前は、引数が無ければ特に何も行わずProcessingのオブジェクトだけを返してくれる関数だったのだけれど、
0.8のバージョンでは、aCodeがあるかないかをチェックする前に、aCodeの内容から画面サイズに関する命令
size(100,100);
とかを抜き出して、使ってしまっている。
aCodeを空にしたままだと、unDefinedを出すし、
aCodeを入れたら入れたで、size(100,100);関数を使うしか無かった。
Resigさんのソース内コメントによれば、そのうちどうにかなるようにするつもりらしい。
せめて、aCodeの有無を調べる順番だけはなんとかしてちょ、とお願いするつもり。
大変そうだのう、、、
サイズ変更は後から効くので、問題は無い。
GWTのキャッシュ(外部JavaScriptを読み込む場合) キャッシュが発生している範囲が判明、
・ブラウザ
JavaScriptのキャッシュ
・war/プロジェクト名フォルダ
プログラムのキャッシュ、書き換えの手続きを行わないと変わらない。
一応動く内容も確認できたが、関数の上書きが出来ない、、らしい。もしくは名前が変わっているのか＞
中身がえらく特化し
ている印象。
if (aMode && (aMode === "OPENGL" || aMode === "P3D")) { // get the 3D rendering context
try {
if (!curContext) {
curContext = curElement.getContext("experimental-webgl");
}
} catch(e_size) {
Processing.debug(e_size);
}
今のところちょっとパス。 でも使える。
GWTでCanvasを自在に使う
概要
GWTでCanvasを使うと、画面サイズや伸縮に対して他の要素の影響を受ける。どんな要素が影響しているのか
GWTでCanvasタグの有効活用、JavaScriptからのマウス制御の位置調整をする
問題点を明確にし、二度と迷わないように知識化、体系化を行う。
問題点
Canvasが横長になる
マウス位置の検知が左上にずれる
挙動速度のネックがまちまち(JavaScriptとの併用で高速化が可能。GWTが遅いという意味ではなく。)
iPhone向けにデプロイした物が表示できるかチェックが必要
エラーの見つけ方 JavaScriptのエラーの見つけ方で現状の物は、
FireFoxのFireBugで、下記のように表示される
これが、唯一に近いくらい便利。
以下メモ
シンプルなHTMLに貼付けてみたら、widthとheightの値が、Processing使用直前のサイズで
925,555だった。 そんな数字は定義してない。
なにかと思ったら、その時点でのブラウザのサイズだった。ええええ？
変数が一つ増えた。
Canvasの作成サイズ
Processingの設定サイズ
ブラウザのサイズ
キャンバスオブジェクトがこんな感じだが、、さて。
<canvas style="width: 100px; height: 100px; background-color: rgba(0, 0, 0, 0.496094); " width="0" height="0"></canvas>
確かめてみたところ、Processingに渡すところで確かにサイズ参照してて、それを用意してあるキャンバスに無理矢理乗っけてただけだった。
っていうかこんなところまで出来るのか、感心した。
切り抜いて表示するかと思った。
ともあれ、謎は解けた。
iPhone/Androidの既存携帯に向けてのチューニング開始
JSONを使う
下記をモジュールに加えると楽
<inherits name="com.google.gwt.json.JSON" /> <inherits name='com.google.gwt.jsonp.Jsonp'/>
このページのURL
