Furyu
[フリュー公式]

Tech Blog

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

2019年07月18日

furusin

色々な画面サイズのAndroid端末をテストする

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

 

Androidアプリを開発していると「これは画面サイズが大きな端末だとキレイに表示されるけど、小さな端末だとどうなるんだろう?レイアウトが崩れたりしないだろうか?」と思うことが稀に毎日あります。

実際、弊社のメンバーが最近Unihertz Atomを購入しまして「これ…ちゃんと表示されるの…?」と心配になりました。

そんな時、Android StudioのPreview機能を使えば実機を用意しなくても擬似的に試すことが可能です。

実際に手元で見ることはできませんが、「この文字列は改行されてしまわないかな?」といったシーンでは活用できるかと思います。

 

実際にやってみる

実際に確認したレイアウトXMLを開きます。

この作業はDesignタブでもTextタブでもどちらでも実施可能ですが、今回は説明しやすいようにDesignタブで解説を進めます。

画面の上部を見てみましょう。

スクリーンショット 2019-07-18 10.36.23

こんなメニューが並んているはずです。

このメニューには、今作っている画面を「どんな状態で見てみますか?」という選択肢が多数用意されています。

このうち丸く囲ったところを変更することで、画面を表示する際の端末や画面サイズ、解像度を色々と試してみることが可能です。

選択してみると端末のリストが表示されます。解像度も表示してくれているのがいいですね。

スクリーンショット 2019-07-18 10.42.10

よく見ると、上から5つ目の「5.5, 1080 x 2160, 440dpi (Pixel 3)」にチェックが入っています。これが今試している端末のサイズとなります。

より小さな画面サイズをテストする

上記リストのうち下から2つ目「Generic Phones and Tablets」を選択してみましょう。

スクリーンショット 2019-07-18 10.45.05

このように、最初に表示されていたPixel3などとは異なるサイズや解像度のリストが用意されています。

こちらはldpiやxhdpiといった表記がされているのでわかりやすいですね。

「とても古い端末の画面サイズを試したい」といった場合はここから選択するとよいでしょう。

 

独自の画面サイズをテストする

それでは、上記リストに含まれないサイズ(例:正方形)をテストしたい場合はどうすればよいでしょうか。

答えは「じぶんでAVD(Android Virtual Device)を作っちゃう」です。

上記リストに「Virtual Device」とありますよね。これがAVDです。

AVDを作成すると、この「Virtual Device」にどんどん増えていきます。

独自画面サイズのAVDを作成する

上記リストの一番下「Add Device Definition…」を選択します。

スクリーンショット 2019-07-18 10.55.27

すると、AVD Managerが起動します。ここから画面下部の「+ Create Virtual Device…」を選択します。

新たにAVDを作成するための端末を選択する画面に遷移します。左下の「New Hardware Profile」を選択します。

スクリーンショット 2019-07-18 10.56.20

新しい端末を作成する画面が表示されます。

ここでテストしたい画面サイズを入力します。

「Screen」の「Resolution」に入力します。今回は例として500 x 500 の正方形にしました。

作成した端末の情報がわかりやすいように、「Device Name」を画面サイズにしておくとよいでしょう。今回は「500×500」としています。

 

スクリーンショット 2019-07-18 10.59.29

画面の作成をFinishすると、端末を選択する画面に、作成した端末が追加されています。

この端末を選択し、通常通りAVDを作成しましょう。

スクリーンショット 2019-07-18 10.59.42

AVDの作成が完了すると、最初の端末リストに作成したAVDが追加されます。

スクリーンショット 2019-07-18 11.05.26

これで特殊なサイズの端末が発売されても、わざわざ購入せずともレイアウトが崩れていないか確認することができます!

最後に

でも特殊な端末が発売されたら手元に欲しくなるのがガジェ厨


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を調べてみると意外と知らなかったパラメータがあったので、興味深かったです。アプリ課金に関する情報は定期的にアップデートされる印象があるので、しっかりとキャッチアップしていきたいと思います。