GoogleさんのGitHubが便利な話と愚痴の話
ちょっと前に音声認識のコードをゆるゆる書いてた
まぁ詰まってたとこは解決したんだけども
AndroidのJetpackライブラリの１つにLiveDataっていうのがありまして
それを使うとAndroidのライフサイクルに処理が振り回されないんですよ
MVVM使ってどうこうとか
Databindingするにはどうこうとか
これらを使ってあげればそもそもコードで逐一制御しなくていいじゃんと
今更気が付いたんですねこれが
んで、調べてみるてリファレンス読んだけどこれがピンとこない
（もっとViewの操作が複雑な場合とかじゃないと恩恵薄そうではあるけど）
Google I/O で使ってたアプリのプロジェクトファイルをそのまま公開してたんですねこれ
アーキテクチャの解説箇所に「LiveDataで良くしたんだぜうんぬん」と書いてありまして
これがまぁ参考になりそうなことよ
しかもテストコードもしっかり付属してます
いやぁ助かる
最近まぁなんか色々やろうと気力を振り絞っているのですが
今日は全然身体が言うことをきかなくて断念
今日もジムで運動した後ならなんとかなると思ったんだけどなぁ
ここ年空けてから精神的に疲れてしまっている
多分年末に爆弾置いてかれたせいなんですけど
ひとまず２月の転職ドラフトの登録に間に合わせたいんですよね
１年で身に着いたことが世間でどのくらいの価値になっているのかを知りたい
明らかにまだ色々足りない部分が多いし
上手くいかなくてもそれが分かれば十分だけど
今の会社にいても自分でなんとかやっていく以外に他がないから早めに出たい
今は仕事でコード書いているのが誰のためにやっているのか分からない
「あなたならなんとかしてくれるでしょ？」みたいな振り方をされてるのが結構きつい
自分のやっていることが正しく「価値として届いているのか」分からない
もうちょっとアウトプットして、みんなに何やってるか伝えたいんだけど
とっとと仕事片づけて帰ってきても疲れてるんすよね
ゲームもなんか上手く楽しめないし
友人と接することだけが心の支えになっている
前の鬱病の予兆段階とは全然違うから少し時間を置けば落ち着くと思う
たぶん
去年買った本の話
去年プログラマーとして社会に飛び立ったので流石に色々と本を買って勉強したりした
全部は読めてないんだけど、経験として晒してみる
books.rakuten.co.jp
プログラマーとして入社したのが2018の12月
それより前の無職期間で作ってたUnityのゲームで散々なコードを書いて
昨日の自分を恨みながらコードを読むことが多かったので反省しながら読んだ
会社の人のコードはめちゃくちゃで頭を抱えたのはまた別の話
books.rakuten.co.jp
AndroidエンジニアとなりJavaからKotlinにしよーぜって感じで唐突に始まったので読んだ
Kotlin楽しいです
新機能など追加の流れが速いので、基本で読むといいです
books.rakuten.co.jp
実際コード改修しようとしてもどうしたらいいのか分からんということで買ってきた
そしたら「テストコード書こうぜ」って書いてあって
違うんだテストが書けないくらいこんがらがってるんだ、ってことで必要な部分だけ読んでスルー
books.rakuten.co.jp
入社してちょっとしたら中途の新人の面倒を見ることになって頭を抱えて読み始めた
こいついつも頭抱えてんな
ストーリーテリングで解説してくれていて、読み物として普通に面白い
基本的にはアジャイルの話だけど、普通に組織に役に立つ考えとかあるので良い
今年に同シリーズの本がまた出るとかなんとか
books.rakuten.co.jp
カイゼン・ジャーニーでふんわりと学んだことに一歩踏み込んで読める本
アジャイルは銀の弾丸じゃねーぞ！って歴史的背景から解説してくれたり
ちょっと堅苦しいけどこれも面白い本でした
books.rakuten.co.jp
急にテストが欲しいとか言われたので書くことになったが知識がない
知りたいことが解説されているとこがいまいち無いので買ってきた
JUnitの他にもテストについて書いてあってためになるなぁという感じ
books.rakuten.co.jp
UIテストは書けた。んでUnitテストって何ですかという疑問を抱え
和田卓人の名前を知ってそのまま買ってきた
途中まで読んだ。手を動かしながら読むのが正解かもってなって放置中・・・
books.rakuten.co.jp
古本屋でくっそ安かったので購入した
プログラマーとしてどうやっていったらいいの？みたいな本
皮肉とか満載で楽しく読める。時間が取れなくて途中までしか読んでない・・・
books.rakuten.co.jp
RxJavaを学ぼうとして、デザインパターンって何？分かんねぇ！ってなって買ってきた
実際は言語やライブラリに実装されているので一から書くことはないなーって
覚えるのではなく、考え方を学べと大学の先輩に助言をもらった
番外編
books.rakuten.co.jp
組織の話やメタ認知の話が非常に役に立った
Androidの音声認識を使ってみたけど上手くいかなかった話
[ 解決 ] 停止時に
speechRecognizer.setRecognitionListener(null)
//---------
結果からいうとあんまり上手くいかなかった
（実用的じゃない気がする
ここのブログを参考にした
http://kivantium.hateblo.jp/entry/2016/02/29/191901
あとAndroidDeveloper
https://developer.android.com/reference/android/speech/SpeechRecognizer
SpeechRecgnizerを利用して音声認識用のクラスを作ってみたんだけど
外部からstartListening() を呼び出したあとにバックグラウンドに行くと
音声準備処理し終えたあとonRmsChanges() の処理が永久に続いてどっかいった
（なんか１回だけ上手くいったけど奇跡的で分からんかった）
呼び出し元のActivityのonStop() で制御したりできないかなーと思ったけどダメ
なんかライフサイクルに振り回されている気がするんだよなー・・・
どこかの実装が間違ってるのかなぁ
ちなみにForegroundServiceで実装するしないに関わらずどっかいった
南無三
そもそも音声認識を実行する時間とか一切設定できなくて
（昔はできたっぽいんだけど、現在はその操作自体が非推奨でRecognizerIntentのリファレンスに「使うな」って明記されている）
しかも 認識開始 -> 認識終了（動作終了） -> （仕方ないのでdestory()の後に再起動させる）
みたいな実装じゃないと数秒しか動かないし
（これは音声認識できたできないに関わらず終了する）
上記の実装をすると音声認識開始時にAndroidのシステム上
録音開始音が鳴るんですよね、うるさいねーん
そのためstartListening() の前にシステムの音量を0にして
onReadyForSpeech() が呼ばれた時点でシステム音量を復帰させる
みたいな処理じゃないといけない
そもそもGoogle的にはこの辺スパイアプリの実装っぽいので
あまりやらせたくないみたいだしー・・・
音声認識の呼び出しとかはぱっとできるし、認識の制度はいいんだけど
実装してみた感じではあまり実用的ではないかなぁみたいな・・・
実際使ってる人も少ないし
アプリがバックグラウンドにいっても音声認識させたいみたいな需要がない
設計的には
１．SpeechRecgnizerの音声認識処理を呼ぶ
２．音声認識の結果を返す
３．結果から文字列のマッチでパターンを分けて処理
でコールバックでどうにかしたいんだけど
その場合はSpeechRecgnizerのリスナーでonResult()に入った時
初めて動作させないといけないのでObserverパターンがいいのかしら
となったがデザインパターンとか全然知らんかったんで
https://www.amazon.co.jp/dp/4797327030/ref=cm_sw_r_tw_dp_U_x_I3E9Db9MTMA6C
これを買った。読む本だけが増えていく
動作のトリガーさえうまく掴めれば
LiveDataとかDataBindingとかその辺でうまくできそう
コールバックについて調べていたら、RxKotlinなるものがあることを知った
https://github.com/ReactiveX/RxKotlin
脱JVMしたいらしくて、名前の通りRxJavaのKotlin版みたい
学ぶことが多すぎるっぴ
Androidで使う技術の話
つよつよAndroidエンジニアになるためには
必要なんじゃねーかなぁという技術を列挙してみる
Android Jetpack
DataBinding ⇒ findViewById() 使わずレイアウトにぶち込んで同期する
LiveData ⇒ ライフサイクルに振り回されないようにするやつ
Navigation ⇒ Activity遷移の監視
Paging ⇒ リストビューとか
Room ⇒ DBにぶち込む
ViewModel ⇒ LiveDataとかDataBindingとかと一緒につかう（管理）
WorkManager ⇒ タスクの実行の管理（だったっけ
ライブラリ
RxJava ⇒ 同期処理とか（だった気がする
RxLifecycle ⇒ ライフサイクルの監視系（だった気がする
Retrofit2(okHttp) ⇒ APIめっちゃ楽
Dagger2 ⇒ 依存性注入奴。Koinってどうなんでしょうね
moshi ⇒ jsonとか使うときに
AndroidKTX ⇒ 忘れた
テスト
JUnit ⇒ この辺は前に書いた
JUnitRunner ⇒ この
Espresso ⇒ 辺
UIAutomator ⇒ 前
Robolectric ⇒ 書いた
mockito ⇒ モックのやつ
Androidの基礎とか設計とか
ライフサイクルの理解
アプリのコンポーネント
・アクティビティ ⇒ 要は画面
・サービス ⇒ 裏で動くやつな！音楽プレーヤーとかいい例
・ブロードキャストレシーバー ⇒ サービス側で受け取ったのをなんとやら
・コンテンツプロバイダ ⇒ まだ理解できてない
MVVM / クリーンアーキテクチャ ⇒ 綺麗に分離させて書けない・・・
Android周辺の知識
Firebase (FCM) ⇒ PUSH通知とかで使う
GooglePlayConsole ⇒ テストユーザーにアプリのCloserdβとか公開できる
リリース周りのあれこれ ⇒ リジェクトされたときめんどいぞ！
そのほか
Kotlin ⇒ まだまだJavaライクにしか書けてないので反省
xml ⇒ ガワ書くのめんどい
Git ⇒ まぁ
GitHub ⇒ 業務で使ってないので知識が不安すぎる
CI / CD ⇒ 業務で（略）
結構多いな
1/3くらいは使ったり理解したりできてると思う・・・
これ全部きちんと使えたら、まぁ間違いないと思う
なんかあったら誰か補足してくれ
AndroidのUIテストの話とかふんわり
前は軽い説明だけ書いたので、UIテストのコードとか
UIAutomatorの一部記載がdeprecatedなんだけどまぁそのうち
早く自動で動くテストが見たくてそのまま実装してしまった
これでJUnit4使える
@RunWith(AndroidJUnit4::class) class hoge { // いえーい }
実際にはこんな感じ
// ぱっけーじ // いんぽーと @LargeTest @RunWith(AndroidJUnit4::class) class testCode { @Rule @JvmField // テスト時に最初にいるActivity(= hogeActivity) // Espressoでの自動生成時にmActivityTestRuleって名前だった。変えてもいいのかしら var mActivityTestRule = ActivityTestRule(hogeActivity::class.java) @Before fun setUp() { // テストが走る前に動くのでデータの初期化とかしとけばいいんじゃない？ } // UI Automator private val uiDevice: UiDevice = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation()) @Test fun hoge() { // 自動生成で出てくるボタン指定クリックはクッソ長いけど１行でまとまる // なんか適当なボタンのid = buttonid // 指定したidを見つけ次第(isDisplayed())クリック onView(allOf(withId(R.id.buttonid), isDisplayed())).perform(click()) // UI Automator系はR.idを直接指定できないので文字列に直す必要がある // -> convertToString() // 指定したidが表示されるまで5000ミリ秒待ってくれる uiDevice.wait(Until.hasObject(By.res(convertToString(R.id.button))), 5000) val button = UiSelector().resourceId(convertToString(R.id.button)) // UiObject Deprecated なおそうね！ UiObject(button).click() } // idを文字列に変換するメソッドをホイ！ private fun convertToString(resourceID: Int): String { return InstrumentationRegistry.getInstrumentation() .targetContext .resources .getResourceName(resourceID) } }
UIテストのコードはだいたいこんな感じだと思う。待つのは通信時とか
あとはperform()で使ったのはこの辺
scrollTo()
スクロールする
replaceText()
テキストボックスに文字を入力（正確には置き換え）
（直接入力する書き方もあるけど、こっちの方が正確）
closeSoftKeyboard()
そのまま。邪魔で不具合起きたりするのでキーボード閉じる
UIテストはボタンと画面があればひとまずテストとして成り立つのでしあわせ
ボタンの生成とか画面の生成を変な方法でやるのはやめようね（嗚咽）
あと自動で動くの眺めてるの楽しい
AndroidのUIテスト書くにあたって参考にした本
peaks.cc
2018年の本だけどほぼすべてこれで網羅されてる。あとは公式見る
正直定期的に出してほしいレベル。マジ
ぶっちゃけAndroidテスト本って無い。全く無い
実はO'Reillyにあるんだけど
www.oreilly.co.jp
2013年5月発行・・・
つまるとこ、Androidアプリ開発はEclipseが主体だったころですね、うむ。
Androidのテストって色んなもの使わないといけないんですけど他の分野ってどうなんですかね
テストコード書くの初めてだったもんで勝手がわからん
UnitテストはRobolectrics（実際サンプルのプロジェクトでしっかり書いてある
Retrofit2の MockWebServer, moshi
Mockito kotlinと
あとRoomとかもモック入れるためのなんかあった気がするしもうなんか色々
多い！
っていうか今のAndroidテストってどういう流れなん？
教えてすごい人！
JUnit4でなんやかんやするのはそのうちなくなりそう・・・
もうJUnit5だしね、そもそも自動生成がJUnitでJUnit4に手直ししないといかんし
最近はプライベートで勉強したことを
職場になんとか反映させよう一人で転がってる日々が続いてます
つらい
特にオチはないです
UIテストを書いたりした話
仕事暇になってテストがなかったのでAndroidのUIテストを書いてる
Espresso
https://developer.android.com/training/testing/espresso
UIAutomator
https://developer.android.com/training/testing/ui-automator
この２つ使っておけば何とかなる感じ
AndroidStudioのEspressoRecorder使ってからの手動修正
からの指定しにくいやつとかちょっと動的なやつはUIAutomatorで書いた
１回書き方わかるとRecorderいらなくなるくらいシンプルに書ける
というかいらない記載が多すぎる
Recoderで生成するとJUnitが古いバージョンなので
JUnit4で適当に手直ししていけばおっけーな感じ
JUnitのあんまりはっきりとした資料がなかったので本を買った（中古）
https://www.amazon.co.jp/dp/477415377X
概要とかテストの概念とかは今もそんなに変わらないから
読むとこ読んで普通に役に立つ感じ
テスト書くと分かるんだけどテスト前提になってないコードは扱いに悩む・・・
実際にユニットテスト書こうと思ったら難しすぎて吐いた
Bitrise使ってみる
CI/CDの知見を得るためにBitriseに手を出してみた
https://app.bitrise.io/dashboard/builds
CIツールだとAndroidならBitriseが良さそう
アプリの配布がdeploygateからGooglePlayConsoleに移行して
CircleCIから環境を移行させた企業も多いっすね
yml書かなくても全部GUIでポチポチやるだけでいいのも良い
お手軽！
そして実際に使ってみる
Githubのアカウントがあれば流れで適当に設定してOK
ブランチの名前さえ間違えなければ普通に紐づく
SSHの設定だけ後から行ってひとまずビルド
失敗しとる
んで、調べたらAndroidのKeyStoreファイルをアップロードしろとな
からの設定したけどビルドが通らず
そしてビルドの結果がメールで届く。おもろい
ビルドのログ見る限り、キャッシュを初期化しろとか書いてあった
調べると同じとこで躓いている外人兄貴も多いみたい。早くBuild Sucessが見てぇ
一番上は指定したブランチにPUSHしたとき自動でビルドしてくれたやつ
コミットメッセージが雑
デフォルトで設定されてるっぽい
ちなみにビルド失敗しまくるとヘルプチャットみたいなの飛んできて草ってなった
おもしろ
今日中にビルド通ればいいなぁ（他人事
