Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2019年02月15日

furusin

GDG京都様と共催でミートアップを開催しました!

こんにちは。ピクトリンク事業部の古川です。

先日のブログで、GDG京都(Google Developers Groups)様との共催でGDG ミートアップ in 京都を開催することを宣言しておりましたが、ついに実現しましたのでご報告致します!

 

GDG ミートアップ in 京都

今回も合計で30名以上の方にご参加頂きました!

特色としては、海外からGDE(Google Developer Experts)が2名参加されることもあり、セッションのほとんどが英語となりました!

GDEの2名以外にもGDG NZ(ニュージーランド)の方も来られており、とても国色豊かなイベントとなりました。

GDG NZの方とGDEのうちの1名は、直前に東京で開催されていた日本最大級のAndroidイベント「DroidKaigi」にも参加されていたそうです。

(ちなみに私も参加していました。弊社はDroidKaigiのスポンサーでもあります!)

 

GDEであるEnrique Lopez Mañas さんの発表「 Kotlin/Native for Multiplatform development」

IMG_20190210_135625

 

GDEであるiñaki Villar さんの発表「 Diving in the WorkManager API」

IMG_20190210_142212991

英語のセッションということもあり、皆さんいつも以上に真剣に(必死に?)話を聞かれているなぁ、というのが印象的でした!

また、GDG京都のメンバーの兼高さんも英語で発表してくださりました!

IMG_20190210_153921186

Pin-point rebuildable and non-rebuild custom widget from cch-robo

僭越ながら、私も発表させて頂きました!

IMG_20190210_160011292

Build your first wear app from furusin

 

本来は私の発表が最後の予定だったのですが、懇親会のケータリングが届くまで時間が余ってしまいましたので、GDG四国、GDG京都のメンバーより発表を頂きました!

IMG_20190210_163719

 

MVIMG_20190210_164002

 

懇親会の様子

hoge

今回はたくさんの方が懇親会に関するツイートをあげてくださりました!嬉しい!

 

最後に

私たち京都Devかふぇとしては、イベントの共催は初の試みとなりました。

初の共催だし、英語ばっかりだしどうなることやら……と不安はありましたが、参加者の皆様にはとても楽しんで頂けたようで、

運営一同嬉しく思っております!

 

今後は色々なコミュニティと共催等を進め、技術コミュニティの活性化や発展により一層貢献したいと考えています。

ご参加頂いた皆様、ありがとうございました!


2019年02月5日

furusin

フリューにてGDG ミートアップ in 京都を共催します!

こんにちは。ピクトリンク事業部の古川です。

 

この度、GDG京都さん(Google Developers Groups)との共催でGDG ミートアップ in 京都を開催することとなりました!🎉

このイベントには、海外からGDE(Google Developer Experts)が2名来日して登壇してくださります。

京都でGDEが2名も揃って登壇されるのは今回のイベントが初めてとのことです!

非常に貴重な機会ですので、是非お越しください!

イベント詳細

イベント名

GDG ミートアップ in 京都

日時

2019/02/10(日) 13:10 〜 18:30

場所

弊社フリュー会議室 (京都銀行 京都駅前支店 6階)

詳しい行き方はこちらを御覧ください。

 

概要

下記2名のGDEがそれぞれ得意分野に関して登壇してくださります。

Enrique Lopez Mañasさん

登壇タイトル:Kotlin/Native for Multiplatform development

AndroidとKotlinのエキスパートで、2013年からGDEとして活動されています。

iñaki Villarさん

登壇タイトル:Diving in the WorkManager API

こちらもAndroidとKotlinのエキスパートです。

GDGバルセロナやGDGマジョルカ、GDGダブリンにて活動するなど、他方にて活動されています。

 

その他登壇者

GDG京都 兼高さん

登壇タイトル:Flutterに関する話題 (仮)

スマートフォンアプリ開発にて最近ホットなFlutterに関してお話頂きます。

兼高さんはGDG京都のメンバーではありますが、全国の勉強会にも幅広く参加/登壇されており、

Androidも初期バージョンの頃から携わられています。

 

フリュー株式会社 古川

登壇タイトル:Build your first Wear App

非力ながら、私も登壇させていただきます!

技術情報があまり豊富ではないAndroid Wear(Wear OS by Google)のアプリをどうやって作るのかをご説明します。

 

イベントの最後には懇親会もご用意しております!

GDEの方と直接会話できる機会はなかなかありません。

会話は英語になってしまうかもしれませんが、ぜひ勇気を出してお話してみてください!

きっと…きっと誰かが助けてくれます!

下記写真は以前の懇親会でご用意した食事の写真です。しっかりお楽しみいただけるかと思います!

IMG_20180914_200603

 

最後に

今後も、このように色々なイベントとの共催も進めていきたいと思っております!

ぜひお声がけくださいませ〜


2018年12月21日

araki

Firebase A/B TestingでアプリのABテストをしよう!

この記事は フリューAdvent Calendar 2018の12/21分です。

こんにちは。ピクトリンク事業部開発部の荒木です。普段はピクトリンクというアプリのAndroid版を開発しています。世間ではスマブラの話が多いなかで、まだスプラトゥーンをやってます。ウデマエはエリアのS+が最大なので、まだXに到達してません。知り合いの子供(ガチホコのウデマエX)に「エリアでS+ならすごいよ。僕はエリアはA+だし。」とフォローされて心が折れそうですが、Xになるまで頑張りたいと思います。

今回は、Firebase A/B Testingをピクトリンクアプリに導入した話を書きたいと思います。

Firebase A/B Testingとは?

https://firebase.google.com/docs/ab-testing/?hl=ja

Firebase A/B Testingを使うと、Remote ConfigまたはNotifications Composerを使ってアプリの画面や通知に関するABテストの実施ができます。A/Bパターンの振り分けはもちろん、結果の分析も実施され、Firebaseのコンソール上で見ることができます。

今回は、Remote Configを使ったABテストについて説明します。

Remote Configを使ったABテスト

テストの作成

ここからは、テスト作成の手順について説明します。画像多めでやっていきます。

① コンソールの左ペインからA/B Testingを選択

左ペインのABTesting

②「テストを作成」を選択

テストを作成

③ Remote Configを選択

RemoteConfigを選択

④ 基本情報の入力

④基本情報の入力

これが、Remote ConfigによるABテストの作成画面です。まずは、テスト名とテストの説明(任意)を入力してください。
今回は、ボタンの色を変えるテストを想定して「ボタンの色」としてみました。

⑤ ターゲット設定

⑤ターゲット設定

テスト対象となるユーザーを設定します。

ターゲットユーザー  アプリのIDやバージョン、ユーザープロパティによって対象を絞ります。
ターゲットユーザーの割合  ターゲットユーザーのうち、何%がテスト対象になるかを設定します。
100%ならターゲットユーザー全員が対象になります。
アクティベーションイベント
(任意)
 このFirebaseイベントが送信されることで、ユーザーがテスト対象になります。
たとえば、特定の画面に遷移したイベントなどを指定します。

⑥ 目標設定

⑥目標設定

コンバージョンの設定をします。

メインとなる目標としてFirebaseのイベントを1つ選択します。このイベントの送信が、コンバージョンとしてカウントされます。また、別のFirebaseイベントを追加したり、推定収益やクラッシュフリー率などを目標に設定することができます。

 ⑦ バリアントの設定

⑦バリアントの設定

次は、バリアントの設定です。バリアントの設定をすることで、Remote Configで取得できる値が変化します。「パラメータ」の部分には、Remote Configのパラメータキーを設定します。「値」の部分にはパターンごとにRemote Configが返す値を設定します。

今回は、 ab_test_param キーで、コントロールグループ(Aパターン)ではBLUE、BパターンではREDを返すような設定にしました。

この設定をしておくと、アプリ側でRemote Configを使って ab_test_param キーで値を取得するとBLUEまたはREDのどちらかが50%の確率で取得できます。

④〜⑦の設定が終わったら画面下の「確認」ボタンを押します。

⑧ テストの開始

⑧テストの開始

テストの内容を確認したら、「テストの開始」を押すとテストが開始します。

ちなみに、「テスト端末を管理」を押すと特定の端末でABパターンを固定する設定ができます。

テスト結果の確認

2週間ほど待つとテストの結果がでます(十分なサンプル数がない場合は終わらないかもしれません)。

下の画像のように、最も効果的なパターンが表示され、コンバージョン率や改善率も提示されます。

ABテストを終了する際に、オリジナルのパターンに固定するか、最も効果的なパターンに固定するかを選択することができます。

テスト結果①

テスト結果②

さいごに

この記事では、Firebase A/B Testingの導入方法と結果の確認について説明しました。Firebase A/B Testingを使うことで、とても簡単にABテストを実施することができます。

ABテストを上手く活用しながらどんどんサービス改善をしていきたいと思います!


2018年12月5日

araki

AndroidのIn-app Billing APIのバージョンについて

この記事は フリューAdvent Calendar 2018 の12/05分です。

はじめに

こんにちは。ピクトリンク事業部開発部の荒木です。普段はピクトリンクというアプリのAndroid版を開発しています。携帯は、Googleブランドの最新スマートフォンPixel3を使っています。非の打ち所がない良い端末なので、みなさん買いましょう。

今回の記事では、Androidの課金APIである In-app Billing API のバージョンについて書きたいと思います。

In-app Billing API とは

公式ドキュメントは以下です。日本語ドキュメントは情報が古かったので、英語ドキュメントを貼ってあります。2018/12/05現在、日本語ドキュメントの最終更新日は2018/4/25、英語ドキュメントの最終更新日は2018/7/17でした。

https://developer.android.com/google/play/billing/api?hl=en

ひとことで言うと、AndroidアプリでGoogle Play課金を実施するためのAPIです。AIDL(Android Interface Definition Language) と呼ばれるインターフェース定義言語によって定義されるAPIで、 .aidl ファイルから生成されるJavaのインターフェースによって利用することができます。

In-app Billing API は、 Google SamplesのIabHelper や Play Billing Library  のように上手くラップしたものがあり、それらを使う分には基本的に意識する必要はないのですが、バージョンごとに使えるメソッドが異なります。日本語ドキュメントや日本語の記事では単に In-app Billing API version 3 と書かれていることが多いので、一度整理してみようというのがこの記事のモチベーションです。

各バージョンで利用できるメソッド

https://developer.android.com/google/play/billing/billing_reference?hl=en

上記のドキュメントを参考に、In-app Billing API version 3 以降のバージョンについて、各バージョンでどのようなメソッドが利用できるかを説明します。

 

 バージョン  メソッド  説明
 3以降  isBillingSupported()  端末がIn-app Billing APIの特定バージョンに対応しているかを調べるためのメソッドです。
 3以降  getSkuDetails()  商品(SKU)の詳細情報を入手できます。
 3以降  getBuyIntent()  このメソッドを利用することで、Google Playによる購入フローを開始するための PendingIntent が取得できます。
 3以降  consumePurchase()  アプリ内アイテムの消費を実施します。たとえば、ゲームなどで有料のアイテムを消費して効果を得た時にこのメソッドを呼びます。
 3以降  getPurchases()  ユーザーが所有する商品(未消費の商品、有効期間内の定期購読)を返します。
 5以降  getBuyIntentToReplaceSkus()  定期購入のアップグレード/ダウングレードに利用されるメソッドです。購読したい商品に加えて、購読解除したい商品を指定することで、新しい商品の購読と、古い商品の購読解除を同時に実施します。
 6以降  getBuyIntentExtraParams()  getBuyIntent() に追加のパラメータを渡せるメソッドです。getBuyIntentToReplaceSkus() と同様に購読解除したい商品を追加パラメータで指定できるので、実質 getBuyIntentToReplaceSkus() のバージョンアップ版と考えられます。
 6以降  getPurchaseHistory()  ユーザーの購入履歴を返します。期限切れの定期購読や、キャンセルされた購入、消費済みの商品も含まれます。
 7以降  isBillingSupportedExtraParams()  isBillingSupported() に加えてアプリ課金のタイプについても調べることができるメソッドです。アプリ課金のタイプとして VR の購入フローを指定して、サポートしているかを調べられます。

 

Play Billing Libraryについて

Googleから提供されている課金のライブラリ Play Billing Library と In-app Billing API のバージョンについても言及しておきます。

2018/12/05 現在リリースされている Play Billing Library の最新バージョン 1.2 の課金周りのコードを見てみましょう。

このコードにあるように、Play Billing Library は、現在 In-app Billing API のバージョン3〜8に対応しているようです。現在の最新APIに対応できていると思われます。

さいごに

この記事では、In-app Billing API のバージョンについて書きました。普段ラップされていて意識しない部分ですが、内部のAPIを調べてみると意外と知らなかったパラメータがあったので、興味深かったです。アプリ課金に関する情報は定期的にアップデートされる印象があるので、しっかりとキャッチアップしていきたいと思います。


2018年12月3日

furusin

TextInputLayoutの導入方法と、導入による効果考察

こんにちは。ピクトリンク事業部の古川です。

この記事はフリューAdvent Calendar 2018の12/03分となります。

AndroidのTextInputLayoutについて触れていきます。

 

TextInputLayoutとは

AndroidのText入力欄をリッチにしてくれるもので、Support Library に含まれています。

Material Design Guidelineはこちら

 

上の動画のように、入力のヒントがアニメーションして常に表示されるようになってくれます。リッチですよね。

最近だと、オミカレさんAndroidアプリがTextInputLayoutに対応しています。

 

導入方法

非常に簡単です。

Support Libraryをimplementする

まずはSuport Libraryを入れます。

これで準備は完了です。

では実際に使っていきましょう。

レイアウトのXMLを作る

TextInputLayoutを入れる

リッチな入力欄を作るには、TextInputLayoutと一緒にTextInputEditTextを利用します。

導入はこれだけです。

ログイン画面風に入力画面を作ると以下のようになります(レイアウトXML全体)

実行すると以下のような画面になりました。

textinputlayoutsample-MainActivity-12032018102340

 

導入のまとめ

いかがでしたか?

非常に簡単に導入する事ができました。

入力欄の色はデフォルトで入っていますが、themeをStyleで作成することで自由に変更することも可能です。

色を自由に変えることで、アプリのデザインに違和感なく導入することができます。

 

導入における効果の考察

以下の2点が大きいと思います。

  1. デザインがかっこよくなる
  2. 入力ミスが低減される

それぞれ見ていきます。

デザインがかっこよくなる

これは言わずもがな、とは思います。

通常のEditTextだとアニメーションも何もなく、少し固い印象です。

TextInputLayoutの小さなアニメーションを入れることで「かっこいい」「なんか動いてる!」といった体験をユーザーへ与える事ができます。

アニメーションがあると、アプリに対するユーザーの感じ方は大きく変化(向上)します。

これだけでも導入する価値は大きいのではないでしょうか。

入力ミスが低減される

TextInputLayoutとTextInputEditTextを組み合わせることで、ヒントが入力欄上部に常に表示されることになります。

そのため、例えばパスワードのような「入力ルール」を常に見られる状態になります。

結果、「半角英数字8文字以上、大文字含む」といったような複雑なルールを忘れずに、スムーズに入力してもらうことが可能になります。

スムーズ入力できるということは、アプリがストレスフリーで利用できることになります。

ストレスフリーなアプリは評価が向上します。

ちょっとしたデメリット

入力欄を全てTextInputLayout+TextInputEditTextにする…となると、その分コードは長くなりますし、

実装関係者が知らずにEditTextをそのまま使ってしまう場合があります。

TextInputLayout+TextInputEditTextを使った独自レイアウトを作っておき、

その独自レイアウトを使うようにルール化すべきなのかもしれません。

 

まとめ

TextInputLayoutの簡単な導入方法と、導入することにおけるメリットをまとめました。

アニメーションやストレスフリーなアプリはユーザー体験を向上させ、アプリの評価も向上させます。

改善は小さなことからコツコツと!

これからも改善活動を続けていきたいと思います。