iOS Reactive Cocoa, RxSwift, and MVVM

[Mascots]

Thoughts and opinions?
I'm surprised that this topic hasn't come up here, yet.

-
Personally, I've fallen heads over heels for ReactiveCocoa and have spent the last while (since the 4.0 branch launch) migrating my primary app and other small tools to use it. I've never had more robust and stable structure in iOS app dev before.

 

[1458279]

I just browsed thru a tutorial and it looks like the source code would be different. Is it an add on that changes how you write the code.

One problem I can see is that if the code isn't compatible with ObjC then it would be harder to find people that work with it.

Can you tell us more about it and the advantages you see in it? How does it work with other APIs?

 

[Dookieman]

Never used reactive style code but I've looked into it, and it seems like it solves a problem that already has a more straight forward solution, KVO or delegate patterns. Like KarlJay said, it really changes the structure of the code and you need to take the reactive approach when starting a project rather than adding it and using it.

Though, the biggest problem I see when using these different pattern frameworks is that the fact you are using a framework maintained by a 3rd party. If Apple changes something with Swift or Objective-C, which is guaranteed to happen, your project could break, leaving you at the mercy of the 3rd party developer to update the Rx framework to reflect the foundational changes.

MVVM, not a fan at all. MVVM seems like a solution looking for a problem. The company I would for uses View Models in some places and I don't see the value in them. If anything it adds an additional layer of obfuscation and complexity to a project and requires a deeper dive into the code to actually find out what's going on when things aren't working right. From my experience with using them, and reading about how they are 'suppose' to work, you can end up copy and pasting code from one class to another, all in the name of reducing "Massive View Controllers" (e.g. The obj.io article that praises them). View Models become a dumping ground for random methods and logic when they should probably have been in their own distinct classes to begin with.

If someone suggests reducing the code within their View Controller by using the MVVM approach, I assume it's because they didn't structure their app well in the first place. If code was properly sectioned off to begin with, they wouldn't need to be looking for a solution to this in the first place.

 

[Mascots]

If someone suggests reducing the code within their View Controller by using the MVVM approach, I assume it's because they didn't structure their app well in the first place. If code was properly sectioned off to begin with, they wouldn't need to be looking for a solution to this in the first place.

Well, I believe the problem is more widespread than you give it credit for. Especially because of Apple and its inability to put forth any guidance. The problem is there, or else we wouldn't see such perforation of this style and these framework among such a large audience or such major players.
Apple is essentially encourage dumping as much code into the controller and sorting it out, without giving much advice on splitting logic out from the interactive bits. If you take things like the Stanford course (or really anything much more encompassing than the basic/Apple material), they encourage usage of logical blocks, but its very hard to adapt to that pattern from circumstances. It's also untestable. Like seriously, untestable. That kills because a rickety app is hella bad and states change outside of your apps control. There is just no real way you can mock a highly complex VC when it is offloading logic tasks and controlling the UI. MVVM offers a nice break between those two highly independent functions.

And that's the one reason I particularly like MVVM. It tends to split the logic that glues the model to the controller into independent pieces that actually make ends (especially controller) testable by allowing you to feed a predisposed mock-object to get expected results versus the standard MVC approach, which requires you to mock into the controller and model itself. Similar to your point on the Massive VC Issue, I think if you're MVVMs are dumping grounds, then there is logic that can be split into more reusable logical blocks that do those independent tasks. I find the approach better because it has more structure, but it any concept only goes as far as the developer takes it.

As far as delegates go, a good example of the strength of the MVVM pattern is that I can easily couple my controlling view functionality (view controller, haha) with the controller instead of splitting it into another logical block that adopts the UITableViewDataSource. For more reusable table views, I'm willing to move that into my MVVM, but more often than not I don't need to.
I particularly like RAC because it eliminates so much logic that goes into breaking apart functions and unifies them with a central theme. I hate switch and if statements or building an independent logical class to figure out how to handle the response from one of many pickers on screen. I also am glad to see the unification of target-action. There's just too many ways objects can respond which contributes to the Massive VC issue.

In reality though, especially from the situation I described above, you're going to have function that floats around. My goal is always to encapsulate it in ways that are reusable and if I find my self copy and pasting, then something is wrong with what I'm doing. And of course, MVVM isn't written in stone, adopting to conditions is what makes a grand programmer

It was this blog that got my particularly interested in MVVM and RAC (mind you, the RAC stuff is out of date but the concept still exists).

 

[Dookieman]

Well, I believe the problem is more widespread than you give it credit for. Especially because of Apple and its inability to put forth any guidance. The problem is there, or else we wouldn't see such perforation of this style and these framework among such a large audience or such major players.
Apple is essentially encourage dumping as much code into the controller and sorting it out, without giving much advice on splitting logic out from the interactive bits. If you take things like the Stanford course (or really anything much more encompassing than the basic/Apple material), they encourage usage of logical blocks, but its very hard to adapt to that pattern from circumstances. It's also untestable. Like seriously, untestable. That kills because a rickety app is hella bad and states change outside of your apps control. There is just no real way you can mock a highly complex VC when it is offloading logic tasks and controlling the UI. MVVM offers a nice break between those two highly independent functions.

And that's the one reason I particularly like MVVM. It tends to split the logic that glues the model to the controller into independent pieces that actually make ends (especially controller) testable by allowing you to feed a predisposed mock-object to get expected results versus the standard MVC approach, which requires you to mock into the controller and model itself. Similar to your point on the Massive VC Issue, I think if you're MVVMs are dumping grounds, then there is logic that can be split into more reusable logical blocks that do those independent tasks. I find the approach better because it has more structure, but it any concept only goes as far as the developer takes it.

As far as delegates go, a good example of the strength of the MVVM pattern is that I can easily couple my controlling view functionality (view controller, haha) with the controller instead of splitting it into another logical block that adopts the UITableViewDataSource. For more reusable table views, I'm willing to move that into my MVVM, but more often than not I don't need to.
I particularly like RAC because it eliminates so much logic that goes into breaking apart functions and unifies them with a central theme. I hate switch and if statements or building an independent logical class to figure out how to handle the response from one of many pickers on screen. I also am glad to see the unification of target-action. There's just too many ways objects can respond which contributes to the Massive VC issue.

In reality though, especially from the situation I described above, you're going to have function that floats around. My goal is always to encapsulate it in ways that are reusable and if I find my self copy and pasting, then something is wrong with what I'm doing. And of course, MVVM isn't written in stone, adopting to conditions is what makes a grand programmer

It was this blog that got my particularly interested in MVVM and RAC (mind you, the RAC stuff is out of date but the concept still exists).

My opinion of what a view controller should be responsible for may be different than yours, but I look at it as UI/Model presentation only. It shouldn't be used for sorting/complex logic (minus what needs to be display based on specific tableViewCell needs or example etc...)/networking etc... It should be given a model, then update the view that reflects that model it was given, with minimal changes needed. This can all be accomplished with classes that manage specific things. This will break the application up into logic pieces into reusable pieces instead of needing to make a view model for every controller.

You're right that this will cause the view controller being difficult to unit test, but I think in most cases, you don't need to unit test view controllers. Now we are getting into the realm of what should or shouldn't be unit tested. Personally, I believe unit testing should be done on things that make logic decisions to ensure what you are feeding it is parsed properly, and if you break your app down then it makes it a bit easier to unit test.

 

[1458279]

I wonder if these issues were taken into account with Swift because it has global functions.

With global functions, you can have a whole bunch of function that apply anywhere you want and these can be app specific as well as general functions.

Imagine how much code could be moved into a module of general and specific purpose global functions and how much easier the code would be to read.

If the issue is code heavy, hard to read modules in MVC, then removing a bunch of it into functions would solve the problem. Unless the problem is memory and I don't know how functions load, probably load and dump as needed.

 

[1458279]

Never used reactive style code but I've looked into it, and it seems like it solves a problem that already has a more straight forward solution, KVO or delegate patterns. Like KarlJay said, it really changes the structure of the code and you need to take the reactive approach when starting a project rather than adding it and using it.

This is strange, I just looked up and read about delegate patterns because you mentioned it and it's what I've been working on for a while now without even thinking about patterns.

http://www.raywenderlich.com/46988/ios-design-patterns

Having all your data going thru one interface (api), that what we used to do back in the old days.

 

[Mascots]

I certainly don't advocate testing controllers just to do it, but I found it's hard to manage them over time. Typically, the controllers that I need to test are the largest and most complex, which makes them inherently harder to test but means it is more important. This also couples with the trend that these types on controllers are the ones users are actively interacting with the majority of the time, so I like to make them as robust as possible. In the long run, it makes fixing bugs and compensating for their occurrence in the future easier for me.

I agree, we have slightly different interpretations for the responsibility of the controller, but that kind of goes back to my saying that Apple offers too little guidance - and even though MVC is a general programming concept, it's their universe and they should to provide more direction to establish guidelines (whether the developer follows them or not).
Then again, they're not too far off. In my interpretation, the controllers only responsibility is to work with values from the model - I just use a VM to transform them from the raw model to a usable model. In this fashion, my controller isn't aware of my model and is completely independent of it.

I basically described what you did ha. The end goal is the same, I just find too many positives to avoid the pattern, even if utilizing to a minimal capacity. You have experience that rightfully left a taste in your mouth, so don't let me make it sound like I'm trying to convince you or something like that ;]

I had a moment where MVVM really shined which made me commit full heartedly: I recently wrote an app in which the same cell is used between 5-6 different Table Views with slight alterations on the cell's view - using MVVM, I was able to share the logic that feeds each of these cells values (CellViewModel) and severely cut down on memory as a single View Model was able to drive values and changes to cells in many other places.

With global functions, you can have a whole bunch of function that apply anywhere you want and these can be app specific as well as general functions.

I like this. I have definitely been underutilizing global functions.

 

[1458279]

I certainly don't advocate testing controllers just to do it, but I found it's hard to manage them over time. Typically, the controllers that I need to test are the largest and most complex, which makes them inherently harder to test but means it is more important. This also couples with the trend that these types on controllers are the ones users are actively interacting with the majority of the time, so I like to make them as robust as possible. In the long run, it makes fixing bugs and compensating for their occurrence in the future easier for me.

I agree, we have slightly different interpretations for the responsibility of the controller, but that kind of goes back to my saying that Apple offers too little guidance - and even though MVC is a general programming concept, it's their universe and they should to provide more direction to establish guidelines (whether the developer follows them or not).
Then again, they're not too far off. In my interpretation, the controllers only responsibility is to work with values from the model - I just use a VM to transform them from the raw model to a usable model. In this fashion, my controller isn't aware of my model and is completely independent of it.

I basically described what you did ha. The end goal is the same, I just find too many positives to avoid the pattern, even if utilizing to a minimal capacity. You have experience that rightfully left a taste in your mouth, so don't let me make it sound like I'm trying to convince you or something like that ;]

I had a moment where MVVM really shined which made me commit full heartedly: I recently wrote an app in which the same cell is used between 5-6 different Table Views with slight alterations on the cell's view - using MVVM, I was able to share the logic that feeds each of these cells values (CellViewModel) and severely cut down on memory as a single View Model was able to drive values and changes to cells in many other places.



I like this. I have definitely been underutilizing global functions.

Back in the day, you used to write your own parser and other string, file saving, ... functions and dump them into a file. I'd spend a lot of time writing those functions and it made a huge difference in productivity. They used to call them UDF (User Defined Functions).

I once wrote a generic data browser that you'd just pass an array of user settings and it would handle most of some whole apps. Productivity was thru the roof.

 

[Dookieman]

I certainly don't advocate testing controllers just to do it, but I found it's hard to manage them over time. Typically, the controllers that I need to test are the largest and most complex, which makes them inherently harder to test but means it is more important. This also couples with the trend that these types on controllers are the ones users are actively interacting with the majority of the time, so I like to make them as robust as possible. In the long run, it makes fixing bugs and compensating for their occurrence in the future easier for me.

I agree, we have slightly different interpretations for the responsibility of the controller, but that kind of goes back to my saying that Apple offers too little guidance - and even though MVC is a general programming concept, it's their universe and they should to provide more direction to establish guidelines (whether the developer follows them or not).
Then again, they're not too far off. In my interpretation, the controllers only responsibility is to work with values from the model - I just use a VM to transform them from the raw model to a usable model. In this fashion, my controller isn't aware of my model and is completely independent of it.

I basically described what you did ha. The end goal is the same, I just find too many positives to avoid the pattern, even if utilizing to a minimal capacity. You have experience that rightfully left a taste in your mouth, so don't let me make it sound like I'm trying to convince you or something like that ;]

I had a moment where MVVM really shined which made me commit full heartedly: I recently wrote an app in which the same cell is used between 5-6 different Table Views with slight alterations on the cell's view - using MVVM, I was able to share the logic that feeds each of these cells values (CellViewModel) and severely cut down on memory as a single View Model was able to drive values and changes to cells in many other places.



I like this. I have definitely been underutilizing global functions.

Sure. I didn't mean to sound aggressive just expressing what I've experienced and just difference of opinion. From what you described on how you use your View Model, is what I do in my Model. I pass my Model raw JSON code and have it parsed and values assign there rather than a separate utility. This all gets done in the NSURLSessionDataTask completion block. Once everything is parsed in the completion block an array of models is returned to the controller to be promptly displayed This allows me to test my model directly.

 

[Mascots]

Yeah, essentially we are doing the same thing, the only difference is the division of the models responsibility on my end. - I pretty much would use a similar structure if not. I think that goes massively far at its appeal, though, because it encourages that division versus adopting it for sake of sanity.

Sure. I didn't mean to sound aggressive just expressing what I've experienced and just difference of opinion.

You weren't at all, I was afraid I was being! Unlike many, I rather enjoy a little less homogeneity in the dev world.

 

[AxoNeuron]

I don't like to follow any particular dogma. Functional programming, MVC, I generally just use what works best in each case.

That said I do try to keep my view controllers as tiny as possible. When I was a newbie some of my view controllers reached >1500 LOC's. Very hard to debug, and testing...? Not a chance. Now that I'm a lot more experienced it's rare for them to exceed 400. The patterns I usually mix and match most are protocols, blocks/closures, singletons (very carefully), and MVC.

I really love closures, I use them all the time in my data models. Generally my view controller will call a function to get info from the data model, the data model will instantly call the closure to provide cached data. But then it performs an HTTP request and calls the same closure again with the latest data. The view controller doesn't know or care whether the data comes from the cache or the web.

With Core Data subclasses, it's really super easy to create a fast cache and integrate it with a backend (NodeJS + MongoDB in my case usually). The only problem with this strategy though is it can have a lot of knock-on effects that are easy to forget about. But with careful planning and thought you can end up with a really fast data model that is easy to test and to work with.

 

[1458279]

I don't like to follow any particular dogma. Functional programming, MVC, I generally just use what works best in each case.

That said I do try to keep my view controllers as tiny as possible. When I was a newbie some of my view controllers reached >1500 LOC's. Very hard to debug, and testing...? Not a chance. Now that I'm a lot more experienced it's rare for them to exceed 400. The patterns I usually mix and match most are protocols, blocks/closures, singletons (very carefully), and MVC.

I really love closures, I use them all the time in my data models. Generally my view controller will call a function to get info from the data model, the data model will instantly call the closure to provide cached data. But then it performs an HTTP request and calls the same closure again with the latest data. The view controller doesn't know or care whether the data comes from the cache or the web.

With Core Data subclasses, it's really super easy to create a fast cache and integrate it with a backend (NodeJS + MongoDB in my case usually). The only problem with this strategy though is it can have a lot of knock-on effects that are easy to forget about. But with careful planning and thought you can end up with a really fast data model that is easy to test and to work with.

I'd be interested in seeing some of the core data subclasses and closure work. I'm just getting back into core data and SQLite and I'll have to dig into the back end soon enough. Maybe you can post a link to where you learned this from. Most of what I find is entry level.

 

[AxoNeuron]

I'd be interested in seeing some of the core data subclasses and closure work. I'm just getting back into core data and SQLite and I'll have to dig into the back end soon enough. Maybe you can post a link to where you learned this from. Most of what I find is entry level.

I learned Core Data back in 2012 in Objective-C, with a course from Lynda.com. It is still one of the favorite courses I've taken. A lot of it is useless to me (I would never use something like NSFetchedResultsController), but the sub classing stuff, NSPredicate, etc. is highly useful.

Even though the course is in Objective-C it's still almost entirely applicable to Swift, nothing has changed. So I would still recommend it.

Ps. Even if you don't end up taking that specific course I would still suggest getting a subscription to that site since there is so much useful stuff on there. It's where I've been learning Java & Android development and as a learning tool it's truly invaluable.

 

[Mascots]

I'd be interested in seeing some of the core data subclasses and closure work. I'm just getting back into core data and SQLite and I'll have to dig into the back end soon enough. Maybe you can post a link to where you learned this from. Most of what I find is entry level.

Along with what AN said, I personally spend a lot of time in Apple's Development Forums and on Google sorting results by date just to consuming as much about Core Data as possible. The most reactive and intimate information you will get will be from those who have worked directly with the framework, smacked heads with it, and did investigations in their problems to reveal a lot of what is happening - and while it's not necessarily a tutorial to learn how Core Data handles its internal SQL base, there is so much knowledge that will bubble up as you work along with it.

 

[firewood]

I like the (pseudo) reactive function paradigm. It's similar to how sample data flows in audio units; so all advanced Core Audio developers use reactive code whether they know or call it that or not.

But I don't like installing 3rd party dependancies and libraries with their weird non-standard syntax in order to use reactive coding (outside of audio buffering). If I were in a larger team project, where more thorough continuous unit testing was required to keep junior developers from breaking things too often, maybe...