iOSアプリの作成は簡単な作業ではありません。 開発者は、できるだけ早くこのプロセスを完了し、最終的にAppStoreで起動することを望んでいます。 しかし、これで終わりではありません。作成者には長年のバグ修正、機能強化、および他の開発者とのコラボレーションがあります。 私たちは彼らの生活を少し楽にしたいと思います。そのために、iOSの開発中に避けるべき3つのことを決めることにしました(情報についてはEnvato Tuts +に感謝します)。
1.定数、定数...私にとって、可変基準
一見、変数は定数よりも普遍的です。 ただし、定数を使用できる場合は、変数に頼らない方が良いでしょう。 定数にはいくつかの利点があります。
読みやすさ
これがおそらく主な利点です。 米国向けの電子商取引アプリケーションを作成しているとします。 8.75%の現地の売上税率を示します。 そして現時点では、条件付きVasyaは開発に接続されており、開発者は売上税について何も知りません。
売上税率を示す変数を入力すると、1行のコードで変数が変更される可能性があり、アプリケーションに重大な損害を与える可能性があります。 キーワードを
var
から
let
に変更すると、コンパイラはこの値を変更できないと言い、Vasyaはキーボードから運命の指を引きます。
値リファレンス
let
を使用すると、コード内の値を参照できます。 アプリケーションを作成して作成し、突然、Rolling Stonesの例に従って、すべてを黒でペイントすることにしました。 定数を登録した場合、1つの場所で変更すると、他のすべての色参照も変更されます。 そうでない場合は、すべてを手動で探して変更する必要があります。
クラスまたは構造のインスタンス化
シングルトンを作成する場合、クラスの共有インスタンスを作成する必要があります。 これは通常、クラス宣言内の静的let宣言によって行われます。 その後、定数に名前を付けてクラスのインスタンスに割り当てれば、アプリケーション全体で安全に使用できます。
通常のクラスをインスタンス化する必要がある場合(ViewController.swiftなど)、定数を作成し、必要なクラスのインスタンスに割り当てます。これにより、ファイル全体で簡単に使用できるリンクが作成されます。 定数が復活しました!
ご覧のとおり、定数には多くの利点があります。 これらはコードの可読性を向上させ、不変の値を保存するのに役立ち、もちろん、あなたが思うほど役に立たないわけではありません。 クールな開発者は定数を愛し、値を変更することから逃れることができない場合にのみ、変数を使用して定数を変更します。
2.バングオペレーター! なんてかっこいいか、オプションに必要なもの!
オプションは、Swiftの非常に強力な機能です。 これらは、型宣言の後に疑問符が付けられたla
int
および
String
型です。 変数をオプションの文字列として宣言する場合は、次のように書くことができます。
var someVariable: String?
これは、コンパイラが値を持っているかどうかを示す信号です。 ひも? とStringは2つの異なるタイプと見なされます。
オプションはギフトボックスです。 このボックスには値が含まれている場合と含まれていない場合があります。 調べたい場合は、オプションを展開する必要があります。 これはさまざまな方法で行われます。
間違った例:強制的なアンラッピング
この操作(感嘆符を使用して実行)は、バング演算子と呼ばれます。 使用はお勧めしません。 この方法でオプションで抽出されたの値がnil(なし)の場合、アプリケーションはクラッシュします。 以下に例を示します。
var someVariable: String? var somethingElse: String = "hello" func setupApp() { self.somethingElse = self.someVariable! }
この例では、someVariableの値を定義しておらず、String型の変数に割り当てようとしているため、アプリケーションがクラッシュします。 そのようなエラーから保護するために、オプションが作成され、それらのすべての作業が削減されます。
正:オプションのバインディング
これは、最も一般的なオプションの1つです。 オプションの定数の値をifステートメントに割り当てるだけです。 オプションから値を抽出できる場合、コンパイラはクロージャに入り、作成された定数を使用できます。 そうでなければ、elseブランチに行き、何も起こらなかったふりをします。
比較のために、同じ例を取り上げます。
var someVariable: String? var somethingElse: String = "hello" func setupApp() { if let theThing = someVariable { self.somethingElse = self.someVariable! } else { print("error") } }
オプションのバインディングを使用すると、コンパイラはアプリケーション全体をクラッシュさせることなく、静かにelseブランチに入り、「エラー」を出力します。
そして再び:オプションの連鎖
オプションのオプションを安全に取得する別の一般的な方法は、オプションのチェーンを使用することです。 これにより、1行だけでnil値を完全に回避できます。 ある時点でそのような値が取得されると、このコード行は単に実行を停止します。 例:
var someClass: SomeClass? = SomeClass() var somethingElse: String? func setupApp() { self.somethingElse = someClass?.createString() }
someClassがnilの場合、行全体が実行されず、somethingElseの値はnilになります。 上記の例のように、値がnil以外の場合、変数somethingElseに割り当てられます。 いずれにせよ、アプリケーションはクラッシュしません。
繰り返しになりますが、Nil Coalescing(nil join operator)
この方法では、オプションを1行で処理できますが、上記の方法とは異なり、デフォルト値または「else」を指定する必要があります。 つまり、オプションがnilに等しいシナリオの場合です。 例:
var someVariable: String? var somethingElse: String = "hello" func setupApp() { self.somethingElse = someVariable ?? "error" }
神秘的に見えますが、本質は単純です。 左側の式に値がある(つまり、nilと等しくない)場合、この値が使用されます。 値がnilの場合、デフォルト値(この場合はハードコーディングされた文字列)が使用されます。 右側の式はnilとは異なる必要があり、そのタイプはオプションではない必要があります。そうでない場合、すべての意味が失われます。
3.これらのすべてのアーキテクチャパターンを後のために残します
そして最後に、古典的な間違い。 多くはコードを構造化しないため、安定性、効率性、および原則としてそれを維持する能力が損なわれます。 すべてのコードをViewControllerクラスに詰め込むことができますが、この無謀なステップは、コードを変更してデバッグする必要があるときに可燃性の涙を流します。
コードは、アプリケーションを開発するための基盤です。 一貫して敷設された基盤がなければ、アプリケーションの多層構造は簡単に崩壊します。 iOSアプリケーションの基盤は、選択されたデザインパターンです。 最も一般的に使用される2つのパターンを検討してください。
MVC(Model-View-Controller)
Model-View-ControllerまたはMVCのデザインパターンは、コードの各部分を3つの部分(モデル、ビュー、コントローラー)に分割します。
- モデル これは基本的にアプリケーションデータです。 このパートでは、アプリケーションデータのみで機能する再利用可能な構造とクラスについて説明します。 モデルは 、ビューに関連するものや、情報がユーザーにどのように表示されるかについては機能しません 。
- 表示 データの視覚的表示とユーザーインタラクションのみを担当します。 データまたは特定のビューに関連するものは処理しません 。 これは、コードを繰り返すことなく再利用できるクラスです。
- コントローラー これが主人公です。 モデルからデータを取得し、それをビューに送信してユーザーに表示します。 これは通常ViewController.swiftで発生します。入力データを認識し、必要に応じてモデルを変更します。
MVVMやMVPなど、MVCには多くのバリエーションがあります。 それらについて読む価値はありますが、彼らの仕事の原理はMVCに似ているので、ここではそれらについては触れません。 これらはすべて、コードをモジュール化する設計パターンです。
シングルトン
シングルトンは、常にメモリに存在するクラスの唯一のインスタンスです。 そして、何がそんなに特別なのですか? データベースに接続するアプリケーションを作成し、すべての接続をどこかに配置する必要があるとします。 シングルトーンはこれに最適です。 それらを作成する方法は次のとおりです。
// Declaration class DataService { static var shared = DataService() func createUser() { } } // Call-site DataService.shared.createUser()
これらの簡単なヒントに従えば、アプリケーションのメンテナンスが簡単になり、顧客よりも早くエラーを見つけることができます。
私たちが調べたすべてのエラーは、ロシアの古い知恵を美しく示しています。「ゆっくり、あなたは続けます。」 この記事がお役に立てば幸いです。また、iOS開発の落とし穴のいくつかを回避する方法を教えてくれることを期待しています。 私たちは、ESFプログラムから最も独創的なストーリーの作者への楽しい贈り物を約束します!