This project showcases the Model-View-ViewModel (MVVM) architecture with ReactiveCocoa 3, while serving as a digital logbook of FIFA matches. It was inspired on a theoretical level by Justin Spahr-Summers' talk Enemy of the State, and on a more practical one by Ash Furrow's C-41 app.
As the Swift language and the ecosystem around it matured, porting the original ObjectiveGoal project became a natural next step, as Swift's type safety makes it a perfect fit for functional reactive programming.
SwiftGoal runs on iOS 9+ and requires Xcode 7.1 with Swift 2.1 to build.
The application uses Goalbase as a backend to store, process and retrieve information. It assumes you have a Goalbase instance running at http://localhost:3000, which is the default URL of the WEBrick server that ships with Rails. Please check out the Goalbase documentation for more detailed instructions.
If you want to provide your own backend, you can do so by editing SwiftGoal's base URL in the Settings app.
- Create players
- Create matches with home/away players and score
- View list of matches
- Edit existing match information
- Delete matches
- Pull-to-refresh any list in the app
- See animated list changes
- Enjoy custom fonts and colors
- Get alerts about network and server errors
- View player rankings
- Switch between different ranking periods (last month, all time, …)
- See date and time of each match
- See matches grouped by date range (e.g. last week, last month, earlier)
- View more player statistics (e.g. won/drawn/lost count, nemesis player, …)
- Delete players alongside their dependent matches
- Validate player name before creating
- Validate match player counts before creating
- Move base URL to Settings for easy customization
- Cancel network requests when the associated view becomes inactive
- Retry network requests 1 or 2 times before giving up
- Detect and animate match data changes
- Write tests for models
- Write tests for view models, helpers and store
- Deduplicate
isActiveSignalcode on view controllers (via a protocol extension?) - Create watchOS 2 app for quick match entry
- Drop Auto Layout library in favor of
UIStackViewandNSLayoutAnchor
High testability: The basic premise of testing is to verify correct output for a given input. As a consequence, any class that minimizes the amount of dependencies affecting its output becomes a good candidate for testing. MVVM's separation of logic (the view model layer) from presentation (the view layer) means that the view model can be tested with minimal setup. For instance, injecting a mock Store that provides a known amount of Match instances is enough to verify that the MatchesViewModel reports the correct amount of matches. The view layer becomes trivial, as it simply binds to those outputs.
Better separation of concerns: UIViewController and its friends have been rightfully scorned for handling far too many things, from interface rotation to networking to providing table data. MVVM solves this by making a clear cut between UI and business logic. While a view controller would still acts as its table view's data source, it forwards the actual data queries to its own view model. Presentation details, such as animating new rows into the table view, will be handled in the view layer.
Encapsulation of state: As suggested by Gary Bernhardt in his famous talk “Boundaries”, view models offer a stateful shell around the stateless core of the app, the model layer. If need be, the app's state can be persisted and restored simply by storing the view model. While the view may be extremely stateful too, its state is ultimately derived from that of the view model, and thus does not require to be stored.
This project is kindly sponsored by Futurice as part of their fantastic open-source program. Kiitos!
The icons within the app are courtesy of Icons8 – a resource well worth checking out.