Advanced iOS App Architecture First edition Real-world app architecture in Swift 5 (Rene Cacheaux, Josh Berlin) (Z-Library)

Author: Rene Cacheaux, Josh Berlin

商业

No Description

📄 File Format: PDF
💾 File Size: 2.2 MB
20
Views
0
Downloads
0.00
Total Donations

📄 Text Preview (First 20 pages)

ℹ️

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1
(This page has no text content)
📄 Page 2
Advanced iOS App Architecture By René Cacheaux & Josh Berlin Copyright ©2019 Razeware LLC. Notice of Rights All rights reserved. No part of this book or corresponding materials (such as text, images, or source code) may be reproduced or distributed by any means without prior written permission of the copyright owner. Notice of Liability This book and all corresponding materials (such as source code) are provided on an “as is” basis, without warranty of any kind, express of implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in action of contract, tort or otherwise, arising from, out of or in connection with the software or the use of other dealing in the software. Trademarks All trademarks and registered trademarks appearing in this book are the property of their own respective owners. Advanced iOS App Architecture raywenderlich.com 2
📄 Page 3
Dedications "To my beautiful wife Lauren, to my fun-loving angel Zara, to my soon-to-arrive son René Jr., to my parents who have given me everything, and, last but not least, to my furry pals Paco and Charlie. I love you all." — René Cacheaux "Thanks to my parents for buying me my first, second, and third computers, and making me put them together myself. Thanks for allowing me to take any path I wanted in life, even when it’s a little crazy. Love y'all." — Josh Berlin Advanced iOS App Architecture raywenderlich.com 3
📄 Page 4
About the Authors Josh Berlin is an author of this book. He loves building thoughtful user experiences on mobile. He’s currently an iOS engineer at Cruise Automation making apps for self-driving cars. He's built apps for the iPhone and iPad since 2008. Josh recently finished culinary school in Austin, TX. When he's not coding, he's probably cooking or dreaming of food. René Cacheaux is an author of this book. He loves to architect and build software. He currently is a Mobile Architect at Atlassian where his mission is to design Atlassian's mobile platform. He especially loves all things mobile and currently architects for both Android and Apple platforms. René has been engineering iOS apps since 2009 and has experience in mobile client and server engineering, mobile user experience design and product management. René has worked on a wide range of apps spanning from industrial sales enablement to world-wide social networking. René enjoys starting his days in true Austin-Texas fashion with a a breakfast taco alongside a freshly brewed cappuccino. In addition to building mobile apps, he loves to travel, snow ski, ocean kayak and root for his alma mater, the Texas Longhorns. About the Editors Aaron Douglas is a tech editor for this book. He was that kid taking apart the mechanical and electrical appliances at five years of age to see how they worked. He never grew out of that core interest - to know how things work. He took an early interest in computer programming, figuring out how to get past security to be able to play games on his dad's computer. He's still that feisty nerd, but at least now he gets paid to do it. Aaron works for Automattic (WordPress.com, WooCommerce, SimpleNote) as a Mobile Lead primarily on the WooCommerce mobile apps. Find Aaron on Twitter as @astralbodies or at his blog at https://aaron.blog. Advanced iOS App Architecture raywenderlich.com 4
📄 Page 5
Joshua Greene is a tech editor for this book. He is an experienced iOS developer who loves creating elegant apps. When he's not slinging code, he enjoys martial arts, Netflix and spending time with his wonderful wife and two daughters. You can reach him on Twitter at @jrg_developer. Manda Frederick is an editor of this book. She has been involved in publishing for over ten years through various creative, educational, medical and technical print and digital publications, and is thrilled to bring her experience to the raywenderlich.com family as Managing Editor. In her free time, you can find her at the climbing gym, backpacking in the backcountry, hanging with her dog, working on poems, playing guitar and exploring breweries. Darren Ferguson is the final pass editor for this book. He's an experienced software developer and works for M.C. Dean, Inc, a systems integration provider from North Virginia. When he's not coding, you'll find him enjoying EPL Football, traveling as much as possible and spending time with his wife and daughter. Find Darren on Twitter at @darren102. About the Artist Vicki Wenderlich is the designer and artist of the cover of this book. She is Ray’s wife and business partner. She is a digital artist who creates illustrations, game art and a lot of other art or design work for the tutorials and books on raywenderlich.com. When she’s not making art, she loves hiking, a good glass of wine and attempting to create the perfect cheese plate. Advanced iOS App Architecture raywenderlich.com 5
📄 Page 6
Table of Contents: Overview What You Need 10........................................................ Book License 11............................................................ Book Source Code & Forums 12................................... About the Cover 13....................................................... Chapter 1: Welcome 14................................................. Chapter 2: Which Architecture Is Right for Me? 16....... Chapter 3: Example App: Koober 34............................ Chapter 4: Objects & Their Dependencies 47.............. Chapter 5: Architecture: MVVM 115............................. Chapter 6: Architecture: Redux 167.............................. Chapter 7: Architecture: Elements, Part 1 212............... Chapter 8: Architecture: Elements, Part 2 233............. Conclusion 297............................................................ Advanced iOS App Architecture raywenderlich.com 6
📄 Page 7
Table of Contents: Extended What You Need 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Book License 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Book Source Code & Forums 12. . . . . . . . . . . . . . . . . . . . . . About the Cover 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 1: Welcome 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What lies ahead 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Who this book is for 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where to go from here? 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2: Which Architecture Is Right for Me? 16. . . . . Identifying problems to solve 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Boosting team velocity and strengthening code quality 17. . . . . . . . . . . Examining the problems 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Increasing code agility 26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Surveying architecture patterns 29. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting a pattern 31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Putting patterns into practice 32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key points 33. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 3: Example App: Koober 34. . . . . . . . . . . . . . . . . Koober 34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Why Koober? 41. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting started with the source 41. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key points 46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 4: Objects & Their Dependencies 47. . . . . . . . . Establishing the goals 47. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Learning the lingo 48. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating dependencies 51. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The fundamental considerations 52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced iOS App Architecture raywenderlich.com 7
📄 Page 8
Why is this architecture? 53. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dependency patterns 54. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dependency Injection 55. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . On-demand approach 59. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Factories approach 61. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Single-container approach 67. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Designing container hierarchies 69. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applying DI theory to iOS apps 74. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applying the on-demand approach 82. . . . . . . . . . . . . . . . . . . . . . . . . . . Applying the factories approach 88. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applying the single-container approach 100. . . . . . . . . . . . . . . . . . . . . . Applying the container hierarchy approach 107. . . . . . . . . . . . . . . . . . . . Key points 113. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where to go from here? 114. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 5: Architecture: MVVM 115. . . . . . . . . . . . . . . . . . What is it? 116. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Container views 122. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communicating amongst view models 124. . . . . . . . . . . . . . . . . . . . . . . . Navigating 125. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applying theory to iOS apps 128. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Composing views 139. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Navigating 148. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing state 159. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key points 164. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pros and cons of MVVM 164. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where to go from here? 166. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 6: Architecture: Redux 167. . . . . . . . . . . . . . . . . . History 167. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What is Redux? 168. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applying theory to iOS apps 179. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key points 209. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pros and cons of Redux 209. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where to go from here? 211. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced iOS App Architecture raywenderlich.com 8
📄 Page 9
Chapter 7: Architecture: Elements, Part 1 212. . . . . . . . . Introducing Elements 213. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Underlying concepts of Elements 214. . . . . . . . . . . . . . . . . . . . . . . . . . . . User interface 218. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interaction responder 226. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key points 232. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 8: Architecture: Elements, Part 2 233. . . . . . . . Observer 233. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use case 266. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pros and cons of Elements 295. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key points 296. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion 297. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced iOS App Architecture raywenderlich.com 9
📄 Page 10
WWhat You Need To follow along with this book, you'll need the following: • A Mac running macOS Mojave (10.14.3) or later. • Swift 5: all projects have been written to work with Swift 5 in Xcode. • Xcode 10.2 or later. You'll need Xcode 10.2 or later to open and run the example apps included in this book. If you haven't installed the latest version of macOS or Xcode, be sure to do that before continuing with the book. The code covered in this book depends on Swift 5 and Xcode 10.2. This book provides the building blocks for developers who wish to broaden their horizons and learn how architectures can help them build robust and maintainable applications and SDKs. The only prerequisites for this book are an intermediate understanding of Swift and iOS development. If you’ve worked through our classic beginner books — Swift Apprentice https://store.raywenderlich.com/products/swift-apprentice and iOS Apprentice https:// store.raywenderlich.com/products/ios-apprentice — or have similar development experience, you’re ready to read this book. As you work through the book, you’ll be taken through a deep dive into different architectures for a fictional app named Koober. Each chapter will explain the theory behind each of the architectures first. The second half of the chapters will guide you through how the Koober application utilized the architecture and show you how the architecture was used within the application. raywenderlich.com 10
📄 Page 11
LBook License By purchasing Advanced iOS App Architecture, you have the following license: • You are allowed to use and/or modify the source code in Advanced iOS App Architecture in as many apps as you want, with no attribution required. • You are allowed to use and/or modify all art, images and designs that are included in Advanced iOS App Architecture in as many apps as you want, but must include this attribution line somewhere inside your app: “Artwork/images/designs: from Advanced iOS App Architecture, available at www.raywenderlich.com”. • The source code included in Advanced iOS App Architecturer is for your personal use only. You are NOT allowed to distribute or sell the source code in Advanced iOS App Architecture without prior authorization. • This book is for your personal use only. You are NOT allowed to sell this book without prior authorization, or distribute it to friends, coworkers or students; they would need to purchase their own copies. All materials provided with this book are provided on an “as is” basis, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software. All trademarks and registered trademarks appearing in this guide are the properties of their respective owners. raywenderlich.com 11
📄 Page 12
BBook Source Code & Forums This book comes with the source code for the example apps for each chapter. These resources are shipped with the digital edition you downloaded from store.raywenderlich.com. We’ve also set up an official forum for the book at forums.raywenderlich.com. This is a great place to ask questions about the book or to submit any errors you may find. raywenderlich.com 12
📄 Page 13
AAbout the Cover Although pufferfish look like the cutest little squeezable stress balls in the sea, they’re nothing you would ever want to cuddle up next to. Most pufferfish contain toxins to protect themselves from predators; one pufferfish alone can contain enough toxin to kill 30 humans — with no known antidote. James Bond knows this all too well. But we didn’t feature the pufferfish because learning about advanced architecture is toxic; rather, pufferfish are one of nature’s great architects. During spawning season, using nothing but their fins, male pufferfish create stunning geometric patterns in the sand on the seabed as potential nesting sites for females. These structures can be up to seven feet in diameter and take the males anywhere from seven to nine days to build. It’s not certain if the structure serves to attract the females, or if the females are simply drawn to the soft sand the male stirred up in the process. So when you’re getting frustrated with Xcode or Swift, just be thankful that you have better tools to architect with than a pair of fins! For an extra-cool view on how the male pufferfish architects his “software,” check out this video: https://www.youtube.com/watch?v=p1PID91sEW8. raywenderlich.com 13
📄 Page 14
1Chapter 1: Welcome Welcome to Advanced iOS App Architecture. The main goal of this book is to thoroughly explain and show how to apply popular iOS app architectures, one by one. We can’t wait for you to explore the architectures covered in the following chapters. We absolutely love this topic. We are super passionate about architecture because architecture unlocks the ability for teams to grow and go quickly. Now, more than ever, it’s very important to understand and apply good software architecture practices in our projects as apps are getting more complex and as development teams are pressured to deliver faster results despite constantly changing requirements. What lies ahead Chapter 1 through Chapter 4 introduce you to different aspects of the material covered in the book. We recommend reading these chapters before diving into any of the architecture chapters. Chapter 5 through Chapter 7 are architecture chapters; in other words, they explore one architecture at a time. Each architecture chapter begins with a little history followed by a detailed theory walkthrough. The second half of each architecture chapter focuses on applying the theory to iOS app development. Each architecture chapter ends by covering the pros and cons of that architecture. Feel free to read these latter chapters in any order. There are many architectures not covered in this book because we wanted to go deep instead of broad; however, we plan to add more architectures in future editions of this book. raywenderlich.com 14
📄 Page 15
Who this book is for This book is for iOS developers who build apps using Swift. The material in this book assumes familiarity with design patterns and with basic architectures — such as MVC — and basic architecture concepts, such as inversion of control. If you’re new to Swift, check out the raywenderlich.com Swift Apprentice book; for a refresher on design patterns, check out the raywenderlich.com Design Patterns by Tutorials. Where to go from here? The next three chapters are designed to be introductions, so give them a read. Then, find the chapters for the architectures you are most interested in learning and go for a deep dive into each. If you aren’t sure which architectures you’d like to explore, we recommend reading the theory section of all the architecture chapters first in order to identify which architectures fit your needs the most. Then you can take a deep dive by reading the iOS app portion of the chapters you found most compelling. Our hope is that, after reading this book, you will be able to apply different app architectures to different projects in a way that will unleash your team’s ability to build quickly and soundly. Happy architecting! Advanced iOS App Architecture Chapter 1: Welcome raywenderlich.com 15
📄 Page 16
2Chapter 2: Which Architecture Is Right for Me? By René Cacheaux You might be wondering: Which architecture pattern is right for me? Honestly, there's no perfect universal app architecture. An architecture that works best for one project might not work best for your project. There are many different aspects to consider when establishing an architecture for you and your team to follow. This chapter guides you through the process of finding the best architecture for your project. There's a lot that goes into shaping your app's codebase into a cohesive and effective architecture. Knowing where to start can especially be overwhelming. Every single file in your app's codebase plays a part in your app's architecture. There's no shortage of architecture patterns. Unfortunately, most patterns only scratch the surface and leave you to figure out the fine details. In addition, many patterns are similar to one another and have only minor differences here and there. All of this makes architecture hard to put into practice. Fortunately, there are pragmatic steps you can take to ensure your architecture is effective: 1. Understand the current state of your codebase. 2. Identify problems you'd like to solve or code you'd like to improve. 3. Evaluate different architecture patterns. 4. Try a couple patterns on for size before committing to one. 5. Draw a line in the sand and define your app's baseline architecture. 6. Look back and determine if your architecture is effectively addressing the problems you want to solve. 7. Iterate and evolve your app’s architecture over time. raywenderlich.com 16
📄 Page 17
Notice how selecting an architecture pattern isn't the first item on the list. The reality is that selecting an architecture pattern is less important than understanding the the problems you're trying to solve using architectural patterns. Taking the time to understand the problems you want to solve allows you to focus on the few aspects of architecture that really make a difference. While many problems will be specific to your project, there are several general problems you can solve through good architecture. The next several sections cover these general problems in detail. Identifying problems to solve Before embarking on any architecture project, you should first identify and understand the problems you'd like to solve. This will allow you to evaluate whether you're getting the most out of your app's architecture. A good architecture enables you and your team to easily and safely change code without a ton of risk. Making changes to code in a codebase that is not architected well is expensive and risky. The two primary problems that good architecture practices solve are slow team velocity and fragile code quality. Additionally, good architecture practices can help you prevent rigid software. The next sections cover these two primary problems followed by a section that covers rigid software. Boosting team velocity and strengthening code quality A good app architecture enables you to deliver features and bug fixes faster without compromising on quality. On the other hand, a less-than-ideal architecture slows your team down and makes your codebase very difficult to change without breaking existing functionality. Knowing this, what problems should you be looking for? Which problems can architecture solve? Here are several problems that, when present, lead to slow velocity and fragile code quality: • My app's codebase is hard to understand. • Changing my app's codebase sometimes causes regressions. • My app exhibits fragile behavior when running. • My code is hard to re-use. • Changes require large code refactors. Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me? raywenderlich.com 17
📄 Page 18
• My teammates step on each other's toes. • My app's codebase is hard to unit test. • My team has a hard time breaking user stories into tasks. • My app takes a long time to compile. You can solve these problems by applying architecture concepts. All of these problems have common root causes. Walking through some of the root causes will help set the stage for studying each of these problems in detail. Understanding root causes Each of these problems can be caused by two fundamental root causes: highly interdependent code and large types. Understanding these root causes is important when creating a plan for boosting team velocity and strengthening code quality. So what exactly are these root causes, and how do you know if they've made it into your codebase? That's next. Highly interdependent code A typical codebase has a ton of interdependencies and connections amongst variables, objects and types. Code becomes highly interdependent when code in one type reaches out to other concrete, i.e., non-protocol, types. Types usually reach out to other types in order to read-write state or in order to call methods. Making one part of your code depend on another is extremely easy. This is especially true when a codebase has a lot of visible global objects. Without properly encapsulating your code, your interdependencies can run rampant! The more you tightly couple parts of your codebase, the more likely something unexpectedly breaks when making code changes. This is further complicated by large teams with multiple developers because everyone needs to fully understand the interdependencies, which on very large teams may be an impossible task. Large types Large types are classes, structs, protocols and enums that have long public interfaces due to having many public methods and/or properties. They also have very long implementations, often hundreds or even thousands of lines of code. Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me? raywenderlich.com 18
📄 Page 19
Adding code to an existing type is much easier than coming up with a new type. When creating a new type, you have to think about so many things: What should the type be responsible for? How long should instances of this type live for? Should any existing code be moved to this type? What if this new type needs access to state held by another type? Designing object-oriented systems takes time. When you're under pressure to deliver a feature making this tradeoff can be difficult. The opportunity cost is hard to see. The thing is, many problems are caused by large types – problems that will slow you down and problems that will affect your code's quality. You'll read about examples of these consequences in the following sections. For now, just know that breaking large types into smaller types is a great way to improve your codebase's architecture. Now that you're familiar with the root causes, you're ready to dig into the problems that can cause slow team velocity and fragile code quality. Examining the problems If you're looking to boost your team's velocity and to strengthen your code's quality, addressing the root causes is a good start. But you might be wondering how the root causes affect team velocity and code quality. Note: As you read the upcoming sections, keep in mind that highly interdependent code and large types are just the common root causes. You'll see these common root causes in almost all the problem sections below. However, you'll also read about other, problem-specific, root causes. With that in mind, it's time to examine the problems associated with team velocity and code quality. My app's codebase is hard to understand Have you ever spent hours trying to figure out how a view controller works? Code is inherently difficult to understand because code is textual. The connections between files and types are hard to see. Having a solid understanding of how parts in your codebase are connected really helps you reason about how your code works. Therefore, the way an app is architected plays a huge role in the ease of code readability. Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me? raywenderlich.com 19
📄 Page 20
There are several ways in which architecture can impact readability: How long are your class implementations? 600 line view controllers are very difficult to understand. If all you need to know is how a button functions, fishing through 600 lines of view controller code will take a lot of valuable time. A good architecture breaks large chunks of code into small, modular pieces that are easy to read and understand. The more an architecture encourages locally encapsulated behavior and state, the easier the code will be to read. Think about the current app you're working on. If a new team member joins your team tomorrow and needs to understand a single view controller, what percentage of the app's overall codebase will that developer need to understand? This is a good gauge to use when evaluating how much your architecture is helping improve your code's readability. Unfortunately, most architecture patterns don't emphasize this point enough. The good news is that this practice can be applied to pretty much any architecture pattern. So this is more of a universal aspect of architecture. How many global variables does your codebase have, and how many objects are instantiated directly in another object? The more your objects directly depend on each other and the more your objects depend on global state, the less information a developer will have when reading a single file. This makes it incredibly difficult to know how a change in a file might affect code living in another file. This forces developers to Command-click into tons of files in order to piece together the control flow. This takes a lot of time. Similar to class size, carefully managing dependencies is unfortunately not emphasized enough by popular architecture patterns. Carefully managing dependencies is a universal aspect that can be applied to any architecture pattern. In fact, we apply this aspect to every architecture code example that ships with this book. We also dedicated a whole chapter to this. You can read more about managing dependencies in Chapter 4. How differently are your view controllers implemented across your app's codebase? Developers, including your future self, will spend a lot of time figuring things out if different features are implemented using different architecture patterns. Human brains are amazing at identifying patterns. You can take advantage of this ability by ensuring your codebase follows similar architecture patterns throughout. Having a consistent structure drastically reduces the cognitive overhead required to understand code. In turn, developers will feel more comfortable changing and improving older parts of an app's codebase because they'll understand the common patterns. Advanced iOS App Architecture Chapter 2: Which Architecture Is Right for Me? raywenderlich.com 20
The above is a preview of the first 20 pages. Register to read the complete e-book.

💝 Support Author

0.00
Total Amount (¥)
0
Donation Count

Login to support the author

Login Now
Back to List