カテゴリー: Android

Androidのプログラミングについての情報を取り扱っています。

TouchDelegateを使ってタッチ可能領域を拡張する

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Buttonのクリックに反応する範囲を拡張したい時がある。
今回は下図のようなカスタムViewを作りたかった。

Image

ImageButtonとTextViewを内包したViewである。
親レイアウトのViewGroupをタッチする=ImageButtonをタッチするという扱いにしたかった。

ImageButtonにしているのは、他のViewとの兼ね合いである。
他のViewはImageButtonにstyle="@style/Base.Widget.AppCompat.ActionButton"を適用して、アイコン画像の周りにだけリップルエフェクトがかかるようになっていて、このカスタムViewもそれに合わせたかったのである。

これはTouchDelegateを使うと実現できる。

TouchDelegate – Android Developers

使い方

TouchDelegateは親のViewGroupに設定する。

TouchDelegateのインスタンスを作成するには、タッチエリアを表すRectと委譲先のView(今回でいうとImageButton)への参照が必要。
Rectはローカル座標系(ディスプレイ上での絶対座標ではなく、ViewGroupの左上を0とした相対座標)を使う。
今回はViewGroupのgetDrawingRect()を使って取得したRectを使った。

ぐぐるとgetHitRect()を使った例がみつかったが、これだとうまく動かなかった。絶対座標になっているからだと思われる。

コード例

class CommentStatusView @JvmOverloads constructor(
    context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0
) : ConstraintLayout(context, attrs, defStyleAttr) {

    private lateinit var binding: ViewCommentStatusBinding

    init {
        binding = ViewCommentStatusBinding.inflate(LayoutInflater.from(context), this, true)
        doOnPreDraw {
            val rect = Rect()
            binding.viewGroup.getDrawingRect(rect)
            binding.viewGroup.touchDelegate = TouchDelegate(rect, binding.imageButton)
        }
    }

    override fun setOnClickListener(l: OnClickListener?) {
        binding.imageButton.setOnClickListener(l)
    }

}

Kotlinで、Android-ktxとDataBindingを使っている。

doOnPreDrawがAndroid-ktxを使っている部分で、ViewTreeObserverを利用してViewの大きさが決まった後で中のブロックの処理(TouchDelegateの設定)を行っているだけである。

後はこのカスタムViewに対するsetOnClicklistenerをImageButtonに対して設定するようにしている。

ポイントは

  1. 親のViewGroupに対してTouchDelegateを設定する
  2. rectはTouchDelegateを指定するViewGroupからみて、どの位置のタッチイベントを委譲先に渡すのかをローカル座標系で指定する

ドキュメントに書いてあるとおりなのだが、英語力がなくていまいちわからず、ググったコードを参考にしながらやってもうまくいかずでちょっとハマった。

実際の動きはこんな感じになった。
リップルエフェクトもクリックリスナもViewGroupに対するものがImageButtonを押している扱いになっている。

Ezgif 4 fc7d03caa2

TextViewに設定したテキスト内のURLに遷移する

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

TextViewに設定したテキスト内にURLがあった場合に、そのリンクをクリックできるようにしたい。
クリックしたらブラウザが開いて該当ページに移動できるようにしたい。

手っ取り早くこの要望を満たそうと思ったら、TextViewには便利な機能が用意されている。
TextViewにandroid:autoLink="web"を追加すればよいだけである。
これでテキスト内のURLをクリックしたらブラウザが開いてくれる。
めでたしめでたし。

といくなら楽でよかったのだが、この機能によるURLの処理はあまり正確ではない。

autoLinkの問題点

Spannable

URLが半角スペースで区切られていたり、2バイト文字以外で区切られていたりしたら正しくリンクとして拾ってもらえる。
例えばあいうえお https://android.gcreate.jp/ かきくけこというテキストであればURLの部分のみがURLとして識別される。
しかしあいうえおhttps://android.gcreate.jp/だとリンクを拾ってくれない。
またあいうえお https://android.gcreate.jp/がリンクになってほしいとした場合、「がリンクになってほしい」という部分までURLとして拾われてしまう。
2バイト文字でない半角カッコで囲ってかっこで(https://android.gcreate.jp/)とした場合、閉じカッコもURLに含まれてしまう。

URLの抽出がうまくいかない場合があるのが最大の問題であるが、URLのハンドリングをカスタマイズできないのもちょっと不便である。
例えばChromeカスタムタブでリンクを開きたい場合に、autoLinkでは対応できない。
autoLinkの場合、リンクをクリックするとACTION_VIEWの暗黙的インテントが発行される。

自前で処理する

以上の問題点を回避するには、自分でテキストにClickableSpanを設定してやると良い。

  1. テキストをSpannableStringに変換する
  2. テキストから正規表現を利用してURLを抽出する
  3. 抽出したURLを用いてSpannableStringにClickableSpanを設定する
  4. TextViewにSpannableStringをsetTextで設定する
  5. TextViewにsetMovementMethodを設定する

以上の手順で独自のClickableSpanを設定することができる。

コード的にはこんな感じ(Kotlinとandroid-ktxを利用している)。

val text = "あいうえおhttps://android.gcreate.jp/かきくけこ"
val spannable = text.toSpannable()
val matcher = Pattern.compile("(https?|ftp|file)://[-a-zA-Z0-9+&@#/%?=~_|!:,.;]*[-a-zA-Z0-9+&@#/%=~_|]").matcher(text)
while (matcher.find()) {
  val url = matcher.group()
  val start = matcher.start()
  val end = matcher.end()
  spannable.setSpan(MyUrlSpan(url), start, end, Spanned.SPAN_EXCLUSIVE_EXCLUSIVE)
}
textView.text = spannable
textView.movementMethod = LinkMovementMethod.getInstance()

MyUrlSpanは自分で定義する。
といっても大したことはやっていない。

class MyUrlSpan(val url: String) : ClickableSpan() {
    override fun onClick(view: View) {
        Snackbar.make(view, "$url clicked", Snackbar.LENGTH_SHORT).show()
    }
}

SnackbarでURLを表示しているだけ。
リンクをクリックした際の挙動はこのonClickでカスタマイズできる。

もう少し詳しく

このあたりの挙動が知りたければ、TextViewのソースコードを確認するのが手っ取り早い。
mAutoLinkMaskをキーに見ていくとだいたい分かると思う。

ClickableSpanを設定する際に必要なのは、文字列中のどこからどこまでにClickableSpanを適用するかが必要になる。
これは正規表現を使ってマッチさせれば該当する文字列、その文字列の開始位置・終了位置が分かるのでそれを使えば良い。
正規表現はこちらの記事を参考にさせていただいた。
AndroidのTextViewのautolink=webが冗長になる

setSpan()する際の第4引数はflagsである。
https://developer.android.com/reference/android/text/Spanned
これはEditTextにSpanを設定しないのであれば、おそらく何を設定しても影響はないと思う。
(Spanを設定したテキストの内容が動的に変化する場合に、変更前に設定したClickableSpanの開始位置・終了位置がどう変動するかを指定するフラグだと思うので)

TextViewのTextをSpannableにして、ClickableSpanを設定しただけではリンクをクリックすることはできない。
ClickableSpanのonClickが呼び出されるためには、setMovementMethodで何らかのMovementMethodがTextViewに設定されていなければならない。
autoLinkを使った場合のLinkをタップしたときの動きはLinkMovementMethodが使われているのでここはそのまま流用する。
ClickableSpanのonClickを呼び出すかどうかは、TextViewのonTouchメソッド内の処理を確認すれば分かるが、mMovementがnullではないことが条件になっている。
だからTextView.setMovementMethod(LinkMovementMethod.getInstance())を行っているのである。

Spannable.Factory

上記のコード例では、TextViewにsetTextする際にSpannableStringを準備してからsetTextで渡している。
この方法だとRecyclerViewなどでTextViewを再利用する状況を考えるとややめんどくさい。
ViewHolderにbindするときに、設定するテキストをSpannableに変換して、正規表現使って検索して・・・となるわけで、bindする部分のコードがすっきりしない。

かといってTextViewを継承した独自のカスタムViewを用意するのも、TextViewのsetTextをオーバーライドできないのでこれもあまり美しくない。

そういう場合にはSpannable.Factoryを使うと良い。

TextViewにsetSpannableFactory()を使ってSpannable.Factoryのクラスを設定すると、そのTextViewのsetTextを呼ぶだけで指定したSpannableの処理を行ってくれる。

object UrlSpanFactory : Spannable.Factory() {
    private val regex = Pattern.compile(
        "(https?|ftp|file)://[-a-zA-Z0-9+&@#/%?=~_|!:,.;]*[-a-zA-Z0-9+&@#/%=~_|]")

    override fun newSpannable(source: CharSequence): Spannable {
        val spannable = source.toSpannable()
        val matcher = regex.matcher(source)
        while (matcher.find()) {
            val url = matcher.group()
            val start = matcher.start()
            val end = matcher.end()
            spannable.setSpan(MyUrlSpan(url), start, end, Spanned.SPAN_EXCLUSIVE_EXCLUSIVE)
        }
        return spannable
    }
}

...


val textView: TextView by lazy { findViewById<TextView>(R.id.text_view) }

textView.setSpannableFactory(UrlSpanFactory)
textView.setText("あいうえおhttps://android.gcreate.jp/かきくけこ")
// これでURLの部分がリンクとして修飾される

https://medium.com/google-developers/underspanding-spans-1b91008b97e4

RoomでLiveDataを扱うときに注意

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Architecture Componentで追加されたRoomを実際に使ってみた。

なんかややこしそうと思って敬遠していたのだけど、やってみると意外とそうでもないなという感じで「あれ、これだけ?」っていう感じで実装できた。実装できたと言っても、適当なサンプルだから簡単だっただけなんだけども。

https://github.com/gen0083/SampleArchitectureComponent

RoomではDatabaseDaoEntityの3種類を用意してやると、AnnotationProcessorによるコード生成が行われてSQLiteを簡単に利用できるというライブラリ。

LiveDataを返すようにDAOで定義することができ、この場合Databaseが更新されるとその変更がLiveDataを通じて受け取れる。いわゆるいいねボタン問題を解決する一つの解決策と言える。

LiveDataを返すようにDAOで定義を行うと、その処理はバックグラウンドで実行されるようなコードが生成される。逆にそれ以外の処理は自分で実行スレッドを考慮しないといけない。デフォルトだとRoomで生成されたコードをメインスレッドで実行すると例外が吐かれる。

LiveDataを返すようにする場合は注意しなければいけないことがある。

https://github.com/gen0083/SampleArchitectureComponent/blob/master/app/src/androidTest/java/jp/gcreate/sample/samplearchitecturecomponent/data/repository/TestRepositoryByRoomTest.kt#L66

このコードのようにsut.watch().valueとLiveDataのvalueを取得しても、その時点ではvalueはnullである。該当のテーブルのデータ全件取得と変更通知を兼ねてLiveDataを使おうとすると想定通りに動かない。実際にデータが取れるまでは時間がかかる。

LiveData<List<TestData>>としておけば、変更通知も受け取れる、データ全件取得もできる、便利じゃんと思ったけど、そうそううまくはいかなかった。といっても、RecyclerViewに表示する目的であれば、LiveDataを使うとすごい楽ちんであった。同じくSupport LibraryのListAdapterと組み合わせるとすごい楽。

ちなみにこのLiveDataを返すメソッドのユニットテストを行う場合、android.arch.core:core-testing:$architecture_version"を追加して、@get:Rule var executorRule = InstantTaskExecutorRule()とJunitTestRuleを適用してやるとうまいことテストができる。このルールを適用しないとバックグラウンドでの処理を待たずにテストメソッドが終了してしまい、LiveDataからデータを受け取ることなくテストが終了してしまう。

versionCodeの最大値

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Google Playにアプリをアップロードする際、versionCodeを常に増やしていく必要がある。

Gradleを使ってこのversionCodeを自動的に生成する(versionNameと一緒に)ときに、versionCodeには最大値が存在するということは覚えておかないとならない。

https://developer.android.com/studio/publish/versioning.html

Google Playでは2.1Mが最大値となっているらしい。

versionCodeを生成するスクリプトを書く際は、APKを作成してそのAPKのversionCodeを確認するところまで気を配ろう。スクリプトでversionCodeが生成できていることだけ確認して、Google PlayにAPKをアップロードしたら最大値にひっかかって更新できなくなった、なんてことになったら悲しすぎる。

ちなみにこの問題にでくわしたのは、versionCodeをメジャーバージョン3桁、マイナーバージョン3桁、パッチバージョン3桁、ビルド番号3桁、MultiAPK識別用の符号1桁でversionCodeを生成したときである。

Google PlayにAPKをアップロードする前に気づけて良かった。

Androidアプリ設計パターン入門を読んだ

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Androidアプリ設計パターン入門を読んだ。製本版を買ったとばかり思っていたが、電子版で出資していた。思い込みとは恐ろしいものである。

せっかく出資して購入したのだから、もっと早く読んで(アーリーアクセス版で)疑問点なり質問すればよかったなと今更後悔している。

購入した動機は、設計に関する考え方を知りたかったからだ。

考え方というと勘違いされてしまうかもしれないが、○○という設計パターンはこういうところで優れている、なんてことを知りたかったわけではない。他の人(というか日本Android界を引っ張っていくようなエンジニアの方々)が、どういうことに困ってどういう思いで設計パターンを選んでいるのだろう、というところが知りたかったのである。

その観点から言うと、やっぱりみんな困るところは一緒なんだなぁということが分かってよかった。個人的には特に4章が興味深かった。

そもそも私自身はこれまでずっとソロで開発してきているので、チーム開発の話自体が新鮮である。みんなこういう感じで開発してるのかと、そういう雰囲気が感じられる事自体が何よりありがたい。そういう意味で買って(出資して)良かったなと思っている。

正直な話、ソロ開発する上ではどの設計パターンで作るかについて神経質になる必要はないと思う。最近の私は、とりあえずActivityのライフサイクルに振り回されないように作ればいいかな程度のゆるい考え方で、設計パターンの遵守より作りやすさを優先して作っている。

本書を読んでいて思ったのは、やはり設計パターンはチーム開発において重要になってくるものだということだろう。

どの章も、チームでの開発の視点で描かれている。設計パターンの導入とチームでの開発は切っても切り離せない問題なのだ。

本書は、Androidにおいてこの設計パターンで作れば間違いがない、このパターンこそ最強であるからこれをやっておけ、という内容にはなっていない。だから、結局どのパターンを学んでおけば安泰なのか知りたい、という観点で読むと肩透かしを食らうと思う。

そもそもそんな銀の弾丸があるなら、みんながそのパターンで作っているはずだ。

私は本書を読んでいて、Fluxパターンはなんか良さそうだなと思ったのだけど(データの流れを一方通行にするというところと、状態を保持するStoreが独立してるってところが良さそうに感じた)、じゃあこのパターンでリストのスクロール位置を保存しようと思ったらちょっと大仰すぎやしないかと感じる。スクロールの度にActionを発行して、Storeの状態を更新していくのだろうか。onSavedInstanceSateで位置を保存するだけでいいんちゃうのと思ったりする。

そんなわけで銀の弾丸はない。どの設計パターンを学べばいいですかっていう人にはもしかしたら合わないかもしれない。

Android開発においては、どんな設計パターンがどういう問題を解決するために使えるのか、どういう作り方をするのかという考え方を学んでおくしかない。自分が他のチームにジョインした時に困らないように。

これからチーム開発を行っていけるようにするためには、どういう問題を解決するためにどんな設計パターンが存在していて、どんな感じにAndroidに適用してくのかの考え方を知っておくことが大事だと思う。その考え方について、本書はMVP、MVVM、Fluxといった設計パターンを、著者の考え方とあわせて書かれているので、独学で勉強していますとかチーム開発の経験がない人ほど有用であるように思う。少なくとも、ずっと独学で勉強してきた私にとってはとても有用な内容だった。

具体的にどうやって実装していくかなんて言うのは自分で手を動かしてみないとわからない。本書で大事なのは著者の頭の中身が覗ける(考え方が赤裸々に書かれている)ということである。

ああ、私も誰かと一緒にアプリ開発したい(切実)。

Android アプリ設計パターン入門

Android アプリ設計パターン入門

  • 著者:日高 正博,小西裕介,藤原聖,吉岡 毅,今井 智章,
  • 製本版,電子版
  • PEAKSで購入する

Adaptive Icon

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Adaptive IconをFigmaを使って作ってみた。

Adaptive icon

Adaptive Iconは、開発者側はアプリのアイコンとなる前景画像と背景画像の2種類だけを用意して、後のアイコンの形はOS(デバイス側)にまかせてしまうという仕組み(という理解を私はしている)。

今まではランチャーアイコンとして四角いやつと丸いやつの2種類を別途用意していたけども、これからは2種類の画像(前景と背景)さえ用意しとけば後はOS側(正確にはホームアプリ?)がアイコンの形をよしなに表示してくれる。

といってもAPI26からの機能なので、現実的には依然として普通のランチャーアイコンは用意しなければならない。

とはいえ今回Figmaを使ってアイコンを作ってみたが、25以下のための画像データを用意するのはそこまで手間だとは感じなかった。108dpでアイコンデータを作っているので、その画像をAndroid Asset Studioに持っていってランチャーアイコンを生成するだけだったので。

Figmaを使ってアイコンデータ作成

今回はFigmaを使ってアイコンデータを作成した。ちなみにベクターデータである。

作成したforeground画像とbackground画像を、Adaptive Iconとして表示した場合にどうなるかは、このツールを使ってシュミレーションしながら確認した。

Adaptive Icon非対応の端末用の既存のランチャーアイコンは、Figmaから書き出した画像データをAndroid Asset Studioを使って生成した。

こんな感じで作成。

Icons

これは重ね合わせた状態だが、前景と背景別々に作ってある。

Fore back

どちらの画像も108dp四方になるように、108dpの矩形を別途用意した上で、その上にアイコン要素を描画するようにしている。そうしないとエクスポートした際に108dpの画像として出力できないからである。

作成した画像はforegroundとbackgroundそれぞれをSVGでエクスポートして、そのSVGファイルをVector Drawableに変換してAndroid Studioへ持っていった。

Vector Drawableへの変換はこのツールを利用した。

複雑な形状だとうまく変換できないこともあるので、適宜調整が必要だろう。Vector Drawableとしてうまく変換できたとしても、パスデータが複雑すぎるという警告が出ることもある。あまり複雑すぎるのも考えものである。

ちなみにFigma用のAdaptive Iconのテンプレートがあったので、こちら
から利用させていただいた。

テンプレートのサイズはFigma上では432になっている。Adaptive Iconは108dpで作成するものだ。FigmaとかSVGの仕様とかに疎いのでよくわからないのだが、432のサイズでアイコンを作成してSVGでエクスポートしても問題ないのだろうか?

私はよくわからなかったので、アイコンサイズを108の大きさで作成した。

ちなみに432とか単位をつけずに書いているのは、Figma上での単位が分からなかったからである。432のままSVGエクスポートしてVector Drawableに変換すると432dpになってしまい、そこからXMLの数値を108dpに書き換えるだけで問題ないのかよくわからなかったので、最初からFigmaの段階で108のサイズで作成したというわけ。

ちなみにテンプレートは一旦フラット化してベクター情報に変換し、サイズを108に縮小してアイコン画像の位置調整のガイドとして利用させてもらった。

Adaptive Iconの対応状況

こうして作成したAdaptive Iconだが、これが表示できるかどうか使っているランチャー次第のようだ。

私の場合、実機Nexus6P(Android 8.1.0)に作ったAdaptive Iconのアプリをインストールしても、固定されたアイコンとしては表示されるものの、アニメーション(ぷるぷる動くような視覚効果)はしなかった。

Pixel Launcherだとぷるぷるするらしい。

私の使っているランチャーはGoogle Nowランチャーなので、Adaptive Iconにきちんと対応しているわけではないようだ。アイコンとして表示することはできるが、アイコンのシェイプを変えたり、アニメーションしたりしない。

試しに他のランチャーをインストールして試してみたところ、Adaptive Iconへの対応を謳っているランチャーであればAdaptive Iconがぷるぷるすることを確認した(私が試したのはNova Launcher)。

参考

3分で分かる?Android OのAdaptive Iconに対応しよう

Adaptive Iconのシミュレーションツール(Web)

Designing Adaptive Icons(各ツールにおけるテンプレートへのリンクあり)

SvgToVectorDrawableConverter.Web(SVGをVector Drawableに変換するツール)

アプリアイコンづくりにFigmaが便利でいいかもしれない

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Sketch はもういらない? デザインツール Figma の紹介という記事を見て知って使ってみた。

ググラビリティが異様に低い(検索するとフィギュア関連のサイトのほうが多く引っかかる)ので、探すのにちょっと苦労する。

UIが英語オンリーなんだけど、それを言ったらAndroid Studioだって同じなので障害にはならないと思う。

私はSketchを持っていないし、チームでデザインなんてこともやったことがないので、そういった観点からこのツールを評価することはできないし、今回はそんなことを言うために記事を書いているのではない。

使ってみたらベクターツールが結構面白いのである。そんなに機能があるわけでもなく、シンプルなことしかできないのだけど、直感的にやりたいことができるというか。ちょっとしたアイコンを作ろうとするときなんかは、扱いやすくて便利なんじゃないかなと思う。

四角形を描画して、その四角形を元にアンカーポイント追加して形を微調整して・・・なんていうのがシンプルにできて、個人的に直感的な操作ができて便利だなぁと思ったのである。

アプリのアイコンを作成するくらいの用途であれば充分使える気がする。

私の場合、Windowsでタブレットを使って手書きで下書き、その画像をMacのAffinity Designerを使ってベクタデータにするなんて作業をしていた。FigmaだとWin-Macを行き来するのも楽でいい。

ちょっと気になるのは、Figmaはタブレットのペン操作に対応していないっぽいということ。タブレットのペンで操作すると、どんなツールを選んでいようともスクロール操作にしかならなくて困った。

ただ、アプリアイコン作るくらいの用途であれば、ベクタツールがシンプルでFigmaは便利なんじゃないかと思う。

KotlinでUnitテストでassertionに何を使うか

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

KotlinでUnitテストを書く際に、assertionに何を使うかという話。

私の場合特にこだわりがあるわけではないのだが、基本的には多数派に従いたいという気持ちが強い。しかしながら、Kotlinのテストのassertionに使うならこれ一択、みたいなものがない(と思っている)ので、いつも困る。

Javaなら特に何もせずともhamcrestのassertThat(sut.getHoge()).is("fuga")みたいなassertionを使っていればいいのだが、Kotlinの場合はisが予約語であるという問題がある。いちいちisをバッククォートでくくらなければならず美しくない。

knit

https://github.com/ntaro/knit

日本ではいちばん有名なやつだと思われる(DroidKaigiのアプリでも使われていたはずなので)。

sut.getHoge().should be "fuga"みたいな感じで使う。

ただrepositoryを追加しないと組み込めないので私はあまり使っていない。build.gradleに一行追加するだけの話なんだけどね・・・。

expekt

https://github.com/winterbe/expekt

knitに似たsut.getHoge().should.equals("fuga")みたいな感じのAPI。リポジトリの追加が必要ないので、私はこっちをよく使っている。

ただメンテされてないのが玉に瑕。

kotlintest

https://github.com/kotlintest/kotlintest

assertionライブラリではなくて、Spec風のテストを書くためのライブラリ。

ただsut.getHoge() shouldBe "fuga"みたいなassertionが含まれている。

SpekというSpec風のテストを書くためのライブラリがあるが、こちらはJava8でなければ使えないという制約があって、Androidのプロジェクトに適用するのはなんだか難しそうで手を出していない。

kotlintestはネストしたテストを書きやすくて、これいいかもとか思ったこともあったのだけれど、androidTestに組み込むとメソッドカウントがオーバーしてしまうので使えない。

assertk

https://github.com/willowtreeapps/assertk

Android Weeklyで流れてきて知った。AssertJチックなassertionライブラリで、Kotlinで使うならコレのが便利なのだろうか。

assert(sut.getHoge()).isEqualTo("fuga")みたいな感じで使う。

しかし個々最近はshould系ばかり使ってきているので、最初にassertを書かないといけない形式はめんどくさいと感じてしまっている。

AssertJ

http://joel-costigliola.github.io/assertj/

Javaのコードも考慮に入れるならJavaで使えるライブラリを使うのがいいのだろう。

私はJavaだとhamcrest使っとけばいいやな人だったので、Javaでassersionライブラリを何使うかなんて特に気にしたことはなかった。

みんなが使っているものが知りたい

みんなはどれを使っているのだろうか。他にこれが使いやすいみたいなのがあったら教えて欲しい。

私はexpektを使う傾向が強いが、揺らいでいる。

正直なところassertionさえできればなんでもいいのだろうからして、自分が使いやすいものを使えばいいってだけの話なのだろうけれども。

https://discuss.kotlinlang.org/t/what-assertions-library-do-you-use/1809

ここをみると、kotlintestが多いっぽい。

Instant-appを試してみた

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

Instant-Appを試してみた。FlexibleTimerというアプリを作って、Instant-Appに対応させてみたのである。

https://play.google.com/store/apps/details?id=jp.gcreate.product.flexibletimer

Instant-Appというのは、アプリをインストールすることなく使えるようにする仕組みで、今回作ったアプリはhttps://app.gcreate.jp/flexibletimer/にアクセスすれば試すことができる。(Androidからアクセスすれば実行できるはず)

Instant-Appを実行できる環境

今のところAndroid6.0以上の端末であれば動くらしい。

Android6.0(API23)以上の端末であれば、おそらく設定 > Googleの中にInstant Appsという項目があると思う。それを有効にすればInstant-Appが実行できる。将来的にはAPI21以上もサポートされるらしいが、今は23以上が要件。

1つ注意点があって、Instant-Appはどうもどれか1つのアカウントでしか有効にできないみたい。私は2つのアカウントを1つの端末で使っていて、片方のアカウントでInstant-Appを有効にすると、もう片方は無効になってしまう。

このことで何を注意しなければならないかというと、Chromeにログインしているアカウントと、Instant-Appを有効にするアカウントは揃えておけということである。揃えていないとChromeからInstant-Appを提供しているURLにアクセスしても、Instant-Appが実行されないからである。揃えていなくても、例えばSlackで共有されたURLを開けばInstant-Appが実行されるし、Google Playからサイトに移動しても起動するので、Instant-App自体が使えないわけではない。

用意したURL(これはアプリを作成する際にAndroidManifest.xmlに定義する)にアクセスすれば、Instant-App用のAPKをGoogle Playからロードしてきて、インストールすることなくアプリが実行される。

URLは実際にアクセス可能でなければならない。つまり、Webサイトを所有していない場合には使えないということになる。所有していない場合はFirebase Hostingを利用してねというQAがある。(Stackoverflow

Instant-Appへの対応の仕方

今のところAndroid Studio3.0を使わなければInstant-App対応は不可能である。理由としては、3.0でなければInstant-Appを作成するために使うcom.android.featureプラグインが認識できないからだ。

まだ3.0は正式バージョンではないので、急いで対応しないとならないというものではないと思う。

既存のアプリをInstant-Appへ対応させるのは、そんなに難しい手順が必要なわけではない。たぶん、3.0でビルドできなくなったとか、gradleプラグインが対応してなくて動かないとか、そういった種類のトラブルに対応するほうがはるかに大変なだけだと思う。

細かいやり方はドキュメントを見てもらえばそんなに難しくはないと思う。

ちなみにcodelabで既存のアプリをInstant-App対応させる方法が一通り学べる。

はまったポイント

foreground serviceが動かない

Instant-AppではLong-running background serviceはサポートされていないが、foreground serviceは使うことができる。ことになっているが、現時点ではまだ対応されていないらしい。

Stackoverflow

Architecture Componentが動かない

私の場合LiveDataを使おうとしていたのだが、Instant-Appでは使えなかった。エラーは起きないが、LiveDataの変更が受け取れなかった。

https://issuetracker.google.com/issues/38493434

Content Providerの仕組みで初期化してるから、Content Providerが使えないInstant-Appでは動かないのではないのかということらしい。

しょうがないので、RxJava2のBehaviorSubjectに置き換えて対応した。

App Linksの設定

私はApp Linksにこれまで対応したことがなかったので、Android StudioのApp Links Assistant任せでやっていたのだが、App Linksについて、仕組みとか対応の仕方とかをちゃんと調べてからやったほうがハマりが少ないのではないかと思う。

特にAndroidManifest.xmlの記述に関してはちゃんとドキュメントに書いてあるので、App Links Assistantに任せるのではなく、ドキュメントを見ながら設定するように。ビルドすること自体は問題なくできるが、Google PlayにAPKをアップロードしたときにはじめて弾かれるので、設定ミスに気づくのが遅くなってしまった。

https://developer.android.com/topic/instant-apps/prepare.html#default-url

私の場合、1つのintent-filterにhttpsとhttpの両方を設定すること、<meta-data>タグでdefault-urlの設定をすることが漏れていて、無駄な時間を過ごしてしまった。

サイト側の設定

私の場合はhttps://app.gcreate.jp/flexibletimer/というURLの、Webサイト側の設定をどうするかという話である。

必須なのはhttps対応することと、有効なドメインを持つこと、後は該当サイトにアクセスできるようにWebサーバを用意することだ。

Instant-AppのためにはApp Linksの対応が必要なので、https://developer.android.com/training/app-links/index.htmlを確認しながら設定すると良い。

Instant-AppのAPKはGoogle Playに置くだけであり、サイト側ではドメイン直下に.well-known/assetlinks.jsonファイルを配置するだけである。

ただこのApp Linksの設定は、Instant-Appの実行に関してはあまり意味は無いのだと思う。これはあくまでApp Linksの設定だから、インストールしたアプリがある状態で、指定したURLにアクセスしたときにアプリが起動するようにするための設定だと思うので。

しかしそうすると、なぜ指定したURLにアクセスするとInstant-App用のAPKがGoogle Playから読み込まれるのかがよくわからない。

仕組みがよくわからないので、どう設定したらどう動くのかが知りたくて、今回試してみたわけである。

とりあえず、用意したURLにアクセスすればGoogle PlayにアップロードしたInstant-AppのAPKが読み込まれてアプリが実行されるという仕組みのようで、Webサイト側は特別な設定は必要なかった(App Links用のjsonファイルを用意するくらい)。

現状ではcanaryバージョンのAndroid Studio3.0を使うので、Instant-Appがどうのというより、Android Studioのバグに振り回されることのほうが多かった気がする。

Instant-Appは利用者同士がコンテンツを共有するようなタイプのアプリの場合、特に効果的だと思う。むしろ今回私が作ったような、アプリ単体で完結してしまうようなアプリの場合、Instant-Appである意味はあんまりないと思った。アプリ内でやり取りされるコンテンツを、アプリをインストールしていないユーザに対して簡単にアクセスできるようにするのがInstant-Appの強みだと思う。

Architecture Componentを触ってみた

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

とりあえず軽く触ってみた。

codelab

Google IOの動画はとりあえず2つ見てみた。

最初のやつは「こんなん作ったでー」という話で、2つ目がその中身を説明っていう感じなので、時間がないなら2つ目だけ見ればいいんじゃないかなと思う。全部英語なので、私の英語力では雰囲気しかわからず時間対効果はあまり良くなかった気がしている。

3つ目もあるのだけど、これはまだ見れていない。タイトルから見るとRoomについての説明なのだろうか。

個人的にArchitecture Componentで気になっていたのは、いかにActivityのライフサイクルに振り回されなくてすむようにできるかという部分だ。つまり、LifecycleOwnerLiveDataViewModelについてである。とりあえずその観点で言うと、最初にあげたcodelabを触れば、雰囲気はわかった。2つ目の動画でだいたいスタンスがわかったような気がしている。

たぶん2つ目の動画で話していたと思うのだけど、このArchitecture Componentはすでに個々の開発者がそれぞれの工夫でActivityなどのライフサイクルによる呪縛を回避している手段を置き換えるためのものではないという話が、個人的にはしっくり来た。すでにライフサイクルとの付き合い方がうまくできている人は、別にそれでいいと。

ただ、Androidをこれから学ぼうとする人にとっては、Android特有のライフサイクルにまつわるあれこれは、学習していく上でつまづきやすいポイントで、さらにそれを回避するためのライブラリの使い方を学ぼうとすると余計にややこしくなってしまう。そこで、これからAndroidを学んでいく人にとって、とっつきやすいシンプルな仕組みを用意したよ、というのがArchitecture Componentということらしい。

私は最近ではDaggerやRxJavaを使って、Activityにはデータを持たせない、単に表示するだけのものとして扱うようにしてアプリを作るようにしている。そういった方法ですでにうまいこと回せているなら、無理して移行する必要はないのだろう。すでにうまいことやっている人にとっては、ちょっと触れば雰囲気がつかめるだろうから、とりあえずcodelabだけ触って雰囲気を掴んでおいて、1.0が出るのを待つくらいのスタンスでいいんじゃないかなと思う。

以下は触ってみた感想。

LifecycleOwnerとは

ざっくりした理解で言うと、ActivityとかFragmentとかServiceとか、Android特有のライフサイクルをもってるオブジェクトのことという認識でいる。

LiveDataの購読を行う際に引数に指定してやったり、ViewModelの生成・取得を行う際に引数に渡したりするのに出てくる。

LiveDataの購読に関しては、LifecycleOwner(Activityとか)のライフサイクルにあわせて自動的に購読解除してくれるらしい。つまり、いちいち自分でunsubscribe/disposeとかしたりしなくていいっていうこと。

またActivity等のライフサイクルにあわせた処理を行うのに利用したりできるっぽい。(codelabではLocationManagerから位置情報を受け取るクラスを作って、Activityのライフサイクルにあわせてセンサーの登録と解除を行うのに使っていた)

LiveData

UIに表示したりする実際のデータ。DataBindingでいうObservable<Hoge>みたいなものだし、RxJavaでいうObservable<Hoge>みたいなもの。

その実態は最新の値を保持してよしなに通知してくれるデータホルダー。RxJavaみたいなストリームではないよということだ。またスレッドの概念も持ってないので、バックグラウンドで処理してメインスレッドで通知みたいなことはしない。

LiveDataの更新はメインスレッドでないとできないみたいで、別スレッドからLiveData.setValue()したら落ちた。別スレッドから値を更新したい場合は、postValue()を使うらしい。

ActivityなどのViewは、このLiveDataを購読して、変更を受け取ったらUIを更新することだけ考えるような作りにするのが良いのだろう。

RxJavaでいうBehaviorSubjectみたいな動きをするなぁという印象を持った。

ViewModel

画面回転してもライフサイクルが継続してくれるもの。これが最初からあればAndroidアプリ開発はもっと楽になっていただろうと思う。

今までActivityにもたせていた状態やロジックを、全部こっちに持ってくればうまいことできると思う。

Activity.finish()を呼び出したらViewModelのライフサイクルも終了する(ViewModel::onCleard()が呼び出される)。

画面を回転させた場合はそのまま以前の状態を引き継いだものが、再生成されたActivityに渡ってくる。ただ、あくまでonConfigurationChangeで破棄されないだけなので、ホーム画面に一度移動した後にOSによって終了されたりした場合(Activityを保持しないが有効になってたりした場合)はViewModelのライフサイクルも終了してしまう。

データの永続化は別途考えないといけない。

軽く触ってみて

RxJavaなどの知識を持っているからか、割りとすんなり使えそうな気がしている。

それを抜きにしてもそんなにややこしくないと思うので、Androidをこれから学ぼうという人はとりあえずArchitecture Componentの使い方を学ぶと、シュッと入門できていいんじゃないだろうか。

触る前は「なんかいろいろあってややこしそうだな」とか思っていたのだが、触ってみると思いの外それぞれ独立していて、使いたいコンポーネントだけ利用すればいいという意味がよくわかった。

私個人としては、ViewModelはすぐにでも使いたい。Daggerを使って似たようなことをやっていたけれども、ViewModelを使うほうが楽だ。LiveDataはもうちょっと調べて、DataBindingとの組み合わせ方を掴んだら置き換えるかもしれない。