Anyca におけるUIフレームワークとスマホによるドア操作の仕組み

Copyright © DeNA Co.,Ltd. All Rights Reserved.
Anyca におけるUIフレームワークと
スマホによるドア操作の仕組み
January 29, 2016
Shuhei Kawasaki
取締役 (元CTO)
DeNA Co., Ltd.

自己紹介
 1975年生まれ (40歳)
 得意分野：サービス設計・開発・運用
 苦手分野：マネジメント、多人数プロジェクト
 初期の開発サービス
 モバオク、ポケットアフィリエイト、モバゲータウン、他
 最近の開発サービス
 Showroom（iOS/Android アプリ側のみ）
 プログラミング教育（Android アプリ）
 Anyca（サーバ／iOS アプリ）← C2C カーシェアサービス
2

Anyca のご紹介
 C2C のカーシェアリングサービス（2015年9月正式リリース）
 レンタカーではなく、個人オーナーの車を共同使用
 基本的にはスマホ ( iOS / Android ) 向けサービス
⁃ PC でも掲載車の一覧等は見られます。
 自動車保険には Anyca からの予約と連動して自動加入
 レンタカーにはないようなクルマに安価で乗れるのがウリ
 人気車だと、3万〜10万円/月のオーナーさんも多数
 スマホからのドアロック操作で、オーナーさんとの立ち合いなしでの乗車も可能
（近日リリース予定）
3

こんな感じ
4

今日話すネタ
1) AnycaにおけるiOS向けUIフレームワークの紹介
2) スマホからのクルマのドアロック操作の仕組み
5

AnycaにおけるiOS向けUIフレームワーク
Anyca iOS 版の開発のために書いたやつを紹介します
6

Anyca での開発方針
 デザインは先進的な印象を与え、同時に信頼感を与えるものに
 デザイン主導の開発
 操作感を大事にするために、可能な限り Native UI で実装
 iOS 版先行で開発してUI/UXを固め、Android 版はそれに追従するかた
ちで移植
 機能数が多く、コード量が増えそうなので swift で書く
※ 開発当初は swift1.2、リリース直後に iOS9 リリースと共に swift2 になったので移行、、、
 画面数が多く、UI/UX 調整も多くなりそうなので、UI 作成・修正が楽
にできるようにする
7

8
なかなかに多い画面数（一部主要ページ抜粋。実際はこの倍以上。途中でデザインのリファインも入る。）

Interface Builder を使わない方針で
 必要機能が多く、それに合わせて画面数も膨大になることが予想された。
 保険の連携や、サービスの立て付け、その他の契約等、未確定要素が多
数ある中での開発だったため、開発途中での仕様確定や変更が多々起こ
ることが想定された。
 なので、共通パーツや共通スタイルの扱い、一括修正等が楽な構成にし
ておきたかった。
⁃ autolayout の制約を頻繁に書きなおすのは辛そう
⁃ Interface Builder で、ひとつひとつプロパティを設定するのが面倒
⁃ でも、全部コードで書くのはもっと面倒だし見通しが悪くなる
9
（自分的に）楽にUIが作れる枠組みを書くことに

UIフレームワーク概要
 xml でのマークアップ方式
⁃ android の layout xml を簡素にした感じ
⁃ xib や storyboard も内部形式は xml だけど、あれを手書きはちょっと無理
 フレームワークがカバーするのはView生成と汎用UI処理のみとして、
Controller のロジックは素直に native (swift) で書く
 できるだけ記述量が少なくてすむような仕様
⁃ style や include にも対応
⁃ IBOutlet / IBAction との紐付けは不要（というか、できない）
 基本的な UI 処理はレイアウトファイル側だけで記述できるような仕様
 アプリのリビルドなしでのレイアウト修正反映→確認が可能
⁃ swift1.2 時代は、プロジェクトサイズが中規模以上になるとリビルドに２分くらいかかってた
 当初は android / iOS の両方に同一レイアウトファイルが使えるようにしようとしましたが、複雑に
なるので一旦 iOS 専用ということで。
 洗練された汎用フレームワークを作るのが目的ではないので、とりあえず Anyca 特化で使えればいい
や仕様。
10

サンプルレイアウト表示例 ( layout_sample.xml )
11
※このレイアウトの xml 内容は次スライドにて
デバッグモード時このボタンを押すと
表示中ページで使われるレイアウトを
ネットワークから取得して置き換えられます

レイアウト xml 定義内容 ( layout_sample.xml )
12
<Layout viewcontroller="SampleViewController">
<Include file="styles.xml" />
<NavigationItem>
<Include file="ui_bar_item_back.xml" onclick="back" />
<BarItem position="title">
<Label class="titleLabel" text="サンプルページ" />
</BarItem>
</NavigationItem>
<Views align="both" valign="both" background="#e6e6e6">
<View class="card">
<View orientation="horizontal" align="both" valign="both" height="45" onclick="push:layout=layout_profile_owner">
<Include file="ui_icon45x45.xml" src="icon_user.png" tintcolor="${keyColor01}" />
<Label text="プロフィール編集" size="13" color="${textColorImportant}" valign="center" />
<Image class="more" marginright="15" />
</View>
</View>
<View orientation="horizontal" align="center" height="40" onclick="customAction1:arg1=value1;arg2=value2">
<Label size="10" color="${textColor}" text="アプリバージョン" />
<Label size="10" color="${textColor}" text="1.0" id="app_version" />
</View>
<View class="filledButton" margin="10" id="login_button" onclick="modal:layout=layout_login">
<Label class="filledButtonText" text="ログイン" />
</View>
</Views>
</Layout>
※説明のため、実際に使用している記法から若干修正してます。

コードからの利用例 ( SampleViewController.swift )
13
class SampleViewController : UIViewControllerEx {
override func viewDidLoad() {
super.viewDidLoad()
// id 指定でビューを取得
if let label = self.views["app_version"] as? UILabel {
label.text = "2.0"
}
// 指定 id の view の onclick の引数設定
if let view = self.views["login_button"] {
view.exData.onClick.params["login_from"] = "sample_page"
}
// 遷移元から渡されたパラメータの取得
let arg1 : String? = self.params["arg1"]
}
// view タップ時のカスタムアクション
override func onClickView(view: UIView) {
if let onClick = view.exData.onClick {
if (onClick.action == "customAction1") {
self.customAction1(onClick.params["arg1"], onClick.params["arg2"])
}
}
super.onClickView(view)
}
}
※説明のため、実際に使用している記法から若干修正してます。

利点・欠点
 テーマカラーの変更や、共通パーツの一括デザイン変更が楽
 実機／エミュレータ表示を確認しながらのデザイン調整が楽
 コピペやスクリプトによる一括処理が楽
 クリックイベント処理や画面遷移処理がフレームワーク化されているので、詳細な操
作ログが追加実装なしでとれる
 アプリ更新なしにレイアウトの動的追加／変更が行える（現状やってませんが）
 独自のものなので、新規に入る人には習得コストがちょっとかかる
 良くも悪くも HTML 的
 コード側も JavaScript 的に書けるようになるので、見通しの悪いコードを書こうと
思えばいくらでも書ける
 最適化をほとんどしてないのでパフォーマンス改善の余地あり
 etc...
 時間ができたらちゃんと整理して、Android 対応もしたいなぁと、、
14

スマホからのクルマのドアロック操作の仕組み
〜 IOT 的なもののケーススタディーとして〜
15

どんな機能か？
 スマホからドアの施錠／解錠を行うことで、ドライバーが、予約したク
ルマにオーナーとの立会なしで利用できる仕組み (*1)
 クルマの OBD2 (On-Board Diagnostics) 端子に Anyca から貸与されるデバイ
ス（スマートデバイス）を接続することで利用可能となります (*2)
 近日クローズドで試験運用を始めながら、徐々に提供拡大予定
16
1) スマートデバイスを利用する予約リクエストは、１回以上立ち合いでの鍵の受け渡しによるシェア
を行った実績があるクルマに対してのみ可能となります
2) 現時点での対応メーカーは、LEXUS, TOYOTA, NISSAN, BMW, Mercedes-Benz となっています

装着イメージ
17
OBD2端子
※ オーナーはデバイス装着後、スマホからデバイス初期登録操作を行う

ご利用の流れ
1. ドライバーがスマートデバイス対応のクルマに予約リクエストする
2. オーナーが予約リクエストを承認して予約成立
3. ドライバーはシェア当日、クルマの近くまで行ってスマホで解錠操作
※ 解錠操作時には、免許証番号（下８桁）の入力が必要（の予定）
4. ドライバーは車内に置かれたクルマの実キーを入手 (*1)
※ 以降、返却まではドアの開閉やエンジンのON/OFFは実キーを使用
5. 返却時、ドライバーは実キーを元の場所に戻して、スマホで施錠操作
18
1) オーナーは予約日時に合わせて、あらかじめキーを車内のダッシュボード等に入れておきます

構成図（概略）
19
DeNA ネットワーク
車両
Anyca 車載デバイス
OBD2端子
BLEモジュール
マイコン3Gモジュール
Anyca 通常サービス
ネットワーク
Anyca スマートキーサービス
ネットワーク
電源供給
ドアロック操作命令、他
BLE 近接通信
(Bluetooth Low Energy)
HTTPSHTTPS
ドアロック操作要求
（ワンタイムリクエスト）
ドアロック操作要求照合
その他、外部API
予約情報登録
端末公開鍵登録
その他、内部API
予約リクエスト
予約車情報取得
端末公開鍵登録、他
車両情報
ユーザ情報
端末公開鍵情報
シェア履歴情報
予約情報、他
端末公開鍵
端末秘密鍵
ドライバー端末
ユーザ情報
車両情報
予約情報
チャット情報、他

開発体制
 プロトコル設計とサーバ＆アプリ側の開発は DeNA
 車載デバイスの設計と、車載デバイスのプログラム開発は外部
20

車載デバイス観点での重要ポイント
 消費電力の制約
⁃ 車の管理を自社でできるわけではないので、待機電力を最小限に留
める必要がある
• Anyca 車載デバイスの場合、実測で、待機時（BLE待受のみ）で約2.5mA、
マイコン+3Gモジュール起動時で約30mA、3G通信時約130mA
• 参考）車両自体の待機時消費電流（暗電流）は 20-50mA 程度、アフター
マーケットの盗難防止装置で〜3mA程度、ルームランプ 5W なら 416mA
 マイコンのスペック上の制約
⁃ 制御用のマイコンは処理速度・メモリ容量共に制約が非常に厳しい
• 暗号関連の処理を行うのは、処理速度・プログラムサイズ的にも厳しい
⁃ プログラマブルな 3G モジュール等もあり、最近のものは処理速度・RAM容量共余裕があるので、
そういうのを使えば車載デバイス側で暗号関連処理を行うことも可能ですが、プログラム構成が
複雑になるので今回は非使用
21

開発・運用観点での重要ポイント
 車載デバイス側のプログラム開発が内製ではないので、、
⁃ QA や問題の切り分けがしやすいように、シンプルなプロトコル設計にする
⁃ 車載デバイス側に複雑な処理はできるだけさせないようにする
• それにより、仕様変更がしやすくなるというメリットもある
 通常サービス側と鍵開けサービスは分離する
⁃ 通常サービス側のバグやオペミスが鍵開けサービスに影響しないように
⁃ 通常サービス側のサービス向上のための開発のスピードを殺さないように
⁃ 鍵開けサービス側のデータやシステムには限られたしか触れないように
22

セキュリティ観点での重要ポイント
 万が一の場合の被害が大きい
⁃ 車両盗難時の金銭的被害
⁃ 車両盗難からの犯罪への利用
 通常より高いセキュリティ設計が必要となる
 スマートデバイス装着によって、通常より盗難対象として狙われや
すい状態が作られることがないように（*1）
 ドライバーの鍵が奪われた場合の被害は、アカウント／鍵を奪われた当
人だけでなくオーナーにも及ぶ
⁃ アカウント（特に休眠ユーザの）乗っ取りへの耐性が重要
⁃ スマートデバイス利用ドライバーの本人確認が重要
23
1) 車両盗難の手口として、ドア開け自体は難しいものではないですし、エンジンをか
けるのにもイモビカッターを使ったやりかたが主流（？）なので、それらとの相対
感において適切なセキュリティ設計を行うことが肝要。

24
ご意見、ご質問等は懇親会にて是非！

Anyca におけるUIフレームワークとスマホによるドア操作の仕組み

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Anyca におけるUIフレームワークとスマホによるドア操作の仕組み

Similar to Anyca におけるUIフレームワークとスマホによるドア操作の仕組み (20)