Download as PDF, PPTX
Recommended
More Related Content
What's hot
Similar to モバイルOSとWeb標準とそれらへのアプローチ
モバイル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アプリでできること」がネイティブ並になるなら、それが行き着く先は概念としてのWebOSに近いのかも知れない
- 7.OSとWeb(1/2)• 「HTML5対応」のモバイル（スマホ／タブレット）向けOS• FirefoxOS、Tizen、Ubuntu Touch、OpenwebOS、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 APIMessaging APIRaw Sockets API…
- 54.W3C Sysapps WG(2/3)•「phase 1I」はこんな感じ
- 55.W3C Sysapps WG(2/3)•「phase 1I」はこんな感じBluetooth APICalendar APINetwork 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 DeviceAPIReference• https://developer.tizen.org/help/index.jsp?topic=%2Forg.tizen.web.device.apireference%2Findex.html
- 65.Tizen Web DeviceAPIReference• 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が勧告予定