1.3 Common challenges for mobile engineers

1.3.1 Rapidly changing environment

1.7 What this book is not

1.7.1 This book is not a traditional programming book

1.11 How this book works

1.11.1 A strong focus on building the right things

1.12 The chapters

1.12.1 Chapter 1: About this book

1.12.2 Chapter 2: Turning a briefing into a strong plan

1.12.3 Chapter 3: Holistic-Driven Development; Turning a plan into code

1.12.4 Chapter 4: System-wide testing; Delivering higher quality apps

1.12.5 Chapter 5: Cross-domain testing; Testing more with less effort

1.12.6 Chapter 6: Dependency injection foundations

1.12.7 Chapter 7: Sane dependency injection without fancy frameworks

1.12.8 Chapter 8: Dependency Injection on a larger scale

1.12.9 Chapter 9: UI frameworks, architectures, and supporting multiple products

1.12.10 Chapter 10: Delivering reusable views; The art of decomposing a design

1.12.11 Chapter 11: Reasoning about Views, Components, Screens, and Bindings

1.12.12 Chapter 12: Pragmatically implementing UI

1.12.13 Chapter 13: Delivering self-sufficient features, part I: The art of staying nimble

1.12.14 Chapter 14: Delivering self-sufficient features, part II; Self-loading features

1.12.15 Chapter 15: Delivering self-sufficient features, part III; Making features portable

1.12.16 Chapter 16: Reusing views across flows

1.12.17 Upcoming chapters

2.1 The briefing

2.1.1 An initial impression

2.2 2. Evaluating common approaches

2.2.1 Start with UI?

2.2.2 A data-focused approach?

2.2.3 Creating an app-skeleton or flow-skeleton?

2.2.4 Starting by making components or features?

2.2.5 Drawing a diagram?

2.2.6 Decide on an architecture?

2.2.7 A recommended approach

2.3 3. Sketching out a landscape

2.3.1 Everything is connected to a course

2.3.2 How far do we decompose?

2.5 5. Working with Designers; Getting secondary features

2.5.1 Whether or not a design is the law

2.5.2 What is “pixel perfect”, really?

2.5.3 Designs often encompass best-case scenarios

2.5.4 Not everything has equal priority

2.5.5 Verify the existence of pre-existing components

2.5.6 Ask general UI questions

2.5.7 Ask functionality-related questions

2.5.8 Talk about error handling

2.5.9 Talk about time-investments and start thinking in a less binary fashion

2.5.10 Giving feedback to the designer

2.5.11 Updating the landscape

2.5.12 A fast app is key

2.5.13 Scheduler

2.5.14 Deep Linking

2.6 6. Aligning with backend engineers

2.6.1 Align on about User sessions, environments, tokens, and timeouts

2.6.2 Align on consolidating network calls

2.6.3 Be on the same page with errors

2.6.4 It’s okay to deviate from backend custom error codes

2.6.5 You might be the backend guinea-pig

2.6.6 Read code from other client implementations

2.6.7 Consider push notifications

2.6.8 Feature-specific questions

2.6.9 Updating the landscape with backend requirements

3.5 Implementing the Course domain

3.5.1 Course and Tutor

3.5.2 TODOItem

3.5.3 Placeholder values

3.5.4 Modeling CalendarEvent

3.5.5 Defining CourseAPI

3.6 The Store component

3.6.1 Starting from the call-site of CourseAPI

3.6.2 The Store implementation

3.6.3 Designing the get() method signature

3.6.4 Implementing the get() method

3.6.5 Store is implemented naïvely on purpose

3.6.6 Placeholder implementations lower priorities

3.6.7 Trade-offs when making a component reusable

3.8 Focusing on UI vs other implementations

3.8.1 Focusing on UI

3.8.2 Going deeper

3.8.3 A team setting

3.9 Implementing on a deeper level

3.9.1 Defining new types

3.9.2 Optimizing CourseAPI

3.11 Reflecting on holistic driven development

3.11.1 Holistic-Driven Development brings confidence to move forward

3.11.2 Lightweight restructuring

3.11.3 Context switching and delegation

3.11.4 Top-down versus bottom-up

3.11.5 We delay writing tests

3.11.6 Why we don't design with interfaces or protocols instead

3.11.7 A note on placeholders

4.2 Damage control and damage prevention

4.2.1 Damage control

4.3 Mocking higher in the stack

4.3.1 Isolating VideoClient

4.3.2 Introducing mocks

4.3.3 Setting up a testing environment

4.3.4 Downsides of mocking higher in the stack

4.4 Mocking lower in the stack

4.4.1 Finding the smallest surface to mock out

4.4.2 Setting up the API dependency

4.4.3 Trade-offs

4.4.4 Mocking for expensive operations

4.4.5 Accepting a closure as a dependency

4.4.6 The end result

4.5 Making system-wide testing smoother

4.5.1 Dealing with boilerplate

4.5.2 Reducing boilerplate in production code

4.5.3 Reducing boilerplate in tests

4.5.4 Dealing with slower-running tests

4.5.5 Consider using file systems in your tests

4.5.6 Dealing with untestable code

4.5.7 Distance between tests and code

5.7 Domains in the context of a larger app

5.7.1 When we are working in the highest domain

5.7.2 Domains are only responsible for their own functionality

6.1 Vanilla code versus third-party frameworks

6.1.1 The cost of third-party solutions

6.3 Testing and mocking

6.3.1 Dependency injection, testing, and interfaces

6.3.2 The purpose of an interface isn't instantly clear

6.5 Singletons, or "What if there's only one instance of something?"

6.5.1 Setting up a singleton

6.5.2 Singletons are often abused as shortcuts

6.5.3 Solving problems for the future

6.5.4 Singletons hinder modularization

6.5.5 Passing values across modules instead

6.5.6 Singletons, thread-safety, and global state

6.5.7 A thread-safe singleton is not enough

6.5.8 Removing a singleton dependency

6.5.9 Use-cases for singletons

6.5.10 Passing values pays off

7.2 Deeply nested dependencies; The ABC problem

7.2.1 Flipping the hierarchy inside out

7.2.2 Setting up the environment

7.2.3 Updating CourseAPI

7.4 The secret sauce

7.4.1 Breaking the ABC rule

7.5 Growing the app

7.5.1 Extending the graph with more classes

7.5.2 Flipping the graph

7.5.3 A larger ABC problem in code

7.6 When dependencies aren't available

7.6.1 A payment flow

7.6.2 Optional dependencies

7.7 Lazy dependencies

7.7.1 Expressing a factory in code

7.7.2 Using the factory

8.2 Handling larger dependency trees

8.2.1 Reducing a sub-tree

8.2.2 Settings as a setup location

8.2.3 Expressing the dependencies in code

8.2.4 Grouping the setup methods

8.3 Dependencies across an entire app

8.3.1 Multiple setup locations

8.3.2 Downsides of our approach

8.4 Passing dependencies across a modular app

8.4.1 A modular app

8.4.2 A spider in the web

8.4.3 Reducing tight-coupling between modules

8.4.4 Expressing a solution in code

8.4.5 The ABC problem appears again

8.4.6 Solving the ABC problem across module bounds

8.4.7 A cleaner graph

8.4.8 Reducing tight-coupling for foundational modules

8.5 Closing thoughts

8.5.1 Trade-offs

9.2 UI Principle 2: UI architectures come and go

9.2.1 Consider UI architectures as alignment tools

9.2.2 There is no "perfect" UI architecture

9.2.3 UI Architectures and trends

9.2.4 Architectures can be formed over time

9.3 UI Principle 3: Imagine your feature as a Command Line Tool

9.3.1 A feature on the command line

9.3.2 Flexibility by disconnecting the business logic

9.3.3 Fat business domain, lean UI domain

9.4 UI Principle 4: The UI does not dictate architectures in business domains

9.4.1 Supporting a variety of products and architectures

10.1 UI Principle 5: Name a view after what it is, not how you use it

10.1.1 Making a reusable view

10.1.2 Type name versus instance name

10.1.3 Expressing reusable view in code

10.1.4 View primitives

10.1.5 The road of becoming too specific

10.2 Introducing abstractions without introducing new types

10.2.1 Abstractions via aliasing

10.4 UI Principle 6: Don't name a view after its styling

10.4.1 Alternative names

10.5 UI Principle 7: Favor composition over smart views

10.5.1 Decomposing the TODO list

10.5.2 Domain naming versus view naming

10.5.3 Handling inconsistent UI

10.5.4 Breaking a view down into smaller views

10.5.5 Avoid delivering for hypothetical scenarios

10.5.6 Button views

11.1 UI Principle 8: View components contain logic and/or bindings

11.1.1 Distinguishing view primitives from view components

11.3 UI Principle 10: Feature views are connected to business logic

11.3.1 Connecting views to data

11.3.2 Bindings can come in many forms

11.3.3 A separation of concerns

11.3.4 Tradeoffs when using viewmodels

11.3.5 Deciding if you need more layers of indirection

11.3.6 Imperative considerations

11.3.7 Lean imperative code

11.4 UI Principle 11: Feature views aren't always full-screen

11.4.1 Not every screen is necessarily a feature

11.6 Is making a reusable component worth it?

11.6.1 Pitfalls of making a reusable component

11.6.2 A heuristic for making reusable components

11.6.3 We placed most views in a UI library

12.2 Considering various approaches

12.2.1 A top-down approach

12.2.2 A bottom-up approach

12.2.3 A holistic approach

12.2.4 A mixed approach

12.7 Implementing SelectionView declaratively

12.7.1 Defining SelectionView

12.7.2 Compile-time versus runtime

12.7.3 Implementing SelectionItemView

12.8 Implementing SelectionView imperatively

12.8.1 A UIKit crash course

12.8.2 Imperative code

12.8.3 Implementing SelectionViewItem imperatively

12.8.4 Updating state changes

12.10 Implementing view primitives

12.10.1 View builders

12.10.2 View primitives in the UI Library

12.11 Implementing the actions

12.11.1 Preparing for navigation

13.1 The problem of dependent features

13.1.1 Error-handling

13.1.2 Handling errors more gracefully

13.1.3 Multiple simultaneous errors

13.3 Connecting data-loading to a feature

13.3.1 Extending to add functionality

13.3.2 Supporting optional data

13.4 Composition instead of extension

13.4.1 Nesting views

13.4.2 Swapping the names for consistency

13.5 Dependencies and self-sufficient features

13.5.1 Modularity and encapsulation

14.5 Implementing the new CourseView

14.5.1 Three states

14.6 A self-sufficient feature in practice

14.6.1 A deep linking example

14.8 Increasing flexibility by removing dependencies

14.8.1 Replacing a property with a closure

14.8.2 The closure in action

14.8.3 Trade-offs when using a closure

14.8.4 Restoring API stability

15.1 Where we left off

15.1.1 Why the Course feature currently isn't portable

15.1.2 Why we currently can't unit-test Course as a system

15.2 Pushing the logic out of the UI domain

15.2.1 Introducing a source-of-truth model

15.2.2 Moving logic to the model domain

15.2.3 Implementing CourseService

15.2.4 Simplifying CourseView

15.3 Verifying our new implementation

15.3.1 Detaching a feature from a screen

15.3.2 Unit-tests instead of manually checking UI

15.3.3 Supporting other platforms and patterns

16.1 Common problems

16.1.1 A smarter, yet still problematic, approach

16.1.2 The view decides what the parent should be

16.1.3 The child orders a parent around

16.2 Preparing for a solution

16.2.1 What we need to support

16.5 A closure implementation

16.5.1 When a parent is a coordinator

16.5.2 Cleaning up the call-site

16.5.3 Gluing everything together

16.5.4 Inside CourseView

16.5.5 Inside CourseUI

16.5.6 Cleaning up CourseUI

16.5.7 Trade-offs when using closures

16.6 Passing a navigation type

16.6.1 A navigation interface

16.6.2 The problem of passing a navigation type

16.6.3 The name sets expectations

16.7 Dealing with optionality

16.7.1 Designing a declarative solution

16.7.2 Reasoning about optionality

16.7.3 Embracing optionality

16.8 Implementing a declarative API

16.8.1 Glueing the action to the new instances

16.8.2 Implementing all declarative methods

16.8.3 Connecting to CourseUI

16.8.4 Chaining forever

17.1 Use case #1: Pagination

17.1.1 Postponing can positively impact development

17.1.2 The technical design

17.1.3 Self-sufficient features pay off

17.2 Use case #2: Bento-Box UI

17.2.1 A flat hierarchy

17.2.2 Showcasing complexity

17.2.3 Pushing out responsibilities

17.2.4 Disconnected features

17.2.5 A deeper hierarchy

17.3 Evaluating our approach

17.3.1 A bug occurs

17.3.2 Transforming a complex screen problem into a simpler dependency problem

17.3.3 When feature views need to inter-operate

17.3.4 Syncing model changes

17.4 Use case #3: Simple UI, complex functionality

17.4.1 A tutor's settings

17.4.2 A naïve approach

17.4.3 Creating a hierarchy, again

17.4.4 Disconnecting UI from functionality

17.4.5 Fewer dependencies

17.4.6 More granularity

18.1 An authorization flow

18.1.1 A flow is born

18.1.2 Defining the Authorization domain

18.2 Gathering requirements: Deceptively complex

18.2.1 List of requirements

18.2.2 First attempt at handling complexities

18.4 Why do we need navigation flows, anyway?

18.4.1 The roles of views

18.4.2 Views rarely are features

18.4.3 Views in flows

18.4.4 Navigation Flows often are features

18.5 .A navigation flow is like a story

18.5.1 Many flows can be reduced to a story

18.5.2 Purpose matters, the rest is a extra

18.6 Designing the API

18.6.1 Re-adding complexities

18.6.2 Defining internal types

18.6.3 Adding dependencies

18.6.4 Adding configurations