iOS Architecture: MVVM-C, Scenes (2/6)
Scene
A scene can be thought of a section, feature, or use-case inside an app. A small but internally complete and contained part of the whole application. How big or small you want to make the scene is up to you.
I usually find that definining a scene as a feature works quite well. It is usually a collection of 1 to 4 screens that are meant to achieve a single purpose. For example a login flow, a picture upload process, or a purchase funnel.
Organization
To begin with I create a folder inside my Xcode project called Scenes which will contain subfolders for all the scenes. Inside a particular scene (as you can see in the Search example below) I have all of the parts pertaining to that scene. From the Coordinator down to the Views. These folder structure will be repeated for each scene.
I think this helps compartmentalize each Scene of the app as a complete little self-contained app inside of the bigger whole application. I could drag this Scene’s folder to another app and it should mostly work.
Storyboards
As you can see from the screenshot above each scene should have it’s own Storyboard with the same name as the scene.
Storyboards are still a little bit of a controversial topic in the iOS community. Some people can’t imagine creating an iOS app without using storyboards, and some other people in the community wouldn’t be caught dead using a storyboard. They either create their views programmatically or they only use XIB’s on a per screen basis.
One of the complaints against storyboards is that sometimes developers cram all of their app’s screens inside one massive storyboard and it becomes a mess, especially when there is multiple people working on the same storyboard. Gotta love those impossible to understand GIT merge conflicts where you have to parse over XML text to understand what’s happening.
But there are still a lot of benefits to using storyboards. They make size-classes and auto-layout a breeze, they allow for static table views, they let you visualize your app’s flow, etc…
I won’t get into all of the pro’s and con’s of using storyboard’s here, but I think I’ve found a middle ground. Each scene should have one storyboard which contains only the ViewController’s included in that scene. This goes a long way to preventing merge conflicts as usually only one developer is working on a specific feature or section inside of an app.
And most importantly, altough I do use storyboard’s to contain the ViewController’s for each scene I do NOT set any segues or relationships on the storyboard. It is only for configuring the View’s for each ViewController included in the particular scene.
Coordinators
This previous point is really important. We can use storyboards but we do not use segues or any other kind of relationships that we can create using interface builder. The reason for this is that the Coordinator is going to be responsible for handling the navigation and relationships between ViewController’s.
Many people think Coordinators and Storyboards can’t co-exist. When in reality if you don’t use segues or relationships they can work together quite nicely.
For more on coordinators head on to the next article in the series:
