Download as PDF, PPTX
モバイルOSとWeb標準とそれらへのアプローチ
- 1.
- 2. 自己紹介 • 名前：きさと • TwitterID：@rkisato • メインジョブ：ヌルゲーマー • サポートジョブ：SEという名の何か • FF11は2年ほど前に引退、FF14は自重
- 3. サポートジョブ または本来のお仕事 • ∼4年前 • 業務系システムの製造→設計→PM •∼3年前 • Android/iOSアプリ等の製造 • ∼1年前 • 社内ニート • Now • 某事業向けの技術調査やアーキテクチャ検討（非Mobile）
- 4. お題 • モバイルOSとWeb標準の関係 • そもそもWeb標準ってなんぞ •OS間のAPI差の情報が少なくて辛い • OS間のAPI差を調べ、まとめる取り組み • 本資料の内容はFirefox OS特化でなく、Firefox OSも 含めた「HTML5 ready」なモバイルOSに共通の話
- 5.
- 6. OSとWeb(1/2) • 「HTML5対応」のPC向けOS • HTML5は（アプリ開発向けの）開発言語の選択肢の一つ だが、「※但しHTML5に限る」であるOSはそんなにない •Chrome OSさん？ • 一方、PCの上で動くブラウザは種々ある • 「ブラウザ上のWebアプリでできること」がネイティブ 並になるなら、それが行き着く先は概念としてのWeb OSに近いのかも知れない
- 7. OSとWeb(1/2) • 「HTML5対応」のモバイル（スマホ／タブ レット）向けOS • FirefoxOS、Tizen、Ubuntu Touch、Open webOS、Sailfish OS、…… • Firefox OSは「※HTML5に限る」な希少種
- 8.
- 9.
- 10.
- 11. HTML5とは(1/2) • 全部ワンソースで動く！ • 開発コストが下がる！ •開発者がハッピーになれる！
- 12. HTML5とは(1/2) • 全部ワンソースで動く！ • 開発コストが下がる！ •開発者がハッピーになれる！ • うおおおお！
- 13. HTML5とは(1/2) • 全部ワンソースで動く！ • 開発コストが下がる！ •開発者がハッピーになれる！ • うおおおお！ • そんな都市伝説もあります
- 14.
- 15.
- 16.
- 17. HTML5とは(2/2) • 上の方の人に多いです • 最近、周辺で物理的に聞こえてきた話 •「HTML5は先端技術だ」
- 18. HTML5とは(2/2) • 上の方の人に多いです • 最近、周辺で物理的に聞こえてきた話 •「HTML5は先端技術だ」 • 「これからはHTML5の時代だ」
- 19.
- 20.
- 21. モバイルOSとWeb(1/3) • 「モバイルOS×HTML5」で何ができて、何が作れ る？ • これまでのブラウザでできることは概ねできる •API的には、サブセットでなくフルセット • バージョンの前後はあるけど • ハード面での制約は置いておく • 逆に、ブラウザでできないことはできない
- 22. モバイルOSとWeb(2/3) • 標準のAPIでは何ができない？ • OS寄り、デバイス寄りの機能 •APIが足りない、定義されていない • ハードウェア制御 • 電源、通信モジュール、バイブレータ…… • OS設定、連絡先、カレンダー • Webアプリのパッケージング、署名、etc…… • 従来の延長でのWebページには必要なかったから、なくて当然
- 23. モバイルOSとWeb(3/3) • つまり？ • モバイルOSの要求に「Web標準」が追いついていない •W3C的に言えば勧告に至っていない • 「勧告」（仕様の確定）までには年単位の時間が かかる • ドラフトすらないものもある • 現時点での未公開含む
- 24. 独自？標準？(1/3) • PCブラウザの場合 • 新API＝新しい要求に対応するAPI＝新しい機能へ繋がる API •「今、存在しない」としても、致命的な仕様不足にはな らない • 特にスタンドアロンでなく相互接続が必要なAPIは、互い に合意した物≒標準化されたものでないと使い物にならな い • ex.WebSocket、WebRTC
- 25. 独自？標準？(1/3) • モバイルOSの場合 • 「存在しないと、そもそもOS（プリ インアプリを含む）が成り立たない」 APIがある •標準化を悠長に待っていたらプロダ クトが出せない
- 26. 独自？標準？(3/3) • Web標準に足りないAPIをどうするか？ • 足りないなら、作ればいいじゃない •各ベンダが独自APIを作っている
- 27. 独自？標準？(3/3) • Web標準に足りないAPIをどうするか？ • 足りないなら、作ればいいじゃない •各ベンダが独自APIを作っている←今ここ
- 28. （参考） ブラウザベンダ独自のAPI • 各ブラウザベンダは、新しい独自APIを追加 • ChromePackeged Apps API • http://developer.chrome.com/extensions/apps.html • Mozilla WebAPI • https://wiki.mozilla.org/WebAPI • OS寄り、ネイティブ寄りのAPIが多い • APIが必要なユースケース（use cases）と要求 （requirements）が背景に存在する
- 29.
- 30.
- 31.
- 32. モバイルOSとHTML5と デベロッパ • このまま行くとデベロッパが辛くない？ • 同じ言語仕様（HTML/JavaScript）の上で 同じことをやりたいだけなんだ •プラットフォーム毎の方言とか、覚えて いられない
- 33. モバイルOSとHTML5と デベロッパ • このまま行くとデベロッパが辛くない？ • 同じ言語仕様（HTML/JavaScript）の上で 同じことをやりたいだけなんだ •プラットフォーム毎の方言とか、覚えて いられない • 第3のOSって言い出したの誰ｄ
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40. とは言え • 流れに身を任せるだけなのもつまらな いので… • 何か取り組んでみよう •結果が伴うかは別 • まずはやってみる
- 41.
- 42.
- 43.
- 44.
- 45. 独自APIを俯瞰できるように • 各社／各開発者が個別にAPIを調べるのは不毛 • 俯瞰できるサイトがほしい •モバイルクリエイターズ（仮）のdocの中に「モバイルOS関連 WebAPI」というページ枠を作った（枠だけ）
- 46. 独自APIを俯瞰できるように • 各社／各開発者が個別にAPIを調べるのは不毛 • 俯瞰できるサイトがほしい •モバイルクリエイターズ（仮）のdocの中に「モバイルOS関連 WebAPI」というページ枠を作った（枠だけ） • https://sites.google.com/site/mcreatorjp/home/materials/webapi
- 47. 独自APIを俯瞰できるように • 各社／各開発者が個別にAPIを調べるのは不毛 • 俯瞰できるサイトがほしい •モバイルクリエイターズ（仮）のdocの中に「モバイルOS関連 WebAPI」というページ枠を作った（枠だけ） • https://sites.google.com/site/mcreatorjp/home/materials/webapi • プラットフォームをまたいでAPIを俯瞰できれば、マルチプ ラットフォームな開発者が少しは楽になるんじゃなかろうか
- 48. 独自APIを俯瞰できるように • 各社／各開発者が個別にAPIを調べるのは不毛 • 俯瞰できるサイトがほしい •モバイルクリエイターズ（仮）のdocの中に「モバイルOS関連 WebAPI」というページ枠を作った（枠だけ） • https://sites.google.com/site/mcreatorjp/home/materials/webapi • プラットフォームをまたいでAPIを俯瞰できれば、マルチプ ラットフォームな開発者が少しは楽になるんじゃなかろうか • 電源管理のAPI、Firefox OSではどうでTizenではどうなの？ とか
- 49.
- 50.
- 51.
- 52. W3C Sysapps WG(1/3) •http://www.w3.org/2012/sysapps/ • 下記は「phase 1」
- 53. W3C Sysapps WG(1/3) •http://www.w3.org/2012/sysapps/ • 下記は「phase 1」 Contacts API Messaging API Raw Sockets API …
- 54. W3C Sysapps WG(2/3) •「phase 1I」はこんな感じ
- 55. W3C Sysapps WG(2/3) •「phase 1I」はこんな感じ Bluetooth API Calendar API Network Interface API …
- 56. W3C Sysapps WG(3/3) •拡大してみると
- 57. W3C Sysapps WG(3/3) •拡大してみると TizenやB2Gの名前
- 58. Web Manifestのドラフト (1/2) • http://www.w3.org/2008/webapps/manifest/ •「Webアプリのマニフェスト」の仕様
- 59.
- 60.
- 61.
- 62.
- 63. Mozilla WebAPI • https://wiki.mozilla.org/WebAPI/ SettingAPIとか W3C EDやCRの記述
- 64. Tizen Web DeviceAPI Reference • https://developer.tizen.org/help/index.jsp?topic= %2Forg.tizen.web.device.apireference%2Findex.html
- 65. Tizen Web DeviceAPI Reference • https://developer.tizen.org/help/index.jsp?topic= %2Forg.tizen.web.device.apireference%2Findex.html こちらもBluetooth APIとか
- 66. 眺めた印象 • 各社が新しいAPIを提案し、あるいは自社ブラウザへ実装し ている • ブラウザベンダだとMozilla、Google、Operaが多い •各社が自発的に作る場合もあり、同意したドラフトに 沿って試行実装する場合もあり • ベンダからWeb標準への提案 • Web標準に従ったブラウザ実装 • これまでの紆余曲折を経て成り立った「Webの文化」
- 67.
- 68.
- 69. Web標準 vs native(1/4) •Web標準とnativeは、同列で評価するもので はない
- 70. Web標準 vs native(1/4) •Web標準とnativeは、同列で評価するもので はない • Web標準は「今」でなく「将来」のWebの 多機能性と互換性を確保するためのもの
- 71. Web標準 vs native(1/4) •Web標準とnativeは、同列で評価するもので はない • Web標準は「今」でなく「将来」のWebの 多機能性と互換性を確保するためのもの • 「今nativeでできること」を「数年後の Webでできるようにすること」
- 72.
- 73. Web標準 vs native(2/4) •今の評価として正当なもの
- 74. Web標準 vs native(2/4) •今の評価として正当なもの • IE6許さない、絶対にだ
- 75. Web標準 vs native(2/4) •今の評価として正当なもの • IE6許さない、絶対にだ • WebViewのAPI古い、互換性なくて辛い
- 76. Web標準 vs native(2/4) •今の評価として正当なもの • IE6許さない、絶対にだ • WebViewのAPI古い、互換性なくて辛い • Firefox OS遅い
- 77. Web標準 vs native(2/4) •今の評価として正当なもの • IE6許さない、絶対にだ • WebViewのAPI古い、互換性なくて辛い • Firefox OS遅い • だけど数年後もそうなの？ 逆に数年前は どうだった？
- 78.
- 79. Web標準 vs native(3/4) •例えば、APIの充実化とハードウェアスペックの向上で 「Web標準が3年でnativeと同等になる」と仮定すると
- 80. Web標準 vs native(3/4) •例えば、APIの充実化とハードウェアスペックの向上で 「Web標準が3年でnativeと同等になる」と仮定すると • いまOS／プラットフォーム毎にnativeで実装しなければ いけないものは、3年後にはWeb標準で作れる
- 81. Web標準 vs native(3/4) •例えば、APIの充実化とハードウェアスペックの向上で 「Web標準が3年でnativeと同等になる」と仮定すると • いまOS／プラットフォーム毎にnativeで実装しなければ いけないものは、3年後にはWeb標準で作れる • 「今のnativeのアドバンテージ」は3年で失われる
- 82. Web標準 vs native(3/4) •例えば、APIの充実化とハードウェアスペックの向上で 「Web標準が3年でnativeと同等になる」と仮定すると • いまOS／プラットフォーム毎にnativeで実装しなければ いけないものは、3年後にはWeb標準で作れる • 「今のnativeのアドバンテージ」は3年で失われる • もちろん、その3年でnativeは新たなアドバンテージ を獲得する
- 83. Web標準 vs native(3/4) •例えば、APIの充実化とハードウェアスペックの向上で 「Web標準が3年でnativeと同等になる」と仮定すると • いまOS／プラットフォーム毎にnativeで実装しなければ いけないものは、3年後にはWeb標準で作れる • 「今のnativeのアドバンテージ」は3年で失われる • もちろん、その3年でnativeは新たなアドバンテージ を獲得する • それは更に時間を経ないと追いつけないけれど
- 84. Web標準 vs native(4/4) •いまこの瞬間にアプリを作らないといけないときに、 未来の話をしても仕方がない • だけど、基盤であるOSやWeb標準という観点に立つと • 今何が足りないのか？ • 何を解決しないと行けないのか？ • を考えて、解く人がいないといけない
- 85. Web標準 vs ライブラリ(1/3) •Webの世界はライブラリが充実している • 今のAPIの不足やブラウザ間の差を吸収してくれる、Webアプ リを簡単に開発できるようにしてくれる • 何はなくともjQuery • あるいは開発言語も、JavaScriptをよしなに拡張してくれる／可 換な言語がある • 最近だとTypeScriptとか • では、ライブラリ等ががんばれば、わざわざWeb標準で新しい APIを作る必要はないか？
- 86. Web標準 vs ライブラリ(2/3) •ノン • ラッパライブラリがいくらがんばっても、エンドポ イント（API）が存在しない機能は実現しようがな い • jQueryががんばったらOS管理下のBluetooth I/Fを叩 ける、わけはない • ブラウザやOS（つまりUserAgent）がAPIを用意 して、初めて使える
- 87. Web標準 vs ライブラリ(3/3) •根本的なところは新しいAPIが必要で、かつブ ラウザ間で実装や解釈の差が出ないように標 準化されないといけない • 標準のAPIをラップして、より便利に使える ようにするのがライブラリ • 古いブラウザの実装差をラップするのは過 渡的な役割
- 88.
- 89. まとめ(1/2) • Web標準と開発現場の差は常に残る • ギャップを補う情報はまとまっている方がよい •互いにシェアした方が、開発者全体のリソースを考えたときに 効率的 • モバイルOSに限らず、興味のある情報や切り口があったら、呼び かけてみると誰かが乗ってくるかも？ • APIのまとめ、誰かがちょっとずつ足してくれると嬉しいなって • ソロプレイ辛い
- 90. まとめ(2/2) • 「標準化」の切り口で他社の動向を眺めてみると面白い • Webと繋がりのなかった業界の参入 •テレビ（Web and TV、Web and Broadcasting） • 車（Automotive） • 広告（Web-based Signage） • 標準化の動きは基本的にオープン • 誰でも見れる（公開ドキュメント、ML、議事録、etc） • センシティブな部分はクローズドなところで行われるが
- 91.
- 92. Firefox OSのキーボード • FirefoxOSは全部HTML5でできている • じゃあキーボードもHTML5なの？ ←これ
- 93.
- 94.
- 95. キーボードとWeb標準(1/2) • 第三者が新しいキーボードを作れるように • MozillaのKeyboardIME •https://wiki.mozilla.org/WebAPI/KeboardIME • これも標準化されていない要素
- 96. キーボードとWeb標準(2/2) • 一方、W3CのInput MethodEditor API (IME API) • http://www.w3.org/TR/ime-api/ • MozillaのKeyboardIMEとは別物（そもそも動機が違う）
- 97.
- 98. デファクト標準 • 特定領域で「事実上の標準」になった仕様 • 国際機関によって後で追認されることもある •例 • VHS • DOS/V（PC/AT互換機） • TCP/IP（後にIETFへ）
- 99. デジュール標準 • 公的機関が取り決めた仕様 • 国際機関の例……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の管轄
- 100. フォーラム標準 • 企業等の団体が集まって作った「フォーラム」に よって取り決められた仕様 • フォーラムの例……W3C、BluetoothSIG • 若干違うけどコンソーシアム標準も似たもの • 例 • Bluetooth SIG：Bluetooth • W3C：HTML（3.2以降／それ以前はIETFの管轄）
- 101. Web標準 • 昔（）のWebはブラウザベンダ毎に独自実装に走っていてカオス だった • DynamicHTML（たぶん黒歴史） • XHTML 2.0（完全に黒歴史） • ブラウザベンダ（のいくつか）が切れてWHATWGを立ち上げた • 今は、W3Cその他の標準化団体が策定した標準仕様に準拠するの が慣例 • 標準化団体が策定する仕様とブラウザベンダから還流される仕 様とで持ちつ持たれつ
- 102. W3C • World WideWeb Consotiumの略 • Web周りの標準化を行う非営利団体 • デバイスベンダ、OSベンダ、キャリアの参加が多い • 最近は別業種のメーカの参加も • 当初は主にマークアップの規格 • HTML、XML、XHTML…… • WHATWGの流れを受けてAPI周りも
- 103. W3Cの標準化プロセス • 草案(Working Draft) •コミュニティやWG内で書いて直して書いて直して • 最終草案(Last Call Working Draft) • 別のWGやW3Cメンバからレビュー • 勧告候補(Candidate Recommendation) • 草案を元に実装してもらう • 2つ以上の実装が存在しないと勧告案へ進めない • ≒、2つ以上のブラウザベンダが実装しないといけない • 勧告案(Proposed Recomendation) • 諮問委員会によるレビュー • 勧告(Recommendation) • 仕様確定、標準化完了
- 104. HTML5の標準化状況 • HTML5（マークアップ仕様の方）は 現在「勧告候補」 • 2014年に「勧告」予定 •2016年にはHTML5.1が勧告予定