mmyoji's diary

プログラミングとか日々のどうでもいいこととか

Swift&Xcode始めました!

仕事でSwift

先日晴れて(?)iOS developerとしてiOS projectに関与していいことになり、Swift及びXcodeの勉強を始めました!

以前から

一応ちょいちょいスマホアプリも作れた方がいいなーと思って勉強しようとしては諦めてを繰り返してました。

挫折してた理由としては

  • (Obj-C and)Swiftがイマイチピンとこなかった(これは解消済み)
  • webに上がってるサンプルコードが古い(コンパイル通らない)
  • XcodeのViewのクラスやメソッドが多すぎて圧倒される

ってところでしょうか。

で解決策としては、

  • SwiftAppleの公式ドキュメントで勉強
    • 英語苦手な人は『詳解 Swift』という本が良いらしいのでそれを一通り読んでおく
  • サンプルコードは新しいもの以外写経しない
    • 古いものは感覚つかむために流し読みするだけにしておく
    • 公式のコードや(活発に開発されてる)オープンソースなどを参考にする
  • Viewクラスやメソッドはちょっとずつ覚える。最初から全部覚えようとしない

かなと思ってます。

詳解 Swift

詳解 Swift

StoryBoard??

普段Railsぐらいしか書いてないので、iOS開発時のディレクトリ構成とか全然わかってないでうす。

仮にMVCスタイルで行くとするなら、ViewControllerになんでも書けちゃうのであっという間にFat Controller化するだろうなと思っていて、ViewController内でViewの生成とかを書くぐらいならStoryBoard使った方が綺麗に書ける(描ける)だろ!って感じでしたが、 Should you use Storyboards on more complex apps? | Roadfire Software にあるようにメリット・デメリットが説明されてました。わかりやすい。

以下ほぼ引用というか翻訳

メリット

  • Viewの関係性が視覚的にわかりやすい
  • Viewの構成・スタイルが即座に反映されてわかりやすい(作っている人は)
  • 静的なテーブルビューをコードなしで書ける

デメリット

  • 複数人開発の際、
    • StoryBoardのConflictがつらすぎる
    • コードレビューできんの?(メリットの2番目に対応します)
  • アプリが複雑になった際、画面遷移なども複雑になり、StoryBoardぐちゃる
  • ViewControllerが増えた際、StoryBoardのloadに時間がかかる
    • 30個ViewControllerがあるStoryBoardの場合4~5秒ほどかかる

まとめ

  • 複数人開発の際は、フローが異なる画面の場合はStoryBoardを分ける
  • アプリのプロトタイプを作る場合や一人で開発する場合はStoryBoard使った方がメリット > デメリットになることが多い

個人的なまとめ

結局「View作るとき、StoryBoard使えるようになればいいの?コードで全部書けるようになっとけばいいの?」と勉強する工数減らすことを考えていましたが、iOSエンジニアとしてやっていくなら 両方できなきゃダメだよね! ってことだと思いました。

近道を探さずにコードでも表現できるように精進します 😤⤴️⤴️