StoryBoardが必要では無い理由

複雑な配置を実現する為にはやる事が多すぎる

昔、僕はStoryBoardを使っていくのにすごく賛成していました。しかし、だんだんと複雑なUIのアプリを作っていくうちにSafeAreaを使用するようになったり、画面の分割をするようになったり、Webで言うレスポンシブデザインのようにiPhoneSEとiPadの両方において綺麗なUIになるようにしなければいけなくなりました。

それをStoryBoard上で実現するには、状況においてはDisable又はHideするAnchorやViewを設定したり、パーセンテージでViewの長さを設定したりと色々と設定しなければいけなくなりました。後からボタンを追加しようと思うとUIが崩れて最初から設定し直しなんて言うことはしょっちゅうありました。

勿論もっと慣れれば崩れることはなくなると思いますが、2、3人以上のチームで開発を始めると皆んなが皆んな同じ様にAnchorを付けるとは限りません。そうなってくるとコードで書かれていた方が順を追って確認ができたり、目に見えない所でコードが変わる事が無いので信用できます。

実際にコードで書くとこんな感じになります。

//Thenライブラリを使用して初期化
var myButton = UIButton().then { button in
    button.setTitle("プロ", for: .normal)
    button.setTitleColor(.white, for: .normal)
    button.sizeToFit()
}

view.addSubview(myButton)

//SnapKitを使用してLayoutの設定
myButton.snp.makeConstraints { make in
    make.width.height.equalTo(50)
    make.center.equalTo(self.view)
}

沢山のボタンやsubViewを使用する場合初期化が多くなってLayoutの設定のコードも長くなって全体のコードが結構長くなってしまう事があります。そのような時にはinitViews()addViews()layoutViews()の3つの関数に分ける事によって見やすくなります。

コードの再利用が簡単に出来る

上で紹介したコードは少しだけ変更するだけで右寄せにしたり、2つ並べて表示したりが簡単にできます。

UIButtonの場合はログインボタンとログアウトボタンが同じデザインだった場合色を変更するだけで初期化(Thenを使用)もLayout(SnapKit)の設定も全てコードの再利用ができます。これは大きなプロジェクトを作っていると大変役に立ちます。

一つコードをまとめるためのクラスを作っていくつかのボタンをそこで宣言しておきます。そうすると色々な場所で同じ形、同じRadiusのボタンを再利用する事ができます。下に例を書きたいと思います。

class Buttons {
    let normalButton = UIButton().then { button in
        button.backgroundColor = .clear
        button.layer.cornerRadius = 5
        button.layer.borderWidth = 1
        button.layer.borderColor = UIColor.black.cgColor
    }
}
//Thenライブラリを使用してボタンのコピー
let loginButton = Buttons().normalButton.with { button in
    button.setTitle("ログイン", for: .normal)
}
let logoutButton = Buttons().normalButton.with { button in
    button.setTitle("ログアウト", for: .normal)
}

アクションシートやViewでも同じ事ができます。クラスを変更すると他の所全てにそれが反映されるのも一つ良い面です。同じ構成の物を複数回使う時は沢山出てきますなので簡単に複製とカスタマイズができるコードで書くというのはすごく良い方法であると言えます。

コンフリクトは最悪

これに関してはあまりいう事がありませんが、StoryBoardの構成上、チームで開発している時、必ずと言って良いほどコンフリクトが起こります、これが起こってしまうと最後、直すのはそう簡単ではありません。しかし、知っている会社や有名なアプリでもUIを全てStoryBoardで作っているプロジェクトはあります、どの様に管理しているかも気になります。

最後に

StoryBoardを使わないようにするというのは勉強の為にもなります。アーキテクチャの勉強からUITableViewがどの様に動いているのか、NavigationBarがどの様な構成でできているのか、みたいな感じで色々な事がしれます。勿論StoryBoardを使用してもコードは沢山書きますので。。。

今回はストーリーボードを使わなくて良い理由を大きく分けて3つ紹介しました。他にもロードとコンパイルが早くなるというメリットもある為是非みなさんStoryBoardを使わないでの実装を一度やってみてください。

Leave a Reply

Your email address will not be published. Required fields are marked *