Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iOS application architecture: MVVM, behaviors, singletons, subclassing

objc.io

Post reply on HN
Print view View original

31–36 of 36 posts

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#31

Post by thoughtpalette »

dep_b wrote: post #16
mpweiher wrote: post #10

Earlier quoted context omitted.

The problem, as with rails, is that the frameworks, documentation etc. encourage this. That's how you make the cool "look ma, no code" demos work: thin model ("ideally" just a CoreData object drawn in the modeler), UI painted in IB, controller to hook it all together. But it's less than ideal, er, for non-trivial programs. In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to…

I think your junior dev shows some promise. Maybe too orthodox in his thinking or taking wrong conclusions from the right info, but at least a hopeful glimmer of understanding. I think the upper limit of possibilities a View should have interacting with a Model for me is the point where your View and Model map 1:1 and the user is able to update the fields of the Model represented in your View. You might argue that in…

"But the decision to read / save / delete the Model should always be taken by the Controller and never be done directly by the View."

Definitely agree

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#32

Post by mariodiana »

mattgreenrocks wrote: post #22
mariodiana wrote: post #20

Earlier quoted context omitted.

There's something else to architecting a Cocoa app that I want to add, mainly because I had heard this a while ago but only just recently figured out how to incorporate it. There are Cocoa programmers (my understanding is that it is mainly the O.G.'s) that make good use of class extensions and categories to split the functionality of a class into different source files. For example, if you have a view controller hand…

If you want it to look prettier on-screen you can just an editor with code folding and hide all the irrelevant functions. Really, this is just a weird halfway house reminiscent of Rails' ActiveSupport::Concern. Much like that implementation, it encourages developers to address SRP by chopping the class up and calling it done. Difficulties in testing and reasoning are still in place, and the class is likely still too…

I'm completely on board with you when it comes to things like the serialization ("web service/DB") that you brought up, but I wasn't talking about that. I was specifically talking about view controllers managing table views.

If we're talking about table views and controllers, I'm not sure how to factor out the delegate and datasource in a convenient way. The delegate, in many cases, will need to know information contained by the datasource (the number of objects in a table view or table view's section, for instance).

How do you suggest it gets this information? Should it have a direct channel to the datasource? Should the controller act as an intermediary? Should it have some indirect channel to the information -- blocks or notifications or wired up in some kind of delegate relationship with the datasource? I haven't been able to find a good answer.

I actually fancy myself a bit of a nut when it comes to partitioning out my code into different objects, because I can't stand the mental overhead when one class does too many things. But I have come up with no solution that satisfies me when it comes to view controllers, because it seems like a lot of plumbing needs to be put in place. What I do know is that Apple itself, as well as several good sources on coding for Cocoa and Cocoa-Touch make extensive use of categories. I still think they can be put to good use in the situation I describe, but I'm open to alternatives.

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#33

Post by mariodiana »

dep_b wrote: post #26
mariodiana wrote: post #20

Earlier quoted context omitted.

There's something else to architecting a Cocoa app that I want to add, mainly because I had heard this a while ago but only just recently figured out how to incorporate it. There are Cocoa programmers (my understanding is that it is mainly the O.G.'s) that make good use of class extensions and categories to split the functionality of a class into different source files. For example, if you have a view controller hand…

I call this "expert band-aid applying skills". I think UITableViewController is one of the worst designed parts of UIKit and it's always a way to gauge how good a developer's OO skills are if they can point out the problems with it or if they're just okay with it. If you put the delegate and datasource in a separate file at least makes your controller look a lot cleaner but still there's still so much stuff going on…

So, when you do use a UITableViewController or a UITableView with a UIViewController, how do you partition the code?

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#34

Post by taspeotis »

tobinharris wrote: post #30
taspeotis wrote: post #19

If you're enamoured with MVVM and know C# you might consider trying out Xamarin + MvvmCross [1]. I'm using it on a few projects and the code shared across platforms is (ballpark) 70-90% depending on the size of the project. Xamarin's come out with Xamarin.Forms which looks like it could supersede MvvmCross but I gave it a shot and it's pretty immature right now. Plus its dependency injection leaves a little to be des…

Do I need still need to spend $17,091 a year to equip 3 developers with reasonably unrestricted Xamarin on 3 iOS, Android and Windows Phone? Or $8,991 if I don't care for hot fixes.

Xamarin doesn't cost anything for Windows Phone. Xamarin Indie is reasonably unrestricted, but let's just go with Business for now:

    Order Summary
    Xamarin.Android Business    999    × 3    2997.00
    Xamarin.iOS Business        999    × 3    2997.00
                                            $5,994.00
    Multiple Licenses                  10%    –599.40
                                               Total:
                                            $5,394.60

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#35

Post by dep_b »

mariodiana wrote: post #33
dep_b wrote: post #26

Earlier quoted context omitted.

I call this "expert band-aid applying skills". I think UITableViewController is one of the worst designed parts of UIKit and it's always a way to gauge how good a developer's OO skills are if they can point out the problems with it or if they're just okay with it. If you put the delegate and datasource in a separate file at least makes your controller look a lot cleaner but still there's still so much stuff going on…

So, when you do use a UITableViewController or a UITableView with a UIViewController, how do you partition the code?

I try to refactor out as much code as possible. Ofcourse the protocols should be implemented separate from the Controller, that's the first step but the implemented methods themselves can be made as thin as possible as well.

For instance the height could be calculated a static function on the UITableViewCell implementation as I think that's the object that should deal with layout.

The headers and footers should be separate UIView implementations not something you build there. Methods that are associated with them then can use methods on those classes instead of inline code.

I think if the delegate / datasource classes implement a lot of methods you want to reduce them to 1-3 lines of code between the braces each so you get a complete overview of what each does within 1-2 screens of information.

You can also often reduce some plumbing code with: https://developer.apple.com/library/ios/documentation/CoreDa...

Re: iOS application architecture: MVVM, behaviors, singletons, subclassing

#36

Post by mpweiher »

dep_b wrote: post #16
mpweiher wrote: post #10

Earlier quoted context omitted.

The problem, as with rails, is that the frameworks, documentation etc. encourage this. That's how you make the cool "look ma, no code" demos work: thin model ("ideally" just a CoreData object drawn in the modeler), UI painted in IB, controller to hook it all together. But it's less than ideal, er, for non-trivial programs. In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to…

I think your junior dev shows some promise. Maybe too orthodox in his thinking or taking wrong conclusions from the right info, but at least a hopeful glimmer of understanding. I think the upper limit of possibilities a View should have interacting with a Model for me is the point where your View and Model map 1:1 and the user is able to update the fields of the Model represented in your View. You might argue that in…

Hmm..you are talking letting the view "change the values in the Model".

I thought "the view was not allowed to talk to the model, instead it had to be fed pre-digested info by the controller" made it clear that I was talking about updating the view from the model, not vice versa.

In MVC, the controller initiates changes in the model, not the view. However, the view updates itself from the model.

Whether that's good or bad is a different story, but that's how MVC is defined.

Post reply on HN