今回はこのライブ配信アプリ「LIVEcommune」の開発チームにどんな技術や体制で開発しているのか、HTML5 Experts.jp白石俊平編集長が直撃インタビューしてきました！

DMMが映像配信のノウハウを活かしたライブ配信アプリ「LIVEcommune」をリリース！

白石：まずは、「LIVEcommune」がどのようなアプリなのか教えてください。

植田：今回開発したアプリ「LIVEcommune」は、配信者と視聴者を繋ぐ生配信アプリです。配信者をプレゼントで応援したり、嬉しいことや面白いことを「LIVEcommune」を通じて共有できます！一般ユーザーがスマホアプリのカメラで配信し、それをスマホユーザーが見てチャットなどでコミュニケーションをとって楽しむライブ配信アプリです。さらに、オンライン上で盛り上がっていただくスタンプ・アイテムを提供しています。

ライブ配信アプリはもうすでにレッドオーシャンになっており、日本だけでなく、中国をはじめるとするアジアでも盛り上がっている市場です。「LIVEcommune」はスピード感を持ってまずはユーザにとって絶対に必要な基本機能を厳選して開発を行いました。戦略的な機能はこれから実装をしていくといったところですが、動画広告やコンテンツ配信など各社マネタイズに工夫しているようです。

▲株式会社DMM.comラボ 植田隼人さん /「LIVEcommune」の開発リーダー、システムの取りまとめをしている

白石：この開発には何人くらい携わっているんですか？

植田：開発時はエンジニア、デザイナー、ディレクターなど、事業推進責任者含めると最大20人でした。今は10人ちょっとくらい。メンバー構成としてはリーダー、開発メンバー、サーバーサイド、iOSエンジニア、Androidエンジニア、ディレクター、デザイナーですね。

山本：iOSはXcodeと、当時の最新であるSwift 3.1で開発しました。あと、MVVMというアーキテクチャを取り入れて、RxSwiftというデータバインディングできるライブラリを使いました。RxSwiftはデータのやりとりから、コントローラーからモデルの間にビューモデルがあって、データのやり取りを簡単にすることができるライブラリです。

▲株式会社DMM.comラボ 山本修平さん / 「LIVEcommune」ユニットリーダー、iOSアプリエンジニアを務める

杉野：僕がエンジニアチームと大きく関わったのは、ぬるぬる動くスタンプのアニメーションのところです。はじめの要求としては3～4カ月くらいでiOS、Android、Webに書き出せるものを作ってほしいという要望もあり、デザイナーだけで完結できるAirbnbが出したライブラリでLottieというのを使いました。

After EffectsからiOS、Android、Webにそのまま反映できるので、ぬるぬる動くアニメーションが実現できました。データはJSON形式にしてアプリの方に送り、アニメを再生するのはRottyを使ってiOS、Androidに吐き出しています。Web版はこれから開発予定です。新しいことに挑戦したいという気持ちもあって、楽しかったですね。

▲株式会社DMM.comラボ 杉野さん /「LIVEcommune」のUIデザインとコンセプトメイキング、技術選定を担当

ロゴが変化するデザイン、ダイナミック・アイデンティティにチャレンジ

白石：デザインやロゴはどうでしたか？

杉野：今回良かったのは開発スタートしたときに、コンセプトやどういうアプリにしようというのがなかったんですね。搭載する機能だけが決まっていた。でも、コンセプトがあった方が機能を作る上での方向性も決めやすいと思ったので、デザインはコンセプトメイキングから入りました。こちらも開発と並行だったけど楽しかった。

コンセプトは「いつでもどこでも一体感を共有」「アプリを開くと新しい発見」「リアルタイムコミュニケーション」。この3つをロゴに落とし込みました。communeの語源は、親しく交わるとかコミュニティ、コミュニケーションからきています。

白石：丸くもこもこしているところがユーザーが交わっているところなんですね。

杉野：ライブアプリなので、再生を想起させるものを作りました。決めるのに2カ月くらいかかりました(笑)。イベントやメディアによってロゴの形や色が変化するダイナミック・アイデンティティという新しい概念も、これから取り入れようとしています。

▲ダイナミックアイデンティティ以外にもロゴの別案(パターン)も複数案出し、検討していったとのこと

WebのフレームワークはLaravel、データベースはAmazon Aurora、KVSはRedis

中里：僕はアプリの中でWebViewを使っているところや、API周りを担当しました。

アプリの中でユーザーが貯めたポイントを現金やiTunesカードなどの景品と交換できるのですが、そのユーザー認証や銀行口座などの入力、景品交換をする一連のページをWebViewを使って開発しています。

▲株式会社DMM.comラボ 中里勇輝さん /「LIVEcommune」Web/APIの開発を担当

白石：なぜ、WebViewで開発しようと思ったんですか？

中里：今後Web版が出たときに共有できるし、DMMの共通機能も使いやすかったからですね。

白石：APIはどの辺を使ったんでしょう。

中里：最初にフレームワークどうしようという話になったときに候補に挙がったのが、Laravel, CakePHP, FuelPHP。どれを採用してもチームの中で全員が使ったことがあるのがなかったし、どうせ学習コストがかかるのなら海外ではメジャーなフレームワークを使ってみたい。ということで、更新頻度も多く、海外ではメジャーだったのでLaravelを選びました。

白石：基本的にはPHPを使っているとのことですが、PHP7になって結構変わりました？

中里：メソッドを作る時に、引数などの型を完全に指定できるようになりましたね。指定したものと違うクラスが来たら、エラーになります。

あと、今回はAWS上に誰でも用意されたコマンドを打てば簡単に開発環境が作れる仕組みを作りました。これまで人によってバージョンが違うと動かなかったりエラーが出たりなど、ローカルで開発環境を作ってはまることが多かったんですが、今回はそういうことがなく、全員同じ開発環境がコマンド１発で作ることができました。

白石：どういうコマンドなんですか？

中里：AWS上でインスタンスを作って、ansibleでPHPやMySQLをインストールして設定するとAWS上に個人環境ができるというものです。ローカルでソースコードを書いて、シンクさせます。元を変えたら全員の環境がアップデートされます。新しいメンバーが参加しても、開発環境の準備で時間を取られることがなくなりました。

白石：反映が遅いということはなかった？

中里：ないですね。すぐに反映されます。

白石：データベースは何を使ってるんですか？

中里：AWSのAmazon Auroraと、KVSはRedisを利用しています。

データ通信のサーバーはSocket.IOで実装、言語はGoを採用

田仲：視聴中のチャットなどのデータ通信は、Socket.IOを利用しており、言語はGoを使用しています。たいていのものはSocket.IOで通信していますが、認証やセキュリティ的要件が必要なものは一回APIサーバーを挟んで通信していますね。

▲株式会社DMM.comラボ 田仲祐介さん /「LIVEcommune」配信サーバー、インフラ周りを担当

白石：重要な方はAPIを挟むんですね。

田仲：視聴者が画面をタップするとハートを送ることができるのですが、これらのデータの信頼性がそこまで重要でないものは速度を重視して、Socket.IOで完結させています。

植田：ちなみに去年くらいから、プラットフォーム上で使う言語はGoを採用するようになってきました。エンジニアが使いたい言語をチームで話し合って決めているので、自由度は高いです。

配信サーバーはWowzaで構築、チャット用サーバーはRedisで運用

白石：DMMさんがもともと自社で持っている映像配信のイメージが強いですが、そのプラットフォームを活用したのでしょうか。

植田：そうですね。社内のインフラチームにはサーバーの基礎の構築だけお願いしました。サーバーにAPIサーバーなどはの特定の情報は持たないようにして、AMIによる構築とで構築することによってオートスケーリングを組み合わせることによって、と組み合わせて障害が起きた際の復旧をインスタンスを自動化することができました。

ログはAWSのElastic SearchとKibanaを使っていて、チャット用のサーバーはRedisで運用しています。

田仲：配信サーバーの方はWowzaという製品を使って構築していて、そちらはAWSではなく、オンプレで構築しています。Wowzaは映像配信のデファクトスタンダードと言われているもので、一部モジュールの方はJavaで開発しています。

AWS Lambdaも少し使っているところがあるんですけど、そこはNode,Ruby,Pythonを使っています。

白石：田仲さんはオールラウンダーですね！配信サーバーだけはオンプレなんですか？

田仲：配信サーバーは要求されるスペックが高く、AWSで試算してみたらランニングコストがかなり高かったので、オンプレで構築しました。

田仲：当初WebRTCの採用も検討したんですが、少人数のグループでの映像配信には向いていると思うのですが、不特定多数に配信するこのサービスでは負荷対策の問題がありました。現在は、RTMPとHLSという技術を組み合わせて使用しています。

配信サーバーのリリース時は、使われていない配信サーバーから順に停止して入れ替えていくんですが、たいていの場合は人力で1台ずつリリースしていると聞きます。そこを自動化したことで、人的なコストとリリースにかかる時間を抑えることができました。

白石：配信はロードバランシングできるんですか？

田仲：視聴という意味では、配信サーバーからHLS形式でクラウドフロンドのCDNをはさんでます。配信のインプットはロードバランサーをはさむのは困難なことと、一度に大量のアクセスが来るものでもないので、振分ロジックをAPIサーバーの方で実装しました。それにより、配信負荷が均等になるように振分されます。

白石：大量のトラフィックが発生する視聴側はHLSで負荷分散をするわけですね。

ユーザー数に合わせたサーバーや開発体制の構築を

白石：最後に、今後サービスや開発の課題でチャレンジしていきたいことを聞かせてください。

田仲：当初予定していた視聴者数などの要件定義に耐えられるような構築したのですが、サービス開始直後ということもあり、まだそこまで利用されていない状態です。今後は利用状況に応じてスケーリングすることにより、ランニングコストの調整をしていきたいなと考えています。

植田：今回のプロジェクトでは、開発手法としてスクラム開発を取り入れました。社内でスクラム開発が増えてきているという背景もありますが、一番の理由は定期的に成果物を確認し合い、手戻りをなくしたいからです。

スクラム開発をやるにあたって、本やネットで調べて手探りでやってみましたが、わからないことがたくさんあったんですね。開発が一旦落ち着いてきたので、今度はもっと正規なスクラム開発をやってみようと思っています。

白石：ちなみにプロジェクト管理のツールは何を使ってるんですか？

杉野：JIRAを使っています。ドキュメント管理はConfluenceやGoogle Docsですね。あとはホワイトボードも活用しています。誰がどんな業務を抱えているのか、目で見てわかりやすいので。

山本：機能ドリブンで開発をしてきましたが、リリースしてわかったことや、自分たちが実際にユーザー側に立って使って感じたことを改善していきたいですね。

白石：DMMさんはエンジニアがチームで話し合って技術剪定をしているので、新しい技術にもチャレンジしやすい環境があって楽しそうですね。今日は興味深い話をいろいろ語っていただき、ありがとうございました！

2016年5月18～20日の3日間、Googleの本社ビルのすぐそばにあるショアライン・アンフィシアターでGoogle I/O 2016が開催されました。

例年5千名程の参加者から大幅に増えて、今年は実に約7千人の人々が参加していたようです。屋外イベント施設ということもあり、まるで野外フェスのような雰囲気でした。

本レポートではGoogle I/O最初のセッションである、基調講演の内容について紹介します。

Google Assistant

まず最初にスンダー・ピチャイ氏に紹介されたのが、Google Assistantです。

Google Assistantは新しい対話型のボイスアシスタント機能です。Google製のアシスタント機能といえばGoogle Nowがありますが、これを進化させ、対話型のシステムとしたのがGoogle Assistantのようです。コンテキストを認識し、ユーザーが質問すると現在地や直近のクエリーなどに応じて、適切に答えを返します。

例えば、有名な建築物の前で「これを設計したのは誰？」と質問すると、その場所の情報に応じて回答してくれます。

デモでは、ユーザーが「今夜やってる映画は？」と聞くと、Google Assistantは近くの映画館で上映しているタイトルをいくつか提示し、さらにユーザーが「子どもと一緒に行きたい」と言うと、子どもと一緒に鑑賞するのにふさわしいと思われる映画を提案していました。さらに「4枚チケットが必要ですか？」とGoogle Assistantが尋ねてくるので、ユーザが映画のタイトルや枚数を答えると、自動で予約し、チケットの情報を提示する、というデモが行われました。

このように、『提案をしてくれる』というのがGoogle Assistantの大きな特徴です。Google Assistantは基調講演の中で発表されたGoogle HomeやGoogle Alloなどの製品にも組み込まれるようです。

Google Home

続いてGoogle Assistantの機能を組み込んだGoogle Homeという製品が紹介されました。

Google Assistantのボイスアシスタント機能の他にWifiスピーカーとしての機能もあり、クラウドから音楽のストリーミング再生もできるようです。プレイリストやアルバムへのアクセスもボイスコントロールでき、Google Castを通して、AndroidやiOSのデバイスから音楽を送信することもできるとのことでした。

Amazon Echoと似たような製品のようです。大きさは手のひらに乗るくらいの小さなデバイスでした。今年の後半から使えるようになるとのことです。

Google Allo

次にAlloというモバイル用のメッセージングアプリが紹介されました。見た目はLineやFacebook messenger等と大差なく見えます。

文字や絵文字の大きさを自由に変えることができることが紹介されました。地味だが良い機能、ということで会場が少し盛り上がります。

しかし当然のことながら、ただのメッセージングアプリではありません。このAlloにはGoogle Assistantの機能が組み込まれており、なんとチャットのテキストや画像を解析して、返信用のテキストを複数提案してくれます。

例えば「Dinner later?」とチャットの相手が送ると、「I’m in!」「I’m busy」という返信用のメッセージが表示されます。ユーザは選んでクリックするだけでメッセージを送信することができます。

またチャット内の画像も解析されるので、誰かが犬の写真をアップロードすると、犬種も識別された上で、「Cude dog!」「Aww!」「Nice bernese mountain dog」といった返信メッセージが提示されます。

またGoogle Asisstantのbotががチャットの中に存在するようなかたちになっており、店のお店のサジェストや予約、検索等も対話形式でチャットの中で行うことができるようです。

さらにChromeのようにIncognito Modeが搭載されており、エンドツーエンドでの暗号化やNotificationの制御、メッセージの期限などを設定できるようになっているとのことです。

Google Duo

続いてDuoというビデオチャットアプリの紹介です。

ビデオチャットを実現するアプリは数多く世に出ていますが、このDuoにはビデオコールをかけられた側は、応答する前にそのビデオストリームを見ることができるという特徴があるようです。この機能は『Knock Knock』と呼ばれているそうで、これにより着呼側は誰が、どんな状況でコールしてきたのかを知ることができます。

コール先は電話番号に紐づくとのことで、AppleのFaceTimeの競合として考えられそうです。

DuoはWebRTCとQUICを使用したWebプロトコルベースのアプリと紹介されました。

AlloとDuoはAndroidとiOSで2016年夏頃リリースされる予定で、Android版では事前登録が開始されています。

• Google Allo
• Google Duo

Android N

続いてAndroid Nについての発表が行われました。

GoogleがAndroidの開発を行うようになってから、10年が経過したようです。今やAndroidはスマートフォンだけではなく、Android Wear、Android TV、Android Autoなど、多くのプラットフォームが登場しています。

Androidの最新バージョンであるAndroid Nは現在プレビュー版(6/28現在Developer Preview 4)が公開中です。こちらで名前の募集も行われていましたが、現在は終了し近日中に公開されるようです。

Android Nでは、新しいOSのアップデートがあると、自動的にソフトウェアをバッググラウンドでダウンロードし、次回Androidの電源を入れた際にシームレスで新しいソフトウェアイメージに切り替わるようです。

またマルチウィンドウが正式に採用され、スマートフォンでYoutubeを見ながら他のタスクを行ったり、Android TVでは映像を見ながら検索などの他の作業を行うことができるようになります。

現在はAndroid NのDeveloper Preview 4がリリースされており、Nexus 6やNexus 5X等の一部の対応した機種であれば、Android Nを試用することができます。(Android Developers Blog)

Daydream

続いてI/O開催前から噂が絶えなかったVRに関する発表です。

Androidスマートフォンで高品質なVR体験を提供可能であるDaydreamというプラットフォームが発表されました。

どのようにAndroidスマートフォン上で、高品質なVR体験を可能にするのか、講演では3つの要素が挙げられていました。 まずはスマートフォン本体、次にヘッドセットコントローラのリファレンスデザイン、そしてアプリで、ぞれぞれが協調してエンドツーエンドのユーザ体験を提供するために設計されています。

ハイパフォーマンスセンサーやヘッドトラッキング、表示のレスポンスの速さなど、VR用に作られた仕様を満たしたスマートフォンは、Daydream-readyと呼ばれ、高いクオリティのVR体験を提供することができます。Daydream-readyなスマートフォンは、SamsungやAlcatel、Asusなどの企業から、2016年秋以降リリースされるようです。発表された中に日本の企業はありませんでした。

リファレンスデザインとして紹介されたヘッドセットとコントローラは非常にシンプルなものでした。コントローラはボタンは少なくクリッカブルなタッチパッドがついており、スクロールやスワイプができます。オリエンテーションセンサーも内蔵しており、ユーザがどこをポインティングしているかが分かります。

アプリに関しては、VR用のGoogle Playが開発されており、ユーザーがアプリを探し、購入、インストールがVR上で可能になることが発表されました。またGoogle Play MoviesやGoogle Mapsのストリートビュー、Google Photos、YouTubeもVR上で鑑賞できるようになります。

Daydreamが使えるようになるのは2016年秋になるとのことですが、Android NのDeveloper Previewを使用することでアプリなどの開発は今から行うことができます。

Android Wear 2.0

Android Wearは2年前のGoogle I/Oで初めて発表されましたが、今回は初めて大幅なアップデートとなるAndroid Wear 2.0が発表されました。

大きな変化としては、今までAndroid Wearのアプリがインターネットにアクセスするためには母艦となるAndroidやiOSスマートフォンが必要であったことに対し、Android Wear 2.0ではスタンドアロンで動作することが可能になることが挙げられます。アプリが直接BluetoothやWi-Fi、LTEなどを通してインターネットにアクセスできるようになり、ペアリングされたスマートフォンが電源を切っている場合でも、アプリは引き続きフル機能を提供できるようになります。

その他にもUIの刷新や、手書き入力の対応等も発表されました。

Android Wear 2.0はプレビュー版が公開されおり、秋には正式リリースとなるようです。

Progressive Web AppsとAccelerated Mobile Pages

基調講演も終盤に差しかかり、ここで初めて、わずかですがWebについての発表がありました。 モバイルデバイス上でWebをより快適にするための取り組みとして、Progressive Web AppsとAccelerated Mobile Pagesの2つの紹介です。

Progressive Web Apps、略してPWAppsは、オフライン状態でも動作可能、エンゲージメントを高めるための通知、ホームスクリーンにアイコンを登録、といったネイティブアプリのような振る舞いを実現したWebアプリのことを指します。ChromeにはServiceWorkerをはじめとする、Progressive Web Appsを実現するための仕組みが実装されています。

Accelerated Mobile Pagesは、既存のWeb標準に基づいた非常に速いモバイルWebサイトを作るための、オープンソースのプロジェクトです。

特に新規発表はなく、基調講演内ではわずか1分程度の紹介でしたが、Google I/O全体では多くのPWAppsやAMPのセッションが行われていました。HTML5 Experts.jpでもGoogleが新たに提唱するProgressive Web Appsの新たな開発パターン「PRPL」とは？という記事を公開していますので、そちらをご覧ください。

Android Studio

Android Studio 2.2 Previewが公開されたと発表がありました。

Android Studio 2.2では、ビルドが10倍、エミュレータも3倍速くなっているそうです。また、新しいレイアウトデザイナやAPKアナライザーが搭載されるとのことでした。

Firebase

続いてFirebaseの新バージョンが発表されました。

FirebaseはGoogleが2014年の10月に買収したBaaSサービスです。モバイルアプリに特化した分析ツールである、Firebase Analyticsが発表されました。ユーザがアプリ内で何をしているか、ユーザがどこからきたのかなど分析することが可能です。Android AnalyticsはAndroidでもiOSも扱うことができ、無制限に無料で使用することができると発表されました。

Android Instant Apps

今回の基調講演の後半で一際注目を集めたのがこのAndroid Instant Appsではないでしょうか。

Webアプリの場合、ユーザはリンクをクリックするだけでアプリを使用することができますが、Androidアプリはインストールを必要とするため、ユーザがそこで離脱してしまうことが多くあります。その課題を解決する一手となるのが今回発表されたAndroid Instant Appsのようです。

今回発表されたAndroid Instant Appsでは、AndroidアプリがWeb等のリンクからインストールレスで使えるようなるとのことです。

講演中のデモの中では、いくつかのAndroidアプリをURLから起動し、実際にアプリを使用できることが示されていました。 アプリの中の直近で必要になるモジュールだけをフェッチしているらしく、起動も素早く行われ、アプリを使用してからのインストールも非常にスムーズに行えるようです。

これにより、Androidアプリ開発者は、より多くのユーザにリーチできるようになります。AndroidアプリとWebとの親和性が高くなり、Androidアプリのユーザ体験が大きく変わる機能となるのではないでしょうか。

おわりに

今年はGoogleのAIの技術力を発揮した製品やサービスが多く発表されました。

基調講演内でWebやChromeに関する発表は非常に少なかったのですが、Google I/O全体では33ものモバイルWebに関するセッションが行われていました。

既に公開されている

• 今、Webの最先端では何が起こっているのか？──最新機能目白押し！Google I/O 2016セッションレポート【前編】
• Webの最先端では何が起こっているか、今Googleが取り組んでいることは？──Google I/O 2016セッションレポート【後編】
• Googleが新たに提唱するProgressive Web Appsの新たな開発パターン「PRPL」とは？

以外にもセッションレポートを公開していく予定です。お楽しみに。

連載5回目の今回は、12月にアップグレードされたSkyWayのiOS/Android用SDKのチュートリアルをお届けします。

iOS/Android用SDKを使うことで、SkyWayの特徴である「WebRTCを使ったP2P通信を簡単に実現」することができます。 また、APIもJavaScript版とほぼ同じで、JavaScript版をすでに利用されている方にも実装しやすく、JavaScript/iOS/Android間での通信もサポートしています。

この記事では、そんなiOS/AndroidのSDKの利用方法を、それぞれサンプルアプリのビルド方法や解説を交えながらご紹介していきます。

まずは、iOSのサンプルアプリのビルド方法からご紹介します。Androidのみ開発される方は読み飛ばしてください。

iOSのサンプルアプリのビルド方法

まず、まだSkyWayに登録されていない方はSkyWayのサイトから開発者登録を行ってください。その際の利用可能ドメインですが、ドメインをお持ちでない方は「localhost」等、適当な文字列を指定してください。

次に、iOS SDKをダウンロードします。
iOS SDKのダウンロードページにアクセスして下さい。

ページ下部のDownloadsからダウンロードして下さい。 解凍したフォルダの中に「SkyWay.framework」というものが入っており、これがiOS SDK本体になります。

次はサンプルアプリプログラムのダウンロードを行います。
SkyWay-iOS-Sampleのレポジトリをクローンするかダウンロードを行って下さい。（下図はダウンロードする場合）

次に、サンプルアプリのフォルダにはSDKが含まれていないので、サンプルアプリプロジェクトにSDKを入れます。

先ほどのSkyWay.frameworkを「SkyWay-iOS-Sample > frameworks」内にコピーします。

サンプルアプリを動かすためには、開発者登録をした際のAPIキーとドメインを設定する必要があります。
では、サンプルアプリプロジェクトを開いて設定してみましょう。

SkyWay-iOS-Sample.xcodeprojをXcode（本記事ではVersion 7.1.1）で開き、
SkyWay-iOS-Sample > SkyWay-iOS-Sample内の「DataConnectionViewController.m」を開きます。

//
// MediaConnectionViewController.m
// SkyWay-iOS-Sample
//

#import "MediaConnectionViewController.h"

#import <AVFoundation/AVFoundation.h>

#import <SkyWay/SKWPeer.h>

#import "AppDelegate.h"
#import "PeersListViewController.h"


// Enter your APIkey and Domain
// Please check this page. >> https://skyway.io/ds/
static NSString *const kAPIkey = @"yourAPIKEY";
static NSString *const kDomain = @"yourDomain";


typedef NS_ENUM(NSUInteger, ViewTag)
{
  TAG_ID = 1000,
  TAG_WEBRTC_ACTION,
  TAG_REMOTE_VIDEO,
  TAG_LOCAL_VIDEO,
};

コードの上方部分に、上図のような箇所があるので、ここにAPIキーとドメインを設定して保存しましょう。

「MediaConnectionViewController.m」にも同様の箇所があるため、こちらも修正します。

ここまで終わったら、ビルドする端末を接続・選択して、ビルドをします。 以上がiOSのサンプルアプリのビルド方法です。

次はAndroidのサンプルアプリのビルド方法をご紹介します。 iOSのみ開発される方は飛ばしてください。

Androidのサンプルアプリのビルド方法

まずはiOSと同じく、まだSkyWayに登録されていない方はSkyWayのサイトから開発者登録を行ってください。その際の利用可能ドメインですが、ドメインをお持ちでない方は「localhost」等、適当な文字列を指定してください。

次に、Android SDKをダウンロードします。
Android SDKのダウンロードページにアクセスして下さい。

ページ下部のDownloadsからダウンロードして下さい。 解凍したフォルダの中に「SkyWay.aar」というものが入っており、これがAndroid SDK本体になります。

次はサンプルアプリプログラムのダウンロードを行います。
SkyWay-Android-Sampleのレポジトリをクローンするかダウンロードを行って下さい。（下図はダウンロードする場合）

次に、サンプルアプリにはSDKが含まれていないので、サンプルアプリ内にSDKを入れます。

先ほどのSkyWay.aarを「app > libs」内にコピーします。

サンプルアプリを動かすためには、開発者登録をした際のAPIキーとドメインを設定する必要があります。
では、サンプルアプリプロジェクトを開いて設定してみましょう。

サンプルアプリのフォルダををAndroid Studio（本記事ではVersion 1.4）で開き、
app > src > main > java > io.skyway.testpeerjava 内の「DataActivity.java」を開きます。

package io.skyway.testpeerjava;

import ...   //省略


public class DataActivity
    extends Activity
{
  private static final String TAG = DataActivity.class.getSimpleName();

  private Peer           _peer;
  private DataConnection _data;
  private Handler _handler;
  private String   _id;
  private String[] _listPeerIds;
  private Boolean  _bConnecting;
  private Runnable     _runAddLog;
  private List<String> _aryLogs;
  private Bitmap _image;


  @Override
  protected void onCreate(Bundle savedInstanceState)
  {
    super.onCreate(savedInstanceState);

    Window wnd = getWindow();
    wnd.addFlags(Window.FEATURE_NO_TITLE);

    setContentView(R.layout.activity_chat);
    _handler = new Handler(Looper.getMainLooper());

    Context context = getApplicationContext();


    //////////////////////////////////////////////////////////////////////
    //////////////////  START: Initialize Peer ///////////////////////////
    //////////////////////////////////////////////////////////////////////


    // connect option
    PeerOption options = new PeerOption();

    // Please check this page. >> https://skyway.io/ds/
    //Enter your API Key and registered Domain.
    options.key = "";
    options.domain = "";

    // PeerOption has many options. Please check the document. >> http://nttcom.github.io/skyway/docs/

    _peer = new Peer(context, options);
    setPeerCallback(_peer);

コードの上方部分に、上図のような箇所があるので、ここにAPIキーとドメインを設定して保存しましょう。

「MediaActivity.java」にも同様の箇所があるため、こちらも修正します。

ここまで終わったらビルドを行い、端末を選択します。 以上がAndroidのサンプルアプリのビルド方法です。

では、コードを参考にしながら、簡単にAPIの使い方を見ていきましょう。

ビデオチャットのコード

iOSとAndroidの二種類のSDKをご紹介をしましたが、この二つのAPIは細かいところを除いては、ほぼ同じです。また、サンプルアプリのコードもほぼ似通ったものとなっています。
そのため、ここではAndroidのビデオチャットのコードを参考にしながら、簡単にAPIの使い方をご紹介します。

また、WebRTC技術についての説明は割愛します。 詳しいWebRTCの仕組みについては、がねこまさしさんが書かれたコチラの記事をお読みください: 壁を越えろ！WebRTCでNAT/Firewallを越えて通信しよう

ではまず、APIの使い方の前に、サンプルアプリの動作を確認します。

このように、

• シグナリングサーバ^*1との接続とPeerIDの取得
• 自分の映像の取得と表示
• PeerIDの一覧取得
• 選択したPeerIDへの通話呼び出し
• 相手の映像の取得と表示

を行う、とてもシンプルなアプリです。

では、この動作に沿ってコードを見ていきましょう。
まずは、SkyWayとのサーバとの接続です。

//////////////////////////////////////////////////////////////////////
    //////////////////  START: Initialize SkyWay Peer ////////////////////
    //////////////////////////////////////////////////////////////////////

    // Please check this page. >> https://skyway.io/ds/
    PeerOption options = new PeerOption();

    //Enter your API Key.
    options.key = "";
    //Enter your registered Domain.
    options.domain = "";


    // SKWPeer has many options. Please check the document. >> http://nttcom.github.io/skyway/docs/

    _peer = new Peer(context, options);
    setPeerCallback(_peer);

    //////////////////////////////////////////////////////////////////////
    ////////////////// END: Initialize SkyWay Peer ///////////////////////
    //////////////////////////////////////////////////////////////////////

ここではSkyWayのシグナリングサーバとの接続を行っています。

まず、接続を行う時のオプションをPeerOptionクラスで設定します。
このクラスでまず必須なのは、SkyWayを利用するためには必須となる「APIキー」や「ドメイン」の設定です。
そのほかにも、SkyWayが提供するTURNサーバの利用を選択する「turn」プロパティや、自前のSTUN/TURNサーバを設定する「config」プロパティ等の設定が可能です。もっと詳しく知りたい方はドキュメントをご参照ください。

次に16行目では、このオプションを使ってシグナリングサーバと接続を行っています。
このPeerクラスはシグナリングサーバとの接続を管理しており、「connect/call」メソッドでのP2Pのデータ/メディア通信の開始や、「listAllPeers」メソッドでのAPIキー毎のアクティブなPeerIDを取得、などができます。
実際にサンプルアプリでは、「Calling」というボタンを押すとlistAllPeersメソッドを呼び出し、PeerID一覧の取得を行っています。

続いて17行目では、このPeerオプジェクトのコールバックを設定しています。
コールバックの説明の前に、ローカルの映像取得部分を見てみます。

//////////////////////////////////////////////////////////////////////
    ////////////////// START: Get Local Stream   /////////////////////////
    //////////////////////////////////////////////////////////////////////
    Navigator.initialize(_peer);
    MediaConstraints constraints = new MediaConstraints();
    MediaStream _msLocal = Navigator.getUserMedia(constraints); 

    Canvas canvas = (Canvas) findViewById(R.id.svSecondary);
    canvas.addSrc(_msLocal, 0);

    //////////////////////////////////////////////////////////////////////
    //////////////////// END: Get Local Stream   /////////////////////////
    //////////////////////////////////////////////////////////////////////

ここでは、ローカルの映像取得を行って、得た映像ストリームをViewに表示しています。
NavigatorオブジェクトのgetUserMediaメソッドを呼び出すことで、MediaSteamオブジェクトの映像ストリームを得ることができます。その際に、MediaConstraintsというオプションを指定することで、映像/音声の利用可否の指定、インカメラ/アウトカメラの指定、などを行うことができます。

また、CanvasクラスはGLSurfaceViewを継承しており、得た映像ストリームはCanvasオブジェクトのaddSrcメソッドで表示することができます(iOSのSKWVideoオブジェクトはUIViewを継承しています)。

では、話を戻してPeerオブジェクトのコールバックを見てみましょう。

//////////////////////////////////////////////////////////////////////////////////
    ///////////////////// START: Set SkyWay peer callback   //////////////////////////
    //////////////////////////////////////////////////////////////////////////////////
    // 簡単のため、適宜、省略しています

    // !!!: Event/Open
    peer.on(Peer.PeerEventEnum.OPEN, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // シグナリングサーバと接続された
        _id = (String) object;

        updateUI();
      }
    });

    // !!!: Event/Call
    peer.on(Peer.PeerEventEnum.CALL, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // 相手から通話がかかってきた
        _media = (MediaConnection) object;

        _media.answer(_msLocal);

        setMediaCallback(_media);

        updateUI();
      }
    });

    // !!!: Event/Close
    peer.on(Peer.PeerEventEnum.CLOSE, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // シグナリングサーバとの接続ステータスがdestroyedとなった
      }
    });

    // !!!: Event/Disconnected
    peer.on(Peer.PeerEventEnum.DISCONNECTED, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // シグナリングサーバとの接続ステータスがdisconnectedとなった
      }
    });

    // !!!: Event/Error
    peer.on(Peer.PeerEventEnum.ERROR, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // 何かしらのエラーが発生した
      }
    });

    //////////////////////////////////////////////////////////////////////////////////
    /////////////////////// END: Set SkyWay peer callback   //////////////////////////
    //////////////////////////////////////////////////////////////////////////////////

ここでは、シグナリングサーバから送られたイベントに対し、処理を行っています。

7行目は、シグナリングサーバとの接続が確立した際の「OPEN」イベントでの処理です。
ここでのObjectは、シグナリングサーバから自分に割り当てられたPeerIDが格納されており、サンプルアプリでは、そのPeerIDを表示しています。PeerIDはnew Peer時にIDを指定することもできますし、指定せずにランダムなIDを取得することもできます。

20行目では、他のPeerから通話がかかってきた際の「CALL」イベントでの処理です。
ここでのObjectはMediaConnectionクラスであり、answerメソッドを呼ぶことで、先ほど作成した自分の映像ストリームを返しています。引数を与えないことで、映像ストリームを返さないことも可能です。
そのあと、30行目でMediaConnectionのコールバックを設定しています。

このように、相手からの通話を受ける際は、Peerオブジェクトのコールバック内で「CALL」イベントで処理を行います。
自分から通話する場合は、下記のようにPeerオブジェクトのcallメソッドを呼びます。

//////////////////////////////////////////////////////////////////////
    ////////////////// START: Calling SkyWay Peer   //////////////////////
    //////////////////////////////////////////////////////////////////////
    // 簡単のため、適宜、省略しています

    CallOption option = new CallOption();

    _media = _peer.call(strPeerId, _msLocal, option);

    setMediaCallback(_media);

    //////////////////////////////////////////////////////////////////////
    /////////////////// END: Calling SkyWay Peer   ///////////////////////
    //////////////////////////////////////////////////////////////////////

この部分は、listAllPeersメソッドで得られたPeerIdの一覧から、通話したいPeerIDをタップした時に呼ばれます。

このように、呼び出し時のオプションを設定し（このコードでは何も設定していませんが）、通話をしたいPeerIDと自分の映像ストリームを指定してcallメソッドを実行します。返り値は通話がかかってきた際と同様、MediaConnectionクラスで、MediaConnectionのコールバックを設定しています。

では、MediaConnectionのコールバックを見てみましょう。

//////////////////////////////////////////////////////////////////////////////////
    //////////////  START: Set SkyWay peer Media connection callback   ///////////////
    //////////////////////////////////////////////////////////////////////////////////
    // 簡単のため、適宜、省略しています

    // !!!: MediaEvent/Stream
    media.on(MediaConnection.MediaEventEnum.STREAM, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        _msRemote = (MediaStream) object;

        Canvas canvas = (Canvas) findViewById(R.id.svPrimary);
        canvas.addSrc(_msRemote, 0);
      }
    });

    // !!!: MediaEvent/Close
    media.on(MediaConnection.MediaEventEnum.CLOSE, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        Canvas canvas = (Canvas) findViewById(R.id.svPrimary);
        canvas.removeSrc(_msRemote, 0);

        _msRemote = null;
        _media = null;

        updateUI();
      }
    });

    // !!!: MediaEvent/Error
    media.on(MediaConnection.MediaEventEnum.ERROR, new OnCallback()
    {
      @Override
      public void onCallback(Object object)
      {
        // 何かしらのエラーが発生した
      }
    });

    //////////////////////////////////////////////////////////////////////////////////
    ///////////////  END: Set SkyWay peer Media connection callback   ////////////////
    //////////////////////////////////////////////////////////////////////////////////

7行目は、通話相手の映像ストリームを取得した際の「STREAM」イベントでの処理です。ここでのObjectは、MediaStreamオブジェクトです。自分の映像ストリームと同じくCanvasオブジェクトを利用して表示しています。

20行目では、通話相手との通話が切断された際の「CLOSE」イベントでの処理です。

ここまでが、簡単なSkyWayを使ったWebRTCの処理になります。

最後に、最近のアップデートで追加されたメソッドについてご紹介します。

Button switchCameraAction = (Button)findViewById(R.id.switchCameraAction);
    switchCameraAction.setOnClickListener(new View.OnClickListener()
    {
      @Override
      public void onClick(View v)
      {
        Boolean result = _msLocal.switchCamera();
        if(true == result)
        {
          //Success
        }else
        {
          //Failed
        }
      }
    });

MediaStreamオブジェクトがローカルの映像ストリームの場合、switchCameraメソッドを呼び出すことができます。
これにより、今まではできなかった、「getUserMedia後のインカメラ/アウトカメラ切り替え」が可能になります。

以上が、サンプルアプリの簡単なコード解説になります。今回はビデオチャットだけの紹介でしたが、ほぼ同じようなAPIでテキストや画像が送れるデータチャットも可能です。

おわりに

今回は、SkyWayのiOS/Android用SDKのチュートリアルをお届けしました。

JavaScript版と同じように、手軽にWebRTCが利用可能です。 是非ご自身のアプリケーションに組み込んでみてください！

それでは実際、レスポンシブ・ウェブとは何についての対応（レスポンシブ）なのでしょうか。

現在のところ、私たちがいうレスポンシブ・ウェブデザインとは、どんなスクリーンの幅や表示領域、デバイスの画面解像度や画面の縦横の向きにも対応したウェブデザイン、というのが事実上の定義となっているようです。

そこで今回、私はその定義を超えたレスポンシブ・ウェブのユースケースについて考えてみました。

太陽光下でのスクリーン・リーダビリティ

私は普段の仕事ではNokia Lumiaというスマートフォンを使っているのですが、これがなかなかの優れもの。環境光センサーでスクリーンの輝度値を自動調整してくれるので、晴天の空の下でもスクリーンのコンテンツがはっきり読めるのです。ところが私の個人用で使ってる別機種の場合、そうもいきません。例えば読みたいウェブがたとえ「レスポンシブ」であれ「モバイル・ファースト」であれ、まぶしいカリフォルニアの空の下では、全くコンテンツが見えないので使い物にならないのです。

一方、W3CのCSSメーリングリストでは、次世代のCSS Media Queries 4のひとつである

luminosity

しかしこれが実現するのは一体いつの日になることやら…

Ambient Light Events API

というわけで、今現在のブラウザでは、CSSを使って環境光の度合いに合わせてウェブのUIを調整するのは不可能。

しかし私たちには、HTML5を使ってブラウザから各種センサーやカメラなどのハードウェアが持つ機能にアクセスするための仕様、デバイス APIのひとつであるAmbient Light Eventsがあるでないですか！
これならJavaScriptを使って環境光センサーから照度を知ることができるはず。これを使えば、次世代メディアクエリをまねて、太陽や照明にレスポンシブなウェブが作れるかもしれない！
そう思って私は、実験的に簡単なデモを書いてみました。

Devicelight events

デバイスのセンサーが照度の変化に反応すると、ブラウザ側では

DeviceLightEvent

devicelight

そこで得られるプロパティの値、

value

実際、大変簡単にこう書くことができます。

window.addEventListener('devicelight', function(event) {
  console.log(event.value + 'lux');
});

照度にレスポンシブなウェブを作ってみる

これを使って、環境光が変わってもウェブの内容を読みやすくするためのUIを考えてみました。

デフォルトではライトグレーの背景に黒の文字、明るい照度の時には白地に黒の文字、そして暗い時には暗めな背景に白の文字、というUIにしてみましょう。

例のAPIを使って、照度によってコンテンツのコンテイナー（このデモではわかりやすいように

document.body

window.addEventListener('devicelight', function(e) {
  var lux = e.value;

  if(lux < 50) {
    document.body.className = 'dim';
  }
  if(lux >= 50 && lux <= 1000) {
    document.body.className = 'normal';
  }
  if(lux > 1000)  {
    document.body.className = 'bright';
  } 
});

body,
body.normal {
  background-color: #ddd;
  color: #111;
}
body.dim {
  background-color: #444;
  color: #fff;
}
body.bright {
  background-color: #fff;
  color: #333;
}

実際に、このデモが動いている様子がわかる動画を作ってみました。

ブラウザサポートとデバイス

このデモで使われた実際のソースコードは、CodePenを見てください。

ほとんどの方の観覧しているブラウザ上では “AmbientLightEvent is not supported.” というメッセージが出ていて何も起こらないのではないでしょうか。というのも、残念ながら今のところ、このAPIをサポートしているのはFirefox 22+ だけ、しかもデバイス側にも環境光センサーが必要。
ですので、デスクトップから見ている皆さんには、どのブラウザを使っていてもこのデモは作動していないでしょう。私のデモで実際に使ったデバイスはNexus 7ですので、AndroidやFirefoxOSのデバイス持っている方は、ぜひFirefoxで試してみてください。

イベントが返す値も、デバイスによってばらつきがあるようです。私が実験した機種2機ではずいぶん違う結果が出ました。たぶんセンサーの精度にブレがあるのでしょう。

この写真にあるデバイスは、Moto G(Android)と、Keon(FirefoxOS)です。暗めの部屋での照度が、一方が6lux、もう一方が61luxとなっています。

CSS Media Queries Level 4 Luminosity

さて、話題をメディアクエリに戻します。
今現在の仕様では、メディアクエリ・レベル4はまだeditor’s draftの段階なので、ブラウザに実装されるまでにはまだまだ時間がかかりそうです。

将来的に実装された際には、このデモで書かれたコードはCSSのみでこのように書き直すことができるようになります。

@media screen and (luminosity: normal) {
  body {background-color: #ddd; color: #111;}
}
@media screen and (luminosity: dim) {
  body {background-color: #444; color: #fff;}
}
@media screen and (luminosity: washed) {
  body {background-color: #fff; color: #333;}
}

このように、

luminosity

おわりに

近い将来、レスポンシブ・ウェブの定義も、デバイスなどの多様性に合わせて変わってくるのではないでしょうか。このユースケースも実際果たして本当に役に立つのかどうかもまだわかりませんが、発想の転換とブラウザの新しい可能性、という面でこの記事を楽しんでいただけたかと思います。

この記事は元々は私個人のブログ（原文は英語）に掲載したのですが、TwitterやReddit、Hacker Newsで思いのほか話題になりました。やはりディベロッパ、デザイナは国境を問わず、みな新しい可能性に興味津々なのでしょう。

では。

WebRTCのAPIへの対応状況

バージョン24での対応状況は以下の通りで、それぞれPC版のFirefoxブラウザと接続して利用する事が可能です。

• mozGetUserMedia （PC版はバージョン20からサポート）
• mozRTCPeerConnection　（PC版はバージョン22からサポート）
• DataChannels （PC版はバージョン22からサポート）

Android版Firefoxとデスクトップ版Firefoxとの相互接続も可能です。

デモサイト

Mozillaが公開している WebRTC Test Landing Page にて動作を確認する事ができます。

編集部でも動かしてみた

Android版Firefox（バージョン24.0）と、MaxOS版Firefox（バージョン23.0.1）を利用してビデオチャットを試してみました。Android側は端末性能の問題だとは思いますが、かなりもっさりとしていましたが、機能として問題なく動くようです。

利用サービス：Multi-Person video chat

ログイン後はユーザリストが表示される

MacOS側から発信動作を行うとモーダルダイアログが表示される

Acceptするとカメラとマイクの利用許可を求められる

カメラについては、「バックカメラ」、「フロントカメラ」、「利用しない」の3種類から選ぶ事ができる。

正常に接続すると映像と音声が流れ始める

現在判明している問題

4件の問題が掲載されています。 最後の問題はFirefox特有というより、モバイル端末での映像処理全般に言えそうです。

• エコーキャンセラーに改善が必要（Bug 916331）
  　現時点ではヘッドセットの利用を推奨する
• 映像と音声の同期や音声遅延の問題（Bug 884365）
  　遅延に関してはバージョン25で改善予定
• 一部の端末でビデオキャプチャ時にクラッシュする問題がある（Bug 902431）
  　詳細は現在調査中
• 性能の低い端末や品質が悪い回線を利用した場合、高解像度＆適正なフレームレートの画像について、デコードや送信に問題が発生する可能性がある

WebRTCの活用範囲が広がる

Chromeに続き、FirefoxについてもPC版、Android版でWebRTCが利用できるようになりました。WebRTCについては仕様化の最中ではありますが、活用範囲が広がっていく事を大変嬉しく思います。HTML5 Experts.jp編集部では今後も最新動向をウォッチしていきます。

記事ソース：hacks.mozilla.org

ちなみに、次期バージョンはベータ版として現在でも触ることが可能です。Google Chrome Beta for Androidはこちら

次期バージョンでの変更点は以下のとおり。かいつまんで書きますので、詳しく知りたい方はChromium Blogを参照してください。

• WebGLがAndroid版でもデフォルトでオンになります！IE11もサポートすることですし、だんだんWebGLの使える領域が広がってきました。これは来年あたり、Web+3Dの大波がきそうな予感です。
• デバイスの「動き」を検知することができるDevice Motion Event APIに対応。
• Media Source ExtensionsがAndroid版でも利用できるように。このAPIを用いれば、メディアデータを動的にvideo要素/audio要素で再生できるようになります。WebSocketで受け取ったメディアデータの断片を再生する……ということも可能でしょう。
• いくつかの新しいChrome Apps APIをサポート。特に、アプリ内課金 (In-app payments)が可能になるのが大きいのではないでしょうか。
• [WebRTC Device Enumeration API] をサポート。MediaStreamTrack.getSources()というAPIを用いて、デバイス上のマイクやカメラの一覧を取得することができます。このAPIを使用すると、WebRTCコールを再起動することなく、マイクやカメラを切り替えることができます。
• 開発者ツールが、CSSのソースマップに対応しました。これで、SassやLessなどのプリプロセッサが出力するCSSをよりデバッグしやすくなります。
• Android版が、Web Speech APIとVibration APIをサポートしました。フラグの設定が必要です。

Chromeの今後について気になる方は、chromestatus.comが必見です。 ぼくも久しぶりにこのサイトを見たのですが、昔に比べてめちゃくちゃ見やすく、綺麗になっています。Chrome以外のブラウザの実装状況や、実装を検討している機能についての（Googleが見た）Web開発者からの反応などもまとめられており、まさにWebの最新状況がわかるサイトと言っても過言ではありません。