Skip to content

This is an app built in SwiftUI to demonstrate the CAP architecture.

Notifications You must be signed in to change notification settings

jonnyholland/HarvardArt

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 
 
 
 
 

Repository files navigation

HarvardArt

HarvardArt displays art pieces from the Harvard Art Museum API. It's a multi-platform project so you can download and build and run the app locally for any supported device (iOS, macOS). The project uses environment variables for the API key; more information on the Harvard Art Museum API key can be found here.

The an app built in SwiftUI to demonstrate CAP (Composable Architecture Pattern) (To understand more details of CAP, please visit the repository).

The idea is for the app to be super composable, follow generally accepted programming guidelines (such as separation of concerns, etc), and be super fast and responsive - hopefully that is quickly noticable. Although an overall basic application, it highlights how you can scale a SwiftUI appliation without having to depend or use any library or framework. The CAP package does include a very lightweight library that is designed to be more protocol driven rather than object driven. This allows you as the developer to customize and dictate how the implementation is actually done.

iPad

Split View List
Simulator Screenshot - iPad Pro (12 9-inch) (6th generation) - 2024-03-10 at 20 07 43 Simulator Screenshot - iPad Pro (12 9-inch) (6th generation) - 2024-03-10 at 20 08 11

macOS

Split View List
Screenshot 2024-03-10 at 8 12 34 PM Screenshot 2024-03-10 at 8 13 11 PM

Structure

Every app should have a control system. For this app, the main control system is Application. This class provides the main view. All initial setup can be found in HarvardArtMuseumsApp's -init.

To ensure separation of concerns, this app uses a protocol approach for views where data sources are needed and all the views are correlated to an enum that acts as the holder for the feature and functionality. All features have Actions that dictate all actions supported for the feature (there can be multiple actions for a feature/view. I chose a single actions enum for simplicity). This ensures that any of the views used can be tested thoroughly (because all user based "main" actions flow through the closure1) but also makes the view very reusable.

You may notice that the main objects that display and control functionality inherit from a protocol called ViewCoordinator. This borrows from some terminology Apple has used since early on in SwiftUI when you needed a "Coordinatorfor advanced functionality inUIViewRepresentables or NSViewRepresentable`s. The view coordinator's main function is to...well, coordinate. It should coordinate between the model, view, and any networking or other additional functionality the view/you may need. This protocol is part of CAP.

All networking occurs through actors conforming to Server that use ServerAPIs for knowing how to communicate to backend servers (both protocols provided by CAP).

#Footnotes 1: It may be best for some user actions to be handled in the view, such as sorting, filtering, etc, while other, more important actions, to be handled in the action handler closure. Again, the point is testability and reusability.

About

This is an app built in SwiftUI to demonstrate the CAP architecture.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages