bradtosのWEB開発日記

WEB開発エンジニアbradtosによる、JavaScriptやHTML5/CSS3の最新情報などなど・・・



2015-04-21

Ruby

13:51

相変わらずJS+(なぜか)Flashの仕事がメインだけど、

合間を縫って今更ながらRuby勉強中。

全てがオブジェクトだったり演算子メソッドだったり

徹底して美しく、かつ緩い言語なんだなというのが第1印象。

なによりJavascriptに近いものを感じるところが気に入った(笑)

IPA公式サイトに分かりやすい入門用教材があるのでおすすめ。

https://jinzaiipedia.ipa.go.jp/it_platform/education/oss

2013-12-03

ハマったこと:AndroidにおけるCreateJS/Canvasのバグ

16:30

スマホアニメーション

AndroidでもFlashが使えなくなって久しいが、

最近では手間のかかるCSS3アニメーションを諦めて、

多少再生パフォーマンスが悪くともFlashから直に出力できる

CreateJSによるアニメーションがソシャゲ界では定番のようだ。



特にAndroid4はCSSのマスクとアニメーションの併用が壊滅的なので、

マスクがちゃんと使えるというメリットも大きい。



さて、CreateJSで開発していると壁にぶち当たるのが

CreateJSというかCanvasバグ

しかもAndroidのWebViewだとさらに調子が悪くなる。

内容としては描画がおかしくなったり、ブラウザアプリが落ちたり。



筆者の経験だとSamsung Galaxy SIIIやXperia Z、A等の

Snapdragon S4を搭載している機種で再現しやすい模様。

Canvasで本気でアニメーションさせるというネタがまだ少ないので

いつか同じ問題にぶつかる方のためにも解決策を記事に残して置く。



例えばcanvasのclearRect()において

キャンバスのサイズと同じ数値を指定すると落ちるなどが有名所だろうか。

CreateJSのclear()の実装はclearRect()なので当然落ちる。

ググると数回にピクセルを分けてclearRect()するなどの対処法が書かれているが、

これについては、easelJSの0.6.1以降では対策されているため、

そちらを使用すれば問題ない。

(まさか縦横ともに1ピクセル大きくクリアするだけで解決とは・・・)



それでも負荷のかかるアニメーションで落ちるパターンがあったので

調べたところ、



http://blog.happyelements.co.jp/2013/08/love-peace-and-android.html



こちらのブログに答えが見つかった。

そう、アニメーションを開始させる前、

stage = new createjs.Stage(canvas);

の後に

stage.clear();

を呼ぶことが大切だったようだ。

特に背景が透過しているアニメーションで発生しやすかったように思うが、

clear()で対策できるということは

明らかにCanvasメモリリークだろう。





Androidはひとつのカーネルでいろんな機種に対応できるのが売りであるが、

ドライバーはメーカーやチップベンダーがカスタムしたものを使用するため

ハードの性能は一流でもドライバーの完成度の低さに起因する

問題が多い気がする。

以前JSによるswfプレイヤーの開発を手伝っていたことがあったが、

とある機種ではJS内での簡単な少数演算で桁あふれを起こすこともあった。

OS自体は無料のはずなのに、めったなことがないとアップデートはされないし、

このままではiPhoneに負ける一方ではないか(もちろんiPhoneにもバグはあるが)。

個人的にはGoogleが好きなので、

Android陣営には4.4 Kitkatで是非とも頑張ってもらいたい所である。

2012-03-11

楽しいこと:JS+CSS3アニメーション

02:19

久しぶりの更新です。

最近のお仕事はスマートフォン向けのブラウザソーシャルゲーム作成。

というか変換に近いかも。



スマホ対応サイトの開発に携わってる方は分かると思うけど、

iPhoneなどのiOSではFlashが動かない。

今やソーシャルゲームユーザーのスマホ率は40%を超えるそうで、

iPhoneに対応しないゲームなんて話にならないところまで来ているとか。



そこでFlashベースで作られたものを元に

HTML5(+JS+CSS3アニメーション)版に出すのが

現在の案件という訳。




今のところiOSとAndroidがターゲットのため

Chromeで開発し、webkit系ブラウザ用で動くようにさえすれば

上記の両者に対応するということになるんだけど、

実際のところはそうもいかない。



自分自身去年末に3年愛用したW63CAからついに

AndroidケータイのXperia Acroに買い換えた訳だけど、

実は今回の仕事で初めて知ったことがある。

それはAndroidブラウザはなんとChromeではないということ!



PCのChromeはベータの時から使っていたし、

SafariもOS Xに搭載されたバージョン1から使っていて

どちらもwebkit系というのは知っていたけれど

さすがにAndroidブラウザはChromeだろうと勝手に思い込んでいた。

調べてみる限りあのブラウザはあくまでも「ブラウザ」という名称だそうで、

確かに多くのソースを共有しているがChrome開発チームとは別の、

Androidチームが作っているそうだ。




そのためか実際、Webkit系ブラウザ向けのCSSアニメーションを使った

ブラウザアプリを開発していると

PC版SafariやChromeとの多くの相違点にびっくりする。

PCではちゃんと表示できても、

実機で見るとまともに動かない部分がかなりある。

例えば-webkit-animation-fill-modeといったような、

webkitプリフィックスを使ったCSSのプロパティ等である。

上記は現在多くのAndroidケータイで採用されている

Android2.3のブラウザでは完全に無視される。



iPhoneのほうについては、3GSなどの古い機種でも

今のところ最新のiOSにバージョンアップすることによって

比較的最新のSafariが使えるためバグに悩まないで済むと思いきや、

何せアップデート自体に問題が多いため

(失敗すると最悪データ全消去なのは周りでは有名)

古いiOSのまま使っているユーザーも相当数いることから

iOS4でも検証を行わなければならないのは非常に面倒な話である。


こちらは動かないというよりは主にパフォーマンス面の

問題が多いので、画像の配置やJSの書き方などに一工夫必要になる。




今のところそれらについての情報が記載されているサイトが少ないので、

次回から少しずつここで書いていきたいと思う。

2011-01-18

技術情報:困ったこと IEでAjax時に起こるエラー c00ce56e

16:09

お久しぶりでございます。



最近また懲りずにいろんなモノを

細々と作ってるわけだけど、

今回はサーバー側がPHPのAjaxアプリ作成中に出くわしたこと。



Ajax開発者の方なら一度は目に触れたこともあろうかと思う

IEのエラー、

「エラー c00ce56e のため操作を完了できませんでした」

について。



そもそも社内で勝手に作ってるので

ページ文字コードは最初っからUTF-8、

サーバーもFedoraでUTF-8、

PHPもUTF-8とくればAjaxで困ることはないだろうと思っていたのだが・・・


サーバーからのレスポンスはJSON形式、

header('Content-type: application/json charset=utf-8');

とした後に

echo '"a" : "ほげほげ"'としたり

echo json_encode(Array("a" => "ほげほげ"))としたり(json_encodeは本当に便利!)

する際に、マルチバイト文字が含まれると上記のエラーが発生。

以前の案件で文字コード関連というのは予想がついていたのだが、

全部UTF-8なのにそりゃないだろ〜と調べていたら、判明。。



php.iniの

default_charset = "UTF8"

となっていた所を

default_charset = "UTF-8"

にしたら直ったorz

紛らわしいけどシフトJISもSJISとかS-JISとかWindows31Jとかあるもんね。。

というわけで皆様もお気をつけくださいまし。

2010-02-23

技術情報:困ったこと IFRAME内のhistoryへのアクセス

02:42

前回紹介したJSOSだが、

やはりクロスブラウザは面倒だなぁと思いながらもちまちま進行中。


とりあえず閉じるボタンと、リサイズ(右下のみ)は実装できてて、

あとはスキン対応なんかを意識してcssと分別化を計ったり。

相変わらずパクりですみません。イカす素材あれば教えてください。

FireFox3でも動くようになりました。

FFの場合、素早いリサイズを試みるとウィンドウが置いてかれるのは謎。


さて今日ぶつかった壁はiframe。

サンプルアプリ第一弾としてiframeによるブラウザもどきを

作ってる途中なんだけど、

今日の困ったちゃんはアドレスバーに必要不可欠な履歴ボタン!

つまり、戻るボタンと進むボタン。


普通に考えれば(window.)history.back()とhistory.forward()しかないので

当然[iframeエレメント.contentWindow.history]からアクセスするつもりだったのだが

当方のIE8だと「アクセスが拒否されました」とでる。

そういえば以前フルJSの案件やってたときも悩まされたような・・・

確かにクロスドメインと言えなくもないし、

まあ悪いことをしようと思えばできるだろうってのは想像つくんだけど、

FFなんかだと現状で動いてるし困った。

これだからセキュリティ云々って嫌い。例外処理と同じくらい嫌い。


とりあえずググると2000年ごろはそれで普通に動いてたらしい(笑)

IE8でも動くいい方法ないかな・・・

チョコチョコ 2010/09/08 13:15 もう解決されたかもしれませんが・・・
私も、同じ問題?にぶつかってて javascript側を疑っていたのですが・・・問題はPHPやCGI側にあったみたいです。
PHP、CGI側に
header('Content-type: text/html; charset=utf-8;');
header('Content-type: text/plain; charset=utf-8;');
など、とすると FFでもIEでも同じ結果が帰ってきました〜♪

間違ってたごめんなさい!

bradtosbradtos 2011/01/15 10:57 >>チョコさん
コメントありがとうございます&遅くなりました!
残念ながら、今のところサーバーサイド側では特にプログラムを
動かしていないので、教えていただいたやり方はできないようです(T_T)

nk.nk. 2011/01/15 18:38 HTTPヘッダのcharsetにUTF8指定がないのが問題だとしたら、.htaccessで設定できた気がします。
http://mikeneko.creator.club.ne.jp/~lab/web/htaccess/httpheader.html#Header
firefoxのaddonにある、LiveHTTPHeaderでHTTPヘッダを確認すればUTF8指定がされてるかチェックできますよー。