"Plugin with id 'androidx.navigation.safeargs' not found."と怒られた

背景

 タイトルのままで、Android JetpackのNavigationで遷移先のFragmentに値を渡したくなって、safe-argsを使ってみようと試そうとし、公式のページとか見ながら追加しようとしたら怒られた。
 他のサイトとかも同じように書いてあったりしたので大丈夫かと思ったらそんなことはなかった...。

起きた問題

 この部分を参考に、app/build.gradleapply plugin: 'androidx.navigation.safeargs'を追加しました。
 そしてsyncさせると Plugin with id 'androidx.navigation.safeargs' not found.と言われてしまい :thinking_face:🤔
 見ていたページの前後を見てみても特にそれ以外に追加すべきなものを書かれていませんでした。

解決法

 ググって、stackoverflowでこのページを見つけました。
 この回答を見ると、"そのクラスパスじゃなくてこっちのクラスパスで試してみて"みたいなこと書いてあり、「クラスパス...?何か追加したっけ....」と思い、質問の方も確認して見ると...
 なんということでしょうapp/build.gradlededependenciesclasspathが追加されているではありませんか(某番組風)

ということでこの質問と回答を参考にapp/bundle.gradleに以下を追加しました。

        classpath "android.arch.navigation:navigation-safe-args-gradle-plugin:1.0.0-alpha05"

そして、syncすると通りました。

まとめ

 公式だけしか見ないのは罠
 pluginとして使うからclasspathが必要なのは当たり前なんて言われてしまうとごめんなさいとしか言えなくなります...
 直接は関係ないけど、gradleについてまだよくわかっていないので、"build.gradleにこれを追加して"と言われてもどれ...というお気持ちになってしまいませんか。なりませんか。

スコープのitでつまづいた

そのまま

失敗したコード

private fun setupView() {
  binding?.let {
    it.setOnClick {
      Toast.makeText(context, it.title.text.toString(), Toast.LENGTH_SHORT).show()
    }
  }

何がしたかったのか

?.letでbindingがnullじゃないことを保証した上で(binding?.hogeって書かなくて良いように)、スコープ関数を使ってクリックリスナーを設定、かつそのクリックリスナー内でView内のwidgetにアクセスして値を取得したかった

何がいけなかったのか

setOnClickの内外でitが指しているものが違う setOnClick外では、NonNullなbinding setOnClick内では、OnClickのリスナー

解決策

private fun setupView() {
  binding?.let {
    it.setOnClick { _ ->
      Toast.makeText(context, it.title.text.toString(), Toast.LENGTH_SHORT).show()
    }
  }

とかとか

まとめ

itは便利だけど何を指しているのかちゃんと考えて使おうな

こんなことで躓くのは自分しかいなさそう

mito.

ViewModelProvidersが使いたかっただけ

背景

既存プロジェクトにMVVMを導入しようとしてViewModelProvidersを使おうとした。

起こった問題

ViewModelProvidersを使うためにプロジェクトに

implementation 'androidx.lifecycle:lifecycle-extensions:2.0.0-alpha1'

を追加し、Gradle Syncすると"Failed to resolve: fragment"と言われ失敗する。

解決方法

build.gradle内のrepositoriesの中にあるjcenter()とgoogle()の順番を入れ替える。
before

repositories {
        jcenter()
        google()
}

after

repositories {
        google()
        jcenter()
}

mito.

Android-KTXを使っているプロジェクトでAndroidX RefactorしてGradle Syncした時に見つからないと言われた時

背景

もともとAndroid-KTXを使っていたTwitterクライアントアプリケーションのプロジェクトをGoogle I/Oの発表が終わった時に AndroidX Refactorをしてみた

起こったこと

AndroidX RefactorをおこなうとJavaやKotlinのコードが書き換えられるだけでなくbuild.gradleのimplementationのリンク(?)も書き換わります。
書き換わった後にGradle Syncした際に、「android-ktxのcoreが見つからない」みたいなこと言われて失敗しました。

解決方法

AndroidX Refactorした際に、書き換えられた

implementation 'androidx.core:core-ktx:0.3'

implementation 'androidx.core:core-ktx:1.0.0-alpha3'

に修正します。

mito.

チームラボ通年インターンシップ参加記

こんにちは、お久しぶりです。 1月ほど経ってしまいましたが、春季休暇中に参加させてもらったインターンシップについての記事を書きたいと思います。(だいぶ遅い)

2月27日から3月14日までの約2週間、チームラボさんにインターンシップでお世話になりました。
本当にありがとうございました。

行った内容

実際の業務のチームで行われているAndroidアプリ開発に参加させてもらいました。
インターンシップでは会社によって、全く業務に関係ないことだったり、1人だけで進めていく作業もあったりと聞いていて少し不安でしたが、自分がお願いしたように実際の業務のチーム開発に参加できてとても良かったです。
インターンシップ初日時点では、要件定義が終わって開発が始まったばかりでした。ですので本当に開発の初期段階から関わらせていただくことができました。

開発した画面

  • アプリ初回起動時のチュートリアルが終了した際に出てくる画面
  • ある桁数の決まった2つの数値をユーザーに入力してもらいその2つの値が正しいか調べ、正しいならアプリ内に保存する画面

一つ目の画面はプロジェクトでの開発に慣れてもらうみたいな感じで画面も処理自体もシンプルでした。ですが最初の1週間のほとんどをここで消費した気がします。
二つ目の画面は2つの値が入力されるまで確認用のボタンを非活性化させておく必要があったため一つ目に比べ複雑でした。ですが、後半ではだんだんと慣れてきたのかなんとかインターンシップ期間中にひとまず終わらせることができました。

初めて触ったインターンシップで触った技術やライブラリ、考え方

  • DataBinding
  • ConstraintLayout
  • Redux
  • Dependency Injection
  • RxShared
  • DataBindingのCustom Setter

どれも名前聞いたことある気がするけど実際に触ったことはないことばかりだったのでとても刺激的でした。

インターンシップで学んだこと

もちろん先ほど挙げた始めた触った技術も学べたのですが、それ以外にもチームのミーティングに参加させてもらい、どういう風にプロジェクトを進めていくのかとかモバイルチーム以外とのコミュニケーションとかも実際に見て学びました。
他にもコードレビューのありがたさや、文言をまとめた文書や画面デザインなどを管理したりコメントしたりするIDE以外でのツールの存在やその使い方などなど本当に多くのことを学ばさせてもらいました。

開発以外のこと

用意していただいた宿泊先が場所的にも設備的にも広さ的にもとても良かったです。
平日の昼にはメンターさんが他のプロジェクトの人などを数人呼んで一緒にご飯に連れて行ってもらったので自分がいるプロジェクト以外の人とも関わることができました。
連れて行ってもらったご飯屋さんも美味しいところばかりでした。
出勤時間が10:00だったので朝余裕をもって準備して出社することができました。
学校の登校時間もそれくらいにして欲しいくらい...()
土日が休みだったので遊びに行ったり東京で行われているイベントに参加したりもできました。
席の両隣の2人には特に世話になりました。

最後に

インターンシップ期間中は本当に多くの人におせわになりました。
ありがとうございました。
とても貴重な体験ばかりで本当に良い経験になりました。
チームラボさん以外の企業にもインターンシップなどで行ってより多くのことを経験したいです。

Bonfire Android #3参加録

こんにちは、mitoです。

1週間くらい経ってしまいましたが、「Bonfire Android #3」のブログ枠用ブログです。

Bonfire Androidとは

 自分も今回が初参加で、詳しいことはまだよくわかっていないのですが 毎回あるテーマに沿って、Androidに関する15分くらいの発表が行われるイベントで 主催はYahoo Japanです。
 今回のテーマは「サービスと設計」でした。

参加への経緯

 Bonfireは、Yahoo Japan主催なのでももちろん会場はヤフー株式会社で、沖縄住みの自分は普段なら参加できないイベントだったのですが、今回某社のインターンシップに参加している期間中に開催されるということを知ったので即参加登録しました。
 人数が多かったので空いていたブログ枠で確実に行けるようにしました。

Androidアプリの設計について

 自分自身は、ちょうど参加していたインターンで初めて設計に触れ始めたくらいには 設計について初心者状態でした。
 ずっと、「動いているから問題はないんだろうな〜」「一人で書いててどこらへんに何が書いてあるかわかるからいいか〜」みたいな感じで書いていましたが、今回のBonfireやインターンシップで設計について知り、どのような影響があるのかわかってきたので既存のプロジェクトや新規プロジェクトに導入できるとこからしていきたいです。

Bonfire Android #3の内容

スケジュールは

でした。  見つけることができた公開されている資料はリンクを貼っています。

 発表の詳細は「#yjbonfire」のタグをTwitterで見ながら、公開されている資料を読んでくれ頼む、って感じで省かせてもらいます。(まとめられる自信がない)

感想

発表

 設計についてほとんど知らない状態で今回のBonfireに参加したため発表された内容を全部理解できたわけではありませんが、なるほどと納得できるものやこんなのもあるのかなどが多くあって、とてもためになりました。
 何人かの人の発表にもあったのですが、既存プロジェクトに設計を導入する際は、そのプロジェクトで起こっている問題やメンバーの構成、学習コストをきちんと判断し適した設計を考えることが大事、ということでやはり設計に関しても「銀の弾丸などない」ということがわかりました。
 適した設計を考えることも大事ですが、どの設計を用いるなどをチーム全体で共有することも大事ということも。
 感じたこととしてはやっぱり、今まで設計を考えたことのない人に対して導入すると言ってもそれを導入するメリットを理解してもらうのは難しいだろうなということです。
 とりあえず導入しても、効果について疑心暗鬼状態では開発スピードは落ちていく一方になりそうです。
 そこらへんも学習コストとして考慮しないといけなさそうではあります。
 イベントに申し込んだ段階では、「サービスと設計...?、なにそれ...、自分がやったことのない分野だから発表を聞いても内容も利点もわからなそう...ブログどうしよ...」みたいな状態でしたが発表では、こんな問題があってこういう状況だからこの設計パターンを導入してみたみたいな感じでなぜそれを選択したのかがしっかり話されていて、とても理解しやすい発表でした。
 もしこのBonfireでの発表を聞いていなかったらまた設計に触れ流のがどんどん先延ばしになってしまっていたと思うので参加して、登壇者や同じ参加者の話を聞けてとてもよかったです。

懇親会

 発表終了後にそのままの会場で懇親会が行われ寿司が出てきたのですが、会話に夢中になりすぎて結局寿司を一貫も食べれないまま容器は空に...
 しかし、スタートアップした人や他高専生、Yahoo Japanの社員の方などなど多くの人と話せてとても楽しかったです。
 今までイベントや大会の懇親会では、開発が終わっていないために早めに抜けたり参加していてもあまり他の人と話さなかったりしたのがとてももったいなく感じました(今更)
 来年度以降のPCK組は早くに開発を終わらせて、コンテストの懇親会にきちんとでて他校の人と話をして欲しいです。

少し、短いですがここで終わりとさせていただきます。
また機会があればBonfireに参加したいです。

mito.

始める時に思ったこと

この記事は主にプログラミングを始めたばかりの人に送る記事です。
偉そうなことを偉そうに書いているかもしれませんがお付き合いください。
偉そうだなとか言うだけの人よりじゃあどこでそう感じるのかどうやったら感じない文章になるのか考えたり指摘してくれたりする人がより素晴らしい人だと思います。
mito自身にも当てはまることがあったりしますが、とりあえず自分のことは棚に上げて書いています。

とりあえずやってみる

新しいことに挑戦するという事はとても勇気がいります。
失敗しないだろうか、自分にはできないんじゃないか、やらなくてもいいのでは、時間の無駄かもしれない、etc...
そう言うことをどんどん考えていくと挑戦しない道を選んだ方が楽なことが多いです。
でも、そこを敢えて挑戦していくと違った世界が見えてくるはずです。
新しい言語の勉強をするときもとりあえず動く何かを作ってみて実感を得ることが大事になってきます。

自分は今年のPCKの開発の際に、挑戦しなくてもよかったかもしれない事をやりながら開発していました。
一番大きいことは積極的にライブラリを使っていったことです。
去年のPCKで出したふぁみここのコードを見るとサーバとの通信方法やJSONのパースの仕方などを標準のはめんどくさい、使いにくいと言われても標準で用意されている機能だけでやったのが多いです。
(一部、okhttpとかが使われているのはおりさの先輩に相談した時のコードです)
その時は、使いにくさだったりは特に感じていなかったし、いざライブラリを使おうとなっても使い方が分からず結局元に戻るだろうと思いが強かったです。
そして今年の開発でもそのコードを流用すればすぐに終わったかもしれない事ばかりでした。
でも、今年はmoshiやokhttp、Ankoといったライブラリを多く使いました。
特にAnkoはKotlinでxmlなしに画面レイアウトが作成できるみたいなライブラリなんですが、そもそもKotlinの情報が増え始めた頃でAnkoの情報が多いわけもなく、分からないことだらけで辛かったです(特にid周り)
こういったライブラリを使ったことでライブラリの便利さ・有り難さが身に染みてわかりました。
今は積極的にライブラリを使うようにしています。

少し脱線しましたが、やってみることによって得られる経験はとても良いものです。
やってみて結局使わなかった・いらなかった・分からないままだったでも、それはそれで良いと思います。 使わなかった・いらなかったでも他のプロジェクトでは使えたり、他のことに挑戦する時にあれではこうだったけどこれではどうなんだろうとかで良い経験値にはなると思います。 分からないままでもしばらく他の事をやってたりして時間を置いてまたやって見ると案外楽になったりします。(少なくとも悪化することはないと思う)

できることからやる

なんか上のやつと矛盾したことになりそうですが、やりたいことがあるが途中でやる気を失ってしまったり達成できずに終わってしまったりすると精神的にしんどいです。
でも、そういう場合って基礎が足りていないだけだったり前提知識がないだけだったりするのでやりたいことだけでなく、今できることを地道にやってどんどんやりたいことに近づいていくというのも道だと思います。

いろんなことに手を出す

よくいろんなことに手を出すより1つのことを極めた方がいいだとか、広く浅い知識より狭く深い知識の方がいいだとか言われることがあります。確かにこれらのことは技術職や専門職の人達にとっては必須ですが、プログラミングを始めたばかりだったりどれを深めていいのかわかっていない状態だと、それよりはいろんなことに手を出して自分の好きなことやりたいこと興味を持ったことを見つけるのが最優先だと思います。
(自分の経験とか書きたいけど1つ目で疲れた長くなりそうなので以降省略)

時にはなぜを忘れる

開発中に実装したい機能がある時にやり方が分からずにググってQiitaとかStackOverflowとかにあるサンプルコードを見つけて使いたいときがあります。
その時になぜそのコードが動くのか分からない状態で使うのは良くないと言われます。確かにその通りでそのコードの意味がわからないと使用独特のバグが生えてしまったり、使えなかった時の対処法がわからなかったりして開発に支障が出てしまいます。でも状況によってはそんなこと言っていられず動けるものを作らないといけないと言った時はわからないままでもいいと思います。
わからないままでもしばらくすると自然にわからないままにしたくないだとか単純に興味が湧いらとかでなぜ動くのかを調べるようになります。
とりあえずは動かすことに意味があると思います。

自分の環境を作る

プログラミングをする際に、ツールにもっとこだわった方が良いです。 どんなに有名なツールでも自分にとってとても使い勝手の悪いものだったらそれを使い続けることは精神的負荷になってきます。 これもとりあえずやってみると近いですが、どんどんいろんな環境を試してみて自分にしっくりくるものを見つけ、それをまた自分に合うようにカスタマイズしていきましょう。
自分の場合はもうJetBrains製品の虜になってしまい、AndroidStudioやIntellijのカスタマイズを結構やっています。 しかし、もうすでに開発が終了していたり非推奨になっていたりするものはなるべく避けましょう。
それ以外であれば、周りの他人に少し言われるくらい言われても拘ったほうがいいです。

どんどん公開する

せっかく何かしら作っても、「いや、駄作だから,,,」とかと言って公開せずに自分や身内だけで終わらせてしまう人がいます。
正直、勿体無いと思います。
せっかく作ったものが日の目を浴びないというのもですが後悔しないと他の人からフィードバックを得られません。 フィードバックを得たものと得てないもののサハ歴然んです。
後悔したことによって起こる人はいませんし(多分)、どんどん公開していきましょう。
個人的にはgithubで星をもらえたらいPRもらうのは嬉しい。

理由を教えてくれそうな人を見つける

何かあった時にその理由や原因をきちんと教えてくれる人は良い人です。やるだけだよとかしか言わない人に聞いていても仕方ありません。他を当たってみましょう。
何かやろうとした時にダメとしか言わないよりなぜダメなのか説明があったほうがいいですよね。そんな感じです。

最後に

途中から疲れてしまって閣僚もだいぶ減って、いくつか項目を消したのもありますがいかがでしたか。
偉そうだなと思った人はいると思います。自分がそうです。
この記事は割と雑に書いてしまっていて間違っているところもあるとは思いますが、参考程度にしてやってください。
ここに書いてあることを実践したからといって必ず良くなるとは限りませんし、このことを意識しすぎるとそれもまた良くないでしょう。
何事も適当にやるのが良いですよ。(この適当は本来の意味)
頑張ってください。応援してます。自分も今以上に頑張ります。

mito.