Yandex Mobile Development Schoolを卒業するためのアプリを作成するためのヒント

モスクワで伝統的に開催されるモバイル開発学部への募集はもうすぐ完了します。 実践的な演習に重点が置かれます。チームミニハッカソンでは、コードの記述に加えて、意思決定を行い、物議を醸す問題に対処し、長期計画に取り組む必要があります。 Yandexの学生は、学生-各チームを個別に支援します。 今後の学校の詳細については、 こちらをご覧ください 。 5月6日23時59分のモスクワ時間に申し込みを受け付けます。タスクを完了する時間はまだありますが、昨年のバージョンを作成することにしました。 初心者の開発者がよく犯す間違いと、最初のアプリケーションのコードを書くときに注意すべき点を確認できます。



伝統的に、タスクは開発のさまざまな側面に注意を払うことができるように設計されています。 これらには、アプリケーションアーキテクチャ、安定性、パフォーマンス、レイアウト、使いやすさが含まれます。 すべてのコンポーネントは同様に重要です。インターフェースに問題がある場合、または基本的なユーザースクリプトの実行中にクラッシュする場合、高い確率で完全にコーミングおよびレイヤー化されたコードでも選択を通過しません。 完全なアプリケーションを作成するための普遍的なレシピはありません。これは、選択に合格することが保証されています。 アーキテクチャを構築するための多くの開発アプローチとさまざまなオプションがありますが、成功の要素の1つは肯定的なユーザーエクスペリエンスです。 製品は、どれだけ便利な機能、画面、または要素が含まれているかに関係なく、完全性の印象を与える必要があります。

内容

• リポジトリとコーディングスタイル
• SDKとライブラリ
• 建築
• UI（リソース、グラフィック、レイアウト）
  レイアウト品質
  設計
  他にやる価値があること
• エラー処理
  try..catch ...どこでも
  WeakReference <すべて>
  リクエストキャンセルなし
• テスト
  単体テストの欠如
  役に立たないテスト
  
• おわりに
  便利なリンク

リポジトリとコーディングスタイル

劇場はハンガーから始まり、プロジェクトはリポジトリから始まります。

開発を開始する前に、適切な.gitignoreファイルを追加して、余分なファイルがリポジトリに正確に入らないようにします。 そのため、IDEの設定ファイル、アプリケーションに署名するためのキーを含むファイル、およびログインとパスワードをリポジトリに保存することはお勧めしません。

開発中は、黄金の平均に従います-一度にプロジェクトの半分をコミットするべきではありませんが、1行または2行に沿った多くの小さなコミットは避けるべきです。 コミットごとに明確なメッセージを書きます。 個々の機能については、 ブランチを使用して独立して機能を開発し、常にマスターブランチにアプリケーションの現在の（および動作する）バージョンを保持する価値があります。 まず、最低限必要な機能を実装するか、すべての「可愛さ」と改善を実装してください。 別のブランチに切り替える必要があり、不完全なコードをコミットしたくない（ただし、失いたくない）場合は、 ネスト文字列を使用すると便利です。

コードは一度書き込まれ、何度も読み取られるため、コーディングスタイルと変数名が適切であることが重要です。 必要に応じて意味のあるコメントを残し、マジックナンバーを追加したり、同じことを行うさまざまなライブラリのコードを混ぜたりしないでください。 コードが1人の開発者によって記述されている場合、共通のスタイルとアプローチを維持するのは簡単ですが、大規模なチームでは、さまざまなアナライザーを使用するか、独自のスタイルを作成してバージョン管理システムにコミットし、各開発者が選択できるようにします。

他にも注意すべき点がいくつかあります。

• ハードコード、役に立たないコード、コメントアウトされたコード、
• スーパーコール、
• 追加の注釈
• 欠落している注釈
• デバッグアセンブリでのみ必要なリリースコードの取得
• 最終修飾子が欠落している、
• 長い方法
• 同じ方法
• 未使用の輸入品、
• new何か（）割り当てなし、
• マジックナンバー
• わからないコードを使用してコピーペースト
• また-lintを使用します 。

SDKとライブラリ

Android SDKとライブラリを使用すると、多くの場合、初心者の開発者の間で疑問が生じます。 以下に、いくつかの一般的な問題とその解決策をリストします。

リストの不適切な作業
LinearLayout + ScrollViewを使用して同じタイプのビューの多くを表示することは、間違いを犯すことを意味します。 このメソッドはメモリに負荷を作成します。すべてのビューは同時にメモリ内にあります。 スクロールが遅くなり始めます。 この場合、少なくともListView、またはより優れた、より高度なRecyclerViewを使用するのが適切です。 これらのコンテナは、ビューの再利用を提供します（アダプタメカニズムを使用）。 現在ユーザーに表示されていないビューには、最新のデータが表示されます。

しかし、ここでは間違いを犯す可能性があります。 RecyclerViewは、ListViewとは異なり、開発者にViewHolderパターンの使用を強制します。 その名前が示すように、このパターンは、オブジェクトがビュー階層ですでに見つかったリンクを保存するクラスを作成することにあります。 値を置く必要があるたびにfindViewByIdを呼び出すべきではありません。 これは、ホルダーの作成中に1回行う必要があります。

状態保存
初心者にとってもう1つの大きな問題は、構成を変更するとき（たとえば、向き、言語、画面サイズなどが変更されるとき）にアプリケーションの状態を維持することです。 多くの場合、初心者はそのようなケースをテストしません。 これは、ユーザーの不満やクラッシュにさえつながります。 時々、開発者は向きを修正するのを止めます-もちろん、それは保存しません。 すぐに使用可能な構成変更をサポートするには、いくつかの方法があります。 これについては掘り下げません。いつでもドキュメントを読むことができます 。 覚えておくべき主なことは、状態を復元する必要があるため、ダイアログに注意を払うために、 AlertDialogではなくDialogFragmentを使用することをお勧めするために、そのような問題が存在することです。 画面の状態を永続ストア（SharedPreferencesなど）に保存することはお勧めできません。 その結果、「クリーンな」ローンチは既存の状態につながる可能性があり、これは特に慣用的ではありません。

データのロードとキャッシング
AndroidのUIストリームでネットワークにアクセスすることは禁止されています。 ネットワーク用の多くのライブラリがあります。たとえば、RESTを使用している場合はOkHttp 、 Retrofitを追加したり、画像のダウンロード用にGlide または Picassoがあります。 したがって、長い間、AsyncTask内でHttpUrlConnectionを使用する必要はなくなりました（特に画像のダウンロードには、実際には簡単ではありません）。 しかし、多くの初心者は、たとえば、データベースへの読み書きもメインストリームのフリーズのためにUXに影響を与える可能性があるI / O操作であるとは考えていません。 同じことは、ファイルの読み取り、ContentProvidersへのアクセスにも当てはまります。 このような操作はすべて、別のスレッドで実行する必要があります。 このために何を使用するか-誰もが自分で決定し、この形式でさまざまなソリューションを説明することは不可能です。

[戻る]ボタンのシステム動作を変更する
多くの場合、このイベントを完全に飲み込む（処理しますが、同時に何もしません）など、システムの標準ではない反応をハングアップする誘惑があります。 だから-しないほうがいい。 このOSのユーザーには習慣があり、戻るは前の画面に移動するか、アプリケーションを終了する必要があります。

建築

多くの場合、Androidアプリのアーキテクチャは、経験豊富な開発者にとっても悩みの種です。 このセクションでは、いくつかの一般的なヒントを示します。 あなたがそれらに従うかどうかはあなた次第です。

アーキテクチャと分解
分解の欠如は、貧弱なアーキテクチャの兆候です。 プラットフォームは、アプリケーションを正しく作成する方法について明確な指示を与えていないため、アクティビティまたはフラグメントのコードにすべてを書きたいという大きな誘惑があります。 その結果、コードはテスト不能になり、変更を加えることが困難になります。 このような状況を回避するために、最新の建築慣行と設計パターンを適用できます。 MVP、MVVM、MVIについて読んでください。 最初の3つのクラスを作成し、テストでそれらをカバーします。 おそらく、テストを書くのは難しく、アーキテクチャについて考える必要があることに気付くでしょう。

抽象化による検索
GitHubリポジトリは、多くの場合、アーキテクチャの「標準的な」実装を示しています。 他の人のアーキテクチャソリューションのブラインドコピーは、メリットをもたらすだけでなく、作業を複雑にし、アプリケーションのパフォーマンスを低下させる可能性があります。 「より正確」または「クリーン」だからといって意味のないコードを書かないようにし、それぞれの場合にソリューションの利点とそのサポートと理解の複雑さを関連付けます。

コンポーネント間の暗黙的な関係、不純な機能
多くの場合、グローバル変数の値はアプリケーションに静的に保存され、アプリケーションのさまざまな部分から変更されます。 コードの外見上は直接関連していない部分の実行はグローバル変数の影響を受けるため、開発者が実行時に受け取ることを期待していなかった状態がアプリケーションで発生する可能性があります。 最悪の事態は、そのようなバグをキャッチして再現するのが非常に難しいことです。 「クリーンな」メソッドを記述し、クラスコンストラクターまたはメソッド引数で依存関係を明示的に指定してください。

UI（リソース、グラフィック、レイアウト）

アプリケーションの外観と使いやすさは非常に重要です。 便利なデザインを作るのは難しいですが、少なくとも以下に概説する点に注意することをお勧めします。

レイアウト品質

Androidのパフォーマンスは、レイアウトの品質に大きく依存します。 複雑なコンテナ階層は計算に時間がかかります。 さらに、ネストが大きいと、計算中およびレンダリング中にフォールが発生する可能性があります（スタックオーバーフローのため）。 ConstraintLayoutの登場により（特にウィザードから作成する場合のxmlルート要素のインストールにより）、初心者にとって階層はさらに複雑になりました。 Nested Relative / ConstraintLayoutが最もよく使用されますが、これは根本的に間違っています。 ConstraintLayoutは、階層をフラットにするためだけに設計されています。 少なくともドキュメントの概要を読み、このクラスを正しく適用することをお勧めします。 また、ViewGroupを過剰にネストしないでください。

設計

すべての開発者が設計スキルを持っているわけではありません。 多くの場合、開発者が好むアプリケーションには一貫性のないカラーパレットがありますが、ほとんどのユーザーはそうではありません。 障害のある人（たとえば、色覚異常者）だけでなく、他のユーザーもラベルを読むことができません。 標準チェック：ラベルがグレースケールで表示されている場合、ほとんどの場合、ほとんどのユーザーにも表示されます。 カラーパレットと一般的な設計原則を選択するには、 material.ioとwww.materialpalette.comの 2つのリンクを参照してください。

他にやる価値があること

• 名前、アイコン、画面についてなど、アプリケーションの完全性の感覚を提供する側面に取り組みます。
• アプリケーションの外観を画面上のさまざまなドット密度に適合させます。
• 未使用の文字列、グラフィック、およびその他のリソースを削除します。
• 他の言語にローカライズします。
• 前の段落が完了したら、必要なものはすべてローカライズしてください。

エラー処理

アプリケーションのユーザーの軍隊は、良いテスターとして、あなたのために何かを壊す方法を常に見つけます。 異常な状況では、必ずアプリケーションを確認してください。 テスターの考え方を開発し、あらゆる種類の非標準の使用シナリオ（インターネットなしで開始する、履歴にエントリを2回追加する、デバイス設定の突然の変更など）を予測することが重要です。 機能の作業を終えたら、この機能をテストし、いくつかのスクリプトを実行して、すべてが機能することを確認することが重要です。 問題は、内部的な感覚があり、すべてが正しく機能することを期待しているため、コードをテストすることが難しいことです。 誰もアイドルコードを書きたくない。 あなたの気持ちに従わないでください。 通常の条件と境界条件を持ついくつかのシナリオを確認することをお勧めします。

エラーを処理するとき、考えずにすべてを処理するか、何も処理しないという2つの極端な方法に進むことができます。 明らかに、2番目のオプションはかなり迅速にポップアップしますが、最初のオプションはより潜行性が高く、予測できない結果につながります。

このようなエラーのいくつかの例について、さらに詳しく見ていきましょう。

try..catch ...どこでも

そのような処理は、名前が示すように、疑わしい（作成者の観点から）コードをtry..catchブロックで囲むことにあります。 ディストリビューションには、 NPEおよびIndexOutOfBoundsException 、 IllegalArgumentException、さらにはOutOfMemoryErrorさえ含まれます。つまり、通常、アプリケーションの論理エラーを示し、適切に復元できないアプリケーションの状態に関する例外です。 もちろん、正しい解決策は論理エラーを修正することです。 さらに、Javaでコードを記述する場合、静的分析を使用して、少なくとも@NonNullおよび@Nullableアノテーションを必要な場所に配置できます。 これは、NPEをキャッチするのに役立ちます。

WeakReference <すべて>

多くの場合、メモリリークについて知る新人は、火のように恐れます。 経験が不足しているため、これによりWeakReferenceのオブジェクトがラップされる可能性があります。 通常、この手法は、オブジェクトのライフサイクルとそれらの間の関係についての不十分な理解を示しています。 以下に例を示します。

public class MyAdapter extends RecyclerView.Adapter<ViewHolder> { private final WeakReference<Context> contextRef; public MyAdapter (@NonNull Context context) { this.contextRef = new WeakReference < > (context); } @Override public ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { final Context context = contextRef.get(); return context == null ? null : LayoutInflater.from(context).inflate(R.layout.item, parent, false); } ... } 

ここで、アダプターコンストラクターにはContextへのリンクがあります。 ただし、アダプターはUIの一部であり、特定のアクティビティに表示されます。 したがって、彼はContextより長く生きるべきではなく、このことからWeakReferenceはここでは必要ありません。

WeakReferenceを使用する別の例：

 public class MyAsyncTask extends AsyncTask<String, String, String> { private final WeakReference<Context> contextRef; public MyAsyncTask(@NonNull Context context) { this.contextRef = new WeakReference<>(context); } ... @Override protected void onPostExecute(@Nullable String result) { final Context context = contextRef.get(); if (context != null && result != null) { Toast.makeText(context, result, Toast.LENGTH_SHORT).show(); } } } 

外観は何も変わっていませんが、AsyncTaskはそれが作成されたアクティビティに耐えることができます。 したがって、ここではWeakReferenceの使用が正当化されます。

メモリリークを回避するには、まず、使用しているオブジェクトのライフサイクルが何であるかを理解する必要があります。 Memory ProfilerとLeakCanaryを使用して、既存の大規模プロジェクトのメモリリークを検索できます。

リクエストキャンセルなし

エラーの原因は、非同期操作、ネットワーク要求またはタイマーのキャンセルの欠如にある場合があります。 これらの操作の耐久性と頻度を考慮し、サブスクライブ/アンサブスクライブ、作成/破棄、開始/キャンセルなどのペアのAPIメソッドに注意してください。

テスト

単体テストの欠如

製品を作成する際に、より優れた、より保守性の高いコードを作成するのに役立ち、時間の経過とともに古くなっていない一種のドキュメントとして役立つため、ユニットテストが大好きです。 一部の開発者は単体テストを怠ります-書くのは難しくて時間がかかり、立ち上げには多くの時間がかかると彼らは言います。

これらのポイントのそれぞれに挑戦することができます。 時間費用に関する項目から始めましょう。 おそらく最初の段階で単体テストを書くのは時間がかかりますが、経験を積むと速度が上がります。 さらに、単体テストは将来への投資であり、将来的にはコードをより速く書くことができます。 起動速度の問題はさらに簡単に解決されます。 継続的インテグレーションを一度設定し 、テストを自動的に実行するだけです。 単体テストを書くのが難しい場合、最高品質のコードを書いているわけではありません。 優れたアーキテクチャにより、タスクが簡単になります。

役に立たないテスト

役に立たないテストは、ソースコードを理解するのを難しくするだけでなく、アプリケーションのビルド時間にも影響を与えるため、役に立たないコードよりもさらにひどくなります。 テストが役に立たない場合がいくつかあります。

他の人のコードをテストする
他の誰かのコードには既にテストが付属していると想定されているため、そのようなテストには時間がかかります。

テストは互いに依存するか、外部要因に依存します。
1つのテストを変更すると他の多くのテストに影響するため、依存テストの保守は困難です。 さらに、テストは異なる順序で実行できるため、テストは予測不可能になります。

実装の詳細をテストする
テストでは、テストされたクラスをブラックボックスとして認識する必要があります。そうしないと、実装を変更するときに、テスト自体を変更する必要があります。 これは不便で、多くの場合、テストを削除または無視します。

おわりに

昨年、数百のテストタスクを分析し、アプリケーションの問題の主な原因が非常に単純であることをもう一度確認しました。

• パフォーマンスチェックなしの直前修正。
• コードのエラー処理の欠落または誤り。
• プラットフォームメソッドのパフォーマンス機能または制限を見落とす、APIメソッドの説明の誤った解釈。
• コンポーネント間の関係を整理するとき、リンクを操作するとき、およびオブジェクトのライフサイクルを考慮するときの注意の欠如。
• テストされていない新しいテクノロジーの使用。

今年は、今年入学するすべての人と、最初のアプリケーションを開発している人にお勧めします。

• より注意を払い、無害に見える変更を行った後でもアプリケーションが機能することを確認します。
• 言語の繊細さを学びましょう：メモリー内のオブジェクトを扱う原則、リンクの種類。
• 静的コードアナライザーとLeakCanaryなどの追加ツールを使用します。
• 使用されるプラットフォームコンポーネントとライブラリの制限と機能を研究する。
• よく知られているプロジェクトで自分自身を証明する時間がなかった新しいテクノロジーを慎重に使用してください。 APIまたはコードが不安定である可能性があり、ネットワークに典型的なエラーのドキュメントまたは分析が含まれていない可能性があるため、質問に対する回答を自分で探す必要があります。

便利なリンク

Android向けに1行も書いていない初心者デベロッパーにとって、 GoogleからUdacityまでのコース （英語とロシア語の字幕）でキャリアを開始するのに役立ちます。 最初の数本のビデオの後にコースを終了せずに最後まで完了すると、理論的な知識だけでなく、自分で作成した最初のアプリケーションも取得できます。

Android Developers YouTubeチャンネルは、Android開発の世界からの短い説明ビデオとニュースの単なる貯蔵庫です。 パフォーマンスが重要なので、 Android Performance Patternsをご覧になることをお勧めします。

トレンドに追いつき 、どこでさらに発展するかを常に知るために、 Androidウィークリーメーリングリストを使用して毎週新しいことを学ぶか、帰宅途中でFragmentedやAndroidDevPodcastなどのポッドキャストを聴くことができます。

Kotlinを知ることは、 Kotlin koansから始めるのが最善です -言語の基本的な構文のアイデアを得ることができます。 Computer Science Centerのビデオコースは 、言語をより詳しく学び、その長所と短所を学び、なぜそのように実装されているのかを理解する価値があります。 Javaの場合、 コンピューターサイエンスセンターからの基礎コースもあります。理論的な知識は、多数の実用的なタスクによってサポートされています。

Android Architecture Blueprintsリポジトリーで一般的なアーキテクチャーの実装を確認できます。

建築のパターンを研究するには、初心者が習得するのが難しい本がしばしば推奨されます。 SourceMakingは、最初の知り合いに最適です。素材はよく構成されており、パターンの大部分には、Javaでの実装の明確な比metaと例があります。

コンピューターサイエンスセンターのアルゴリズムオンラインコースを修了すると、基本的なアルゴリズム手法に精通し、古典的なアルゴリズムを実装する際に手を打つことができます。 また、コースでは、参考文献の良いリストを見つけることができます。 練習が十分でない場合は、いつでもwww.hackerrank.comで練習できます。 簡単な難易度のタスクに時間を無駄にしないでください-それらは単純すぎます。

Learngitbranching.js.orgを使用すると、gitの基本を学ぶことができ、Enkiモバイルアプリでより高度な機能を習得できます。

コンソールからのみgitを使用することを決定した場合は、たとえば、ゲームvim-adventures.comを使用して、基本的なVimコマンドを学習することをお勧めします。