Objective-CからSwiftへのプロジェクトの翻訳について

こんにちは親愛なる読者。



過去6か月間に出版のヒントで取り上げられた最も燃えているトピックの中で、Swiftプログラミング言語には特別な場所があります。 欧米の開発者からの大きな関心と、このテーマに関する本の豊富な本で、言語はまだかなり生々しく見えます。 したがって、新しい言語の関連性について調査し、「Programming iOS 8：Dive Deep into Views、View Controllers、and Frameworks」という本の著者である壮大なMatt Neuburgの投稿に精通することを提案します。 著者は、アプリケーションの新しいApple言語への翻訳について詳細に説明し、「目が怖い-手がしている」ことを証明しています。



幸せな読書と実り多い実験。



Objective-Cで記述されたアプリケーションが既にある場合は、Swiftでアプリケーションを書き直してみてください。 これは、Swift言語に精通し、Swiftを試して、Swiftをメインテクノロジーとして選択する準備ができているかどうかを自分で判断する絶好の機会です。 このような移行をいくつかの実際のアプリケーションで実行することができました。この記事では、この経験から収集したいくつかの観察結果を共有したいと思います。



ハイブリッドアセンブリ



もちろん、すべてのコードをすぐにSwiftに翻訳する必要はありません。 クラスごとに書き直す可能性が非常に高くなります。 Objective-Cで記述されたアプリケーションのアセンブリにSwiftファイルを追加するとすぐに、このアセンブリはハイブリッドになります。 その中のいくつかのクラスはObjective-Cに残り、他のクラスはSwiftで書かれます。 したがって、すべての宣言が両方の言語のコードで表示されるようにする必要があります。 この作業を始める前に、このような可視性のメカニズムがどのように機能するかを見てみましょう。

覚えているように、Objective-Cクラスの宣言は通常、2つの部分に分かれています。インターフェイスセクションを含むヘッダーファイル（.h）と、@ implementationセクションを含むコードファイル（.m）です。 .mファイルにクラス情報が必要な場合、そのクラスの.hファイルをインポートします。

SwiftとObjective-Cコードの相互可視性は、次の規則に基づいています。.hファイルレベルで提供されます。 可視性には2つの方向があり、それぞれ個別に考慮する必要があります。



SwiftがObjective-Cを認識する方法



SwiftファイルをObjective-Cのアセンブリに追加する場合、またはObjective-CファイルをSwiftのアセンブリに追加する場合、Xcodeはブリッジヘッダーを作成するように求めます。 これは、プロジェクトの一部である.hファイルです。 デフォルトでは、その名前はアセンブリに代わって作成されますが、一般に任意であり、Objective-Cアセンブリの「リンクヘッダー」設定を同様に変更する場合は変更できます。

Objective-Cの.hファイルは、このリンクヘッダーにインポート（#import）されていれば、Swiftに表示されます。



Objective-CがSwiftを認識する方法



リンクヘッダーがある場合、アセンブリを作成すると、すべてのSwiftファイルの対応するトップレベル宣言が自動的にObjective-Cに変換され、DerivedDataフォルダーの深い場所にあるこのターゲットアセンブリのIntermediatesディレクトリに隠しリンクヘッダーを作成するために使用されます。 この非表示ヘッダーは、ターミナルウィンドウに入力された次のコマンドを使用して最も簡単に表示できます。

$ find ~/Library/Developer/Xcode/DerivedData -name "*Swift.h"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、非表示のリンクヘッダーの名前が認識されます。 または、ターゲットアセンブリの[製品モジュール名]設定を表示（または変更）してみてください。 非表示のリンクヘッダーの名前は、ここで指定した製品名に基づいて作成されます。



Swift宣言は、これらのSwiftファイルが表示されるすべてのObjective-Cファイルにこの隠しリンクヘッダーをインポート（#import）することを条件に、Objective-Cファイルに表示されます。



状況は、.mファイルの上部の非表示リンクヘッダーが正確にインポートされる場所から大幅に変化する可能性があります。 一般的なアラームは、「不明なタイプ名」のコンパイルエラーの出現です。不明なタイプはObjective-Cで宣言されたクラスです。 この問題を解決するには、非表示のリンクヘッダーをインポートする前に、不明な型宣言を含む.hファイルをObjective-Cファイルにインポートする必要があります。 そのような作業は、特に問題のObjective-Cファイルがこのクラスを知る必要がない場合は面倒なことがありますが、この方法で問題を本当に解決し、その後コンパイルを続行できます。



順を追った説明



変更を行う前に、gitで新しいブランチを作成します。 次に、Objective-CからSwiftにクラスを1つずつ転送します。 次のアルゴリズムに従ってこれを行います。

1. Swiftに変換する.mファイルを選択します。 Objective-CはSwiftクラスを継承できないため、サブクラスから始めて、Objective-Cでサブクラスとクラス自体の両方を定義する必要があります。 アプリケーションデリゲートクラスは最後に翻訳されます。
2. この.mファイルをターゲットアセンブリから削除します。 これを行うには、.mファイルを選択し、ファイルインスペクターを使用します。
3. 対応する.hファイルをインポートするすべてのObjective-Cファイルで、＃importステートメントを削除し、代わりに非表示のリンクヘッダーをインポートします。 （隠しリンクヘッダーをこのファイルに既にインポートしている場合は、この手順を繰り返す必要はありません。）
4. 対応する.hファイルをリンクヘッダーにインポートする場合は、＃importステートメントを削除します。
5. このクラスの.swiftファイルを作成します。 ターゲットアセンブリに追加されていることを確認してください。
6. .swiftファイルで、クラスを宣言し、.hファイルで公開されたすべてのメンバーのスタブ宣言を配置します。 このクラスがCocoaプロトコルに準拠する必要がある場合は、それらを受け入れます。 また、このプロトコルのすべての必須メソッドにスタブ宣言を提供する必要があります。 このファイルが、Objective-Cのターゲットアセンブリでまだ宣言されている他のクラスも参照する必要がある場合は、それらの.hファイルをリンクヘッダーにインポートします。
7. これでプロジェクトがコンパイルされます！ もちろん、.swiftファイルにはまだ実際のコードがないため、機能しません。 しかし、これは本当に問題なのでしょうか？ だから、ジャークのためのビール！
8. ここで、.swiftファイルにコードを記述します。 結果が慣用的ではない場合でも（Swift）、元のObjective-Cファイルのコードを1行ずつ翻訳することを好みます。
9. この.mファイルのコードがSwiftに完全に変換されたら、ビルドして実行し、テストします。 ランタイムがこのクラスを見つけることができないことを誓う場合（特に同時にクラッシュする場合）、nibエディターでそれへのすべてのリンクを探し、IDインスペクターでクラス名を再入力します（また、変更を設定するためにTabを押します） 。 すべてを保存して再試行してください。
10. 次の.mファイルへ！ 上記のすべての手順を繰り返します。
11. 他のすべてのファイルが翻訳されたら、アプリケーションデリゲートクラスを翻訳します。 この段階で、Objective-Cにターゲットアセンブリにファイルが残っていない場合は、main.mファイル（アプリデリゲートクラス宣言属性の@UIApplicationMain属性に置き換えます）と.pchファイル（プリコンパイル済みヘッダー）を削除できます。

すべてのコードをSwiftに翻訳する必要があるとは思わないでください。 一部のセクションは、Objective-Cに残すほうがよい場合がありますが、これは完全に正常です。 実際、SwiftがアクセスできないCocoa APIの詳細があるため、Objective-Cにいくつかのコードを残す必要があります。 たとえば、C関数をSwiftまたは関数ポインターに書き込むことはできないため、Objective-CヘルパーメソッドなしでCGPatternCreateまたはAudioServicesAddSystemSoundCompletionを呼び出すことはできません。 AppearanceWhenContainedIn：メソッドは、Swiftから呼び出すこともできません。



一方、Swiftでは使用できないperformSelector：メソッドのいずれかを使用するコードは、Objective-Cにすぐに残すことができますが、遅かれ早かれ、これらのメソッドをSwiftのコードに置き換えるための回避策を考え出す必要があります。



Swiftを試してみましょう



おめでとうございます！ これで、アプリケーションの全部または一部がSwiftで作成されました。 しかし、私のすべての推奨事項に従えば、この段階ではアプリケーションはまだ「速すぎ」ません。 結局、私たちは主にコードを実行しようとしました。 これですべてが機能するようになったので、コード自体に戻ってコードをより慣用的にすることができます。 Objective-Cで複雑に、または厄介に解決されたいくつかのタスクは、Swiftで実装されたよりクリーンで優れたものである場合があります。



もちろん、可能な限り、ネイティブのSwiftタイプに切り替える必要があります。 NSStringとNSMutableString、NSArrayとNSMutableArray、およびNSDictionaryとNSMutableDictionaryなどの不変/可変型のペアは、ネイティブのSwift型（String、Array、Dictionary）に置き換えることができます。 また、これらのタイプに付属していた複雑なトリックのいくつかはもう必要ないことがわかります。 そのため、配列にはインスタンスメソッドmap、filter、reduceがあります。 彼らはあなたにとって非常に役立つでしょう。



たとえば、私のアプリケーションの1つに、データがセクションごとに分割されて表示される表形式のビューがありました。 システム内レベルでは、このデータは配列の配列に記録されます。各サブ配列は、特定のセクションの表形式の行を表す行で構成されます。 テーブルを検索できます。次に、ユーザーが検索フィールドに入力したサブストリングを含まない行を検索して削除します。 セクション自体には触れませんが、行を削除するときに一部のセクションが完全に空になっている場合は、このセクションの配列全体を完全に削除します。 これはObjective-Cで行われた方法です（sbはUISearchBarです）：

  NSPredicate* p = [NSPredicate predicateWithBlock: ^BOOL(id obj, NSDictionary *d) { NSString* s = obj; NSStringCompareOptions options = NSCaseInsensitiveSearch; return ([s rangeOfString:sb.text options:options].location != NSNotFound); }]; NSMutableArray* filteredData = [NSMutableArray new]; for (NSArray* arr in self.sectionData) { NSArray* filteredArr = [arr filteredArrayUsingPredicate:p]; if (filteredArr.count) [filteredData addObject: filteredArr]; } self.filteredSectionData = filteredData;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初に、NSPredicateを構成して配列をフィルターします。 次に、配列の配列をループ処理して、フィルター処理された各サブ配列のコンポーネントを1つずつ空のNSMutableArrayに「分散」します。 あなたはこのイディオムに精通していると確信しています。 Swiftでは、NSPredicateも「配布」のイディオムも、2つの中間配列も必要ありません！ マップとフィルターがあり、すべての作業が単一のステートメントに収まります。

 self.filteredSectionData = self.sectionData.map { $0.filter { let options = NSStringCompareOptions.CaseInsensitiveSearch let found = $0.rangeOfString(sb.text, options: options) return (found != nil) } }.filter {$0.count > 0}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、コードがメッセージ転送に関連するObjective-Cダイナミクスに依存している場所では、Swiftでは関数が最初のクラスのオブジェクトであるため、このメカニズムがなくても実行できます。



例を考えてみましょう。

辞書カードアプリケーションには、ラテン語を表すTermクラスがあります。 多くのプロパティを宣言します。 各カードは1つの用語に対応し、各プロパティは個別のテキストフィールドに表示されます。 ユーザーが画面上のテキストフィールドのいずれかをクリックすると、インターフェイスの現在の用語を、ユーザーが選択したプロパティによって前の用語とは異なる次の用語に変更する必要があります。 したがって、3つのテキストフィールドすべてのコードは同じになります。 全体の違いは、画面に表示する次の用語を選択するプロパティにあります。



Objective-Cでは、このような並行性を表現する最も簡単な方法は、キーと値のペアを使用することでした（gはクリックジェスチャレコグナイザーです）：

  NSInteger tag = g.view.tag; // the tag tells us which text field was tapped NSString* key = nil; switch (tag) { case 1: key = @"lesson"; break; case 2: key = @"lessonSection"; break; case 3: key = @"lessonSectionPartFirstWord"; break; } //       NSString* curValue = [[self currentCardController].term valueForKey: key];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、Swiftでキーと値のペアを引き続き使用できます。 ただし、これには、TermクラスがNSObjectを継承する必要があり、Objective-C / Cocoaのダイナミクス-文字列をプロパティ名に変換する-Swiftの精神とは無関係です。 Swiftでは、匿名関数の単純な配列を使用して、ラベルをメソッド呼び出しに変換することにより、同じダイナミクスを簡単に実装できることがわかります。

  let tag = g.view!.tag let arr : [(Term) -> String] = [ {$0.lesson}, {$0.lessonSection}, {$0.lessonSectionPartFirstWord} ] let curValue = arr[tag-1](self.currentCardController.term)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに



Swiftの多くのプロパティは、最初からコードの信頼性を高めることを目的としています。



Objective-Cでプログラミングする際のよくある間違いは、インスタンスプロパティを宣言することですが、元の値に設定するのを忘れることです。 nilにメッセージを送信しても何も起こらないため、問題に気付かずに長時間作業できます。 Swiftでは、すべてのインスタンスプロパティの初期化が必要です。 次に、悪名高いストロングタイピングSwiftについて説明します。 Objective-Cでは、配列の要素を推測することはかなり可能ですが、Swiftでは、厳密に定義された配列の要素タイプを指定する必要があります。 これらのSwiftの特性と戦おうとしないでください、彼らに感謝してください！ 単にSwiftコードをコンパイルするように管理するだけであれば、すでに何かを学びます。 おそらく、あなたのコードは、そのような正確さがSwift言語の本質に組み込まれているという単純な理由で正しいでしょう。



疑問がある場合は、Swiftを試してみる価値があります。もうheしないでください。 今こそ、Swiftを学び、この言語を楽しむ時です。 Xcode 6.3のベータ版では、Swift 1.2がすでに利用可能であり、この言語が既に十分な成熟度に達していることを確認できます。 Swiftは興味深くシンプルな言語であり、Objective-Cで作成されたアプリケーションをすばやくすばやく翻訳できます。 結果のコードがどれほど明確で単純になるか、驚くかもしれません。