モバイルOSとWeb標準と
それらへのアプローチ
関東Firefox OS勉強会 3rd
2013/08/28
きさと(@rkisato)
自己紹介
• 名前:きさと
• Twitter ID:@rkisato
• メインジョブ:ヌルゲーマー
• サポートジョブ:SEという名の何か
• FF11は2年ほど前に引退、FF14は自重
サポートジョブ
または本来のお仕事
• ∼4年前
• 業務系システムの製造→設計→PM
• ∼3年前
• Android/iOSアプリ等の製造
• ∼1年前
• 社内ニート
• Now
• 某事業向けの技術調査やアーキテクチャ検討(非Mobile)
お題
• モバイルOSとWeb標準の関係
• そもそもWeb標準ってなんぞ
• OS間のAPI差の情報が少なくて辛い
• OS間のAPI差を調べ、まとめる取り組み
• 本資料の内容はFirefox OS特化でなく、Firefox OSも
含めた「HTML5 ready」なモバイルOSに共通の話
モバイルOSと
Web標準の状況
OSとWeb(1/2)
• 「HTML5対応」のPC向けOS
• HTML5は(アプリ開発向けの)開発言語の選択肢の一つ
だが、「※但しHTML5に限る」であるOSはそんなにない
• Chrome OSさん?
• 一方、PCの上で動くブラウザは種々ある
• 「ブラウザ上のWebアプリでできること」がネイティブ
並になるなら、それが行き着く先は概念としてのWeb
OSに近いのかも知れない
OSとWeb(1/2)
• 「HTML5対応」のモバイル(スマホ/タブ
レット)向けOS
• Firefox OS、Tizen、Ubuntu Touch、Open
webOS、Sailfish OS、……
• Firefox OSは「※HTML5に限る」な希少種
HTML5とは(1/2)
HTML5とは(1/2)
• 全部ワンソースで動く!
HTML5とは(1/2)
• 全部ワンソースで動く!
• 開発コストが下がる!
HTML5とは(1/2)
• 全部ワンソースで動く!
• 開発コストが下がる!
• 開発者がハッピーになれる!
HTML5とは(1/2)
• 全部ワンソースで動く!
• 開発コストが下がる!
• 開発者がハッピーになれる!
• うおおおお!
HTML5とは(1/2)
• 全部ワンソースで動く!
• 開発コストが下がる!
• 開発者がハッピーになれる!
• うおおおお!
• そんな都市伝説もあります
HTML5とは(2/2)
HTML5とは(2/2)
• 上の方の人に多いです
HTML5とは(2/2)
• 上の方の人に多いです
• 最近、周辺で物理的に聞こえてきた話
HTML5とは(2/2)
• 上の方の人に多いです
• 最近、周辺で物理的に聞こえてきた話
• 「HTML5は先端技術だ」
HTML5とは(2/2)
• 上の方の人に多いです
• 最近、周辺で物理的に聞こえてきた話
• 「HTML5は先端技術だ」
• 「これからはHTML5の時代だ」
つまり
つまり
• 絶望が俺のゴールだ(@kassy_kz)
モバイルOSとWeb(1/3)
• 「モバイルOS×HTML5」で何ができて、何が作れ
る?
• これまでのブラウザでできることは概ねできる
• API的には、サブセットでなくフルセット
• バージョンの前後はあるけど
• ハード面での制約は置いておく
• 逆に、ブラウザでできないことはできない
モバイルOSとWeb(2/3)
• 標準のAPIでは何ができない?
• OS寄り、デバイス寄りの機能
• APIが足りない、定義されていない
• ハードウェア制御
• 電源、通信モジュール、バイブレータ……
• OS設定、連絡先、カレンダー
• Webアプリのパッケージング、署名、etc……
• 従来の延長でのWebページには必要なかったから、なくて当然
モバイルOSとWeb(3/3)
• つまり?
• モバイルOSの要求に「Web標準」が追いついていない
• W3C的に言えば勧告に至っていない
• 「勧告」(仕様の確定)までには年単位の時間が
かかる
• ドラフトすらないものもある
• 現時点での未公開含む
独自?標準?(1/3)
• PCブラウザの場合
• 新API=新しい要求に対応するAPI=新しい機能へ繋がる
API
• 「今、存在しない」としても、致命的な仕様不足にはな
らない
• 特にスタンドアロンでなく相互接続が必要なAPIは、互い
に合意した物≒標準化されたものでないと使い物にならな
い
• ex.WebSocket、WebRTC
独自?標準?(1/3)
• モバイルOSの場合
• 「存在しないと、そもそもOS(プリ
インアプリを含む)が成り立たない」
APIがある
• 標準化を悠長に待っていたらプロダ
クトが出せない
独自?標準?(3/3)
• Web標準に足りないAPIをどうするか?
• 足りないなら、作ればいいじゃない
• 各ベンダが独自APIを作っている
独自?標準?(3/3)
• Web標準に足りないAPIをどうするか?
• 足りないなら、作ればいいじゃない
• 各ベンダが独自APIを作っている←今ここ
(参考)
ブラウザベンダ独自のAPI
• 各ブラウザベンダは、新しい独自APIを追加
• Chrome Packeged Apps API
• http://developer.chrome.com/extensions/apps.html
• Mozilla WebAPI
• https://wiki.mozilla.org/WebAPI
• OS寄り、ネイティブ寄りのAPIが多い
• APIが必要なユースケース(use cases)と要求
(requirements)が背景に存在する
モバイルOSとHTML5と
デベロッパ
モバイルOSとHTML5と
デベロッパ
• このまま行くとデベロッパが辛くない?
モバイルOSとHTML5と
デベロッパ
• このまま行くとデベロッパが辛くない?
• 同じ言語仕様(HTML/JavaScript)の上で
同じことをやりたいだけなんだ
モバイルOSとHTML5と
デベロッパ
• このまま行くとデベロッパが辛くない?
• 同じ言語仕様(HTML/JavaScript)の上で
同じことをやりたいだけなんだ
• プラットフォーム毎の方言とか、覚えて
いられない
モバイルOSとHTML5と
デベロッパ
• このまま行くとデベロッパが辛くない?
• 同じ言語仕様(HTML/JavaScript)の上で
同じことをやりたいだけなんだ
• プラットフォーム毎の方言とか、覚えて
いられない
• 第3のOSって言い出したの誰d
モバイルOSとHTML5と
デベロッパ
モバイルOSとHTML5と
デベロッパ
• 絶望が俺のゴールだ(@kassy_kz)
この先の想像
この先の想像
• 今、各OSで固有に実装されているAPI
は、数年後には標準になっているかも
しれない
この先の想像
• 今、各OSで固有に実装されているAPI
は、数年後には標準になっているかも
しれない
• でもその時には固有仕様が生まれてい
るはずで
この先の想像
• 今、各OSで固有に実装されているAPI
は、数年後には標準になっているかも
しれない
• でもその時には固有仕様が生まれてい
るはずで
• 先生…エンドレスな匂いがします…
とは言え
• 流れに身を任せるだけなのもつまらな
いので…
• 何か取り組んでみよう
• 結果が伴うかは別
• まずはやってみる
モバイルOS関連のWeb APIを
まとめないか的な取り組み
独自APIを俯瞰できるように
独自APIを俯瞰できるように
• 各社/各開発者が個別にAPIを調べるのは不毛
独自APIを俯瞰できるように
• 各社/各開発者が個別にAPIを調べるのは不毛
• 俯瞰できるサイトがほしい
独自APIを俯瞰できるように
• 各社/各開発者が個別にAPIを調べるのは不毛
• 俯瞰できるサイトがほしい
• モバイルクリエイターズ(仮)のdocの中に「モバイルOS関連
WebAPI」というページ枠を作った(枠だけ)
独自APIを俯瞰できるように
• 各社/各開発者が個別にAPIを調べるのは不毛
• 俯瞰できるサイトがほしい
• モバイルクリエイターズ(仮)のdocの中に「モバイルOS関連
WebAPI」というページ枠を作った(枠だけ)
• https://sites.google.com/site/mcreatorjp/home/materials/webapi
独自APIを俯瞰できるように
• 各社/各開発者が個別にAPIを調べるのは不毛
• 俯瞰できるサイトがほしい
• モバイルクリエイターズ(仮)のdocの中に「モバイルOS関連
WebAPI」というページ枠を作った(枠だけ)
• https://sites.google.com/site/mcreatorjp/home/materials/webapi
• プラットフォームをまたいでAPIを俯瞰できれば、マルチプ
ラットフォームな開発者が少しは楽になるんじゃなかろうか
独自APIを俯瞰できるように
• 各社/各開発者が個別にAPIを調べるのは不毛
• 俯瞰できるサイトがほしい
• モバイルクリエイターズ(仮)のdocの中に「モバイルOS関連
WebAPI」というページ枠を作った(枠だけ)
• https://sites.google.com/site/mcreatorjp/home/materials/webapi
• プラットフォームをまたいでAPIを俯瞰できれば、マルチプ
ラットフォームな開発者が少しは楽になるんじゃなかろうか
• 電源管理のAPI、Firefox OSではどうでTizenではどうなの?
とか
モバイル∼(仮)の
モバイルOS関連WebAPIのページ
• https://sites.google.com/site/mcreatorjp/home/materials/
webapi
とりあえず眺めた仕様
• W3Cの公開文書
• MozillaとTizenのAPIリファレンス
W3Cのサイト
• http://www.w3.org/
W3C Sysapps WG(1/3)
• http://www.w3.org/2012/sysapps/
• 下記は「phase 1」
W3C Sysapps WG(1/3)
• http://www.w3.org/2012/sysapps/
• 下記は「phase 1」
Contacts API
Messaging API
Raw Sockets API
…
W3C Sysapps WG(2/3)
• 「phase 1I」はこんな感じ
W3C Sysapps WG(2/3)
• 「phase 1I」はこんな感じ
Bluetooth API
Calendar API
Network Interface API
…
W3C Sysapps WG(3/3)
• 拡大してみると
W3C Sysapps WG(3/3)
• 拡大してみると
TizenやB2Gの名前
Web Manifestのドラフト
(1/2)
• http://www.w3.org/2008/webapps/manifest/
• 「Webアプリのマニフェスト」の仕様
Web Manifestのドラフト
(2/2)
• 拡大してみると
Web Manifestのドラフト
(2/2)
• 拡大してみると
Mozilla
Mozilla WebAPI
• https://wiki.mozilla.org/WebAPI/
Mozilla WebAPI
• https://wiki.mozilla.org/WebAPI/
Setting APIとか
Mozilla WebAPI
• https://wiki.mozilla.org/WebAPI/
Setting APIとか
W3C EDやCRの記述
Tizen Web Device API
Reference
• https://developer.tizen.org/help/index.jsp?topic=
%2Forg.tizen.web.device.apireference%2Findex.html
Tizen Web Device API
Reference
• https://developer.tizen.org/help/index.jsp?topic=
%2Forg.tizen.web.device.apireference%2Findex.html
こちらもBluetooth APIとか
眺めた印象
• 各社が新しいAPIを提案し、あるいは自社ブラウザへ実装し
ている
• ブラウザベンダだとMozilla、Google、Operaが多い
• 各社が自発的に作る場合もあり、同意したドラフトに
沿って試行実装する場合もあり
• ベンダからWeb標準への提案
• Web標準に従ったブラウザ実装
• これまでの紆余曲折を経て成り立った「Webの文化」
ここでちょっと私見
Web標準 vs native(1/4)
Web標準 vs native(1/4)
• Web標準とnativeは、同列で評価するもので
はない
Web標準 vs native(1/4)
• Web標準とnativeは、同列で評価するもので
はない
• Web標準は「今」でなく「将来」のWebの
多機能性と互換性を確保するためのもの
Web標準 vs native(1/4)
• Web標準とnativeは、同列で評価するもので
はない
• Web標準は「今」でなく「将来」のWebの
多機能性と互換性を確保するためのもの
• 「今nativeでできること」を「数年後の
Webでできるようにすること」
Web標準 vs native(2/4)
Web標準 vs native(2/4)
• 今の評価として正当なもの
Web標準 vs native(2/4)
• 今の評価として正当なもの
• IE6許さない、絶対にだ
Web標準 vs native(2/4)
• 今の評価として正当なもの
• IE6許さない、絶対にだ
• WebViewのAPI古い、互換性なくて辛い
Web標準 vs native(2/4)
• 今の評価として正当なもの
• IE6許さない、絶対にだ
• WebViewのAPI古い、互換性なくて辛い
• Firefox OS遅い
Web標準 vs native(2/4)
• 今の評価として正当なもの
• IE6許さない、絶対にだ
• WebViewのAPI古い、互換性なくて辛い
• Firefox OS遅い
• だけど数年後もそうなの? 逆に数年前は
どうだった?
Web標準 vs native(3/4)
Web標準 vs native(3/4)
• 例えば、APIの充実化とハードウェアスペックの向上で
「Web標準が3年でnativeと同等になる」と仮定すると
Web標準 vs native(3/4)
• 例えば、APIの充実化とハードウェアスペックの向上で
「Web標準が3年でnativeと同等になる」と仮定すると
• いまOS/プラットフォーム毎にnativeで実装しなければ
いけないものは、3年後にはWeb標準で作れる
Web標準 vs native(3/4)
• 例えば、APIの充実化とハードウェアスペックの向上で
「Web標準が3年でnativeと同等になる」と仮定すると
• いまOS/プラットフォーム毎にnativeで実装しなければ
いけないものは、3年後にはWeb標準で作れる
• 「今のnativeのアドバンテージ」は3年で失われる
Web標準 vs native(3/4)
• 例えば、APIの充実化とハードウェアスペックの向上で
「Web標準が3年でnativeと同等になる」と仮定すると
• いまOS/プラットフォーム毎にnativeで実装しなければ
いけないものは、3年後にはWeb標準で作れる
• 「今のnativeのアドバンテージ」は3年で失われる
• もちろん、その3年でnativeは新たなアドバンテージ
を獲得する
Web標準 vs native(3/4)
• 例えば、APIの充実化とハードウェアスペックの向上で
「Web標準が3年でnativeと同等になる」と仮定すると
• いまOS/プラットフォーム毎にnativeで実装しなければ
いけないものは、3年後にはWeb標準で作れる
• 「今のnativeのアドバンテージ」は3年で失われる
• もちろん、その3年でnativeは新たなアドバンテージ
を獲得する
• それは更に時間を経ないと追いつけないけれど
Web標準 vs native(4/4)
• いまこの瞬間にアプリを作らないといけないときに、
未来の話をしても仕方がない
• だけど、基盤であるOSやWeb標準という観点に立つと
• 今何が足りないのか?
• 何を解決しないと行けないのか?
• を考えて、解く人がいないといけない
Web標準 vs ライブラリ(1/3)
• Webの世界はライブラリが充実している
• 今のAPIの不足やブラウザ間の差を吸収してくれる、Webアプ
リを簡単に開発できるようにしてくれる
• 何はなくともjQuery
• あるいは開発言語も、JavaScriptをよしなに拡張してくれる/可
換な言語がある
• 最近だとTypeScriptとか
• では、ライブラリ等ががんばれば、わざわざWeb標準で新しい
APIを作る必要はないか?
Web標準 vs ライブラリ(2/3)
• ノン
• ラッパライブラリがいくらがんばっても、エンドポ
イント(API)が存在しない機能は実現しようがな
い
• jQueryががんばったらOS管理下のBluetooth I/Fを叩
ける、わけはない
• ブラウザやOS(つまりUserAgent)がAPIを用意
して、初めて使える
Web標準 vs ライブラリ(3/3)
• 根本的なところは新しいAPIが必要で、かつブ
ラウザ間で実装や解釈の差が出ないように標
準化されないといけない
• 標準のAPIをラップして、より便利に使える
ようにするのがライブラリ
• 古いブラウザの実装差をラップするのは過
渡的な役割
まとめ
まとめ(1/2)
• Web標準と開発現場の差は常に残る
• ギャップを補う情報はまとまっている方がよい
• 互いにシェアした方が、開発者全体のリソースを考えたときに
効率的
• モバイルOSに限らず、興味のある情報や切り口があったら、呼び
かけてみると誰かが乗ってくるかも?
• APIのまとめ、誰かがちょっとずつ足してくれると嬉しいなって
• ソロプレイ辛い
まとめ(2/2)
• 「標準化」の切り口で他社の動向を眺めてみると面白い
• Webと繋がりのなかった業界の参入
• テレビ(Web and TV、Web and Broadcasting)
• 車(Automotive)
• 広告(Web-based Signage)
• 標準化の動きは基本的にオープン
• 誰でも見れる(公開ドキュメント、ML、議事録、etc)
• センシティブな部分はクローズドなところで行われるが
……で終わると
Firefox OSの話がないので
サンプルを1つだけ
Firefox OSのキーボード
• Firefox OSは全部HTML5でできている
• じゃあキーボードもHTML5なの?
←これ
HTML5です
• Gaiaのapps/keyboard
• https://github.com/mozilla-b2g/gaia/tree/master/apps/keyboard
日本語キーボード
• apps/keyboard/js/imesのjskanji配下
• https://github.com/mozilla-b2g/gaia/tree/master/apps/keyboard/
js/imes/jskanji
キーボードとWeb標準(1/2)
• 第三者が新しいキーボードを作れるように
• MozillaのKeyboardIME
• https://wiki.mozilla.org/WebAPI/KeboardIME
• これも標準化されていない要素
キーボードとWeb標準(2/2)
• 一方、W3CのInput Method Editor API (IME API)
• http://www.w3.org/TR/ime-api/
• MozillaのKeyboardIMEとは別物(そもそも動機が違う)
時間があれば……
デファクト標準
• 特定領域で「事実上の標準」になった仕様
• 国際機関によって後で追認されることもある
• 例
• VHS
• DOS/V(PC/AT互換機)
• TCP/IP(後にIETFへ)
デジュール標準
• 公的機関が取り決めた仕様
• 国際機関の例……IEEE、ISO、ITU、IETF
• 国内機関の例……JIS
• 例
• IEEE:IEEE802.11何とか(Wi-Fi)
• ISO:ISO/IEC 8859シリーズ(8ビット文字コード体系)
• ITU:ITU-T勧告E.164(電話番号体系)
• IETF:RFC-6455(WebSocketプロトコル)
• 念のため:WebSocket APIはW3Cの管轄
フォーラム標準
• 企業等の団体が集まって作った「フォーラム」に
よって取り決められた仕様
• フォーラムの例……W3C、Bluetooth SIG
• 若干違うけどコンソーシアム標準も似たもの
• 例
• Bluetooth SIG:Bluetooth
• W3C:HTML(3.2以降/それ以前はIETFの管轄)
Web標準
• 昔()のWebはブラウザベンダ毎に独自実装に走っていてカオス
だった
• Dynamic HTML(たぶん黒歴史)
• XHTML 2.0(完全に黒歴史)
• ブラウザベンダ(のいくつか)が切れてWHATWGを立ち上げた
• 今は、W3Cその他の標準化団体が策定した標準仕様に準拠するの
が慣例
• 標準化団体が策定する仕様とブラウザベンダから還流される仕
様とで持ちつ持たれつ
W3C
• World Wide Web Consotiumの略
• Web周りの標準化を行う非営利団体
• デバイスベンダ、OSベンダ、キャリアの参加が多い
• 最近は別業種のメーカの参加も
• 当初は主にマークアップの規格
• HTML、XML、XHTML……
• WHATWGの流れを受けてAPI周りも
W3Cの標準化プロセス
• 草案(Working Draft)
• コミュニティやWG内で書いて直して書いて直して
• 最終草案(Last Call Working Draft)
• 別のWGやW3Cメンバからレビュー
• 勧告候補(Candidate Recommendation)
• 草案を元に実装してもらう
• 2つ以上の実装が存在しないと勧告案へ進めない
• ≒、2つ以上のブラウザベンダが実装しないといけない
• 勧告案(Proposed Recomendation)
• 諮問委員会によるレビュー
• 勧告(Recommendation)
• 仕様確定、標準化完了
HTML5の標準化状況
• HTML5(マークアップ仕様の方)は
現在「勧告候補」
• 2014年に「勧告」予定
• 2016年にはHTML5.1が勧告予定

モバイルOSとWeb標準とそれらへのアプローチ