Các trường hợp sử dụng storyboard trên iOS
Tôi đã đọc một số bài viết gần đây chống lại việc sử dụng storyboard.Những vấn đề chung nhất là con người không dễ đọc được storyboard, nó chậm và có thể gây xung đột ở git.Những quan ngại có thể chấp nhận được nhưng có thể tránh được.Tối muốn nói với bạn chúng ta sử dụng storyboard trên những ...
Tôi đã đọc một số bài viết gần đây chống lại việc sử dụng storyboard.Những vấn đề chung nhất là con người không dễ đọc được storyboard, nó chậm và có thể gây xung đột ở git.Những quan ngại có thể chấp nhận được nhưng có thể tránh được.Tối muốn nói với bạn chúng ta sử dụng storyboard trên những project không bình thường như thế nào và làm thế nào bạn có thể tránh những mối lo ngại và vẫn có được những thứ tốt đẹp storyboad cho bạn.
Tại sao sử dụng storyboard?
Một bức tranh là giá trị của ngàn từ ngữ
Con người là những nhà tư duy thị giác.Phần lớn thông tin chúng ta nhận được là đôi mắt và não là mô hình kết hợp rất phức tạp, nó giúp chúng ta hiểu được thế giới xung quanh chúng ta. Storyboard cho ta cái nhìn tổng quan về giao diện trong ứng dụng của bạn, chưa từng có biểu diễn bằng mã code, cho dù đó là XML hay đơn giản là Swift.Khi chúng ta mở một storyboard thì chúng ta có thể xem tất các views, vị trí và thứ bậc của chúng trong một giây.Mỗi view, bạn có thể xem được constraint có ảnh hưởng đến nó và tương tác của nó như thế nào đến các views khác.Hiệu quả truyền tải thông tin không thể so khớp với văn bản. Một lợi ích khác của storyboard nữa là có thể làm auto layout trực quan hơn.Auto layout là hệ thống trực quang vốn có.Nó có thể là một tập các phương trình toán học dưới đó nhưng chúng ta lại không nghĩ thế.Làm auto layout trực quan là phù hợp tự nhiên. Ngoài ra, làm auto layout trong storyboard cho bạn sự an toàn trong biên dịch.Hầu hết các ràng buộc bị thiếu hoặc mơ hồ đều bị bắt trong quá trình tạo bố cục, không phải khi bạn mở ứng dụng.Điều này có nghĩa là sẽ mất ít thời gian hơn cho những layouts mơ hồ và tìm ra tại sao một view bị thiếu trong màn hình.
Bạn nên làm như thế nào
Bạn sẽ không muốn viêt toàn bộ ứng dụng của bạn trên một UIViewController duy nhất.Cũng vậy đối với storyboard.Mỗi một view controller sẽ ứng với một storyboard.Điều này có một số lợi thế. 1.Xung đột git chỉ xảy ra khi hai developer cùng làm việc trên một view controller trong một storyboard trong cùng một thời điểm.Theo kinh nghiệm của tôi, điều này không thường xuyên xảy ra và không khó để sửa nó. 2.Storyboad không còn tải chậm vì nó chỉ tải cho một view controller. 3.Bạn tự do nhanh chóng với bất kỳ UIViewController nào với bất kỳ cách nào bạn muốn, chỉ bằng cách nhận được view controller của storyboard.Cho dù bạn đang sử dụng segues hoặc đẩy chúng thông qua code.
Khi bạn tạo mới một màn hình, bước đầu tiên của bạn là tạo một view controller.Sau bước đó, bạn sẽ tạo một storyboard có tên giống với view controller bạn đã tạo trước đó.Điều này cho phép bạn làm một điều khá mát mẻ:nhanh chóng UIViewController một cách an toàn, mà khống có chuối hard-coded
let feed = FeedViewController.instance() // feed is of type FeedViewController
Phương thức làm việc bởi tìm kiếm một storyboard có teen giống với class UIViewController và lấy ra một trường hợp view controller từ storyboard đó. Tôi biết sử dụng file Xib như thế nào.Nhưng xib là định dạng đã lạc hậu và một vài tính năng (như tạo một UITableViewCells trong UIViewController của Nib) không được hỗ trợ trong Nib.Tôi cảm giác rằng danh sách các tính năng không được hỗ sẽ chỉ tăng và đó là lý do tại sao tôi dùng Storyboard thay vì Nib.
Không segues
Segues thoạt đầu nhìn có vẻ cool, nhưng ngay sau khi bạn phải truyền dữ liệu từ màn hình này sang màn hình kia thì đó thực sự là trở thành một nỗi đau.Bản phải lưu trữ dữ liệu trong một số biến tạm ở đâu đó.Sau đó truyền giá trị trong phương thức 'prepare(for segue:, sender:'
class UsersViewController: UIViewController, UITableViewDelegate { private enum SegueIdentifier { static let showUserDetails = "showUserDetails" } var usernames: [String] = ["Marin"] func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) { usernameToSend = usernames[indexPath.row] performSegue(withIdentifier: SegueIdentifier.showUserDetails, sender: nil) } private var usernameToSend: String? override func prepare(for segue: UIStoryboardSegue, sender: Any?) { switch segue.identifier { case SegueIdentifier.showUserDetails?: guard let usernameToSend = usernameToSend else { assertionFailure("No username provided!") return } let destination = segue.destination as! UserDetailViewController destination.username = usernameToSend default: break }
} }
Đoạn code này có nhiều vấn đề trong hàm 'prepare(for:sender:)' nó không phải là một hàm thuần túy vì nó phụ thuộc nhiều vào biến tạm được định nghĩa trước đó.Thậm chí tệ hơn, biến đó là tùy chọn, và nó không rõ ràng những gì sẽ xảy ra nếu nó là nil. Bạn cần phải nhớ tự thiết lập property usernameToSend, nó có thể bị thay đổi trong code của chúng ta.Bạn cũng cần phải phân phối đích đến của segue tới loại bạn mong đợi.Đó là rất nhiều boilerplate và nhiều hơn một điểm của sự thất bại.
class UsersViewController: UIViewController, UITableViewDelegate { var usernames: [String] = ["Marin"] func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) { let username = usernames[indexPath.row] showDetail(withUsername: username) } private func showDetail(withUsername username: String) { let detail = UserDetailViewController.instance() detail.username = username navigationController?.pushViewController(detail, animated: true) } }
Đoạn code này sẽ an toàn hơn, ngắn gọn và dễ hiểu hơn.
Tất cả các properties được gán trong code
Tất cả cá giá trị của Storyboard là mặc định.Nếu một label muốn có 1 text hay 1 view cần có background color, tất cả những điều đó đều ở trong code. Điều này liên quan đến tất cả cá checkmark nhỏ trong các properties. Vì sao bạn lại không muốn hard-code fonts, colors, texts.Bạn có thể cố định cho những điều đó, và một nơi duy nhất để giữ chúng, vì vậy bạn có một nơi để thay đổi khi bạn cần thực hiện thay đổi thiết kế. Ngoài ra, việc quét mã cho thuộc tính của chế độ xem dễ hơn là cố gắng tìm các dấu kiểm được kiểm tra trong Storyboard. Điều này có nghĩa bạn có thể xây dựng auto layout trong storyboard,nhưng định dạng chúng trong code cho phép bạn hoàn toàn tự do tạo dùng lại code và lịch sử thay đổi do con người có thể đọc.
Những storyboard dành cho tôi
Bạn có thể đang đọc bài báo này và nghĩ rằng "Chàng trai này nói Storyboard là tuyệt vời, và sau đó nói rằng anh ấy không sử dụng một nửa các tính năng", và bạn nói đúng! Storyboard có vấn đề, và đó là những cách tôi tránh những vấn đề đó. Tôi tìm các storyboard hữu ích cho những gì tôi muốn làm với chúng: Tạo ra hệ thống view và constraint chúng. Không hơn không kém.