「Android開発者になったとき、まだサンプルを探す場所がありませんでした」：David Gonzalezのインタビュー

Android開発者は、 David Gonzalezがいくつかの異なることに関連して知っている場合があります。 たとえば、彼はオープンソースプロジェクトAndroid Architecture Blueprintsに参加しており、具体的な例を使用してさまざまなアーキテクチャアプローチを示しています（最近、このプロジェクトは25,000のGitHubスターを超えました）。 彼はまた、プレゼンテーションを行い、ベルギーのコトリンユーザーグループに参加し、以前は積極的にブログ投稿を書いてきました-一般に、さまざまな方法でコミュニティを支援し、Google Developer Expertの肩書きは驚くことではありません。

そのため、インタビューでは、Davidにいくつかのトピックについて一度に尋ねました。Androidアーキテクチャブループリントから始め、Kotlinに切り替え、Androidでの認証で終わりました。これは彼の新しいレポート専用です。

-Androidアーキテクチャブループリントに関する主な詳細は、2016年のレポートに記載されています。 そして、その報告以来、プロジェクトで何が変わったのでしょうか？

-プロジェクトは成長し、さまざまなアプローチのサンプルが増えました。 当時、RxJavaとDaggerのサンプルはまだ安定した状態に達しておらず、Kotlinには単一のバージョンはまったくありませんでした。

現在、私はプロジェクトコードに積極的にコミットしていませんが、今では人々がプロジェクトをより理解するのを助けています。 現在、より多くの人々がそれに関与しており、彼らはより多くの質問を持っています。 新しいメンバーはとても役に立ちます。

メインプロジェクトに加えて、「外部」アーキテクチャの例もあります。私はこれに参加しました。私は彼の例MVI-RxJava-Kotlinで Benoit Quenadonを助けました。

-「さて、設計図ではなめられたアーキテクチャのサンプルは見栄えが良いのですが、実際のプロジェクトで同じことをしようとしましたが、すべてがそこでバラバラになりましたか？」

-あなたは正しい、あなたがしなければなりません。 しかし、ブループリントはアーキテクチャ実装の単なる例であり、「それを実装する唯一の確実な方法ではなく、ここからすべてをコピーする必要があります」。 これはおそらく聖書よりもガイドラインです。

既にGoogle Playでアプリケーションを使用している場合は、数年間作業して、1つのアーキテクチャアプローチを使用してから変更することを決定します。もちろん、これはコピーアンドペーストほど簡単ではありません。

多くはあなたが働くチームに依存します。 孤独な方が簡単かもしれません。 そして、あなたが大規模なチームにいる場合、ここでの対話と議論が重要になります。チームとして、あなたは前進する方法とこれらの変更の実装を開始する方法を決める必要があります。

-Android Architecture BlueprintsのキュレーターはGoogleです。 有益なものを拒否するのではないでしょうか。それは会社の利益とは異なるからです。

-いいえ、絶対に。 たとえば、RxJavaのサンプルがありますが、Googleはこれを内部で使用しない場合があります。 これは、コミュニティの力が役立つ場所です。私たちはそれを自分で実行できます。 これはオープンソースプロジェクトであるため、そのコンポーネントをリードできます。 Daggerの別の状況：これは内部で使用されるGoogle製品であるため、その実装例にはより多くのGoogle社員が関与しています。 しかし、彼らは私たちに何をすべきかしないかを教えていない、アプローチは完全にオープンソースです。

-参加者は特定のアーキテクチャの実装についてしばしば意見が異なりますか？ プロジェクトに何を含めるかが明確でない場合、そのような矛盾はありますか？

-通常、新しい例を議論するとき、紛争はGitHubで議論され、互いに助け合います。 たとえば、BnoitがMVIでRxJavaを作りたいと思ったとき、私は助けたいという願望を表明し、話しました。 どちらが望ましいかわからない場合は、同じ例の2つの完全に異なるバージョンよりも、わかりやすいダイアログのように見えます。

-Android Architecture Blueprintsは、ほとんどのプロジェクトとは異なります。複数のサンプルブランチに分割され、それぞれが「完成」段階に到達できます。 これは、新しいブランチが出現するにつれて、プロジェクトの作業が「波」になるということですか？

-実際、do-applicationには常に同じものがありますが、いくつかの例では新しい機能が表示される場合があり、他のすべてのブランチにも実装する必要があります。 さらに、 Joseは、ブループリントを使用して他のアプリケーションを実装できることを理解しています。

しかし、活動には増減があります、はい。 新しい人気のあるアーキテクチャが登場すると、多くの人がブログに投稿し、すべてがブループリントに到達し、新しいタスクが登場します。



-ご覧のフィードバックでは、Android Architecture BlueprintsでのKotlinサンプルの需要はJavaサンプルよりもすでに高いですか？

「そう思います。」 Google I / OでのKotlinのサポートが発表された翌週、多くの人が「こんにちは、いつ入手できますか？」と書きました。 Kotlinの例を助けてくれました。とても便利でした。

-KotlinがまもなくAndroid開発の明確なリーダーになる、またはレガシーコードを使用する保守的な企業が大多数がとにかくJavaに参加することを意味するという感じがありますか？ もちろん、これは投機的な質問ですが、Kotlin User Groupの主催者として、あなたは目に見える傾向があるはずです。

-さて... COBOLを生産している企業はまだ世界中にあります。 そして、これをサポートするには、COBOLで書く人がまだ必要です。 しかし、このようなシステムは20年ほど前のものです。20年前にモバイルアプリケーションを使用する人がいるかどうかはわかりません。 そして、モバイル開発者はより頻繁にリファクタリングを好むようで、2〜3年ごとにアプリケーションがどのように書き換えられるかを見ることができます。 したがって、ここでのコードの有効期間は、古いエンタープライズコードよりもはるかに短くなります。 そして、3年後に新しい言語が登場すると、Kotlinからこの新しい言語への移行に関する新しいブログ投稿とレポートがすぐに行きます。

-あなたはロンドンに住んでいて、今はベルギーでKotlinユーザーグループを組織しているので、比較するのは興味深いです。ベルギーのAndroidコミュニティでのKotlinとの関係はどうですか。ロンドンとの違いは何ですか？

-違いが感じられます。 ロンドンには多くの開発者がいます。常にミーティングがあります。 ベルギーは別の国です。この点ですべてがはるかに遅いです。 イベントに参加する人々の数でさえ、それは徐々に成長していますが、非常に異なっています。 そして、ベルギーの企業にコトリンへの切り替えを納得させることは、ロンドンよりもはるかに遅いプロセスです。

しかし、開発者はKotlinに触発されており、Kotlinと一緒に仕事をするのは楽しいですし、誰もがエキサイティングな仕事を望んでいます。 毎日仕事で8〜10時間を過ごすとき、あなたはそれを楽しみたいと思います。Kotlinはこの新鮮な空気の流れをもたらし、Android開発やバックエンドで再び夢中になれると思います。 今こそ、開発する絶好の機会だと思います。

-ヘルプスカウトアプリケーションでの作業についての講演で、最初から作成した方法について述べました。「Kotlinで書くべきですか？ しかし、私が6か月後に会社を辞め、他の誰かがその面倒を見てくれたらどうでしょうか？ Javaはより信頼性が高い。」 その後、それは非常に合理的に聞こえ、現在状況は変わりました。 最後に、これをKotlinですべて書き直していますか？ :)

-状況は本当に変化しました。開発者が会社を辞めたとき、Kotlinについて心配することはできません。言語の知識がある他の人を見つけることは難しくありません。 今日、Kotlinに時間を費やせば、これは会社にとって問題になりません。

しかし、KotlinのためだけにKotlinでアプリケーションコード全体を書き換える理由はありません。 Kotlinで新しい機能を作成することの方がはるかに重要だと思います。 古いコンポーネントに問題がある場合は、書き直すことができます。

私たちは新しいプロジェクトにも取り組んでいます。それは最初からコトリンで書かれました。

-「Kotlin」をより機能的に記述するように設計されたΛRROWライブラリの外観に注目しました。「そして、どう思われますか、そのような要求はありますか？

-そう思う。 そのクリエイターは素晴らしい仕事をしました。 まず、既存の2つのライブラリを1つにまとめました。 次に、ドキュメント、サイト、サンプルに多くの時間と労力を費やしました。 最後に、それは人々を魅了します。

そして、Androidは機能的なスタイルに最適なプラットフォームのようには見えませんが、他の言語に慣れている人々がこのプラットフォームを利用できるようになると思います。 あなたがScala開発者であり、適切なスタイルに慣れている場合、Androidに取り組むのが簡単になりました。

最終的に、これは同じ結果を達成するための別のツールです。最終的には、アプリケーションを作成できます。 そして本当に重要なのは、ユーザーがそれを好むかどうかです。 しかし、その過程で多くの喜びを得ることができます。

-長い間Androidの開発に携わっています。最初のデバイスはHTC Magicでした。 あなたの意見では、「then」と「now」の開発の主な違いは何ですか？

-私がこれを始めたとき、実際に例を探す場所はまったくなかったと思います。 Android開発に関するブログは3〜5件しかありませんでした。 今日、ブログ、コース、および例の突破口があります。 GitHubで出会ったコードを読んで学ぶことができます。 本を読んだり、オンラインコースを受講したり、個人訪問のコースを受講したりできます。世界中で会議がほぼ毎週行われています。 常に何かが起こっています。 利用可能な情報が豊富なため、Android開発への統合が間違いなく簡単になりました。

そして、デバイスは大きく変わりました。 それから、数ギガバイトのRAMを搭載した最新のマルチコアスマートフォンについて考えることさえできませんでした。 今では、Pixel 2ではメモリ不足になることはないので、アプリケーションの微調整にそれほど時間を費やしていません。

「今日、Android開発者はよく「APIの特定のバージョンを最終的に削除できるようになるのを待っています。」と言います。」 そして、バージョンの変更はさらに重要で苦痛でしたか？

-それから、新しいバージョンのリリースの数か月前に新しいSDKを使用してアプリケーションをテストできるようになった現在、開発者のプレビューはありませんでした。

Honeycomb 3.0がリリースされたとき、すべてが変わりました。 断片が現れた。 それらで何をしますか？ なぜ必要なのですか？ APIは、現在よりも大幅に変化しました。



-認証についていくつか質問をしたいと思います。 Habrahabrについては、それほど前ではなく 、多くの人が自分のためではなく、同期アダプターのためにAccount Managerを使用していると書いています。 同じ絵が見えますか？ これは問題だと思いますか？

-はい、同じものです。それは、フレームワークがどのように配置されているかによるものです。 同期アダプターにはGoogleアカウントが必要です。 そして、このアカウントは、アカウントマネージャーを介してのみフレームワークに表示されます。

認証とは何の関係もないため、これは悲しいことですが、それ自体に同期アダプターが必要なことです。 そして、非常に多くの人々がそれを使用することを止めました：あなたはデータ同期のためだけにボイラープレートコードの束を必要とします、そして、これは干渉します。

しかし、幸いなことに、アカウントマネージャーを必要としない、デバイスとサーバー間でデータを同期するためのその他のオプションがあります。 GoogleのAndroid Priority Job Queue 、EvernoteのAndroid-Jobがあります。

-同じハブアカウントで、アカウントマネージャーは複数のアプリケーションの一般的な承認も称賛されました。 しかし、Yandexの従業員は、多数のアプリケーションが存在することを称賛しましたが、これは依然として非典型的な状況です。 同期アダプタには適切な代替手段があり、平均的な開発者は巨大企業で働いていないため、そのような開発者にとってアカウントマネージャーはどの程度関連していますか？

-大企業にとって特に有用であり、すべてのサービスに対して単一の認証ポイントを作成できることは事実です。 あなたがGoogleであり、Gmail、Googleマップなどを持っている場合、ユーザーがそれぞれに個別にログインする必要がない場合、はるかに便利です。

ただし、アプリケーションが1つしかない場合でも、アカウントマネージャーは有益です。 彼から得られる主なものは、ユーザー情報の安全な保管です。 このトピックについては、メビウスに関する講演で詳しく説明します。

-Android開発に長い間携わっていることを思い出してください。認証は時間の経過とともにどれだけ変化しましたか？

-基本は同じままで、同じ方法が何年も利用できました。 しかし、今では生活を楽にするツールが増えています。

たとえば、Android TVまたは他の場所で既に使用されているアプリケーションを開くとき、Googleはトークンを保存してアクセスを許可するため、認証を変更する必要はありません。

また、Firebaseによる認証は進化し、より一般的になりました。 数年前、FacebookやTwitterをログイン方法として使用したい場合は、SDKを使用する必要がありました。 Firebaseに依存できるようになり、FacebookやTwitterの依存症を取り除くことで生活が楽になりました。 これは多くの開発者にとって非常に魅力的です。

そして、喜ばしいことです。会議でのレポートにとって認証は最も魅力的なトピックではありませんが、私たちは皆、アプリケーションでそれを処理しなければならないと思います。 そのため、ログインパスワードとボタン用の2つのテキストフィールドよりも退屈しない方法を見つけることは常に素晴らしいことです。

「しかし、このすべての開発において、どの方法も「最高」とは考えていません。すべて特定のシナリオに依存していますか？」

-はい、認証方法は会社とその規模に大きく依存します。 Firebaseのようなサービスを既に使用している小さな会社で、同時に認証を処理できる場合は、これにより人生が大幅に簡素化されます。

他の要因があります。 たとえば、Fingerprint APIは非常に魅力的に見えますが、実際には、すべてのデバイスに指紋スキャナーがあるわけではありません。 したがって、ある特定の国用のアプリケーションを開発している場合は、そこにいるユーザーの何パーセントがそれを使用できるかを確認してください。

-より良い方法はなく、比較する必要があるため、Androidアーキテクチャブループリントとの類推によってAndroid認証ブループリントを作成すると便利でしょうか？ :)

-これは非常に良い質問です！ 私はそれについて考えたことがありません。 レポートの中で質問する価値があり、人々がこれにどのように興味を持っているかを見ることができます。 いいね！

1分間の広告：サンクトペテルブルクでMobius会議を開催します。これは、Davidのプレゼンテーション「Android Authentication made simple」などです。 会議のWebサイトで、既知の詳細をすべて表示し、チケットを購入できます。