EDIT MODE

モバイルアプリ開発に関することを書いています

トップ > Android

Firebase Analytics Guide

Android

前回は Firebase Analytics の概要をまとめたのですが、ドキュメントや Google I/O 2016 のセッション動画などを見て、もう少し具体的な内容をまとめたいなと思い、この記事を書きました。

androhi.hatenablog.com

Firebase Analytics の位置づけ

Firebase Analytics は、Firebase のコアとして、無料かつ無制限のアナリティクス・ツールとなっています。 Google I/O 2016 での各セッションでも、そのことが繰り返し述べられていました。

Google Analytics とは異なり、モバイルアプリのためのツールとなっているため、対象となるプラットフォームは現在のところ Android と iOS のみとなっています。

なお Google Analytics との違いは、以下のヘルプページで詳しく解説してありました。

上記にも記載がありますが、Google Analytics との大きな違いは以下の2点だと思います。

  1. イベントベースのデータ収集モデル
  2. いくつかのイベントやプロパティの自動測定

どのように機能するのか？

Firebase Analytics は、iOS もしくは Android アプリでいくつかのイベントとユーザープロパティを、自動で収集してくれます。 どのような項目を自動収集するのかは、以下のページに詳細があります。課金イベントも自動で収集されるのは嬉しいですね。

これらの自動収集されたデータは、Firebase console のダッシュボードで確認することができます。

f:id:androhi:20160527003216p:plain

他のサービスとの統合

Firebase Analytics は、他の Firebase サービスのログも収集することができ、それらをダッシュボード上で確認することが出来ます。 たとえば Notifications の通知イベントは、自動収集対象にもなっているので下図のように細かくログを確認することが出来ます。

f:id:androhi:20160603014823p:plain

他のサービスについては、どのように統合されているのかを示すにはサンプルアプリでは限界があるので、以下の Google I/O 2016 のセッション（英語）を見ていただくのがいいかと思います。

Analytics の基本的な使い方

Analytics では、最初に次の 1〜4 を行ったあと、必要に応じて 3 と 4 を繰り返していくことを想定しているようです。それぞれの手順を、以下にまとめました。

1. アプリを Firebase に接続する

"Get started with Firebase Analytics for Android" を参考に、解析したいアプリでデータの自動収集が行われるようセットアップします。 詳細は上記サイトを見ていただいて、以下はおおまかな流れです。

a. Firebase SDK のセットアップ

やるべきことは次の3つです。

  • Firebase console にアプリのパッケージ名（=ApplicationId）を登録
  • build.gradle を編集
  • app/build.gradle を編集
b. FirebaseAnalytics オブジェクトの初期化

ドキュメントには、アプリのサインイン・アクティビティの onCreate() メソッドに、以下の初期化処理を書くように記載されています。

// Obtain the FirebaseAnalytics instance.
mFirebaseAnalytics = FirebaseAnalytics.getInstance(this);
c. [オプション]: ログイベントの使い方

いくつかのイベントは、b までのステップが完了したらログは自動収集されますが、もちろん開発者が自分でログを送信するイベントを記述する方法も用意されています。 以下のように、 logEvent() メソッドを使って実現します。その際、自動収集対象のイベントは FirebaseAnalytics クラスに定数として用意されているので、それを使用することも可能です。

Bundle bundle = new Bundle();
bundle.putString(FirebaseAnalytics.Param.ITEM_ID, id);
bundle.putString(FirebaseAnalytics.Param.ITEM_NAME, name);
bundle.putString(FirebaseAnalytics.Param.CONTENT_TYPE, "image");
mFirebaseAnalytics.logEvent(FirebaseAnalytics.Event.SELECT_CONTENT, bundle);

ちなみに、以下のように adb コマンドを叩くと logcat 上で logEvent() のログが見れるようになります。


ターミナルなどで

$ adb shell setprop log.tag.FA VERBOSE
$ adb shell setprop log.tag.FA-SVC VERBOSE
$ adb logcat -v time -s FA FA-SVC


logcat から抜粋

06-03 01:00:26.952 D/FA      (23012): Logging event (FE): select_content, Bundle[{_o=app, item_category=button}]
06-03 01:00:26.952 V/FA      (23012): Using measurement service
06-03 01:00:26.953 V/FA      (23012): Connecting to remote service
06-03 01:00:26.969 D/FA      (23012): Connected to remote service
06-03 01:00:26.970 V/FA      (23012): Processing queued up service tasks: 1
06-03 01:00:27.008 V/FA-SVC  (11813): Saving event, name, data size: select_content, 43
06-03 01:00:27.009 V/FA-SVC  (11813): Event recorded: Event{appId='com.androhi.firebaseextensionsample', name='select_content', params=Bundle[{_o=app, item_category=button}]}
06-03 01:00:27.025 V/FA-SVC  (11813): Upload scheduled in approximately ms: 3579219
06-03 01:00:27.027 V/FA-SVC  (11813): Background event processing time, ms: 55
06-03 01:00:31.977 V/FA      (23012): Inactivity, disconnecting from AppMeasurementService

2. カスタム・イベントのログを送る

これは前述した「ログイベントの使い方」とほぼ同じですが、以下のようにイベント名を任意の名称にすれば、独自のイベントとしてカウントされるという内容です。 ドキュメントでいうと、"Firebase Analytics - Log Events" の項目です。

Bundle params = new Bundle();
params.putString("image_name", name);
params.putString("full_text", text);
mFirebaseAnalytics.logEvent("share_image", params);

3. オーディエンスを作成する

いわゆる収集データのフィルタリングです。

イベントやユーザープロパティ、デバイスデータなどを使って、収集されたデータにフィルタをかけます。 Firebase console にて、下図のようにフィルタする条件を選択することができます。

f:id:androhi:20160603015007p:plain

4. ターゲットへの施策を実行する

手順3で施策を打ちたいターゲット層を決定し、他の Firebase サービス、例えば Notifications や Remote Config などを使って、プロモーションなどを行います。

f:id:androhi:20160603023905p:plain

補足：既に Google Analytics を使って場合はどうするのか？

以下の内容は、個人の見解です。

まずは公式の見解はどうなのかというと、Google のヘルプページに参考となる情報が載っていました。

  1. アプリ専用の企業の場合: Firebase Analytics をご利用ください
  2. ウェブサイトのみを運営する企業の場合: Google アナリティクスをご利用ください
  3. アプリとウェブサイトの両方を運営する企業の場合: Firebase Analytics と Google アナリティクスの両方をご利用ください

つまり今後モバイルアプリは、 Firebase Analytics を使って欲しいということのようです。確かにページビューなどによる計測は、アプリの場合あまり意味を成さないですし、無料枠での Google Analytics ではデータのサンプリングなども行われるので、すぐにでも Firebase Analytics に移行しても良い気がします。

それ以外では、以下の状況によって移行の是非や時期を関係者で良く話し合うのが、現実的なのかなと思います。

  • Google Analytics はプレミアムか？
  • AppIndexing や AdWords など、Firebase に統合されたサービスを使っているか？
  • 今後アプリのグロースを強化したいか？

ちなみに、上記3に該当するような場合、両方の管理画面をチェックするのが面倒になりそうですが、Google Analytics 上で Firebase Analytics のレポートを見られるように設定ができるようです。


参考：Google Analytics と Firebase Analytics の接続

f:id:androhi:20160603022250p:plain

f:id:androhi:20160603022316p:plain

まとめ

簡単な導入ステップされ終えれば、基本的なデータは自動的に収集されるので、まずは Firebase Analytics だけを先行して導入してみても十分なメリットが得られるように思います。（場合によっては、Google Analytics からの移行に検討が必要かもしれませんが。）

しかし、Firebase Analytics の真価は他のサービスとの連携にあるようなので、導入した際には積極的にアプリのグロース関係を始めとして、他のサービスの利用も検討してみるべきかなと感じました。

Firebase Analytics Overview

Android

Firebase Analytics とは？

Google I/O 2016 で発表された、Firebase 拡張機能群のうちの1つです。

Google Analytics をモバイル向けに最適化したもので、特に「アプリの利用状況」と「ユーザーエンゲージメント」の監視に特化しているようです。 Android と iOS に対応していて、解析内容は専用の Firebase Console 上で確認できるようになってます。


f:id:androhi:20160527003313p:plain Firebase Console

公式のドキュメントはこちら。

Firebase Analytics Guides


拡張された Firebase の概要は、このセッションが参考になりました。（英語ですがデモが多くて見やすいです。）

Firebase Overview - Google I/O 2016

Firebase Analytics の利点

ざっと触った中で、（主に Google Analytics と比較して）良かった点を挙げてみようと思います。

なお以下は、個人的な見解です。

1. 導入および実装がものすごく簡単

Firebase Analytics のセットアップは驚くほど簡単です。
この公式の手順通り進めていけば、特に迷うことは無いと思います。 ちなみにAnalytics は Firebase-Core に含まれているので、上記の共通手順を終えるだけで組み込むことが出来ます。


注意点

"通常はスムーズにセットアップ出来ると思いますが、1点だけ僕がハマったところがあります。 Firebase Console は Google Account でログインした状態で使用しますが、ブラウザに複数アカウントをログインさせてる状態だと、設定ファイル（google-services.json）のダウンロードに失敗するようです。
もしそういった状況になった時は、Firebase Console で使用しないアカウントをログアウトしてから、再度 Firebase Console にログインするとうまくいくようになりました。"


プラグインとライブラリをセットアップしたら、Analytics のセットアップ方法にあるように、 FirebaseAnalytics.getInstance(Context) を Activity の onCreate() などで呼ぶだけです。 必要なコードの追加は、ものすごく少ないです。

getInstance() メソッドコール以降は、Analytics 側で自動でログを収集してくれるようです。 何を自動収集するかは、以下に書かれています。


f:id:androhi:20160527003216p:plain 収集されたイベントログ

Google Analytics で xml 書いたりログ送信処理書いたりしていたのが、嘘みたいな簡単さですね...

2. Web のダッシュボードが見やすい

下図のように、モバイルアプリに必要な項目に絞って各レポートが表示されており、とてもスッキリして見やすいです。 また、フィルターを組み合わせていけば、レポート表示をカスタムすることもできます。

個人的には普段 Android 端末メインなので、Console 全体が Material Design に沿って作られていることも良いなと思います。


f:id:androhi:20160527001921p:plain Analytics ダッシュボード

まだ細かく触っていないので、どこまで詳細な分析ができるか未知数ですが、Google Analytics よりも操作は直感的に行えるように思えました。

3. 他機能との連携が強力

Firebase Analytics の真価は、他の機能と一緒に使うことで発揮されるようです。 具体的にはこのあたりに、どういった連携がなされるのかが書いてあります。

中でも Firebase Notifications は、関連するイベントが自動で記録されたり、下図のように「送信数（予測）」や「既読率」なども計測できるようです。


f:id:androhi:20160527003647p:plain Notifications ダッシュボード

まとめ

Firebase Analytics は Google Analytics に比べると、シンプルでアプリに特化している分、使いやすくなっているなと思います。 加えて、導入も簡単で他の Firebase 機能との連携もあるなど、開発者視点だと今すぐにでも Google Analytics から移行したいほど、Firebase Analytics は良く出来ているなと感じました。

ただし、Web 的な指標がベースの Google Analytics とは、分析内容がかなり異なる部分もあります。そのため、もしその分析内容を共有しているメンバー（特に非エンジニアが含まれる場合）がいるようなプロダクトに投入したい場合は、しっかりと事前に検討が必要そうだとも思いました。

サンプルコード

この記事を書くにあたり、実際に Firebase Analytics と Firebase Notifications が動くサンプルアプリを、GitHub にアップしています。 とはいっても、本当に追加したコードは少ないので、ドキュメント見たほうが早いかもしれません...。

サンプルアプリ - GitHub

DroidKaigi2016にスタッフ&スピーカーとして参加したのでKPTしました

Android イベント

DroidKaigiの運営では、2015のときもそして今回もイベント終了後に全員でKPTによる振り返りを行っています。 それにあやかって、僕個人に対してもKPTをしてみようと思いました。

Keep

  1. 発表のシミュレーションを繰り返し行う
  2. 事前にイベント会場を下見する

1については、今回初めて50分という持ち時間に挑戦しました。これまでは30分が最長だったため、資料を作っていても時間配分のイメージが全く湧きませんでした。細かい内容は今までの経験上、当日ちょっと変わる可能性もあったので、大まかにですが全体を流すように発表のシミュレーションをするようにしました。

シミュレーションをすることで、資料を作っているときには気づけなかった点に気づくことができ、資料にメリハリをつけられるようになったと思います。1つ注意点としては、いろんなところが気になってしまい、何度もシミュレーションと修正を繰り返し、無限に時間が吸われていったことです。

2は、スタッフとしての視点です。一応念のためくらいの軽い気持ちで、2週間ちょっと前くらいに他のスタッフと一緒に会場の下見に行ったのですが、今思うと行っておいて大正解だったなという感じです。

当日朝の集合時間が早かった（朝8時現地集合）のですが、会場までの道のりは経験済みだったため余裕を持って移動できたし、イベント中も会場となる大学内を1人で移動するのも不安はありませんでした。イベント1ヶ月前とかまでは、誘導担当でも無いし下見しなくていいかなと考えていましたが、下見は重要でした。

Problem

  1. スタッフとスピーカーの兼任はリソース配分をよく考える
  2. 備品はケチらない

1はそもそも兼任しないのがいいなという結論なのですが、それでも兼任するならどうすれば良かったのかを書こうと思います。 当たり前と言えば当たり前ですが、イベント日が近づくにつれ、スタッフ業務もどんどん忙しくなっていきます。時には予定外の作業も発生します。そのときに資料作成も佳境に入っていたのでは、睡眠時間を削るしかなくなっていきます。（実際にそうでした。）

ではどうするべきだったか。スタッフ業務の忙しさは自分ではコントロールできないので、資料作成のピークをスタッフ業務のピークと反比例するようなスケジュールを立てるべきだったと思います。今だから言えることで、実際にやるのは大変そうですが...。

2については、僕は今回のDroidKaigiで各会場で使用する電源タップの発注を担当したのですが、全体の約半数を型落ちの安価な品で購入しました。一応販売会社のレビューとかもチェックして、粗悪品を掴まないようにと気にしてはいたのですが、現実には安価な方の2個が初期不良で、別の2個がイベント中に大破するという結果でした。

もう半数の品は1個も壊れることなくイベントを終えたので、まさに「安物買いの銭失い」を地でいってしまうことになってしまいました。必要なものは、きちんと相場と同程度の金額を掛けるのが安心だと思いました。（幸い別のスタッフが1日目終了時に、電源タップを追加購入してくれたおかげでイベントに支障はでませんでした。）

Try

  1. 海外スピーカーの方に質問する

これは本当は今回のDroidKaigiで挑戦したかったのですが、完全に自分自身をコントロールできなくなって資料作成とスタッフ業務で手一杯となって、英語学習が日に日に疎かになったため、実行する勇気が出ませんでした。 ただ今回、スタッフとして海外スピーカーと接する機会があったのに、「Yes」しか言えなかった悔しい体験をしたので次こそは...。

他にもTryな項目を考えたのですが、次回スピーカーをやりたいのかスタッフをやりたいのか、まだ全然決められないので、今の時点としては1つだけにしました。

まとめ

Problemにも書きましたが、もし次のDroidKaigiがあって関わりたいのであれば、スタッフとスピーカーはどちらかにして、今回の教訓を活かしてもっとクオリティの高いアウトプットをしなければいけないなと思いました。

最後になりましたが、素晴らしいスタッフの面々と一緒にDroidKaigi2016に携われたことが、とても嬉しいです。本当にお疲れ様でした！＆ありがとうございました！

f:id:androhi:20160219202842j:plain

@mgmix5さんの写真より

0 から Android アプリ開発を学びたい人へ

Android

先日「Androidアプリ開発って、どうやって勉強したらいいですかね？」という質問を受けたので、そのときに話した内容に少し追加して、まとめてみました。

ネット上の情報だと断片的で、体系的な学習に使えそうなものが少ないですし、書籍だと何を買ったらいいか選ぶのも難しく、かつ値段も高いという悩みが多いと思います。そのあたりの敷居を下げつつ、きちんとした内容で学習できそうなものを、独断と偏見でピックアップしました。

続きを読む

API level 23 未満を考慮した指紋認証 API の実装

Android

前回、指紋認証 API のサンプルコードをざっと見てみたのですが、そのときに FingerprintManagerCompat クラスが Support Library v4 にあるのを見つけました。

androhi.hatenablog.com

このクラスを使えば Android 6.0 (API level 23 未満) も含め、スッキリと実装できるんじゃないかなと思い調べてみました。

FingerprintManager のインスタンス取得

前回のGoogleのサンプルコードでは、以下のようなコードでインスタンスを取得していました。

FingerprintManager manager = context.getSystemService(FingerprintManager.class);

ところが以下の2点で API level 23 未満では、getSystemService() 経由だと使えません。

  1. Context.getSystemService(Class<T>) は API level 23から追加されたメソッド
  2. Context.getSystemService(String) だと引数のサービス名に Fingerprint は無い

そのため FingerprintManagerCompat では、別途 Context を使った方法が用意されていました。

// contextはActivityなど
FingerprintManagerCompat managerCompat = FingerprintManagerCompat.from(context);

FingerprintManagerCompat のソースコードを辿って行くと、内部で Build.VERSION.SDK_INT をチェックしていて、23 以上だと Api23FingerprintManagerCompatImpl 内部クラスを、23 未満だと LegacyFingerprintManagerCompatImpl 内部クラスを、それぞれインスタンス化していました。

指紋センサーの判定など

FingerprintManager では、端末に指紋センサーのハードウェアがあるか？や、指紋の登録があるか？などを判定するメソッドを提供しています。

まったく同じメソッドが、FingerprintManagerCompat クラスにも実装されていますが、どのような挙動になるのか確認してみました。

結論から書くと、API level 23 以上だとちゃんと FingerprintManager 経由で判定し、23 未満だと固定で false を返していました。

API level 23 未満

    private static class LegacyFingerprintManagerCompatImpl implements FingerprintManagerCompatImpl {

        public LegacyFingerprintManagerCompatImpl() {
        }

        @Override
        public boolean hasEnrolledFingerprints(Context context) {
            return false;
        }

        @Override
        public boolean isHardwareDetected(Context context) {
            return false;
        }

        ...
        }
    }

API level 23 以上

    private static class Api23FingerprintManagerCompatImpl implements FingerprintManagerCompatImpl {

        public Api23FingerprintManagerCompatImpl() {
        }

        @Override
        public boolean hasEnrolledFingerprints(Context context) {
            return FingerprintManagerCompatApi23.hasEnrolledFingerprints(context);
        }

        @Override
        public boolean isHardwareDetected(Context context) {
            return FingerprintManagerCompatApi23.isHardwareDetected(context);
        }
        
        ...

public final class FingerprintManagerCompatApi23 {

    private static FingerprintManager getFingerprintManager(Context ctx) {
        return ctx.getSystemService(FingerprintManager.class);
    }

    public static boolean hasEnrolledFingerprints(Context context) {
        return getFingerprintManager(context).hasEnrolledFingerprints();
    }

    public static boolean isHardwareDetected(Context context) {
        return getFingerprintManager(context).isHardwareDetected();
    }
    
    ...

分かりやすくいいですね。

指紋認証

実際に指紋センサーから指紋を読取るときは、 FingerprintManager#authenticate(CryptoObject, CancellationSignal, int, AuthenticationCallback, Handler) メソッドを使ってましたが、これも先ほどと同じ形でした。

API level 23 以上では、FingerprintManager 経由で処理し、23 未満では何もしません。

API level 23 未満

    private static class LegacyFingerprintManagerCompatImpl
            implements FingerprintManagerCompatImpl {
        ...

        @Override
        public void authenticate(Context context, CryptoObject crypto, int flags,
                CancellationSignal cancel, AuthenticationCallback callback, Handler handler) {
            // TODO: Figure out behavior when there is no fingerprint hardware available
        }
    }

API level 23 以上

    private static class Api23FingerprintManagerCompatImpl implements FingerprintManagerCompatImpl {
        ...
        @Override
        public void authenticate(Context context, CryptoObject crypto, int flags,
                CancellationSignal cancel, AuthenticationCallback callback, Handler handler) {
            FingerprintManagerCompatApi23.authenticate(context, wrapCryptoObject(crypto), flags,
                    cancel != null ? cancel.getCancellationSignalObject() : null,
                    wrapCallback(callback), handler);
        }

public final class FingerprintManagerCompatApi23 {
    ...
    public static void authenticate(Context context, CryptoObject crypto, int flags, Object cancel,
            AuthenticationCallback callback, Handler handler) {
        getFingerprintManager(context).authenticate(wrapCryptoObject(crypto),
                (android.os.CancellationSignal) cancel, flags,
                wrapCallback(callback), handler);
    }

まとめ

当分 API level 23 以上でアプリを開発出来る状況は来ないので、開発しているアプリに指紋認証を導入したいときは、この FingerprintManagerCompat を使うのが良さそうです。

今まで割と自力で API level 判定して処理を分けていたようなところも、xxxCompat クラスがいい感じに内部で切り替えてくれるケースが増えてきた気がします。

新しい機能が出てきたら、まずは xxxCompat クラスも一緒に探すと、既存アプリへの導入が楽になりそうですね。

Android 6.0 の指紋認証 API を触ってみた感想文

Android

10/26（月）に Android Developers Blog で、New in Android Sample: Authenticating to remote servers using the Fingerprint API という記事が公開されました。

さらに 10/19（月）にNexus5Xが発送されたにも関わらず全然触ることが出来なかったのですが...

今日やっとセットアップを終えたということもあり「思ったより指紋認証よさそう」って高まってるので、実際にサンプルコードを見て触ってみました。

指紋認証 API

先程のブログ記事によると、Android 指紋認証 API は安全に利用することが出来るよう、デバイスのセキュアなハードウェアに含まれているとのことです。

指紋認証 API の利用の仕方としては2種類の方法を、アプリケーションのニーズに合う方を選ぶのが望ましいようです。

例えば、オフラインのファイルやデータベースにアクセスするときは、パスワードと同じような Symmetric Keys を使い、ネットワークへのログインやオンライン取引のようなケースでは、公開鍵と秘密鍵で構成される Key Pair による Asymmetric Keys を使う、といった形です。

サンプルコード

Google が公開している指紋認証機能に関するサンプルコードは、AsymmetricFingerprintDialog と FingerPrintDialog の2つあります。

f:id:androhi:20151028030749p:plain

AsymmetricFingerprintDialog の方は、名前の通りペアの鍵を用いてクライアント／サーバー間で認証を行うサンプルです。今回新たに追加されたサンプルは、こちらのようです。

FingerprintDialog の方は、Android 6.0 が public preview のときに公開されたサンプルで、とりあえずどうやって指紋認証をアプリに実装するかを示したものです。

両者のサンプルコードを比較してみると、違うのはサーバー側の処理のフェイクを実装している部分と、鍵の生成に KeyGenerator クラス使ってるか KeyPairGenerator クラスを使ってるかっていうあたりでした。

f:id:androhi:20151028030950p:plain f:id:androhi:20151028031002p:plain

認証フロー的な説明は、公式ブログが詳しいのでそっちを読めばいいとして、もう少し細かいとこを見てみました。

指紋認証の可否判定

サンプルコードを見てみると、2つのチェックを行っていました。1つは画面ロックに、スワイプ／パターン／PIN／パスワードのいづれかが設定されているかどうか、もう1つは端末に指紋が登録されているかどうかです。

画面ロックの有無をチェックするコード

getSystemService(KeyguardManager.class).isKeyguardSecure();

設定 > セキュリティ > 画面ロック の設定をチェックできる

指紋登録の有無をチェックするコード

getSystemService(FingerprintManager.class).hasEnrolledFingerprints();

設定 > セキュリティ > Nexus Imprint の設定をチェックできる（Nexus5Xの場合）

f:id:androhi:20151028030837p:plain

指紋の読み取り

サンプルアプリを動かしてみると、下図のような指紋センサーにタッチさせるダイアログが出るのですが、このダイアログが表示されてるときに指紋センサーが反応するようです。

f:id:androhi:20151028030912p:plain

どういう風に実装されてるか見てみました。（公式ブログにも載ってますが...）

細かい部分は割愛しますが、以下のコードで実現していました。

指紋の読み取りを開始するコード

getSystemService(FingerprintManager.class).authenticate(cryptoObject, cancellationSignal, 0, this, null);

FingerprintManager#authenticate(FingerprintManager.CryptoObject, CancellationSignal, int, FingerprintManager.AuthenticationCallback, Handler) メソッドで読み取り開始〜コールバック受け取りまで出来るようです。

一応 Support Library にも FingerprintManagerCompat クラスが用意されいて、API level 23 より前のデバイスで指紋機能なしとして振る舞ってくれるらしいです。試してません。

あとは FingerprintManager クラスには、ハードウェアとして指紋機能が有効かチェックする isHardwareDetected() というメソッドもありました。

まとめ

ざっくり見た感じでは、Asymmetoric Keys のやり方でもサンプルコードのおかげで、割とすぐに実装できそうな気がしました。

アプリのログインが指紋認証で出来るのは、すごく楽だと思うので積極的に取り入れていきたい気持ちになりました。

エンジニア向けの Sketch3 入門を DevDays と potatotips で発表しました

Android イベント 勉強会

少し前に、仕事で Android アプリのデザインリニューアルを行う際、Sketch3 を使ってデザイナーさんと UI デザインを共有する機会がありました。

そのことがきっかけとなり、自分でも Sketch3 を使えるようになりたいなと思い、ちょっとずつ練習していった内容などを、タイトルにある2つのイベントで発表させて頂きました。

Stack Overflow DevDays

みんな大好き Stack Overflow が、日本で初めて主催したイベントです。 個人開発者向けとしては珍しい平日開催のイベントでした。

イベントページでは最終的に149名の申し込みがあったようですが、（数えていませんが）当日はその半分くらいな印象でした。 ちょっとギリギリまでイベントの内容も分からなかったので、予定に組み込むのが難しかったのかなと、個人的には思います。

イベント全体の振り返りは、以下のブログが詳しいので、ここでは自分の発表について触れるだけにします。

発表資料

15分の発表枠を頂いていたのですが、Sketch3 の良さが伝わるようデモをメインで行いました。 Shapeを組み合わせて、シンプルなアイコンなら割と簡単に出来るということと、画像の書き出しがとても便利だということをデモしました。

ちなみにこのとき手順メモを手元で見るために、モニタの設定をミラーリングにしないでプロジェクタを見つつデモしたのですが、ものすごくやりづらかったです。デモはやっぱりミラーリングにして、手元を見ながらやるべきですね...。

potatotips #22

Android と iOS の Tips 共有にフォーカスした勉強会です。 毎月1回のペースで、いろいろな企業が主催する形で開催されています。今回はメルカリさん主催で行われました。 大人気のイベントで、発表枠もオーディエンス枠も抽選を勝ち抜かないと参加出来ません。

この勉強会は、参加枠に「ブログまとめ枠」という形式があり、イベントについてまとめる専任者がいらっしゃるので、こちらも全体については、以下が詳しいのでそちらをご覧ください。

発表資料

前述の DevDays と日程が近く、せっかくなので DevDays での発表内容に、もっとエンジニア向けの内容を追加して資料を再構築したのが、この資料です。 本当はプラグインについても触れたいなと思ったのですが、そもそも DevDays に参加したという potatotips 参加者が少なかったら、Sketch3 についても改めて説明を入れたかったので、プラグインに触れるのは止めました。

ということで、実際に発表の冒頭で DevDays に参加した人に挙手してもらったら1名のみでしたので、プラグインに触れなくても時間ギリギリの発表になってしまいました。

まとめ

Mac OS 専用ソフトではあるものの、モバイルやWebの仕事でデザイナーさんと一緒に作業をする機会があれば、Sketch3 は絶対にエンジニアも使うべきです。

それ以外でもプライベートで何か作っているのであれば、Sketch3 は購入を検討するに値する価値があると思います。 出来れば OSS ライセンス版みたいのが、あると嬉しいんですけどね。

最後に、僕もまだまだ Sketch3 使い始めたばかりなので、ノウハウに飢えてます。 もし Sketch3 の勉強会情報とか知ってる方は、@androhi にメンションいただけると泣いて喜びます。