iOS 版 Facebook の実装が HTML5 アプリケーションからネイティブアプリケーション (CocoaTouch フレームワークを使ったアプリケーション) に変更されたのは記憶に新しいところ。

それに対して「Facebookのモバイルアプリが失敗した理由は HTML5 のせいじゃない。HTML5 でサクサク動く Facebook アプリを作って見せた Sencha Touch 開発チーム」という記事がありました。

元ネタは The Making of Fastbook: An HTML5 Love Story (以下、元記事) です。

簡単に言うと、「HTML5 だから遅いんじゃないよ、デモアプリケーション Fastbook のようにネイティブアプリケーション同等な (むしろそれを上回る) パフォーマンスでるよ」ということになるでしょうか。

動画も挙がっていて、自信の程が伺えます。

これに対して、いくつか指摘が挙がっています。

え？これSafariじゃね？WebViewとSafariじゃあスピード全然違うよ

[→はてなブックマーク - hazisarashi のブックマーク - 2012年12月20日]

Safariとかずるすぎワロタ。WebviewはSafariの約3.3倍遅いんですが、Webviewで動かすとどうなるんでしょうね（ゲス顔

[→はてなブックマーク - fikah のブックマーク]

同様に元記事のコメントでも……

The demo is really promising, but it is in MobileSafari. When you make an iOS app, you can only use WebView, which is a second-class and slower browser.

[意訳] デモはとても前途有望だけれど、MobileSafari で動いているね。iOS アプリを作る時には WebView しか使えなくて、それは遅いブラウザになってしまうよ。

[→元記事コメント @hlb]

A sticking point with iOS is that embedded WebKit (in Facebook’s old native app) performs horribly compared to Mobile Safari (what Sencha used here) due to Apple's selfish hoarding of the Nitro JavaScript engine.

[意訳] 問題は Facebook の前バージョンでも利用されてた組み込み WebKit で、このデモで使っている Mobile Safari よりもひどく遅いけど。Apple の勝手な囲い込みで Nitro JavaScript エンジンは使えないから。

[→元記事コメント @Ron Waldon]

Mobile Safari では Nitro と呼ばれる JavaScript エンジンでスクリプトが処理されるのですが、CocoaTouch フレームで利用できる UIWebView ではその高速な JavaScript エンジンが (セキュリティ上の理由から) 使われません。

私もこの点 (デモが Safari 上で動いている) は少し気になっていました。

それに対して、Sencha Team のメンバーの何人かが答えています。

@hlb the issue is NOT JavaScript. It's the DOM. The DOM engine is the *same* for both use cases.

[意訳] @hlb JavaScript が問題ではないんだ。DOM が問題で、DOM エンジンは (Safari も UIWebView も) 同じなんだよね。

[→元記事コメント @Jay Garcia]

@hlb Simply save the app to your homescreen to force it to use a WebView.

[意訳] @hlb ホームに置くと、WebView を使うようになると思う (iOS 5.1 以降では Mobile Safari を利用するようになったという指摘あり)。

[→元記事コメント @Jamie Avins]

@Ron Waldon It doesn't matter for such apps like this. Again as we mentioned the bottleneck is never JavaScript execution. We wrapped the app in native webviews for you to try it out yourself: github.com/extjs/fastbook

[意訳] @Ron Waldon このアプリではそこは問題にならないんだ。(これまで) 指摘している通り、ボトルネックは JavaScript の実行にあるわけではないから。ネイティブな webview で実装した例を github に挙げたので、試してみてね。

[→元記事コメント @Jacky Nguyen]

Jacky Nguyen さんと Jamie Avins さんは動画にも登場されています。

コメント受けて、WebView を使った利用例が github に公開されました。

コードは実にシンプルで、

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    // Override point for customization after application launch.
    self.window.backgroundColor = [UIColor whiteColor];
    
    UIWebView* view = [[UIWebView alloc] initWithFrame:[UIScreen mainScreen].applicationFrame];
    [self.window addSubview:view];
    [view loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://fb.html5isready.com/"]]];
    [self.window makeKeyAndVisible];
    return YES;
}

メインのコードはこれだけ。UIWebView を作って http://fb.html5isready.com/ を開いているだけです。

動作させてみると、私が思っていた以上に速い。iPhone 4S / iOS 6.x で確認。確か iOS6 から WebView に対して動作割当メモリが増えたので、それも影響している可能性あり。

UIWebView 上の WebKit でも、スクロールとかきびきびと軽快に動作します。

iOS のアプリケーションとしては、ステータスバーをタップしてもトップにスクロールバックしない、ローディングアニメーションが表示されるべきところで表示されない、未実装な機能 (例えば検索機能) がある、などブラッシュアップが必要な部分はありますが、デモアプリケーションとしてはなかなか興味深い。

もっともこれでもって「HTML5 使うべき」とも言えない部分もあって、

スクロール速度だけを取り上げても。Facebookのエンジニアが指摘した第一の問題はそこじゃないですよね。クラッシュの原因が解らない等 http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html

[→はてなブックマーク - Teshのブックマーク]

という Tesh さんのブックマークコメントや

The premise of this argument is wrong. It's not a simple question of "slow" versus "fast." Application performance is only one factor in building an HTML5 app. Device support, engineer productivity, testability, measurement, tooling/debugging, and native integration are all points that should be factored in. Anyone who has burnt the hours trying to debug a perf issue on a device that doesn't support Webinspector knows this pain. As does anyone who has gotten the bug report about the keyboard not popping up correctly on insert random Android 2.X no one has ever heard of here. As does anyone who has gotten the layout performance awesome in one test environment only to test another and find it terrible. The argument that HTML is ready while the device landscape is not is pretty fraught.

As far as fast goes, even as well done as this demo is, the scrolling framerate is noticeably slower on the Nexus 4 compared against the native application. I feel like all the demo is proving is what we already knew - somethings can be done reasonably well in HTML while many other can't. I'm a person who would rather have the web win. I'm pretty sure it will win in time. It's a pretty clear fact that until the browsers/webviews get faster and/or the device's have faster hardware, HTML is the second best option for smartphones.

[意訳] 議論の前提が違っているよね。単に「遅い」か「速い」という問題じゃない。アプリケーション性能は HTML5 アプリを構築するひとつファクタに過ぎないよ。どのデバイスをサポートするか、エンジニアの生産性、テストのしやすさや計測しやすさ、ツールの使い勝手、デバッグのしやすさ、ネイティブなサポート、など全てのファクタを考える必要がある。ウェブインスペクタをサポートしないデバイスでパフォーマンスをデバッグするのがどんなに大変か知っている人はいる？Android 2.X でキーボードが正しく表示されずにランダムな文字が入力されてしまうというバグレポートを見たことがある人は？あるテスト環境では素晴らしく性能がいいのに、別の環境ではめちゃくちゃだというのを経験したことがある人は？この議論を実際デバイスを横向きにして見ると見づらいという事実についてはどう？

[意訳] 速さという点に関しては、このデモはとても良くできている。スクロールのフレームレートは Nexus 4 で見るとネイティブアプリに比べて遅いけど。このデモは Sencha Team が HTML に関して深く理解している (そしてそれは他の多くの人はできない) こと証明しているに過ぎないと思うんだ。私個人的にはむしろ web が勝って欲しいし、いつかその日がくると信じているけれども、それはブラウザとデバイスが十分に速いというの明快になった時で、HTML はスマートフォンに対して二番目にベストなオプションだと思う。

[→元記事コメント @Jackson Gabbard]

元記事に寄せられた Jackson Gabbard さんのコメントのご指摘の通り、単純に速い・遅いという問題ではなくて、もちろんそれはとても重要な部分ではあるけれども、あくまでも全体の一部の問題でしかありません。

ツールの使いやすさ、デバッグのしやすさ、習得に対する敷居の低さ、などはソフトウェアを恒常的にメンテナンスする上で、重要なポイントになってきます。

Objective-C が習得に対して敷居が低いかどうかはまた別の議論になってしまいそうですが、ネイティブサポートのため、ハック的な知識がなくてもある程度の性能はいけるという印象はあります。もちろん実装次第ですけれども。

これは Sencha や Titanium だけでなく、他のクロスプラットフォームなフレームワークでも大きな課題になっているポイントのような気がします。

reeder は Google Reader を快適に利用できるアプリケーションです。

その reeder からインスパイアされて、似たルック & フィールを Chrome 上で実現する機能拡張が Reeder for Chrome (Unofficial) (以下、RFC) です。

残念ながら RFC の開発は継続されないことになりましたが、ソースは公開されています。

RFC の最も肝となるルック & フィールは基本 css のみで実現されていて、Stylish を使えば、他のブラウザでも利用できそうです。

他に fork している人がいたので、その内容を確認しようと思っただけだったんですが、間違えて自ら fork してしまい、それをきっかけに中身を確認することに……。

1. Stylish for Safari より Stylish の機能拡張をダウンロード・インストールします。
2. ツールバー上にある「Stylish」ボタンから管理画面 (Manage) を開きます。
3. 「Edit」を選ぶと新規スタイル編集画面が開きます。

   Title

   RFC

   CSS

   GitHub から CSS の内容をコピー

   Applies to

   "Regexp" を選択して、https?://www.google.*/reader/.*

   

その後、Google Reader を見ると Reeder のようなインタフェースに変わっていると思います。オススメは 3 カラム表示。

(Webkit に特化したスタイルを利用しているため) CSS の一部変更が必要になりますが、Firefox でもほぼ同様に Stylish から利用できます。

JunichiIto さんによる「Excel列名変換問題で第２回社内プログラミングコンテストを開催してみた(前編)」という記事を見かけて自分でもやってみる。

正確に時間を測ったわけではありませんが、問題 1 と問題 2 あわせて一応 90 分で解けたと思います。

問題1: Excel列名変換問題

• 仕様
  • 入力されたアルファベットを数字に変換する。
  • 変換ルールはExcelの列名と同等。
  • 例) A=1、B=2、Z=26、AA=27、XFD=16384

• 起動時引数
  • [0] アルファベット (A〜ZZZZ...[上限なし])

• 実行例
  • ExcelColConv.pl A → 1
  • ExcelColConv.pl AA → 27

[→Excel列名変換問題で第２回社内プログラミングコンテストを開催してみた(前編)]

→ 問題 1 に対する私の回答

問題2: Excel列名変換問題(逆変換)

• 仕様
  • 入力された数字をアルファベットに変換する。
  • ただし、問題1で作ったプログラムを拡張すること。

• 起動時引数
  • [0] 0=数字へ変換、1=アルファベットへ変換
  • [1] 変換する数字またはアルファベット(どちらも上限なし)

[→Excel列名変換問題で第２回社内プログラミングコンテストを開催してみた(前編)]

→ 問題 2 に対する私の回答

問題 1 回答

#!/bin/perl

if ($ARGV[0] =~ /[A-Za-z]+/)
{
  print &convert(uc($ARGV[0])) . "\n";
}
else
{
  &usage();
}
exit 0;

sub usage
{
  print 'Usage: ',$0,' input',"\n";
}

sub convert
{
  my $input  = shift;
  my $output = 0;

  my $rank = 0;
  foreach my $char ( reverse(split(//,$input)) )
  {
    my $num = index('ABCDEFGHIJKLMNOPQRSTUVWXYZ', $char) + 1;
    $output += $num * (26 ** $rank++);
  }

  return $output;
}

アプローチとしては、3 位の方と同等ですね。一応、入力パラメータチェックしてます。

問題 2 回答

#!/bin/perl

if ($ARGV[0] eq '0' and $ARGV[1] =~ /[A-Za-z]+/)
{
  print &convert(uc($ARGV[1])) . "\n";
}
elsif ($ARGV[0] eq '1' and $ARGV[1] =~ /[0-9]+/ and $ARGV[1] > 0)
{
  print &rev_convert($ARGV[1]) . "\n";
}
else
{
  &usage();
}
exit 0;

sub usage
{
  print 'Usage: ',$0,' dir input',"\n";
  print '       dir 0 : alpha to num [input must be alphabet]'."\n";
  print '       dir 1 : num to alpha [input must be number greater than 0]'."\n";
}

sub convert
{
  my $input  = shift;
  my $output = 0;

  my $rank = 0;
  foreach my $char ( reverse(split(//,$input)) )
  {
    my $num = index('ABCDEFGHIJKLMNOPQRSTUVWXYZ', $char) + 1;
    $output += $num * (26 ** $rank++);
  }

  return $output;
}

sub rev_convert
{
  my $input  = shift;
  my $output = '';
  my @chars = split(//,'ABCDEFGHIJKLMNOPQRSTUVWXYZ');
  my $base = @chars;

  my @stack = ();
  while ($input > $base)
  {
    my $num = $input % $base;
    push(@stack, $chars[$num - 1]);
    $input = int($input / $base);
    # Needs to decrement $input if $input value is in multiple of $base
    if ($num == 0)
    {
      $input--;
    }
  }
  # Now handles within $base case
  push(@stack, $chars[$input % $base - 1]);

  return join('',reverse(@stack));
}

入力数値が基数にあたる 26 の倍数の時、桁を正しく処理する必要があるのがトリッキーな部分になるでしょうか。

一応、ざっくり確認したつもりですが、間違っていたらごめんなさい。

[2010.11.04 03:30 追記] perl の場合、配列に対して負のインデックスを指定すると、配列の後ろからアクセスするという仕様があります。なので、$input % $base の結果が 0 になる場合、@stack には "Z" が格納されます。

Serene Bach 3.00b027 から iPhone/iPod touch 用の Safari 向け管理画面インターフェースをサポートしました。

Android のブラウザも対応したつもりでしたが、先程エミュレータで確認したら、認識されていませんでした。近日中に修正する予定。

iPhone/Android で採用されているブラウザエンジンは Mobile WebKit (Mobile Safari) と呼ばれるもので、WebKit のサブセットになっているようです。

デスクトップ版 Safari と Mobile Safari で挙動が違うことは知られている通り。JavaScript ではマウスイベントハンドラ、実行時間の制限などがあり、読み込める画像のファイルサイズに制限があったりします。

ここでは Windows 版・Mac OS X 版の Safari をデスクトップ版 Safari と呼んでいます。

今回、Serene Bach 3.00b027 開発中に気づいた細かーーい挙動の差異をメモ。

head 要素内で document.write は使えないっぽい

document.write 自体は使える様子ですが、実行場所を選ぶようです。

詳細は検証していないのですが、とりあえず head 要素内に置かれた script で document.write は実行できないようでした。

どうしてそんな場所で document.write を実行しているのかというと、外部 js から別の js ファイルをロードするため。head 要素内に DOM で appendChild する方法もあって、個人的にはこっちの方がしっくりするんですが、やや古い Safari で動作しなかったという経緯があり、document.write を使っていました。

td 要素 (多分 th 要素も) の display スタイルを変更できないっぽい

これも詳細は検証していませんが、例えば、以下のようなスタイル……

table#specific > tbody > tr > td {
  display: block;
}

は動作しませんでした。

ある特定の項をブロック要素として動作させたい意図があったのですが、動作しませんでした。デスクトップ版 Safari では動作するので、Mobile Safari の特徴の様子です。perl スクリプト本体の方は変更なしでいけるかとも思ったのですが、この仕様 (?) のため、ダメでした。

contenteditable は利用できない

Preparing Your Web Content for iPad: Technical Note TN2262: Preparing Your Web Content for iPad でも触れられていますが、contenteditable は利用できないようです。

おそらく designMode もダメでしょう。とりあえず、Serene Bach 3 で利用されているカスタム CodePress は利用できませんでした。