このトピックに関する以前に公開された記事（
Cocoapodsの紹介と、独自の「pod」の作成に関する
簡単な要約）に言及することは
間違いありません。
引用された最後の記事は、正しい方向に弾みをつけましたが、提供された情報を完全に理解する知識がありませんでした。 この記事の目的は、独自のCocoaPodを作成して使用するプロセスを可能な限り詳細に説明することです。 さて、この分野の知識を合理化するために。
はじめに
前述の最初の記事を確認した後、すでにCocoaPodsがインストールされており、Macでの戦いの準備ができています。それが何であり、何のためであるかを理解しています。 独自の「ポッド」が必要な理由も明確になっているはずです。
プロジェクトページでは、独自の「ポッド」を構築する一般的な原則
についてはほとんど説明していません 。 「pod」の開発のために著者が推奨するディレクトリ構造は次のとおりです。
. ├── Classes └── ios └── osx ├── Resources ├── Project └── Podfile ├── LICENSE ├── Readme.markdown └── NAME.podspec
何が：
- クラス -iOSおよび/またはOS Xの「ポッド」のソースであるサブディレクトリ内のディレクトリ
- リソース -画像、ビデオ、その他のバイナリ、コアデータモデルなど
- プロジェクト -原則として「ポッド」を使用するプロジェクト -「ポッド」の使用例を示すプロジェクト。単体テストでは非常に望ましい
- Podfile-このファイルでは、すでに知られているはずですが、プロジェクトのさまざまな「ポッド」への依存関係が示されています。この場合、
- 名前で自分自身を表すファイルを省略します
- NAME.podspec-作成された「ポッド」の仕様 'a
「ポッド」プロジェクトを作成する
それでは始めましょう。 念のため、サンプルプロジェクトは
GitHubにあり
ます 。
MyCustomPodなどの名前でGitHubリポジトリを作成します。
「pod」プロジェクトを作成しましょう。このために、ターミナルに次のように入力します。
$ mkdir ~/Documents/PodSample $ cd ~/Documents/PodSample $ git init $ git remote add origin https://github.com/username/MyCustomPod.git $ touch LICENSE $ git add LICENSE && git commit -m "License file" $ git push -u origin master $ mkdir Classes
何が起こっているかの簡単な説明。
ローカルgitリポジトリを作成し、GitHubにバインドし、プロジェクトのライセンススキームを記述するファイルを作成してコミットし、変更をGutHubに送信します。 「pod」自体のソースコードが置かれる
Classesディレクトリを作成します。
Classes / iosおよび
Classes / osxのサブディレクトリは作成しません。 これまでのところ、1つのプラットフォーム（iOS）のみに焦点を当てています。
「仕様」を作成する
そして再び理論に。 各「ポッド」には独自の仕様があります。「スペック」は、名前、バージョン、ライセンス、プラットフォームバージョンへの依存、使用されるフレームワーク、他の「ポッド」、ソースリポジトリ、ARCの使用などのメタデータを記述します。 これらはすべて
NAME.podspecファイルに書き込まれます。
.podspecファイルは開発者「pod」によって作成され、「spec」の特別なリポジトリに配置されます。 悪名高い
AFNetworkingなど、デフォルトで利用可能なすべての「ポッド」が存在する
メインリポジトリがあります。 便利な「ポッド」もそこに表示される場合があります。 また、独自の「仕様」リポジトリを作成して使用する機会もあります。リポジトリへのアクセスは、個人によって規制されています。
しかし、最初に戻ります。 ターミナルで
.podspecを作成するには、次のコマンドを入力します。
$ pod spec create MyLibrary
その結果、現在のディレクトリでは、
MyLibrary.podspecファイルの形式で「spec」テンプレートを取得します。これは、各パラメーターが何のために必要なのかを詳しく説明しています。 ファイル形式のより詳細な説明は
、プロジェクトwikiページに示され
ています 。
誰もが最高の訓練は常に「単純なものから複雑なものまで」という軍事原則に基づいていることを知っており、我々は規範を敬遠しません。
まず、名目上のパラメーターセットを設定します。
Pod::Spec.new do |s| s.name = "MyLibrary" s.version = "0.0.1" s.summary = "Example of creating own pod." s.homepage = "https://github.com/username/MyCustomPod" s.license = { :type => 'MIT', :file => 'LICENSE' } s.author = { "Username" => "username@mail.domain" } s.platform = :ios, '7.0' s.source = { :git => "https://github.com/username/MyCustomPod.git", :tag => s.version.to_s } s.source_files = 'Classes/*.{h,m}' s.public_header_files = 'Classes/*.h' s.framework = 'Foundation' s.requires_arc = true end
何が起こっているのかを正確に理解する必要がある行を見てみましょう。
複数の作成者またはフレームワークを指定する必要がある場合は、パラメーター名を複数形、たとえば
作成者に変換し、値をコンマで区切ってリストします。
プロジェクトがOS Xでも使用される場合は、
Classes / iosおよび
Classes / osxサブディレクトリを作成し、パラメーター値を修正する必要があります。
s.source_files = 'Classes/**/*.{h,m}' s.public_header_files = 'Classes/**/*.h'
platformパラメーターを含む行を削除し、次のパラメーターを追加します。
s.ios.deployment_target = '7.0' s.osx.deployment_target = '10.8'
リント「スペック」
リンクプロセスは、
.podspecファイルの構文、必要なパラメーターの存在、パラメーター値の関連性、および「pod」のコンパイルの試行で構成されます。 いわゆる「高速」リンクがあり、「pod」リポジトリをダウンロードしてコンパイルしようとせずに、
.podspecファイルの構文と必要なパラメーターの存在が単純にチェックされます。
結果の
MyLibrary.specpodを記述し、最初に
--quickスイッチを使用して「クイック」リンクを
実行します。
$ pod spec lint ~/Documents/PodSample/MyLibrary.podspec --quick
理想的には、次のようなものです：
$ pod spec lint ~/Documents/PodSample/MyLibrary.podspec --quick -> MyLibrary (0.0.1) Analyzed 1 podspec. MyLibrary.podspec passed validation.
エラーが発生した場合、各エラーは非常に明確にコメントされ、修正しても問題は発生しません。
次に、gitへの変更をコミットします。
$ git add MyLibrary.podspec && git commit -m "Completed podspec file"
完全なリンクを成功させるために、空のファイルをいくつか作成します（そうでない場合、エラーが表示されます-「
ERROR | [iOS] The source_files`パターンがどのファイルにも一致しませんでした。 」）
$ touch Classes/AKClass.m $ touch Classes/AKClass.h $ git add Classes/AKClass.* && git commit -m "Empty files for successful lint"
現在のバージョン番号でタグを書き留め、GitHubで「pod」を公開します。
$ git tag "0.0.1" && git push origin master --tags
リンティング：
$ pod spec lint ~/Documents/PodSample/MyLibrary.podspec
すべてが適切に観察された場合、同様の画像：
$ pod spec lint ~/Documents/PodSample/MyLibrary.podspec -> MyLibrary (0.0.1) Analyzed 1 podspec. MyLibrary.podspec passed validation.
やった！ 「ポッド」プロジェクトは構成されており、エラーは含まれていません。
継続する。
予定：
パート2.「ポッド」をモジュールに分割します。 エイリアンの「ポッド」を使用して独自の開発を行います。
パート3.彼の「ポッド」の公開 共有リポジトリと個人。