Việc xây dựng một hệ thống thiết kế để hỗ trợ một sản phẩm không phải là điều dễ dàng - nó phải mạnh mẽ và linh hoạt đồng thời để có khả năng mở rộng. Mặc dù đầy thách thức nhưng rất nhiều nguồn tài nguyên tuyệt vời đã chia sẻ các nguyên tắc và cách tiếp cận hữu ích giúp các nhóm xây dựng một hệ thống tốt cả về mặt trực quan và chương trình. Đứng trên vai của họ, bài viết này cố gắng đóng góp vào một nền đất hoang sơ bằng cách tập trung vào việc xây dựng một hệ thống tốt trong SwiftUI .
Tại sao tôi viết bài này
Trong mùa hè đầu tiên của tôi tại ITP tại New York, tôi may mắn có cơ hội làm việc với tư cách là một thực tập sinh nhà phát triển iOS tại Line Break Studio. Một nhiệm vụ mà tôi được giao là xây dựng hệ thống thiết kế theo hai bước:đầu tiên là trực quan trong Sketch, sau đó lập trình trong SwiftUI . Trải nghiệm thử nghiệm với khung công tác mới và xây dựng hệ thống thiết kế với nó thật tuyệt vời, nhưng cũng có nhiều lỗi trong quá trình thực hiện. Đó là lý do tại sao chúng tôi muốn chia sẻ kinh nghiệm của mình với cộng đồng, hy vọng sẽ giúp quá trình phát triển của bạn dễ dàng hơn.
SwiftUI là gì
Apple đã phát hành khuôn khổ mới đột phá này trong WWDC 2019, đây là một trong những khuôn khổ tốt nhất trong nhiều năm. Từ quan điểm của một nhà phát triển web, kinh nghiệm phát triển dự án trong SwiftUI gần hơn với điều này trong khuôn khổ và ngăn xếp front-end thông thường.
Đây chắc chắn là một động thái tuyệt vời vì giao diện lập trình và quản lý trạng thái dễ dàng hơn trước rất nhiều. Và phần tốt nhất của cải tiến này là người ta có thể tích hợp UIKit và SwiftUI một cách trơn tru. Để tìm hiểu những điều cơ bản về SwiftUI, các hướng dẫn chính thức do Apple cung cấp rất hữu ích.
Dự án demo
Với mục đích trình diễn, tôi đã đưa ra một phiên bản đơn giản hóa của hệ thống thiết kế mà chúng tôi đã xây dựng trong Line Break Studio. Đó là một tập hợp của nút các thành phần ở các dạng khác nhau, được xây dựng dựa trên hai phần cấp thấp hơn: kiểu chữ và colorPalette .
Dự án được công khai trên GitHub và tôi đang sử dụng Xcode 11 Beta 5 cho sự phát triển. Cơ sở Airtable làm trung tâm quản lý hệ thống thiết kế (đọc thêm về quản lý quy trình làm việc) cũng được công khai để tham khảo.
Nguyên tắc xây dựng hệ thống thiết kế
Hệ thống thiết kế trong mã là phần mềm trung gian giữa nhà thiết kế và nhà phát triển. Nhà phát triển hệ thống lấy đầu vào từ hệ thống thiết kế ở dạng trực quan và tạo ra API giống hệt với API để phát triển thêm. Cần thừa nhận hai nguyên tắc sau để hoàn thiện hệ thống này trong mã:
1. Giao tiếp với mã thông báo
Về cơ bản, mục đích của việc có một hệ thống thiết kế trong chương trình không phải là để quản lý mã tốt hơn hoặc hiệu quả phát triển, mà là để đảm bảo chế độ xem phù hợp với tệp thiết kế. Để đạt được mục tiêu đó, việc sử dụng mã thông báo để biểu thị màu sắc, phông chữ, kích thước nhất định hoặc bất kỳ yếu tố hình ảnh nào là rất quan trọng để duy trì chất lượng giao tiếp giữa các nhà phát triển, nhà thiết kế và người quản lý trong một nhóm.
2. Các cấp độ của hệ thống phân cấp
Trong bài viết của EightShapes, nó chỉ ra rằng chúng ta nên "Hiển thị các tùy chọn trước, sau đó quyết định tiếp theo", bởi vì "Bạn không thể đưa ra quyết định mà không có các tùy chọn."
Loại kiến trúc thứ tự này nới lỏng mức độ kết hợp giữa các cấp độ khác nhau, do đó cung cấp tính linh hoạt và năng động hơn cho các bản sửa đổi có thể. Cách tôi cấu trúc các cấp theo thứ tự từ dưới lên trên:material → base → token. Nhưng dù sao thì điều đó cũng có thể khiến cả nhóm cảm thấy thoải mái.
Đang tìm hiểu về mã
Phần sau là danh sách những điểm nổi bật mà chúng tôi muốn chỉ ra dựa trên kinh nghiệm của chúng tôi. Vui lòng truy cập repo GitHub để biết mã hoàn chỉnh. Mọi phản hồi hoặc phê bình đều được hoan nghênh để cải thiện.
1. Kiến trúc các cấp độ của hệ thống phân cấp
Có hai cách xếp chồng vật liệu ở cấp thấp hơn để tạo mã thông báo ở cấp cao nhất:
- Sử dụng
enumđể đảm bảo an toàn cho loại và hiểu biết về mã
Ưu điểm của việc sử dụng enum trong mã như trình bao bọc nhóm hoặc tham số trong hàm đã được công nhận rõ ràng. Một điểm đáng nói ở đây là việc thực hiện các cấp độ của hệ thống phân cấp.
Chúng tôi luôn lưu trữ các giá trị thô, bao gồm cả kích thước phông chữ (CGFloat ) và tên phông chữ (String ), ở mức thấp nhất, bởi vì chúng tôi không muốn gây rối với nó. Nhưng vì giá trị thô phải là một ký tự trong enum, chúng ta không thể chỉ định một case là một giá trị từ enum khác.
Để khắc phục sự cố này, chúng tôi triển khai một hàm getValue , trả về giá trị thô trong switch trường hợp cần thiết.
- Sử dụng
structđể có cấu trúc dễ dàng hơn
Mặc dù enum rất tuyệt, nhưng chúng ta không cần tính năng độc đáo của nó trong một số trường hợp. Ví dụ:bởi vì Xcode đảm nhận công việc nặng nhọc là xử lý màu động và không yêu cầu tùy chọn tham số trong điểm cuối API, chúng tôi có thể thiết lập bảng màu theo hai cấp cấu trúc đơn giản.
2. Đặt tên rõ ràng và dễ hiểu của API điểm cuối
Quy ước đặt tên là một chủ đề rộng lớn khác để thảo luận và tranh luận. Ngoài các quy ước Swift cơ bản, hai quy tắc duy nhất mà chúng tôi tuân thủ là 1) không có từ viết tắt và 2) làm cho nó trở nên đơn giản. Ví dụ:để sử dụng kiểu chữ và hệ thống màu, thay vì tạo các điểm cuối mới, chúng tôi tạo phần mở rộng từ cấu trúc Phông chữ và Màu sắc. Cách tiếp cận này làm giảm nỗ lực ghi nhớ các tên API không quen thuộc đối với các nhà phát triển.
3. Quản lý động các bộ màu ở hai chế độ
Vì vậy, chế độ tối đã trở thành một tiêu chuẩn trong ngành và cả nhóm iOS và Android đều đã triển khai tính năng này. Đó là một xu hướng tốt cho người dùng, nhưng có thể mang lại cho các nhà thiết kế và nhà phát triển một số thách thức, bao gồm việc quản lý và đặt tên cho các bộ màu, đặc biệt là các bộ màu xám.
Để suy nghĩ và giao tiếp về các màu thang xám một cách linh hoạt, hãy sử dụng các thuật ngữ như trắng , ánh sáng , đen hoặc tối không hoạt động. Bởi vì nếu chúng ta đề cập đến một màu động #000000 (đen trong HEX) đen hoặc tối trong light color scheme , làm thế nào để bạn nói về màu cụ thể này, màu này sẽ chuyển thành #FFFFFF (màu trắng trong HEX), trong dark color scheme ? defaultDark hoặc lightDark ?
Rất khó hiểu khi đặt tên cho các tập hợp màu động thang xám theo cách tiếp cận thông thường. Để tránh nhầm lẫn này, chúng tôi sử dụng theme và contrast để quản lý một tập hợp màu trong light và dark các chương trình thay thế.
Lưu ý rằng không phải lúc nào cũng cần đảo ngược màu thang xám ở chế độ màu đối lập. Trong những trường hợp này mà màu sáng vẫn sáng và màu tối vẫn tối, chúng tôi chỉ cần đặt tên là màu sáng hoặc màu tối.
Sau khi chúng tôi tìm hiểu về phương pháp đặt tên này, việc quản lý kiến trúc bảng màu này thật dễ dàng trong Xcode . Để tạo tập hợp màu, chỉ cần tạo Asset Catalog mới tệp → thêm một Color Set mới → và thay đổi Appearances thành Any, Light, Dark sẽ làm.
4. environment cài đặt
Một tính năng tuyệt vời trong khung làm việc SwiftUI là công cụ sửa đổi môi trường, cung cấp khả năng kiểm soát các giá trị môi trường trên chế độ xem mục tiêu. Về hệ thống thiết kế xây dựng, khả năng này cung cấp cách tiếp cận thuận tiện để thay đổi phông chữ của ứng dụng ở cấp cơ sở. Và lợi thế khác của việc sử dụng environmentValue là thay đổi và thử nghiệm các phối màu sáng và tối đang được phát triển.
5. buttonStyle và nhãn nút
So với ngày xưa trong UIKit, việc xây dựng các nút có thể sử dụng lại trong SwiftUI dễ dàng hơn đáng kể. Chế độ xem Nút bao gồm hai phần, đó là action đóng cửa (sự kiện được kích hoạt khi nút được nhấn) và label (phần thân của nút). Sau đó, chế độ xem có thể được xâu chuỗi bằng một công cụ sửa đổi buttonStyle . Để tìm hiểu chi tiết về cách xây dựng các nút có thể sử dụng lại, tôi khuyên bạn nên đọc hướng dẫn của Alejandro, hướng dẫn này toàn diện và hữu ích.
Trong các thành phần nút tùy chỉnh của chúng tôi, bước đầu tiên là tạo hai cấu trúc, bao gồm TokenButtonLabel và TokenButtonStyle . Hai cấu trúc này được lập trình theo các loại nút mà chúng ta có trong tệp thiết kế. Ví dụ:chỉ có hai loại nhãn:biểu tượng và văn bản. Mỗi loại có một init theo chức năng được thiết kế với các tham số khác nhau cho các phiên bản mới.
Mặt khác, có bốn loại kiểu nút chính:biểu tượng hình tròn, biểu tượng, viên nén và văn bản. Để theo dõi ButtonStyle giao thức, một makeBody func phải được thực hiện. Hàm này mang lại cho chúng ta configuration , cung cấp một isPressed gốc giá trị để theo dõi xem nút có được nhấn hay không.
Cuối cùng, xếp chồng lên trên TokenButtonLabel và TokenButtonStyle , điểm cuối của API thành phần nút sẽ là TokenButton - một nhóm bao bọc nội dung và kiểu nút lại với nhau, phù hợp với các loại nút trong hệ thống thiết kế trực quan.
6. AnyView dưới dạng trình bao bọc
Khi chúng tôi xử lý makeBody chức năng do ButtonStyle mang lại , chúng tôi đã tìm thấy một mẹo hữu ích để làm việc với View . Để lưu chế độ xem trong một biến, chú thích loại có thể được chỉ định là AnyView , hoạt động như một vùng chứa các chế độ xem chung trong SwiftUI.
Trong trường hợp của chúng tôi, vì chúng tôi muốn thêm công cụ sửa đổi độ mờ vào configuration.label cho tất cả các loại nút, thay vì làm như vậy nhiều lần trong mỗi switch trường hợp, sẽ có ý nghĩa hơn khi xâu chuỗi công cụ sửa đổi vào cuối hoàn toàn. Chúng ta có thể đạt được mô hình này bằng cách sử dụng lợi thế của AnyView theo cách này:
7. Xây dựng công cụ sửa đổi chế độ xem với mutating chức năng
Để cập nhật động kiểu của các nút, chúng ta có thể xây dựng công cụ sửa đổi của riêng mình. Đầu tiên khởi tạo các thuộc tính trạng thái có thể thay đổi được tùy chỉnh trong chế độ xem, sau đó tạo mutating hàm trả về Self nhập sau khi cập nhật thuộc tính trạng thái đích.
8. Kiểu đường viền phức tạp
Một nhược điểm của SwiftUI là kiểu dáng hình tròn với đường viền tròn không đơn giản chút nào. Tôi đã vật lộn trong một thời gian và cuối cùng đã tìm ra giải pháp ở đây trên StackOverflow. A clipShape và một overlay cần có công cụ sửa đổi để làm cho nó hoạt động.
Kết luận
SwiftUI là một cải tiến đáng kinh ngạc của Apple. Mặc dù vẫn còn tồn tại những sai sót, nhưng việc xây dựng một hệ thống thiết kế linh hoạt và mạnh mẽ với nó, và hơn nữa giao diện người dùng phức tạp trong iOS là cách hiệu quả hơn bao giờ hết. Tôi hy vọng bài viết này hữu ích cho bất kỳ nhóm iOS nào đang cố gắng xây dựng giao diện người dùng và luôn hoan nghênh mọi phản hồi!
? Đọc thêm các tác phẩm của tôi tại vcityhao.com / Theo dõi tôi trên Twitter hoặc LinkedIn