Response to MVVM is lipstick on a pig

In the last view years Unit Testing has grown more important in iOS land. Because Unit Testing UIViewControllers doesn't lend itself naturally to Unit Testing the MVVM pattern has found its way in the iOS universe. 

Patterns always add complexity to the problems that they are supposed to solve. Especially if you are unfamiliar or worse yet, we can't agree on the definition of the pattern.

My thoughts on MVVM boil down to Unit Testing. I've used MVVM for unit testing, and I can't say that I'm in love with it, but like Winston Churchill said,

"MVVM is the worst pattern for testing ViewContollers except for all of the others" .

So this blog caught my eye

https://sharpfivesoftware.com/2016/07/20/mvvm-is-lipstick-on-a-pig/

Which main point is that we need better defined classes, and who would argue with that?

Anyway here is my comment on the article. 


A downside of MVVM is that you can see a Massive View Controller become a Massive View Model which only transfers the same problem somewhere else with added complexity. 

I agree with your premise that the real problem is with class design. In both cases, what should be abstracted out, becomes code in a class that is bigger then it should be. 

However if Unit Testing is a concern, MVVM can be a good pattern where these better designed classes (dependencies) are passed in (injected) to a ViewModel where they can be tested. 

With ViewControllers this becomes harder, but not impossible. 

This also makes in clearer to see that this view is dependent on these nicely designed classes with clearly defined responsibilities, more so than a ViewController instantiating dependencies in a say an action handler. 

With a ViewModel I could test.
1. Button tap
2. Service call
3. Update label with some formatted text, is the text in the view the required format. 

Doing that with a ViewModel, the interactions between all of those parts becomes natural, but in a ViewController not so much.

You could argue that unit testing is of little value and let’s use UI testing for these types of test, but I think that really the value of unit testing is better code, with better separation, which should be the end result here.

 

 

 

 

Swift Sunrise Sunset Calc

Background

The next version of FastCast is going to be less dependent of paid services. NOAA doesn't provide Sunrise/Sunset data so a calculation was needed. 

Another goal of FastCast 2 is not to contain Objective C code, so I wanted to avoid EDSunriseSunset . I've been through this route in the original version of FastCast (written 4 years ago). At that time either EDSunriseSunset didn't exist, or I didn't find it. 

Maybe to my detriment, I've also taken a more cautious approach to 3rd party components. I'm not keen on reinventing the wheel, but more and more there are components that offer little real value that have become a standard, such as AFNetworking. 

You'll actually see AFNetworking as a skill on job listings, which to me is a warning sign on the company posting the AD. I'm not suggesting that it's not great code, by great developers, I just see it as an unnecessary abstraction on the common task of downloading and parsing JSON.

Maybe a developer who can use NSURLSession, NSData and NSJSONSerialization  would be of higher value, but hey I digress.

Writing the Swift Version

So I'm not so smart that I can write this calculation off of the top of my head, so off to Google..

There is some JavaScript code that has been floating out for a while that my original Objective-C version was based off of, but I decided to take a step back, and not simply port that code over. I found that NOAA had a spreadsheet that contained all of steps that can be found here . 

This gives us a good step by step example outside of any programming language. It is also nice to be able to break each step down, to validate each step before moving on. 

The biggest challenge using Swift is the 'expression to complex' error. 

I'm not sure if this is something that the Swift team is working on, or just the way it is. This is certainly my biggest gripe with Swift, but like all relationships there are the things to like and the things, not so much.

It does lead to some ugly code with the expressions being broken down to many steps, but maybe that makes it more simple..

Lazy Properties

Lazy properties are used allot to avoid recalculating more than necessary. 

The code with a Playground can be found on GitHub here