Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a モバイルOSとWeb標準とそれらへのアプローチ
Semelhante a モバイルOSとWeb標準とそれらへのアプローチ (20)
Último
Último (8)
モバイルOSとWeb標準とそれらへのアプローチ
- 2. 自己紹介 • 名前：きさと • Twitter ID：@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に共通の話
- 6. OSとWeb(1/2) • 「HTML5対応」のPC向けOS • HTML5は（アプリ開発向けの）開発言語の選択肢の一つ だが、「※但しHTML5に限る」であるOSはそんなにない • Chrome OSさん？ • 一方、PCの上で動くブラウザは種々ある • 「ブラウザ上のWebアプリでできること」がネイティブ 並になるなら、それが行き着く先は概念としてのWeb OSに近いのかも知れない
- 7. OSとWeb(1/2) • 「HTML5対応」のモバイル（スマホ／タブ レット）向けOS • Firefox OS、Tizen、Ubuntu Touch、Open webOS、Sailfish OS、…… • Firefox OSは「※HTML5に限る」な希少種
- 8. HTML5とは(1/2)
- 11. HTML5とは(1/2) • 全部ワンソースで動く！ • 開発コストが下がる！ • 開発者がハッピーになれる！
- 12. HTML5とは(1/2) • 全部ワンソースで動く！ • 開発コストが下がる！ • 開発者がハッピーになれる！ • うおおおお！
- 13. HTML5とは(1/2) • 全部ワンソースで動く！ • 開発コストが下がる！ • 開発者がハッピーになれる！ • うおおおお！ • そんな都市伝説もあります
- 14. HTML5とは(2/2)
- 17. HTML5とは(2/2) • 上の方の人に多いです • 最近、周辺で物理的に聞こえてきた話 • 「HTML5は先端技術だ」
- 18. HTML5とは(2/2) • 上の方の人に多いです • 最近、周辺で物理的に聞こえてきた話 • 「HTML5は先端技術だ」 • 「これからはHTML5の時代だ」
- 19. つまり
- 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を追加 • Chrome Packeged Apps API • http://developer.chrome.com/extensions/apps.html • Mozilla WebAPI • https://wiki.mozilla.org/WebAPI • OS寄り、ネイティブ寄りのAPIが多い • APIが必要なユースケース（use cases）と要求 （requirements）が背景に存在する
- 32. モバイルOSとHTML5と デベロッパ • このまま行くとデベロッパが辛くない？ • 同じ言語仕様（HTML/JavaScript）の上で 同じことをやりたいだけなんだ • プラットフォーム毎の方言とか、覚えて いられない
- 33. モバイルOSとHTML5と デベロッパ • このまま行くとデベロッパが辛くない？ • 同じ言語仕様（HTML/JavaScript）の上で 同じことをやりたいだけなんだ • プラットフォーム毎の方言とか、覚えて いられない • 第3のOSって言い出したの誰ｄ
- 36. この先の想像
- 39. この先の想像 • 今、各OSで固有に実装されているAPI は、数年後には標準になっているかも しれない • でもその時には固有仕様が生まれてい るはずで • 先生…エンドレスな匂いがします…
- 40. とは言え • 流れに身を任せるだけなのもつまらな いので… • 何か取り組んでみよう • 結果が伴うかは別 • まずはやってみる
- 42. 独自APIを俯瞰できるように
- 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ではどうなの？ とか
- 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アプリのマニフェスト」の仕様
- 63. Mozilla WebAPI • https://wiki.mozilla.org/WebAPI/ Setting APIとか W3C EDやCRの記述
- 64. Tizen Web Device API Reference • https://developer.tizen.org/help/index.jsp?topic= %2Forg.tizen.web.device.apireference%2Findex.html
- 65. Tizen Web Device API 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. ここでちょっと私見
- 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でできるようにすること」
- 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遅い • だけど数年後もそうなの？ 逆に数年前は どうだった？
- 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） • センシティブな部分はクローズドなところで行われるが
- 92. Firefox OSのキーボード • Firefox OSは全部HTML5でできている • じゃあキーボードもHTML5なの？ ←これ
- 95. キーボードとWeb標準(1/2) • 第三者が新しいキーボードを作れるように • MozillaのKeyboardIME • https://wiki.mozilla.org/WebAPI/KeboardIME • これも標準化されていない要素
- 96. キーボードとWeb標準(2/2) • 一方、W3CのInput Method Editor 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、Bluetooth SIG • 若干違うけどコンソーシアム標準も似たもの • 例 • Bluetooth SIG：Bluetooth • W3C：HTML（3.2以降／それ以前はIETFの管轄）
- 101. Web標準 • 昔（）のWebはブラウザベンダ毎に独自実装に走っていてカオス だった • Dynamic HTML（たぶん黒歴史） • XHTML 2.0（完全に黒歴史） • ブラウザベンダ（のいくつか）が切れてWHATWGを立ち上げた • 今は、W3Cその他の標準化団体が策定した標準仕様に準拠するの が慣例 • 標準化団体が策定する仕様とブラウザベンダから還流される仕 様とで持ちつ持たれつ
- 102. W3C • World Wide Web 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が勧告予定