The configurator in Clean Swift has two functions:
- Connect the VIP components using protocol conformance
- Set up the VIP cycle by connecting the output variables
Now that the protocols are no longer duplicated, the first function is not needed anymore. That leaves only the second.
It’s worthwhile to rethink if there’s a better way to set up the VIP cycle.
Among the feedback that I receive are:
- Why does the configurator need to be a singleton? There is a newer, simpler way to make a singleton class.
- Storyboards in Xcode have trouble recognizing the view controller subclass due to the protocol conformance specified by the extensions.
- Some developers couldn’t use the templates out of the box because the configurator’s
configure(viewController:)method is only invoked from
Keep reading to find out how each of these has been taken care of in the latest update.
The endless singleton debate
Singletons have a bad rep in the development world. Code smell. Bad design. Misuse. Overuse. Deservedly or not. You name it. That’s a topic for another day.
There are also the old Objective-C, and new Swift way of making a class singleton. Simpler syntax. Race condition. That’s out of scope here.
Also, the previous implementation actually didn’t prevent a developer from instantiating more than one instance of a singleton configurator. You just need to call the configurator’s default initializer instead of
sharedInstance. Although you can safeguard against that by overriding the default initializer and making it private, so that it can’t be invoked. But there is no way to prevent a developer from adding another custom initializer to circumvent that.
Regardless of your opinion about singleton, a heated debate is sure to follow.
View controller class names aren’t recognized in storyboards
Whenever you create a
UIViewController subclass, the first thing you do is to set the class name in the storyboard. One previous annoyance is that storyboards in Xcode cannot recognize the view controller class name due to its indexing order.
One way to get around that is to move the extensions out of the configurator and into the view controller. Now, Xcode can index properly, and storyboards can recognize your view controller classes.
But I don’t really like it. I think it’s bad to have to sacrifice readability for a tool’s shortcoming.
So I decided to wait, and hope Apple would fix it. But that hasn’t happened for two years. So I’m taking matters into my own hands this time.
Support for building UI in code
Most iOS developers use storyboards to build their UI. It’s super slick and easy. Apple has also been investing heavily in storyboards. Every WWDC, we see improvements to auto layout, size classes, view debugging, and much more in terms of Xcode support.
But you can’t argue there are some situations where building the UI in code makes more sense. Especially in some self-contained
UIView subclasses or frameworks.
So, I really want to make Clean Swift work for those who build the UI in code instead of storyboard. For whatever reasons.
Less is more – Yay!
In the latest update of the Clean Swift Xcode templates, the configurator is gone. It’s removed in favor of just one
setup() method in the view controller.
First, you won’t have to worry about singleton anymore.
Second, because there is no more duplicate protocol, your beautifully named
UIViewController subclasses can now be recognized in the storyboards for your autocompletion pleasure.
Third, by hooking into
UIViewController’s initializers –
init?(aDecoder:), Clean Swift now works for those who prefer to build their UIs in code.
Lastly, there is one fewer class and file. It should speed up Xcode’s indexing and build time.
Thanks for the amazing templates! It’s really good. However I was using version 2.x, I’m half way through my project. What’s the best route to update to the new version?
I suggest creating new scenes with the latest template version to get familiar with the changes first. Then, you can decide if it’s worthwhile to update your existing scenes to the latest templates. You don’t have to because they still work. Each scene is on its own.
I have a question regarding an edge case: would it be possible to reuse the VC in two different scenes? Given the fact that the ViewController is setting up the interactor, what would be the best way to have two scenes with different business logic, thus different interactor that could reuse the same ViewController?
Thanks for your thoughts!
In practice, it’s very rare that you want to reuse a view controller. But if you do, you can always pull out the
setup()method out of the view controller and into a configurator for your scene. Alternatively, you can look into promoting the view controller to a superclass, and then you can create two subclasses from it, one for each scene. You can simply override the
setup()method to hook up different components.
One little thing … In the TemplateInfo.plist is still showing the entry to create the configurator in the scene. It would be good to have an update to fix that in the templates.
Good catch! The fix will be in the next update, as it doesn’t really affect the generated files.
Hey there, I am using Clearn Architecture in my projects using new Templates provided by you.
I am having a problem when my project source code gone through the ‘Code Climate’ analysis.
Code Climate marks setup() function (template’s function in UIViewController) as “Similar block of code”. As I have many scenes (UIViewController) in my project so Code Climate marks all the setup() functions in different scenes as issue of Similar block of code.
Please suggest me how to resolve this issue.