Xcode: Phương pháp tối ưu để làm việc với Storyboard

55

Apple đã thực hiện những cải thiện lớn trong môi trường Interface Builder ở Xcode 8. Việc sử dụng size classes trở nên trực quan hơn, có khả năng zoom storyboard của bạn rất thuận tiện và tính năng xem trước toàn diện ngay trong Interface Builder đáng kinh ngạc. Đối với những người đang do dự về việc sử dụng Interface Builder, điều này có thể trở thành một rào cản lớn.

Mặt khác, nhiều dev vẫn có một số rắc rối với Interface Builder khi họ xây dựng các ứng dụng đa màn hình với sự điều hướng phức tạp.

Trong bài viết này, tác giả sẽ chia sẻ một số phương pháp tốt khi bạn làm việc với storyboard và nib trong dự án của bạn. Hoặc là bạn đã sử dụng Interface Builder trước, hoặc bạn chỉ cần thực hiện các bước đầu tiên theo hướng dẫn này, những lời khuyên có thể hữu ích cho bạn.

1.Nếu bạn làm việc theo nhóm, hãy sử dụng storyboard riêng biệt cho mỗi màn hình. Nếu làm việc một mình, nó vẫn là thói quen tốt

Bạn đã từng có duy nhất một file main.storyboard trong project của bạn như thế này?

storyboard

Điều này có vẻ tốt từ các designer stand-point: bạn có thể dễ dàng nhìn thấy các giao diện người dùng và sự điều hướng hoàn toàn. Đó chính xác là những gì mà Interface Builder đã được tạo để làm.

Nhưng đối với các developer điều này có thể gây nên nhiều vấn đề:

  • Source control: việc giải quyết conflicts trong Storyboard là rất khó khăn, vì vậy chỉ cần làm việc trong các storyboards riêng biệt sẽ dễ dàng hơn.
  • Storyboard file trở nên nặng nề và khó điều hướng. Đã bao nhiêu lần bạn vô tình thay đổi constraint bằng một cái click chuột trong ViewController?
  • Bạn cần gán storyboard ID cho mỗi ViewController, điều đó dễ mắc lỗi: bạn cần nhớ ID này khi mỗi lần bạn muốn sử dụng cho ViewController trong code.

Làm thế nào để kết nối những storyboards khác nhau trong project của bạn? Có 2 cách để làm điều này:

1. Sử dụng storyboard referencing được giới thiệu trong Xcode 7.

2. Kết nối storyboards trong code.

Bạn có thể tìm hiểu kỹ hơn về cách thứ nhất ở đây.

Tác giả sẽ giới thiệu về cách thứ hai nhiều hơn, vì nó phổ biến hơn đối với những project phức tạp.

2. Sử dụng cùng tên cho file storyboard và kết hợp subclass ViewController.

Điều này sẽ đơn giản hóa các quy ước đặt tên và cũng cung cấp cho bạn một số lợi ích trong lời gợi ý thứ 3.

3. Khởi tạo storyboard ngay trong subclass UIViewController của nó.

Khi nói đến việc khởi tạo một storyboard trong ViewController bằng code, chúng ta hãy xem đoạn code sau:

Điều này nhìn không rõ ràng lắm: bạn cần đặt tên cho storyboard, bạn cần cung cấp các storyboard ID viewController và bạn cần phải sử dụng pattern này mỗi khi bạn tạo HomeViewController của bạn.

Một cách tốt hơn là di chuyển code vào bên trong subclass viewController và sử dụng một static method để khởi tạo nó với storyboard:

Nếu bạn làm theo những lời khuyên trên, bạn có thể tránh được việc khó gõ tên storyboard và sử dụng className:

Hãy chắc chắn rằng file storyboard của bạn có tên giống như các class thực tế. Nếu không, các ứng dụng sẽ crash khi bạn cố gắng tạo ra một tham chiếu tới storyboard này.

Điều đó làm cho code của bạn thậm chí còn có thể đọc được nhiều hơn và ít bị lỗi hơn:

Nếu bạn muốn truy cập vào ViewController bằng instantiateInitialViewController (), hãy chắc chắn rằng bạn đã đánh dấu viewController này như initialViewController trong Interface Builder. Nếu bạn có nhiều viewControllers trong Storyboard tương tự, bạn sẽ phải sử dụng các method instantiateViewController (withIdentifier: _)

Bây giờ, khi bạn cần khởi tạo viewController này, nó sẽ là một dòng code:

Code chúng ta rất gọn, phải không?

Bạn có thể sử dụng phương pháp tương tự cho việc khởi tạo view từ nib:

4. Đừng overload project của bạn với storyboard segues

Điều này sẽ không phải là vấn đề, nếu bạn làm theo lời khuyên thứ nhất. Nhưng thậm chí nếu bạn có nhiều viewController trong cùng một Storyboard, sử dụng segues để điều hướng giữa các viewController có thể không phải là một ý tưởng tốt:

  • Bạn cần đặt tên cho mỗi segue, chỉ điều đó thôi đã dễ bị lỗi. Code cứng một chuỗi dài luôn là một thói quen lập trình tệ.
  • PrepareForSegue method sẽ trở nên xấu xí và gần như không thể đọc được, khi bạn thêm một vài bằng cách dùng câu lệnh “if/else” hoặc “switch”.

Sự thay thế ở đây là gì? Khi bạn muốn điều hướng đến các viewController kế tiếp trên nút bấm, chỉ cần thêm một IBAction cho button này và khởi tạo viewController này trong code: nó thực sự chỉ là một dòng code, khi bạn áp dụng Lời khuyên # 3.

5. Unwind segue? Chưa bao giờ nghe nói

Đôi khi các dòng điều hướng mang user trở lại màn hình trước đó.

Dưới đây là một sai lầm phổ biến: sử dụng một segue mới để điều hướng trở lại viewController trước. Điều này tạo ra một instance mới của cùng một ViewController, cái đó đã có trong hệ thống phân cấp view, thay vì dismiss ViewController đầu.

Bắt đầu với iOS 7, Interface Builder đã cung cấp cho bạn những cách để “unwind” navigation stack.

exit

Unwind segue cho phép bạn chỉ định điểm đến để quay trở lại màn hình trước đó. Nghe có vẻ đơn giản nhưng trong thực tế nó đòi hỏi một số bước và chỉ gây bối rối cho các developer:

  • Bình thường, khi bạn tạo ra một action/outlet cho một button, Interface Builder sẽ tạo code cho bạn. Trong trường hợp này, Ctrl-kéo thả từ button tới “Exit” outlet.
  • Bình thường, khi bạn tạo ra một action/outlet cho một button, nó sẽ đặt code trong class cùng sở hữu các button. Đối với Unwind Segues, bạn cần phải viết code trong destination view controller.
  • prepareForUnwind method có tất cả các nhược điểm của phương pháp prepareForSegue (xem những lời khuyên trước).

Cách dễ dàng hơn là gì?

Sẽ rất đơn giản để làm điều đó trong code: thay vì tạo ra một hành động “unwind” cho button của bạn, tạo ra một IBAction bình thường và sử dụng dismissViewController hoặc popViewController (tùy thuộc vào cấu trúc điều khiển của bạn):

Nguồn IDE Academy via medium.com