iOS model or controller...

[grandM]

Hi guys!

I'm looking at code concerning a stopwatch. This stopwatch has a Stopwatch model. The model calculates the TimeInterval. The timeInterval is formatted into a string for instance 04m11s and put upon the view. The author puts the code to transform the Interval into a string into the Model. I however am tempted to put this code in the controller. Who is right and can you explain why?

Thanks once more.

 

[PhoneyDeveloper]

It kind of depends. Normally the model doesn't know about the appearance of the UI but the controller does. Following that reasoning the formatting code should go in the controller.

However, you could write a TimeIntervalFormatter class that takes a TimeInterval and returns a String. Maybe your app formats a lot of TimeIntervals and in different ways in different places in the app so it's worth it to spend time writing a hierarchy of these utility objects. Or you could just write a bunch of utility global functions that take a TimeInterval and return a String. Which layer are these objects or functions in: Model or Controller?

Maybe you write a view class that draws TimeIntervals. When you setTimeInterval: it formats the TimeInterval according to its TimeIntervalFormatter that's been previously set and displays the TimeInterval as text. Now we're in the view layer.

OK, now that I've confused everyone I'll say this: It's good to think about these questions and good to put code into a particular layer on purpose. I would most likely put this code in the controller or in a utility class used by the controller for the reason I mentioned first. The model doesn't need to know about the UI. Avoiding having too much code in the View Controller is also a good thing so if this code is more than a few lines I'd probably put it into a utility class.

 

[AxoNeuron]

My biggest rule of thumb is if I will end up using some logic in multiple places, if it's even remotely possible, then I will abstract it into its own class.

I am not religiously attached to the concept of modularity though. Like everything else in life, the concept of modularity is great but you can take it too far. But as a general principle it's a great way to craft software. Keep the view and the logic aspects of the app separate.

I often use extensions in Swift for something like this. For example, let's say I've got an app that shows a lot of big formatted number labels (i.e. takes a double variable 1663363 and prints 1,663,363 on a label), I would create a UILabel extension function called printFormattedDouble that accepts a double variable as an argument.

 

[grandM]

My biggest rule of thumb is if I will end up using some logic in multiple places, if it's even remotely possible, then I will abstract it into its own class.

I am not religiously attached to the concept of modularity though. Like everything else in life, the concept of modularity is great but you can take it too far. But as a general principle it's a great way to craft software. Keep the view and the logic aspects of the app separate.

I often use extensions in Swift for something like this. For example, let's say I've got an app that shows a lot of big formatted number labels (i.e. takes a double variable 1663363 and prints 1,663,363 on a label), I would create a UILabel extension function called printFormattedDouble U that accepts a double variable as an argument.

extending UILabel seems a great idea indeed as this class is view oriented.