アプリのクラッシュリポートを統計解析できるBugSenseの使い方：iOSアプリ開発でもCI／継続的デリバリしようぜ（5）（2/3 ページ）
iOSアプリにBugSenseのSDKを組み込む
次に、iOSアプリにBugSenseのSDKを組み込みましょう。
CocoaPodsでBugSenseをインストール
ここでは、これまでの連載と同様に「CocoaPods」でインストールする方法を紹介します。下記のようにPodfileを修正し、「pod install」コマンドを実行してください。
target "AtmarkApp" do pod "BugSense" end
クラッシュリポート用のコードを埋め込む
インストールが完了したら、BugSenseのセットアップ処理を実装します。AppDelegateの「application:didFinishLaunchingWithOptions:」に次のコードを追加してください。
#import <BugSense-iOS/BugSenseController.h>
//...略
- (BOOL) application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[BugSenseController sharedControllerWithBugSenseAPIKey:@"<BugSenseのAPIキー>"];
return YES;
}
これだけでBugSenseのセットアップは終わりです。このアプリを実行すると、BugSenseのトラッキングが開始され、クラッシュするとリポートが送信されるようになります。
クラッシュリポートが送信できているか確認
クラッシュリポートが送信できているか確認するために、アプリをクラッシュさせてみましょう。適当なViewControllerなどに、次のようなコードを追加します。
- (void)viewDidLoad
{
[super viewDidLoad];
// クラッシュするようなコード
NSArray *array = @[@1, @2, @3];
NSNumber *four = array[3];
}
上記コードは、3個しか存在しないはずの「NSArray」インスタンスの4個目の要素にアクセスしようとしているため、実行すると必ずクラッシュしてしまいます。
この状態でアプリを実行してクラッシュさせると、BugSenseのダッシュボードに新しいクラッシュリポートが1件送信されていることが確認できます。
これでBugSenseのアカウント登録からiOSアプリへの組み込みまで、ひと通りの流れが終わりました。非常に少ない手順でトラッキングが行えるということがお分かりいただけたかと思います。
コラム「クラッシュリポートのカスタマイズ」
BugSenseでは、送信するクラッシュリポートのカスタマイズを行えます。デフォルトのままでも多くの有益なデータが取得できますが、アプリ固有の特別なデータが存在する場合など、要件に合わせて送信するデータのカスタマイズを行えます。
カスタムデータを追加するには、トラッキング開始時に`NSDictionary`で作成したデータを登録します。次の例は、カスタムデータとして`Age`という年齢データを追加しています。
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
NSDictionary *customData = @{@"Age" : @27};
[BugSenseController sharedControllerWithBugSenseAPIKey:@"<BugSenseのAPIキー>" userDictionary:customData];
return YES;
}
クラッシュの原因を解決するための「課題（イシュー）管理機能」
これまでの手順で、アプリのクラッシュリポートがBugSenseに送信できるようになりました。さて、送信されたクラッシュリポートを使って、どのようにクラッシュの原因を解決していけばいいのでしょうか。
BugSenseには、クラッシュリポートの原因を解決できる課題（イシュー）管理機能が備わっています。クラッシュリポートを「課題」（イシュー）として取り扱い、解決したらステータスを変更する、といったような操作をダッシュボード上から行えます。
あらためてダッシュボードのクラッシュリポートを確認してみましょう。クラッシュリポートに「Open」と表示されていることが確認できると思います。これは、このクラッシュリポートが未解決であることを示しています。
次に、クラッシュリポートの詳細データを閲覧してみましょう。クラッシュリポートをクリックすると、下図のような画面が表示されるはずです。
この画面では、クラッシュリポートに関する詳細なデータを、次のようなグループ分けで表示しています。
| グループ | 説明 |
|---|---|
| Error Details | クラッシュの原因のエラーの詳細。対象のクラスや発生日時など |
| Integrations | 連携サービスに関する情報。詳しくは後述 |
| Stacktrace | スタックトレース。クラッシュした経緯が確認できる |
| Error Instances | デバイスの情報。デバイスの種類やOSバージョンなど |
| Breadcrumbs | 発生した経緯を示すパンくず。有料プランのみ利用可能 |
| Comments | コメント。クラッシュに対して自由にコメントを付けられる |
| History Graph | 発生日時と発生回数のグラフ |
| Aggregated Metrics | デバイスが利用した通信サービスやメモリ使用量などの統計情報 |
| App Versions | アプリのバージョンの統計情報 |
| OS Versions | OSのバージョンの統計情報 |
| Devices | デバイスの種類の統計情報 |
| Countries | 言語設定の統計情報 |
ここで、「Error Details」についてもう少し細かく見てみましょう。「Status」が「Open」になっていることが確認できると思います。このステータスを変更してみましょう。「Change」をクリックすると、下図のようなステータスを変更する画面が表示されるので、「resolved」（解決済み）に変更してください。
図8 ステータスの変更これで対象のクラッシュリポートが解決済みのステータスになりました。ダッシュボードに戻ってみると、「resolved」に変わっていることが確認できます。
ダッシュボードのクラッシュリポート一覧では、右側に表示されている絞り込みメニューでステータスを指定して絞り込めます。クラッシュリポートを元にバグなどのエラーを解決したい場合、どのようなクラッシュが未解決なのか、ステータスを絞り込みによって切り替えながら確認できます。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。