本エントリーは、つぎの二つの機会に発表した内容をまとめ直したものです。
資料はこちらに公開しています。ただスライドは発表の補助資料な為、資料だけ見ても伝わり切りませんので、本エントリーもあわせてご覧ください。
https://www.slideshare.net/AtsushiNakamura4/app-center-analytics-97896393
目次
- 目次
- はじめに
- App Center Analytics概要
- App Center Analytics 利用手順
- Event Trackingを利用する上での課題
- Aspect Oriented Programing 概要
- XamarinにおけるAOPの課題と解決策
- 静的コード生成によるAOPの問題点
- 参考資料
- まとめ
はじめに
さて、本セッションの概略は次の通りです。
- App Center Analytics の概要を理解いただく
- Xamarin で Custom Events をAOPで使い倒すコツ
さて、当日のセッションで最も大切なことを言いそびれていたので、先の補足しておきます（あとで詳細は説明します）。それは
「現状XamarinでCustom Eventを抜け漏れなく、重複コードなく実装するのは難しい。それをきれいに解決するソリューションはあるが、実装（提供）されていない。そして実装は難しい。
しかし、誰かが一度実装すれば誰もが幸せになれる。これから実装したいと思うので、お手伝いしてもらえませんか？」
という事です。
某田淵さんに了承も貰ったので、近いうちにプロジェクト？をスタートしようと思います。その際は、Twitterで告知しようと思いますので、気が向いた方はお付き合いください。
それでは、本題に進みたいとお澪ます。
App Center Analytics概要
App Centerでは大きく6種類の機能が提供されています。 今回題材は、そのうちの一つAnalyticsについてです。 さて、Analyticsといっても何を分析するかといいますと対象は基本的にユーザーの行動解析になります。
具体的には大きく次の４つの機能群が提供されています。
「Export to Azure」以外はApp Centerのメニューにある通りです。
それでは、それぞれの機能について簡単に説明します。 まずOverviewです。
Overviewでは、アプリケーションの利用状況をグラフィカルに確認することができます。 Overviewは、アプリケーションで1行コードを挿入するだけで有効になります。 Overviewで確認できる項目は、現時点ではこちらの通りです。
期間別のアクティブユーザー数や、ユーザーが1日に何度アプリケーションを使っているか全体で１日あたりどの程度利用されているかといったEngagement情報や、利用者のデバイスやOSのバージョン比率、国や言語別の利用者数情報。 そして、アプリケーションのバージョン別の利用者数や、最新バージョンへの移行率などが、Overviewでは見ることができます。
つづいて二つ目の機能がCustom Events機能です。 これはアプリケーションのEventをトラッキングするために利用します。
Custom Eventsには二つのViewがあり、こちらはEventページで 発生したイベントの一覧を見て取ることができます。
もう一つはDetail Event Viewで個別のイベントの詳細情報を閲覧できます。
ここのページで見ることができる項目の詳細はこちらの通りです。
なお、Overviewの機能が、Analyticsを有効にするだけで収集されるのに対して、Custom Eventsでは、ユーザーが明示的に収集したい箇所に、トラッキングコードを埋め込んであげる必要があります。
三つ目の機能はLog Flowです。
これはOverviewやCustom Eventsとは違って、分析に使う機能ではありません。
では何に使うのかというと、Analyticsの機能をアプリに埋め込んでいるときに、正しくイベントが通知されているか確認するための機能です。
こちらのように、リアルタイムで通知されたイベントが表示されます。
さいごに、Export to Azure機能です。
これはApp Center Analyticsで収集した情報をAzureのApplication Insights（もしくはBlob Storage）にエクスポートする機能です。
Application Insights には、分析クエリーなどの機能があるらしいので、 App Centerで収集して、 Application Insights へエクスポートして分析するような使い方を想定しているようです。
さて、ここまでAnalyticsの機能の概要を説明してきました。
App Center Analytics 利用手順
では実際にEvent Trackingを使うための方法を簡単に説明しましょう。
まずアプリにNuGetからパッケージを適用し、アプリケーションを起動する個所などで、App Center SDKを実行します。この初期化コードを埋め込むだけで、先ほど紹介したOverviewの機能が有効化されます。そして、Trackingコードを必要箇所に記載すれば完了です。
簡単ですよね。
Event Trackingを利用する上での課題
Event Trackingを利用する場合、二つほど悩ましいポイントがあります。 それは、Eventを「どこ」で「どう」とTrackingするか？という事です。
仮にApplicationをMVVMで作るとした場合、Event Trackingを埋め込む場所は、次の二つのどちらかが有望でしょう。
- ViewからViewModelのプロパティ更新やCommandを実行する個所
- ViewModelからModelのメソッドを呼び出す箇所
ケースバイケースではありますが、実際にはユーザーの詳細な操作ログを取得したいケースが多いでしょう。したがって、前者つまりViewModelでトラッキングするのが適切なケースが多いと思います。もちろんそこまで詳細な操作情報は必要ない場合、Modelでトラッキングするというのも、ありだと思います。
さて、より悩ましいのが「どう」トラッキングするか？です。
トラッキングコード自体は非常に簡単です。
しかし、ベタに実装すると、トラッキングコードがプロダクトコード内に散在することになってしまいます。プロダクトコードがトラッキングコードによって汚染された状態となってしまいます。
コードが汚染された結果
コードの可読性が低下したり、トラッキングの箇所ごとにテストが必要になったり、変更が困難になったりしてしまいます。
これを解決するには、手動でトラッキングコードを埋め込むのではなく、ルールにのっとって機械的に埋め込むのが最適だと思います。
そこで有効なのがAOPです。
Aspect Oriented Programing 概要
AOPとはAspect指向プログラミングのことです。
AOPでは、機能要件と非機能要件を分離実装し、異なる機能要件に対して、共通の非機能要件を簡単に適用することが可能となります。
オブジェクト指向プログラミングとは両立可能な概念で、AOPを併用することで、よりシンプルに重複コード無く実装することが可能になります。
イメージ化するとこんな感じです。
ViewModelでは商品検索や商品購入といった機能をコマンドとして実装します。トラッキングなどの非機能要件はアスペクトとして実装します。ViewからViewModelを呼び出すときに、コマンド呼び出しをインターセプトし、アスペクトを織り込みます。こうすることで、異なる機能要件に、共通する非機能要件を簡単に適用できるようになります。
つまり、イベントトラッキングのような非機能要件を実装するにあたり、AOPは非常に有効な手段であると言えます。
ただ、Xamarinの場合は実装にやや問題があります。
XamarinにおけるAOPの課題と解決策
.NETのAOPフレームワークの多くが、動的コード生成を利用しています。そしてiOSはセキュリティの観点から、動的コード生成を許可していません。
ではXamarinでAOPはできないのでしょうか？
もちろん可能です。 その手段が静的コード生成です。
静的コード生成とは、コンパイル後のバイトコードに任意のコードを埋め込む仕組みです。
機能要件が実装されたコードに対し、非機能要件の実装を埋め込むことでAOPを実現します。
これでiOSでもAOPを利用することが可能になります。
イベントトラッキングにAOPを利用することで、多くの課題が解決されます。
プロダクトコードの汚染が防げますし、テストも個別に行う必要はなくなります。また変更も容易になります。良いことだらけです。
ただし、別の問題が発生します。その問題が何か？
実際に静的コード生成で、どのようなコードを生成するか見ていただくと、すぐ理解いただけるのでは、ないでしょうか？
静的コード生成によるAOPの問題点
ここでは、AOPを利用することで、つぎのようなコード生成前の状態から、コード生成後と同等の状態になるよう、静的コード生成することを考えます。
ViewModelにMessageというプロパティが存在し、そのプロパティの変更をトラッキングするとします。
これにたいして静的コード生成を行い、下のコードと同等となるようバイトコードを編集するとします。
静的コード生成前のC#のコードとバイトコードがこちらになります。非常にシンプルなコードですが、バイトコードにすると、ちょっと増えますね。
そして、このバイトコードをコード生成するとした場合、コード生成するC#のコードはどんなものかというと
こんな感じになります。いきなり辛そうですね。。。
そして、本来の目的であるトラッキングコードを埋め込んだC#コードと、それと同等なバイトコードがこちらになります。
これを各々が個々のプロジェクトで個別に実装しようというのは、現実的ではないと思います。しかし一度上手く実装してあげれば、多くのプロダクトで採用できる仕組みになることも確かでしょう。
という事で実際に取り組んでみようと思っていますので、もしよかったら興味のある方はお付き合いいただけると嬉しいです。取り組み際には、Twitterへ投稿しようと思いますので、興味のある方は事前に私のTwitterアカウントをフォローしておいていただけると幸いです。
され本題に戻り、あと少しだけお付き合いください。
参考資料
- Fodyを利用した静的コード生成の解説記事
「XamarinでもAOPしたい！ 黒魔術で自作編」
https://qiita.com/Nuits/items/3bd43f41a19d61510ef0 - ReactivePropertyに対しEventTrackerを織り込むAOP実装
https://github.com/nuitsjp/ReactiveTracker.Fody - ReactiveTracker.Fodyを適用したアプリケーション実装
https://github.com/nuitsjp/BlueMonkey-and-AppCenter
まとめ
- App Serviceではユーザーの分析機能が提供されます
- 分析機能にはCustom Eventsという、イベント トラッキングのサービスが提供されます
- イベント トラッキングはそのまま利用すると、トラッキングコードによって、プロダクトコードが汚染されてしまいます
- この問題はAOPを利用することで解決できます
- XamarinでAOPを利用する場合、静的コード生成を活用します
- コード生成は用法容量をまもって利用しましょう
以上です。
