今回はこのライブ配信アプリ「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さんはエンジニアがチームで話し合って技術剪定をしているので、新しい技術にもチャレンジしやすい環境があって楽しそうですね。今日は興味深い話をいろいろ語っていただき、ありがとうございました！

連載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が利用可能です。 是非ご自身のアプリケーションに組み込んでみてください！

Chrome 45でES2015のArrow Functionsに対応

9月1日にChrome 45がリリースされました。

Chrome 45ではJavaScriptエンジンのV8が更新され、ECMAScript 2015のサポートが向上しました。新たにサポートされた機能には、関数の読みやすさ・書きやすさが上がるArrow Functionsがあります。同月リリースされたNode 4.0でもArrow Functionsが使えますし、これから見る機会が増えてくるかなと思います。

パフォーマンス改善点として、スクロール中のカーソル位置を更新しなくなったというものがありました。スクロール中に:hoverのスタイルやマウスイベントが反応すると、不必要な処理や描画が増えてしまうため、パフォーマンスが低下します。今回の変更で、IEやFirefoxとだいたい同様の挙動（スクロール停止100ms後にカーソル位置を更新）となったようです。WebKitも今年春に同様の変更を行ったようなので、今後はスクロール中にスタイルを無効にし、タイマーを仕掛けスクロール後に再適用するなんてことをしなくてもよくなりそうです。

Alliance for Open Media設立

9月1日にGoogle, Microsoft, Mozilla、ほか数社が、ロイヤリティフリーなビデオコーデックを推進するアライアンスの設立を発表しました。

• ビデオの特許使用料をなくすためのアライアンスを結成しました | Mozilla Japan ブログ

Webでのビデオコーデックというと、HTML5のvideo要素やWebRTCが求めるコーデックで激しい議論が行われた過去があります。映像・機器業界などが推し進めるコーデック（video, WebRTCともH.264）が特許使用料を求めるため、Webのオープン性との関わりから反対があるのです。

次世代コーデックとしてはHEVC（H.265）が出ていますが、新たなパテントプールHEVC Advanceがコンテンツ提供者からの使用料徴収を検討していることから、ストリーミング配信事業者から警戒されています。Alliance for Open MediaではCiscoのThor、MozillaとXiph.OrgのDaala、GoogleのVPシリーズといったビデオコーデックをはじめ、ロイヤリティフリーなフォーマットや音声コーデックを推進していくとしています。

WOFF2の圧縮アルゴリズムBrotliをサーバにも

Webフォントのフォーマット、WOFF2で採用された圧縮アルゴリズムBrotliを一般的なコンテンツの圧縮にも適用しようという動きが進んでいます。Blink, Geckoで実装が進められています。

• Introducing Brotli: a new compression algorithm for the internet – Google Open Source Blog

WOFF 1.0ではDEFLATEアルゴリズムが採用されましたが、圧縮率の点では新しいフォーマットに劣ります。WOFF2では当初LZMAなど圧縮率の高いアルゴリズムを検討していたのですが、メモリの使用量が大きいことやLZMAの仕様が存在していないことなどから、代わりのアルゴリズムとしてGoogleが開発し、そして採用されたのがBrotliです。

• WOFF 2.0 Evaluation ReportとBrotli – fragmentary

Content-Encodingでの利用によって、gzipよりもさらにbandwidthの削減を見込めます。プロキシソフトFiddlerの開発者Eric Lawrence氏がBrotliを試したところ、gzipに比べてCSSでは12％、JavaScriptでは9％の削減がみられたそうです。

FacebookやCloudFlareなども興味を示しており、今後の普及が期待されます。

iOS 9のコンテンツブロッカーに賛否

9月16日にiOS 9がリリースされました。iPhone 6sの機能も話題ですが、iOSの新機能、コンテンツブロッカーが話題となっています。

• Surfin’ Safari – Blog Archive » Introduction to WebKit Content Blockers

コンテンツブロッカーを使うアプリをインストールすると、Safariは広告とおぼしきリソースをダウンロード＆実行しなくなるため、表示時間やメモリ使用量が減るといった利点があります。反面、広告による収益が多くを占めるWebにおいて、こういったものが広まるのはWebに良い影響をもたらさないという反応もあり、なかなかに激しい議論が起こっています。

広告ブロックの是非はさておき、コンテンツブロッカーを使うアプリにはWebフォントをブロックするオプションも用意されていたりします。WebKitはWebフォントが読み込まれるまでテキストを表示しないため、回線速度やサーバーの性能、フォントファイルの容量によってはページを見られるまでに非常に時間がかかります。

コンテンツブロッカーがWebフォントをブロックできるようにしたのはそのためかと思われますが、ブロックされてしまうとアイコンフォントが読み込まれなくなります。リガチャを利用したアイコンフォントであればテキストが読めるかと思いますが、Private Use Area上のコードポイントにアイコンを設定しているフォントは問題になるでしょう。最近はSVGでのアイコンスプライトが流行っている感じがするので、アイコンフォントに問題を感じる方は試してみてはいかがでしょう。

Firefox 41でCSSの縦書きが可能に

9月22日にFirefox 41がリリースされました。

• Firefox 41リリースノート

今回のリリースでは、CSS Writing Modesの基礎部分に対応しました。writing-modeプロパティやtext-orientationプロパティが使えるようになったので、基礎的な縦書きが実現できます。

またFirefox 41では、Document.execCommand('cut')とDocument.execCommand('copy')がサポートされました。Webアプリなどでクリップボードにコピーさせたい場合、これまではFlashを使う方法が使われてきましたが、それをJavaScriptで実現できます。Chromeも春頃に対応したので結構使えそうですね。

• Flash-Free Clipboard for the Web — Mozilla Hacks
• Cut and Copy Commands — Google Web Updates

開発者ツールには、選択したノードのスクリーンショットを撮るコンテキストメニューが追加されました。これまでも開発ツールバーからコマンドを打てば特定のノードのスクリーンショットを撮れたのですが、CSSセレクタを調べなければならず面倒でした。今回右クリックというUIがついてかなり使いやすくなりました。

ノードを選び右クリックメニューにある”Screenshot Node”を選ぶだけ

元記事は非常に長大、かつ詳細なため、全てのポイントを紹介することはとてもできません。素晴らしい記事ですので、関心のある人は、ぜひ元記事を参照してください。

ちなみに、最初にガッカリさせることになってしまいますが、@firt氏によれば、「1.0以降最もバグの多いバージョンだ」（this is the buggiest Safari version since 1.0）だそうです…

UIが大幅に変更、フルスクリーン（に近いサイズ）がデフォルトに

Webブラウジングをしている最中は、フルスクリーンがデフォルトになりました。ホスト名部分をクリックしたり、トップに戻るようスクロールを始めた時に、URLバーとツールバーが表示されます。

Webページはフルスクリーンに近いサイズで表示される

ユーザーの操作に応じてツールバーが出現する

問題は、ツールバーの表示／非表示が切り替わった際にresizeイベントが発生せず、メディアクエリなどでも検知できないことです。これにより、画面の高さが変わったことをアプリが検知できないということになり、なるべく固定の幅や高さを確保しようとするゲームなどでは、時に大きな問題になります。 また、ネイティブではないスクロール（iframeやoverflow:scroll、JavaScriptベースのスクロールなど）を使用しているアプリの場合は、ツールバーが表示されっぱなしになってしまう事があります。

Appleのサイトもネイティブのスクロールを使用していないためか、URLバーとツールバーが表示され続ける

新しいジェスチャー

新しいSafariでは、画面端からスワイプするというジェスチャーに操作が割り当てられました。 画面の下端から上に向かってジェスチャーすることでコントロールセンターを表示でき、画面の横端から右／左にスワイプすることで「戻る／進む」といったナビゲーションを行えます。

スワイプ操作を取り扱っているWebアプリは、画面端に適切なマージンを設けていない限り、これらのジェスチャーと被ってしまう可能性があります。

また、右・左のスワイプ操作に割り当てられている「戻る／進む」と言ったナビゲーションは、ナビゲーション前後のページが重ねて表示されます。こうした動作は、履歴管理API（History API）を用いる単一ページアプリケーションでは多少問題になるかもしれません。同じアプリのUIが重ねて表示されることになるためです。

History APIを使用するアプリケーションでは、同じアプリのUIが重ねて表示されてしまう

HTML5関連の変更

• track要素のサポート・・・動画や音声に対して、文字による補足情報（字幕やチャプタータイトルなど）を追加できる、track要素がサポートされました。JavaScript API（webkitHasClosedCaptions）やCSS（::cue擬似要素）もサポートされています。ただし、::cue擬似要素で使用できるプロパティはtext-shadow, opacity, outlineだけです。
• progress要素のサポート・・・進捗状況を表すprogress要素がサポートされました。また、meter要素はサポートしようとした形跡はあるものの、画面に何も表示されないというバグがあるそうです(^^;意図的に無効にされており、利用できません。(エキスパートNo.18 矢倉さんの指摘により修正)
• output要素のサポート・・・プログラムによる計算結果を意味すすoutput要素がサポートされました。
• input要素のdatetimeタイプが削除された・・・代わりに、dateタイプとtimeタイプを合わせて使うことが推奨されています。datetime-localタイプを使用してください。(エキスパートNo.18 矢倉さんの指摘により修正)
• iframe要素のseamless属性がサポートされた・・・シームレスなiframeには、親要素のCSSが適用されます。

JavaScript API関連の変更

• Page Visibility APIのサポート・・・ページの表示状態（表に表示されているか、裏に回っているか）を検知できるAPI
• XMLHttpRequest Level2のフルサポート・・・blobの送受信やアップロードの進捗状況を取得すると言った事が可能になりました。(エキスパートNo.18 矢倉さんの指摘により削除。XMLHttpRequest Level2は、仕様としてはもはや存在せず、XMLHttpRequestの仕様に統合されています)
• AirPlay APIが導入されました・・・Apple TVと連携したAirPlayを、Webアプリケーションから制御することができます。
• CanvasのAPIが拡充・・・globalCompositeOperation属性やPathクラスがサポートされました。
• Shared Workerが削除・・・複数のWebページ間で一つのワーカーインスタンスを共有するためのShared Workerが削除されました。
• WebSpeech Synthesis APIがサポートされましたが、正しく動作しません。
• MutationObserverがサポートされました。
• requestAnimationFrameからwebkitプレフィックスが取れました。
• transitionendイベント名からwebkitプレフィックスが取れました。
• Web Audio APIからwebkitプレフィックスが取れました。
• hidden属性がサポートされました。
• visibilityState属性がサポートされました。
• window.doNotTrackプロパティがサポートされました。
• Web SQL Database APIが、5MB以上のストレージ容量を扱えなくなりました（以前は上限50MBまで利用可能だった）。5MB以上のデータを保存しようとすると例外（DOMException）が発生します。

CSS関連の変更

• position:stickyのサポート・・・position: stickyを指定された要素は、スクロールによって表示領域から追い出されそうになると、画面端に吸い付くように表示されます。こちらのデモで動作を確認することができます。

  

  position: stickyをMobile Safariで動作させた様子

• CSS Regions・・・複数の要素にまたがってコンテンツを「流しこむ」ことができ、雑誌のようなレイアウトを実現できます。こちらのデモを試してみてください。

• CSS Grid Layout・・・要素をグリッド状に配置することのできる仕様です。うまく動作しないそうです。
• CSS Flexbox・・・コンテナ上で要素を縦横に柔軟に配置することのできる仕様です。

• 動的なフォント・・・筆者も詳細は理解できていないのですが、「読みやすさを向上するために、現在のフォントサイズをベースとして、フォントの重さや文字の間隔などが調整される、とあります。以下に示すような、-apple-というプレフィックスを持つ定数を多数利用してフォント定義を行っていくようです。

  h1 { font: -apple-system-headline1 } p { font: -apple-system-body }

• CSS Transitionからプレフィックスが取れた

• 丸や四角、多角形などの図形にしたがってコンテンツの切り抜きを行えるCSSクリップパスのサポート。
• フォントのカーニングや合字がデフォルトで利用可能になった
• box-decoration-break: slice/cloneのサポート
• tab-sizeのサポート
• overflow-wrap: normal/hypernate/break-word
• 長さの単位としてのchやvmaxのサポート
• mask-type: alphaのサポート

終わりに

iOS 7のMobile Safariは、Indexed Database APIやWebGL、WebRTCなどの期待される機能は搭載されませんでしたが、細かいアップデートがたくさん行われています。 特に、track要素やCSS Flexboxのサポートは嬉しいですね。 ただ、バグが多いらしいので、Web開発者は頭を悩ませる日々が続きそうです…

この記事では、Webページを記述する際にポイントとなりそうな変更点に絞ってご紹介しました。 繰り返しになりますが、この記事の元になったMaximiliano Firtman氏（@firt）のブログ記事は素晴らしいリソースですので、ぜひ一度目を通してみてください。