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


3

Anyca のご紹介

C2C のカーシェアリングサービス（ 2015 年 9 月正式リリース）

レンタカーではなく、個人オーナーの車を共同使用基本的にはスマホ ( iOS / Android ) 向けサービス

⁃ PC でも掲載車の一覧等は見られます。

自動車保険には Anyca からの予約と連動して自動加入レンタカーにはないようなクルマに安価で乗れるのがウリ人気車だと、 3 万〜 10 万円 / 月のオーナーさんも多数スマホからのドアロック操作で、オーナーさんとの立ち合いなしでの乗車も可

能（近日リリース予定）


4

こんな感じ


5

今日話すネタ

1) Anyca における iOS 向け UI フレームワークの紹介

2) スマホからのクルマのドアロック操作の仕組み


6

Anyca における iOS 向け UI フレームワーク

Anyca iOS 版の開発のために書いたやつを紹介します


7

Anyca での開発方針

デザインは先進的な印象を与え、同時に信頼感を与えるものに

デザイン主導の開発

操作感を大事にするために、可能な限り Native UI で実装

iOS 版先行で開発して UI/UX を固め、 Android 版はそれに追従するかたちで移植

機能数が多く、コード量が増えそうなので swift で書く

※ 開発当初は swift1.2 、リリース直後に iOS9 リリースと共に swift2 になったので移行、、、

画面数が多く、 UI/UX 調整も多くなりそうなので、 UI 作成・修正が楽にできるようにする


8

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


9

Interface Builder を使わない方針で

必要機能が多く、それに合わせて画面数も膨大になることが予想された。保険の連携や、サービスの立て付け、その他の契約等、未確定要素が多

数ある中での開発だったため、開発途中での仕様確定や変更が多々起こることが想定された。

なので、共通パーツや共通スタイルの扱い、一括修正等が楽な構成にしておきたかった。⁃ autolayout の制約を頻繁に書きなおすのは辛そう⁃ Interface Builder で、ひとつひとつプロパティを設定するのが面

倒⁃ でも、全部コードで書くのはもっと面倒だし見通しが悪くなる

（自分的に）楽に UI が作れる枠組みを書くことに


10

UI フレームワーク概要

xml でのマークアップ方式⁃ android の layout xml を簡素にした感じ

⁃ xib や storyboard も内部形式は xml だけど、あれを手書きはちょっと無理

フレームワークがカバーするのは View 生成と汎用 UI処理のみとして、Controller のロジックは素直に native (swift) で書く

できるだけ記述量が少なくてすむような仕様⁃ style や include にも対応

⁃ IBOutlet / IBAction との紐付けは不要（というか、できない）

基本的な UI 処理はレイアウトファイル側だけで記述できるような仕様アプリのリビルドなしでのレイアウト修正反映→確認が可能

⁃ swift1.2 時代は、プロジェクトサイズが中規模以上になるとリビルドに２分くらいかかってた

当初は android / iOS の両方に同一レイアウトファイルが使えるようにしようとしましたが、複雑になるので一旦 iOS 専用ということで。

洗練された汎用フレームワークを作るのが目的ではないので、とりあえず Anyca 特化で使えればいいや仕様。


11

サンプルレイアウト表示例 ( layout_sample.xml )

※このレイアウトの xml 内容は次スライドにて

デバッグモード時このボタンを押すと表示中ページで使われるレイアウトをネットワークから取得して置き換えられます


12

レイアウト xml 定義内容 ( layout_sample.xml )<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>

※説明のため、実際に使用している記法から若干修正してます。


13

コードからの利用例 ( SampleViewController.swift )

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) }}

※説明のため、実際に使用している記法から若干修正してます。


14

利点・欠点

テーマカラーの変更や、共通パーツの一括デザイン変更が楽実機／エミュレータ表示を確認しながらのデザイン調整が楽コピペやスクリプトによる一括処理が楽クリックイベント処理や画面遷移処理がフレームワーク化されているので、詳細な

操作ログが追加実装なしでとれるアプリ更新なしにレイアウトの動的追加／変更が行える（現状やってませんが）

独自のものなので、新規に入る人には習得コストがちょっとかかる良くも悪くも HTML 的コード側も JavaScript 的に書けるようになるので、見通しの悪いコードを書こう

と思えばいくらでも書ける最適化をほとんどしてないのでパフォーマンス改善の余地あり etc...

時間ができたらちゃんと整理して、 Android 対応もしたいなぁと、、


15

スマホからのクルマのドアロック操作の仕組み

〜 IOT 的なもののケーススタディーとして〜


16

どんな機能か？

スマホからドアの施錠／解錠を行うことで、ドライバーが、予約したクルマにオーナーとの立会なしで利用できる仕組み (*1)

クルマの OBD2 (On-Board Diagnostics) 端子に Anyca から貸与されるデバイス（スマートデバイス）を接続することで利用可能となります (*2)

近日クローズドで試験運用を始めながら、徐々に提供拡大予定

1) スマートデバイスを利用する予約リクエストは、１回以上立ち合いでの鍵の受け渡しによるシェアを行った実績があるクルマに対してのみ可能となります

2) 現時点での対応メーカーは、 LEXUS, TOYOTA, NISSAN, BMW, Mercedes-Benz となっています


17

装着イメージ

OBD2端子

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


18

ご利用の流れ

1. ドライバーがスマートデバイス対応のクルマに予約リクエストする

2. オーナーが予約リクエストを承認して予約成立

3. ドライバーはシェア当日、クルマの近くまで行ってスマホで解錠操作

※ 解錠操作時には、免許証番号（下８桁）の入力が必要（の予定）

4. ドライバーは車内に置かれたクルマの実キーを入手 (*1)

※ 以降、返却まではドアの開閉やエンジンの ON/OFF は実キーを使用

5. 返却時、ドライバーは実キーを元の場所に戻して、スマホで施錠操作

1) オーナーは予約日時に合わせて、あらかじめキーを車内のダッシュボード等に入れておきます


19

構成図（概略）DeNA ネットワーク

車両

Anyca 車載デバイス

OBD2端子

BLE モジュール

マイコン3G モジュール

Anyca 通常サービスネットワーク

Anyca スマートキーサービスネットワーク

電源供給ドアロック操作命令、他

BLE 近接通信(Bluetooth Low Energy)

HTTPSHTTPS

ドアロック操作要求（ワンタイムリクエスト）

ドアロック操作要求照合その他、外部 API

予約情報登録端末公開鍵登録

その他、内部 API

予約リクエスト予約車情報取得端末公開鍵登録、他

車両情報ユーザ情報端末公開鍵情報シェア履歴情報予約情報、他

端末公開鍵端末秘密鍵

ドライバー端末

ユーザ情報車両情報予約情報

チャット情報、他


20

開発体制

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


21

車載デバイス観点での重要ポイント

消費電力の制約⁃ 車の管理を自社でできるわけではないので、待機電力を最小限に留

める必要がある• Anyca 車載デバイスの場合、実測で、待機時（ BLE待受のみ）で約

2.5mA 、マイコン +3G モジュール起動時で約 30mA 、 3G 通信時約130mA

• 参考）車両自体の待機時消費電流（暗電流）は 20-50mA 程度、アフターマーケットの盗難防止装置で〜 3mA程度、ルームランプ 5W なら 416mA

マイコンのスペック上の制約⁃ 制御用のマイコンは処理速度・メモリ容量共に制約が非常に厳しい• 暗号関連の処理を行うのは、処理速度・プログラムサイズ的にも厳しい

⁃ プログラマブルな 3G モジュール等もあり、最近のものは処理速度・ RAM容量共余裕があるので、そういうのを使えば車載デバイス側で暗号関連処理を行うことも可能ですが、プログラム構成が複雑になるので今回は非使用


22

開発・運用観点での重要ポイント

車載デバイス側のプログラム開発が内製ではないので、、⁃ QA や問題の切り分けがしやすいように、シンプルなプロトコル設計にする

⁃ 車載デバイス側に複雑な処理はできるだけさせないようにする

• それにより、仕様変更がしやすくなるというメリットもある

通常サービス側と鍵開けサービスは分離する⁃ 通常サービス側のバグやオペミスが鍵開けサービスに影響しないように

⁃ 通常サービス側のサービス向上のための開発のスピードを殺さないように

⁃ 鍵開けサービス側のデータやシステムには限られたしか触れないように


23

セキュリティ観点での重要ポイント

万が一の場合の被害が大きい⁃ 車両盗難時の金銭的被害⁃ 車両盗難からの犯罪への利用通常より高いセキュリティ設計が必要となるスマートデバイス装着によって、通常より盗難対象として狙われや

すい状態が作られることがないように（ *1 ）

ドライバーの鍵が奪われた場合の被害は、アカウント／鍵を奪われた当人だけでなくオーナーにも及ぶ⁃ アカウント（特に休眠ユーザの）乗っ取りへの耐性が重要⁃ スマートデバイス利用ドライバーの本人確認が重要

1) 車両盗難の手口として、ドア開け自体は難しいものではないですし、エンジンをかけるのにもイモビカッターを使ったやりかたが主流（？）なので、それらとの相対感において適切なセキュリティ設計を行うことが肝要。


24

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

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

Engineering