040 iPhreaks Show - MGPCommandBus with Saul Mora
The panelists talk to Saul Mora about The Responder Chain and MGPCommandBus.
CHUCK: Cue the theme music. CHUCK: Hey everybody and welcome to episode 40 of the iPhreaks Show. This week on our panel we have Pete Hodgson. PETE: Good morning from the Baghdad of the West. CHUCK: Where’s that? PETE: San Francisco. I looked it up after the last episode when everyone had a nickname and I didn’t. I looked it up on Wikipedia; I've got a list now that I can go off of for quite a few weeks. CHUCK: Got it. Andrew Madsen. ANDREW: Hello, from Salt Lake City. I really think we don’t have a nickname for our city. CHUCK: Jaim Zuber. JAIM: Hello from South Canada. CHUCK: I'm Charles Max Wood from DevChat.tv and this week we have a special guest, Saul Mora. SAUL: Hello from Denver, home of the Denver Broncos – your next Super Bowl Champions! CHUCK: I honestly think that’s most likely the case. [Chuckles] You haven’t been on the show for a while, do you wanna introduce yourself? SAUL: Do I need an introduction? Really? ANDREW: Wow. CHUCK: He’s that guy from that show. SAUL: I'm just messing with you guys, man. I've got a [inaudible] attitude now, I guess. So yeah, I'm Saul. I write code; I work or my little company called the Magical Panda Software; I do another podcast called NSBrief; I wrote MagicalRecord – I do lots of different things here and there. I'm a busy guy, I guess, so I forget everything that I do. CHUCK: [Laughs] Okay. ANDREW: With everyone from all the different podcasts, on everyone else’s podcast – it’s like the ‘80s where every show had someone from Facts of Life. SAUL: On this very special episode of iPhreaks Show –. ANDREW: It’s kinda like that. SAUL: [Chuckles] ANDREW: Are we going to get the phones on in a sec? CHUCK: Oh, man. PETE: That’ll be great! I wonder if he knows anything about iOS development? SAUL: Probably not. PETE: [Inaudible] he has any bugs; he just kinda like does that thing where he whacks the side of the iPhone just right and then he fixes it. CHUCK: Oh, really? SAUL: That’s my iPhone. PETE: Crickets. CHUCK: That’s how I void my warranty. Alright well, we did the episode on MVC – what was it? Two or three weeks ago – ish? And I think it was more than that when we recorded it because we recorded extra episodes to get through Christmas. Anyway, we talked about the Responder Chain, or we mentioned the Responder Chain; we also got an email from Saul and he was being nice about the stuff that we may not have mentioned that we should have, so I'm kind of curious as to what your take on that is, and then we’ll just kind of move through the topics from there. SAUL: Well I think a lot of what I had to say also revolves around the twitter conversations I've been going around lately. I know Ash Furrow recently posted a blog post on Model view ViewModel patterns, and even before that there the ReactiveCocoa guys talking about stateless designs. All these extra ways to kinda design your iOS applications that are different from MVC and I think, covering MVC, it’s a hard thing to do because it feels like such a classical pattern and it feels like, “Oh, we’re in this modern world where things don’t apply; the rules are different for us!” and we come up with all these different names for things when it’s really kind of the same deal, but different subtle takes and subtle approaches to things when in reality is, what it seems to me is that if you really just dig down in to the core design principles of things – how to design applications properly so that you don’t have a lot of redundancy and craziness, so that you can kind of keep track of where everything is and things like that –. It kinda doesn’t matter what the name of the pattern is, it just matters that you designed an application that you can actually fix when things go wrong. PETE: So you're saying, we don’t have to obsess with whether we’re MVVM or MVP or MVC or MVstar or MVBBQ or –. SAUL: Right. I guess it’s trying to reach a higher level of Nirvana, right? PETE: It’s transcending the facts. SAUL: [Chuckles] And that’s a thing that I've learned, you know. I used to be a huge student of patterns, and I still am, but I think it’s like any piece of advice or knowledge or wisdom – you gotta take it with a grain of salt and apply what's right. You get down to the core fundamental principles of things, and they don’t always nicely fit into a pattern or a template or some kind of pre-designed architecture, and that’s not to say there aren’t valid architectures and patterns that you can start off with; it’s just that you have to realize that you have to know the rules before you can break the rules, right? So it’s kind of that way, and that’s kind of how I –. I was listening to your episode, I was thinking about that. I was like, “Well, it’s great for beginners, but I think it’s good to still explain that there are exceptions to the rules and they're valid exceptions, and there are other ways to do things and you can still use MVC and use it pretty well these days, and still kind of have a different way to organize your app, and still use MVC. PETE: I guess that’s the challenge with all of these patterny things, is they're kind of like when you're early on in your learning, when you've journeyed down the road of architectural enlightenment or whatever, you need something pretty prescriptive, right? I'm a big fan of the Dreyfus Model, which is this model of how we learn, and that talks about when you're a beginner or something, you just need loads of prescriptive advice. So if you're a beginner chef, you just want a very, very step-by-step [inaudible] instructions on how to cook whatever you're cooking. Then as you gain levels of enlightenment on the deep, profundities of food, then you kind of start deviating from the path, right? If the recipe calls for garlic and onions, you might kinda decide that in your context, you wanna cook with shallots instead, or use red onions rather than white onions or whatever. I kinda feel like the challenge is to know where you are on that scale, and once you’ve spent a little bit of time just following the recipe exactly, you need to start understanding the principles behind the practices, right? Like, why is MVC good or bad, so that you can start deviating. That’s my take on what you're saying, Saul. SAUL: Right, and I'm also trying to kind of address some of the haters out there on the Twitter-verse, just because –. You know, I have a lot of respect for the GitHub guys that have the time and the ability to do something like ReactiveCocoa, but ReactiveCocoa is not the end-all solution to everything either. It’s really using, again, putting another tool in your toolbox, having that available for when it’s the right time to use it. That doesn’t mean that you have to throw away all of the other things that you’ve learned. This is kind of coming at the – after a long career of writing applications and things and doing a lot of studying over the years. It’s like you said, it’s kind of knowing where you are in that scale; knowing if you are a beginner or intermediate, or advanced guy. I think it also comes down to just kind of that whole 10,000 hours of experience – was it that Malcolm Gladwell book? PETE: Yup. SAUL: Was it Blink or something? CHUCK: No, it’s Outliers but –. SAUL: Outliers, right. CHUCK: But the 10,000 hours is to get to be the top of the top, the best of the best – you know, the people that are playing professional sports kind of level. So you don’t even need 10,000 hours to be proficient. SAUL: Right. And I think for developers it may be even – it might be more. So here’s the other thing, I mentioned jokingly, it’s this about achieving Nirvana in your design and your application skills, and I think there's another level beyond the 10,000 hours where you kind of become more than proficient, more than competent in your field. You kind of achieve, like I said, this Zen state of you kinda see things – you start to see things differently and put things together in a different way so that you can really start challenging the way things work. And I think that’s the level – I can’t say that I'm at that level or not – I just try to aspire to those kinds of levels. PETE: And here’s the frustrating thing about that is that once you’ve hit that kind of expert status or that Zen status, that’s actually really hard for you to describe why things are good or bad to people who are lower down on that scale, because the way you think about problems is really different, right? So for you, Saul, in your Zen state, in your architectural Zen state we’ve just decided you're in, if you know something’s a good idea or a bad idea, so you know for maybe a specific type of application, the reactive approach is going to work really well, or is going to work really badly, or not work well I’d say. You describing that to someone who’s lower down on that Dreyfus scale is actually going to be quite hard because the way that you think about things is going to be very abstract; it’s going to be very kind of bound to context, and it’s really, really hard to translate that because you have to bundle up so many concepts at the same time when you're explaining that, so you have to kind of, before you can talk about one thing you have to chunk it down and talking about the underlying things behind that, and explain that principle, and that principle, and before you know it you’ve been talking for an hour, and you still haven’t really started talking about why something is wrong for that context. SAUL: Alright, so getting back to the actual conversation we had – talking about MVC and all that stuff, you know, speaking at a way too higher level, I think as kind of an educator myself, I consider myself an educator in the iOS and Mac developer space. I try to explain some of these higher-level concepts in simpler terms so that at least people would kinda get an idea and do some more research themselves and do that as well. As far as what you're talking about the MVC show a couple of weeks ago, the one thing that really struck me, if I recall correctly, was that you only briefly, passingly mentioned the Responder Chain. The Responder Chain, I think, is not the end-all solution to a lot of the MVC’s woes, but I think it’s a good start to looking at how to use the Responder Chain if you coupled your apps. That’s kind of the talk that I gave, and you mentioned that as well, that talk on design patterns that I gave at the Mdevcom last year and all that, and really what that talk was about was using the Responder Chain to decouple a lot of the connections between your apps so that when it comes time to change your hierarchy, you need to introduce a view or remove a view, or a ViewController or such, it doesn’t really matter as long as it’s within the Responder Chain which on iOS kinda happens automatically. PETE: So I'm going to play the role of someone who doesn’t get all of the details of this stuff – so is this Responder Chain stuff an alternative to MVC, or is it a way of using MVC, or where does it fall in that? SAUL: The Responder Chain is, I guess, it’s a chain of responsibility – the classical gang of four design pattern. It’s funny, because if you take a look at the Responder Chain when your app is built app, it’s actually more of a tree. Basically, what happens when your app is drawn on the screen for iOS, you’ve got all these views, buttons, tap areas – all these things that can respond to touch events or more than touch events: motion events, push notification events – basically outside inputs into your application, and that’s what a responder is. So if you notice, if you look at the docs, you'll notice that UIResponder is really a non-visual control. I believe UIControl even subclasses from UIResponder. The responder is basically something that can respond to outside input. So as far as how it fits into the MVC pattern is – I think of it as more of a communication channel or getting things from the Views into the Models, and I think that was the big point of contention in that last show was, “How do you have these things observe stuff without having tightly coupled and all this stuff?” And it really all comes down to you have to define some kind of language. In objective-C, we have protocols that hold that very definition, but we’re not really bound to that. Objective-C is so flexible that we can just send any open message up the pipeline, up the Responder Chain pipeline and if it doesn’t get handled, then nothing happens, and that can also be a problem, but you should also try to handle that as well. PETE: Can you go into more detail into – can you give us a concrete example of how this would work using the Responder Chain? I don’t know, maybe just a trivial example of you’ve got a standard login page, let’s say, and you wanna hand all of the interactions between the view and the controller that might happen during that login. SAUL: Sure. Take your Code Monkey login page that manager Rob actually implemented, and –. So you’ve got like a login or username and you’ve got a password field, and then you’ve got the little login button. If you're familiar with iOS a little bit, what you'll do is that when you have the username, so you want the keyboard to show up right when that login form shows up, you'll go ahead and say, textfield, basically a self.login field, becomes first responder. That’s kind of one clue as to what's going on there, is that you're telling the system that you want the first responder, or basically the thing, the controller, or the responder that’s in the system – you want that to accept all the incoming events. And what that does is kinda tells the system, “Well okay, this is the text field, okay, you can become the first responder. It’s got some built-in stuff there to fire up the keyboard,” and the keyboard then will fire off basically key press events and fill in that text field for you, and that’s just kind of the first thing. And you'll also notice that if you got a UITextField or Textview delegate, you should return DelegateMethod – I don’t remember the exact signature, but it basically says, “If you hit return, should this return?” And with login fields, you basically don’t want any return characters so you just say, you tell it to return ‘no,’ and then what you do there is you say, well what's my –. You wanna implement the next responder, which would be the password field, so you tell it in that method, “Well, did I just come from the text from the username text field? If I did, and I hit the return key, well I want to jump to the password field and [inaudible] entering the password in there.” It’s really just entering in that delegate method and just doing that same logic, and it’s usually three lines of code; one of them is an ‘if’ statement, and the other one is a ‘return no’ statement. So that’s a pretty simple thing and then from there, what you can also do is in that same delegate, you can say, “Well, was the delegate the password field?” And I hit return and what should happen next? Well, by default they should go ahead and kick off the login mechanism. And now this is where it gets a little bit more complicated as far as the way that I see things is that a lot of people will go ahead and put their login functionality right in that ViewController that’s containing all those Views and delegate callbacks and everything, and they’ll fire off a network thing to go and login to your web service, and they’ll fire off a bunch of [inaudible] there to make sure that it looks like something’s happening. You have all these blocks and all these things kind of going off right there. The way that I would do it instead is you use the same Responder Chain, so instead of just calling another method within that ViewController, you basically have all your login functionality living in a separate subsystem somewhere, basically outside of that ViewController, and it could be anywhere along the Responder Chain. My suggestion is to make another class that kind of sits in the application delegate; it’s not application delegate methods that you attach to it – this is another class that is a responder after the application delegate. I’ll talk about which ones are in the chain in a minute, but basically what you wanna do is send a login command with that information that tells you how to login and send that up the chain so that this other network thing can do the login for you. PETE: That makes sense to me, the login ViewController is responsible for kind of managing the view, controlling the view, but it’s not responsible for figuring out – like it’s responsible for managing the login UI but it’s not responsible for the actual active locking in because it’s a ViewController, not a business logic, everything-in-the-application-lives-in-here controller. SAUL: Right. It’s not a network controller or controller in that kinda sense; it’s not meant to control all of your business logic. I guess for the enterprising folks, your business logic isn’t live-in-a-ViewController; that’s just trying to, like it says, control the view, which means displaying where the cursor goes, what becomes a responder when, how to react to a failed login maybe, basically by displaying a failed login prompt – things like that. But the actual act of doing the login and all that stuff is just somewhere else in the system, and franklythe best way that you could do it is to basically have a ViewController not really care. And by not caring, it’s basically designing it to an interface, and that’s where protocols again come in and you could do that more explicitly or you could do it implicitly with just a magic selector somewhere that you just happen to know and it happens to send that up to the Responder Chain. JAIM: So Saul, this is [inaudible] describing: does the ViewController have any knowledge of kind of the login handler that’s in the Responder Chain, or is this kind of [inaudible] passed up? SAUL: As far login handler, you're talking about the actual thing that performs the login? JAIM: Right. Talks to the service, or does whatever you used to do. SAUL: So this is kinda where I've been a little ambiguous with this protocol definition. Now the thing is, in order to use your Responder Chain, you need to know the selector, because the selector is the messenger. So basically I guess in general terms, the Responder Chain is sending messages to a bunch of different handlers in the chain and whoever wants to handle it, or basically the first one that can handle it, should handle it, and if they want to they can pass it back up the chain and stuff. There is no formal definition of what selector you can pass up the chain; you use the @selector syntax and you could just pass any old message up the chain. I won’t say there's no way to really formalize it, because you certainly could, but what you do need is to, in modern objective-C I would say, that you need to know what that selector is so that the compiler can tell you if you're basically making up a selector. I mean, we’re not dealing with Ruby here; we can just make up anything and have it crash with these crazy [inaudible]. [Chuckles] JAIM: But for example like, okay, you’ve [inaudible] all your information, your username, your password, now you’ve clicked the login button. SAUL: Right. JAIM: So you type it inside, the selector goes up, is that calling a selector on the ViewController just going up the view chain – how does that work? SAUL: Yeah, so let me talk about the actual chain. Like I said, it’s like a tree and the root of the tree is actually your application delegates. So the application delegate, it’s kind of the last stop in the Responder Chain, and then after that, it’s actually that RootViewController – it’s actually the window and then the RootViewController on that window, so it kinda bubbles up. So everything that you add as a SubViewController or a Subview to that becomes part of the Responder Chain for iOS. For Mac, it’s a little bit different – it’s just basically the Views; the ViewController is actually not part of the chain. So you basically have everything; basically it’s almost a reflection of the view hierarchy, and that’s a very tree-like structure. So basically what happens is, when you tap on that login button or you tap on the go button or whatever it is – it is tapping basically a leaf in that tree, and it’s kind of bubbling up to the root via that connection chain of the view hierarchy more or less. So that’s kind of what happens when you tap the go button, the login button, and you're sending that message. Actually, that’s kind of the way that I do things now, personally in my own apps, is to grab that message and then pass it along the Responder Chain that way. What's nice also is it’s pretty easy to send a message up the chain; it’s basically one line of code – something to do with the UI application [inaudible] application and look for send events, to-from, or something, or send action to-from events and that’ll get you a long way as far as sending messages up the Responder Chain. PETE: So what would the ‘to’ and the ‘from’ be in this example of the login? SAUL: This is where knowing all these difference patterns that exist in Cocoa and in iOS development. The first one that we talked about is the delegate, with the callback delegates – that’s a pretty common one. The other one is this target action [inaudible] and that basically just says that any target or any object can be cast in action, which is basically a message, and for all intensive purposes. For us, it’s just a selector. So any target action deal kind of has a convention as well. You could pass no arguments to it; you can pass one argument to it, and that’s usually when you see on the ID action [inaudible] ID action in code, you'll see it kinda creates the I'd sender for you? That’s generally always the first one. So that ‘to’ is kind of who it’s going to, and the action is obviously the selector that we’re sending, and the ‘from’ is generally always going to be that sender. So now you’ve got kind of something that you see more commonly when you actually do a button, like an interface builder or even in a code, when you add a target and an action, you're basically telling what specific object, what action you want to perform, and # who sends the message. CHUCK: So this may sound somewhat explicit, but it sounded like before you were implying that some of this was implicit, that they would just do the right thing under the right circumstances. SAUL: Yeah, so with the Responder Chain, when you're doing a specific action or a specific target, if you have – basically, for the beginners, you'll generally send all targets to the files owner if you're using a ViewController nib, you'll say “when you light a button, you'll say you'll drag the line to the files owner,” and you'll have an action that you connected to. That’s being very explicit. The way that you be implicit in the UserResponder Chain, you’ve also got in the nib file that first responder deal, and you just drag it in there and that’ll basically –. And sometimes it’ll be slow when it pops up, but it’s inspecting all the actions in the Responder Chain from that point. I think it’s just for the application; I don’t know exactly what the scope is of that part over there, but basically you could just connect an action to the Responder Chain that way. And what that basically does under the covers is you know how we had the send action to-from event method – though you're still specifying the action, and you're specifying from, but for ‘to’ you're saying ‘nil’, which basically, that ‘nil’ is what's targeting the Responder Chain, which means that you can also do this for buttons. If you have a button and you specify the target as ‘nil’, that will also go up to the Responder Chain as well. CHUCK: So one thing that I'm a little bit fuzzy on still with the Responder Chain is, so it goes to the first responder, whoever it is that it’s supposed to take care of that first, and then does it just automatically know who to bubble up to next if it’s not going to handle that, or do you explicitly tell it from there? SAUL: T hat’s where the whole chain comes in; if you also notice on the UIResponder class, there's a NextResponder method, and that’s what happens. So it’ll basically say, it basically does very simply, “Does this object respond to the selector? If no, well what's your next responder? Does that one do?” And it just keeps on bubbling up the chain that way and that’s what makes this so dynamic and so flexible that you really don’t care who handles it. All you care about is that, “Well I have this message that’s login. Okay, whoever’s going to implement login probably has some idea that I want to login to the system.” And it’s kind of this really general assumption of that you name these methods correctly, so that’s kinda what makes it magical; it’s kind of a combination of convention and then this infrastructure that’s already there for you. JAIM: Okay, walk us up an example of a Responder Chain, just for the benefit of everyone listening. So you start with a view, and it goes –. SAUL: You can see here in my slides, my nice ViewController Responder Chain diagram, right? You guys not seeing this? PETE: Looks good to me. SAUL: Crickets. [Chuckles] ANDREW: It’s very Zen. SAUL: Yeah, sure. PETE: I like the color scheme. SAUL: I know, man. I worked all night on that for you guys. JAIM: Why’d you use PowerPoint? SAUL: So it would animate better. No, wait; that’s not the right answer. So I think there's a few diagrams actually, and I think they're in the Apple docs; I have to grab one of that for you. As far as here’s how the Responder Chain works, and I mentioned that the application delegate is part of the chain, and it’s basically a reflection of your view hierarchy. So basically what happens is, and like what I said, when you tap a button, for example, you're basically telling the system that that’s the first responder, and then that one kind of starts this whole process off. JAIM: That button, I mean, [inaudible] responder, that it passes up the chain to a Superview, right? SAUL: Not exactly. So it doesn’t use Views. When you add Views and ViewControllers and buttons and all that stuff to the view, all that Responder Chain stuff is done for you automatically. You'll notice that there is no set next responder method on UIResponder, because it’s all done for you. If you do try to override – except ‘next’ responder, because I think you can, you will get a lot of problems – and this is from experience. [Chuckles] I haven’t tried this; you don’t need to do this, just kind use it as is and it will get you a long way. Whatever the systems decide will be the next responder, and that’s just # the weight; it’ll bubble up the chain, and I won’t use the view hierarchy exactly; that’s just kind of my visual model of the way that it looks. But it basically just follows that NextResponder method to kind of basically to do a why loop over that chain. JAIM: Okay, I was trying to get a visual image of how, what the next responder’s going to be. SAUL: Yeah, and the next responder –. So generally, it’ll be – if it’s the view, if that particular View or Responder handles it, it’ll be that one. And then the next responder will generally be the SupeCview, and then it'll be the ViewController, and then it’s the window, and then it’s the app delegate – so it kinda goes in that. And I would refer to this picture, I think, of the event architecture that probably explains that in a better detail. One of the other things that you can do with a Responder Chain is that you can follow it yourself; there's no reason you can’t. So you can write your own why loop, and I've done this in debugging, is to kind of make my own category in UIResponder, that says, print out responder chain and all it does is say, while nextresponder, bubble up, print out the current responder, and then bubble it up, and then keep going. That’s really useful for debugging, because that also helped me figure out as far as when the Responder Chain doesn’t work. It doesn’t work in your ViewControllers if you try to launch something before view ViewDidAppear is called. Now think about it – it’s really important though. ViewDidAppear happens when your view, or ViewController, is in the view hierarchy. If this kind of models the view hierarchy, like I said, the whole tree structure, if it’s not in the tree structure that connects up to the app delegate and all the other top-level stuff, there's no way – it’s basically you severed the chain before that. So if you send messages up the Responder Chain before ViewDidAppear, or after ViewDidDisappear, your messages are basically at the end of that ‘nil’, eventually because it’s not going to bubble up; it’s all the way at the top. So that’s one caveat you can look at. But I would encourage you to try it out on your own apps; it’s a really simple method to write. It maybe takes around four lines of code, depending on how may ViewDidAppear is. JAIM: As a warning to our users, UIScrollview had a bug, or it didn’t pass on Responder Chain correctly. I think it has been fixed, but at least with iOS 5 and possibly iOS 6, it was not working. SAUL: That would be a pretty big problem [crosstalk], JAIM: Work around is not pretty, but we gotta figure it out. SAUL: Wow, yeah. I'm glad I started using it after iOS 5. CHUCK: So are these calls to the next level in the chain? Are they synchronized calls, or does it split off another thread to handle that [inaudible]. SAUL: Yeah it’s basically in the same thread, in my experience, or the same –. Yeah, it’ll block, so if you call that SendAction method, it’ll block until it gets done so be aware of that as well. PETE: But these are kind of fire and forget, right? You're not going to get a – well not fire and forget necessarily, but you're not going to get a response back, like you can’t get a –? SAUL: You could. There's a couple of hacks that I've kind of discovered in my use of the Responder Chain, but first of all, what you should also do is that if you're not sure that an event or a message or whatever is not being handled in the Responder Chain, the SendAction to-from event message will return a Boolean whether it was handled or not. So if it kinda made it to the end and nobody handled it, it’ll say ‘no’ and then you can kinda debug from there. You can always check that return value and see how things are going. That’s where maybe you wanna check that and then print out the Responder Chain to see if it’s disconnected somehow, or if maybe you're in the wrong branch or something, the thing that you expected to handle, that particular event, is in a different branch of the view hierarchy than you expected. That’s also been something that I've run into as well. What was the original question? I was on the train of thought and I lost it there. PETE: I was asking about whether you can get a response back; that’s what I was – I was thinking about it –. SAUL: Alright. PETE: It doesn’t fit the pattern, right? Like if you're firing an event, it’s an event; it’s not something where you're asking a question and expecting a response. SAUL: Right. So here’s the thing: you’ve got that ‘from’ parameter and you generally want to fill that in because that is kind of your only way to get back from where you were. This is kind of my original hack. When you have a network responder, you’ll generally want to know what's going on with it and one of the ways that you do that is having a delegate. So we basically will say, “Well, I'm sending this message; let me know what's going on – whether there's an error, or there's progress, or I need to do authentication, or something like that” so you have like delegate callbacks for that. Well, setting the delegate is not always an easy thing to do if it’s kinda that detached. If you're not using a singleton, which I hope you're not, it’s pretty hard to set the target. Think about the form of the SetDelegateMessage on any object, right? So if you have a delegate property, you get two methods: you'll get a delegate accessor which tells you what the delegate is, and you have a SetDelegate:mutator or a setter. If you look at it, it’s basically the exact same form as the action:sender syntax, right? In objective-C, we don’t care what the parameters are; we don’t do any type checking in our parameters. So one of the hacks that I did early on, just kinda messing around, was send the SetDelegate from self up the Responder Chain. That way, the network thing, the network objects that’s somewhere in my Responder Chain would send all of those event messages back to whatever it was that I passed in as the ‘from’ object. So I could set it as ‘self’ or I could set it as the ViewController, something like that. But basically it would set the delegate first – and like I said, these things are synchronous so that would be guaranteed to be called first – set the delegate on the ViewController, and then after that I could send just my general login message, and then after that, I basically got my communication channel between my network guy and my ViewController that has information that the delegate, or the network login command, might need and do all that [inaudible] that way. JAIM: Okay, so the ViewController sends something up the Responder Chain, saying, “Hey, let me know that I'm the responder to this type of event when this happens.” So when I press the button click for the login, it’s going to a waits for that response – am I getting that right? SAUL: It doesn’t really wait for a response other than the –. JAIM: Waiting is not the right word, but it kinda sits and does its thing until it gets the message from –. SAUL: Right, so this kind of whole little weird, kinda hackitty pattern that I came up with was kind of an abuse to the Responder Chain and basically using a setProperty method to set the delegate, so you can get all this – so basically you can open up this communication channel for yourself when you do something that requires much more callback information for you. PETE: Seems kinda of little bit sketchy though, because if someone else also is interested in finding out when that network call’s complete, these guys – because they don’t really know even who they're talking about, let alone who else is talking to that thing, so it seems like there's a risk that these guys are going to trample on each other and kind of take it, “I registered for a delegate for my ViewController, and then you registered for a delegate – you have a ViewController and suddenly I don’t, I'm no longer getting any notifications anymore.” SAUL: Right, and that’s kind of what I found; it’s just kind of like a hack. That’s why I'm explicitly trying to say it’s a hack, but it was a fun thing to discover that I could do stuff like that with the Responder Chain, because again that first parameter is basically the ‘from’ or the sender, and if that first parameter on your method is basically who you want to be the delegate instead, like I said, it doesn’t check types. It’ll just call setDelegate on the sender and it’s pretty fun. So as far as addressing what you're saying about the Responder Chain and that little hack – yeah, that is kind of a problem. That’s where I kinda inspired Graham Lee to write about a CommandBus pattern, which I guess he had seen from somewhere, so I guess this whole idea of a CommandBus that I recently released has been around for a while; I just kinda took some of the stuff and ideas that Graham had posted on his blog and in that little project that he had – kind of put it on steroids. And I think actually the CommandBus is really the Responder Chain on steroids as well. So what the CommandBus pattern does is lets us fire off command. The limitation, like you said, of the Responder Chain is we only can send objective-C selectors or messages that way. But the idea holds is that what we want to do is embrace the message-passing environment of objective-C, right? So objective-C is message-passing, so you can send any message to any objects as long as it implements it and it doesn’t – it won’t crash. And using the Responder Chain is basically a way to send a message to someone in the chain that might handle that. Now what the CommandBus does is kinda encapsulate these messages into a collection of parameters and also what it does and what I've been kind of experimenting with is encapsulate some logic. So if you want some callback logic within the command, so basically the command can7 handle some rudimentary parsing stuff for you before it passes it back to the sender, which you should also pass. I guess the general thing is, this CommandBus is really a communications channel through your application and really, to me, it’s kind of an extension to the Responder Chain pattern, even though it kind of sits aside from the Responder Chain itself. ANDREW: So the services, [inaudible] a bit like kind of a service bus, end service bus, that would be used kind of like an enterprise, like distributed systems. Is that a fair comparison to what we’re talking about here? SAUL: Yeah, right! I remember in my enterprise days I always looked at these message bus things, and things like a queuing system and all that stuff, and I thought it was way overkill until I learned what it was actually for, which is kind of basically load balancing and evening out the work load so work can still get done when the hardware, the machine is ready for it, which is kinda the way this thing works also. So yeah, it is a lot like that. I guess we noticed that after the fact. JAIM: So walk us through kinda the login thing we were talking about before, how that gets setup with this MGPCommandBus. SAUL: Yeah, so with the CommandBus, once you have that thing installed, you would have to set up your own little handler. There's a protocol in there, it’s MGPCommandHandler, that basically says, “Well can you execute a command, and ExecuteCommand,” and it'll also return an error.” If you're going to do the login, you'll still do the same stuff with the responder chain and all that stuff, and I do this with all the text fields and all that, but when you go to the actual login, what you would do instead is create a login command, and that you would want to extend from MGPCommand – I think there's a base class in there, but there's also an interface as well. What that will do is, basically, instead of – in the responder chain example you'd say, “Send a login message” and all that gets passed as a parameter is the sender. There's no username, there's no password, or hash password or whatever else; there's no way to call you back explicitly. So you can put all that information in the command, so you can just say, loginCommand.username=this, loginCommand.password=that; you could encrypt it before it saves it into the thing and all that stuff; you could have the sender so you could have where that command originated from, so basically who sends it on, so whoever’s displaying that view can be notified of anything that happens after the fact. You can also say, say like you know that this login command is for a specific service. Say, it’s like the Twitter [inaudible] login command, and it has to parson JSON. Well, you could eventually make a base network command that will parse JSON for you automatically and put that into some nice little properties in that command. So what happens is when that command finishes and it sends the command callback message to the object that you specified, the sender, it'll send you the command back, and then you can just query the command, “Well hey, what was the actual response? That’s basically have been preprocessed for you.” So by the time it gets to the view, you don’t have to do any parsing work already; it’s already been done by the command or the handler, or whoever decides does what work. But basically all you do is you create this command, you send it along the bus, and then the bus will handle it. That handler gets done; it'll create a little NS operation in the background for you, basically a queue, and process these stuff asynchronously. And you don’t have to worry about it at that point, other than making sure that your handler works correctly as far as network stuff goes. But basically, it is kind of a said it and forget it, and it’s asynchronous automatically, so I find that that’s kinda nice and it really defines the lines as to what the ViewController is responsible for. What happens after the command is done, if it’s successful or not, you can pop up your ‘login successful’ message or ‘failed’ or you could display the errors if you need to, that kind of thing. And it separates that view, that presentation logic from all that network business logic, communication logic – all that craziness that is headless anyway, this command bus really defines that line really explicitly, which is what I think the big downside is to a lot of the things that a lot of MVC haters say is that the lines get blurred, and I think that this will clean up those lines pretty well. PETE: I think I'm following with the idea that you – the ViewController generates this command, saying, “I wanna do a login.” And then that command gets put on the bus – where does the logic for actually doing the logging in? Is that embodied in the command itself, or is there some other thing that’s seeing these commands come along the bus and saying, “Oh login commands; I know how to handle those. Let me go ahead and do that for you.” SAUL: Right, I'm still kind of experimenting with it because it can go in the command or the handler. The idea with the handler is that’s supposed to basically execute the command. I've gone back and forth on this in my own projects, and I feel like I'm still discovering how this thing should work well but I think the general rule of thumb that I've come with so far, if it’s kind of plumbing stuff, like it’s basically like the network logic that is so general, like creating a NSURL session, setting the callback, setting all the things that you need to get a network communication thing to work is where the handler should be used and if you're doing command-specific parsing logic, or even command-specific setup logic, that seems to be where the command – putting that logic in the command is useful. For example, I've actually had to implement communication channel with Amazon s3 web services or the API. What I've done myself, or if you're familiar with it, you’ve got a basically signnin with your keys, your access key and you access secret, so you basically have to use those two pieces of information to sign all of your network requests. So what I've done there is I've got basically a generic network handling handler that will say, “Well, is this a network command?” “Yes” “Well, I can handle you.” “Now network command, give me a request,” and because it’s a network command, it knows that the command knows how to generate a request. In the request, I go ahead and fire off all of the requests singing logic – the things that you have to do to sign the header – and then pass that off to basically have that generate the request, and the request is generated in the handler. After that, it kinda continues on, and then it gets send off or in the network and gets it all back. And then eventually, what will also happen is the command will get some of the more specific callbacks when it does come back, do simple things like parsing the XML that used to come back from Amazon, and also cleaning that up into something that’s more appropriate for just an objective-C app, basically converting it into a NSDictionary that’s for easy, easy use down the line in the application. That’s kind of where I've done things so far. PETE: I'm a little skeptical about the implementation [inaudible] you have going on there were like if you got the network code in a base class and you’ve got your custom stuff in a subclass then it’s going to be really irritating to test that. If you are using composition instead, then you can just swap out the networky stuff, the fake networky stuff, but because you're inheriting and you're doing it that way, it’s going to be hard to fake out the network stuff if it’s coming in from a superclass. SAUL: Well yeah, there's no reason you couldn’t use composition over inheritance which is another rule of thumb there. But like I said, I'm still experimenting with stuff to see how things turn out. I think, generally –. PETE: [Inaudible] SAUL: I mean, just generally, that the command logic just has some of the stuff that basically will help the handler set things up, and also takes away the needfor the handler to know all the post-processing stuff. PETE: That makes sense to me that you want to just be able to plugin if you're making your own type of special command, you just wanna be able to plugin the stuff that’s relevant and all of that boring kind of plumbing is handled by a superclass or whatever. SAUL: Well it’s also handled by the handler itself, and like I said, that network plumbing is something that you don’t wanna do all the time. Generally, what people seem to do in their applications is write a network manager singleton, because manager makes it more official. Once you get singletons from your code, I mean, it’s all downhill from there. It really couples your application to this network thing and by sending commands you really don’t care if it’s an actual network manager, or if it’s this mock manager that returns pre-rendered responses and things like that. It really is a nice way to setup your application as far as decoupling things. PETE: I like the decoupling and I like that it gives you somewhere to put this stuff, [inaudible]. Like one of things, Saul I mean you talked about this I think, but one of the things that really irritates me about this debate or discussions around MVC is that people tend to seem to think that because there's an M a V and a C – everything has to live in one of those three places. I actually think – I know that’s not the case, you can just put all these stuff and write your own classes, and we’ve talked about this a few times on this show before, I think. But at the same time, I kind of like, “Atleast, another place to put this stuff that isn’t the ViewController, isn’t the model, and definitely isn’t the View.” So that’s kinda neat. SAUL: Yeah, well, what's nice about this is that, like I said, it’s a communication channel. It’s an MVC thing, but it’s also got kind of an input-output so that you can send stuff outside of the MVC architecture pattern that you’ve got for a particular set of classes for an app, and you can also get a response back. It’s still also doing things that MVC would do anyway, which is kind of have an observer kind of pattern, and that’s kind what the whole callback functionality the command bus does. It will just kinda let you know, it’s less observer and more of the Hollywood thing - we’ll tell you what's going on. And yeah, it’s just nice to, like you said, have a place for this stuff, which is, again, where everybody seem to put all this stuff in singletons and now you don’t have to put it in a singleton, and now you don’t have to have this stuff to be tightly coupled in your app. You also don’t have to have it live forever in your app. There are still things like life cycle that I need to work on for the CommandBus as far as being able to tear down certain handlers and things, but I think right now they kinda live for the life cycle of the CommandBus, but I'm looking at ways to kind of just clean it up so you don’t use the network if the network is down; it will just destroy the network handler and that way, you can’t send network commands well because there's no network – things like that. What's also nice is if you look at the CommandBus signature, you have a method for CanHandleCommand. I made that a class method because I just – basically, it’s just really simple validation for the handler that doesn’t do anything. It doesn’t instantiate all the heavyweight stuff that the handler would need to do to live like, say, it needs to set up a network. Well, if you can’t send anything to the network anyway, if the network’s not connected, why bother putting together an NSURL session in the first place. I kinda did that, whether it’s right or wrong – I don’t know, it could still change – but what's nice about that is that what you can do is it returns a Boolean whether it can handle it or not. So basically it'll say, you set up your command, say, “Can I send this network request?” and say you have a button that needs to work or be enabled and not based on whether the network is active, well you just prepare your command like usual and just send it up to the bus and say, “Hey, can you do this command?” If no, just disable the button. I've used this in a couple of places in my UI and it’s been awesome. All I do, when I'm ready to re-enable that button is recreate the command, resend it up the chain, and it’ll say, “Yeah, I can handle it now” and re-enables the buttons; it’s really nice. It’s decoupled, still. PETE: That’s awesome; that’s a really nice example of here that decoupling can really pay off is the UI or the ViewController doesn’t care why it can’t do that; it just knows “I can’t do that right now, so let me give that feedback in the UI without having to understand, ‘Oh, is the network available? Is my reach ability API doing whatever?’” SAUL: Right, exactly. And it’s getting all that specific [inaudible] away from the ViewControllers, which I think, really, helps to clean these up and get away from the Massive ViewController that so many people also seem to adhere to. I have noticed that even before my ViewControllers were, I would say, generally lighter weight; they’ve basically gone on a diet with this pattern. They basically only manage the pixels on the screen, which has been awesome. Enabling things to show up on the screen, or hiding things, or moving things around can really let my ViewControllers focus on the presentation of the pixels on the screen, which has been really, really nice to keep that separate. ANDREW: That’s something that we can all get behind. CHUCK: Yeah, definitely. JAIM: Two thumbs up. CHUCK: There you have the ViewController that has a single responsibility, more or less. SAUL: Right. CHUCK: And you have other classes, or other job handlers, or whatever you wanna call them, that are out there that do these other jobs so you can segment the responsibility according to where it actually belongs instead of, like you said, kind of piling everything up in the ViewController than just saying, “Well, I don’t know where else to put it.” SAUL: Well yeah, and it also helps my not putting things in a singleton, which is, like I said, a common solution to that problem of decoupling with – or you're segregating responsibility, but it still leaves things tightly coupled and I think this solves that particular problem as well. CHUCK: Right, because it’s just a message sent on the system that’s meant to handle those jobs. SAUL: Exactly. Again, it’s following the same message-passing paradigm; it’s just that the message in this case is a command that’s basically an entire class, so it’s kind of a message in steroids in the objective-C sense. CHUCK: Does MGP in MGP CommandBus stand for ‘Magical Panda’? SAUL: It does. I couldn’t think of a better three-letter acronym. [Chuckles] PETE: One last question, which may be a stupid question: the MGP CommandBus, is that using the Responder Chain, or is that an alternative to the Responder Chain? SAUL: It is an alternative to the Responder Chain. I had toyed around with kind of hooking it up inside the Responder Chain, but because selectors are different enough from Command Objects, I didn’t want to confuse the two. Now I'm sure what I could do is have the CommandBus be the first responder, wrap that selector and all that stuff into a command, and have that fire up the CommandBus and things like that – I could do that, I'm sure. But I hadn’t gone that far just yet; I kept them separate. And one of the things that’s also good to know is that, as far as specifically for the MGP CommandBus, is that I've made a couple of additions. I had mentioned as far as the Responder Chain, there is that sendAction to-from event method that’s a method on UI application. So what I'd done in the CommandBus is make a category on UI application that’s basically sendCommand. There's some variations on it: sendCommand from ‘self’, things like that, so that what you can do is – basically, it’s just the same paradigm. You're just following the paradigm that Apple has already stated with the API and just doing something along the same lines. So I try to make it very similar. It’s also got some handly setup helpers, so basically in your app delegate, you could just set an array of classes for the delegate method and it'll kinda set itself up automatically, on demand, so it doesn’t setup a CommandBus right away until you actually send messages or command up the bus, so. It’s a pretty nice project I think; it’s a very low-level plumbing project, but I'm hoping in the future for it though, to have some contributions for maybe like a network handler by default which I may contribute to have various handlers, and eventually maybe get a set of commands like a Twitter command, or things like that, that just kind of let me do all these things with the CommandBus. And the thing is, I know they're all asynchronous, I know they all can be handled in the queue and all that stuff. So there's still some things that can be done. One of the other things that’s really nice that should be pretty easy for the bus to do is to serialize the commands. One of the other methods, I guess one of the other interfaces that a command implements is the NSCoding, or the NSCoder – I forgot which one of them where it tells you that you need to use this to write stuff to. What it does is basically lets you serialize a command, so basically, you can save the state of a command to whatever, to disk, basically. And what this lets me do is eventually – and I haven’t added this is – eventually what I could do is basically let the CommandBus listen to the applicationWillTerminate notification, and basically say, “Well, all the commands that haven’t been done, let’s serialize those, and we’ll save to disk, and then the next time tht the bus launches, we can just say, “Well application did finish launching” and check out that notification as well and then re-inflate those commands and then just resubmit them to the bus and then everyone goes on their merry way. And that’s another thing that I think those enterprise things do is they serialize those commands or those messages so that they can be replayed later. PETE: Yes they do durable storage and all that from message bus stuff. SAUL: Yeah, so I mean, that’s definitely a possibility with this project – and I forgot what I was going to say about it – but it’s still something that could be really nice. Or what you could also do is basically save a collection of commands eventually and replay it, so if you wanted to undo, or maybe you undo some action and then you just kind of have a macro that’s basically a collection of commands in serial, you just send them to the bus, save off those commands in some kind of [inaudible] or something, re-inflate them and send them off again and again and again, and it really doesn’t care. There's a lot of neat things that you could eventually do with a bus, and hopefully, I’ll get to some of them. I'm doing what I need right now and I don’t need it to serialize just yet. PETE: And presumably, this is open source and on GitHub so you can leave and get some people to contribute so you don’t have to do all the work yourself. SAUL: Woah, really? Is that how it works? PETE: I've heard it, that’s how it works. SAUL: Is that what the kids are doing these days? PETE: Forking all over the place. SAUL: Get your fork off my lawn. So yeah, it’s open source, it’s out there. I think my GitHub repo is GitHub.com/magicalpanda and you can find it under MGP CommandBus there. Download the bits; let me know what's going on. One of the other things, the features of the bus that was also something that I needed was the idea of subcommands. A lot of times, I try to decompose bigger things into smaller problems, and that meant, for certain things, like just sending one giant command was just too much work – well, conceptually it was a lot of work, I guess, so I broke it down into smaller pieces. Basically what I have is the ViewController will just say, “Well, send this huge command” and what the command will do is send smaller commands that break it up into pieces and they set those subcommands –. Basically, the parent command is only done when all the subcommands complete, so basically the ViewController gets a true callback when everything is actually done. So hopefully that’s, “Oh, that is helpful for people.” CHUCK: Yeah, hopefully it does help some folks. I think the approach is a fairly common one, not just in mobile development but in general, having this kind of CommandBus or some kind of side process or way of threading out and handling things asynchronously, and there are different benefits to it; I think you outlined them pretty well. Let’s go ahead and get to the picks. Jain, do you wanna start us off with picks? JAIM: Well sure. I only have one pick: I'm going to pick MongoDB University. A friend of mine has signed up for this class and he is talking about it, and I’d done a little bit of MongoDB enough for – I wasn’t taking one of the beginning classes, but I signed up for MongoDB for DBAs, so most of my work has been this kind of a developer, doing stuff like that. I hadn’t really done like replica sets, setting of a cluster, sharding. Video’s actually very good, so yeah, I learned a lot. I've been going over the last seven or eight weeks; been watching a lot of MongoDB videos and they’ve got some homework and at the end they’ll give you a certificate, which is fantastic, right? Everyone loves certificates. It’ll actually be my first certificate, ever, on anything, but yeah. Overall, I've learned a lot, so I recommend it if you wanna get into MongoDB, especially if you're coming from a relational background, I think the one-on-one classes, I imagine, are pretty good, so a lot of good videos. Check it out. CHUCK: Very nice. Pete, what are your picks? PETE: I just have an image of frames of MongoDB University certificates now. [Inaudible] JAIM: It’s going to be my Twitter background. PETE: Yeah, I'm hoping it would come with like a nice kind of, one of those gold stars and maybe a ribbon. CHUCK: Oh, there you go. JAIM: Well I’ll buy one if it doesn’t come with it. PETE: Yeah, mail order. So my first pick is a conference, Mdevcon, which is in Amsterdam. CHUCK: [Inaudible] PETE: Yup, it’s happening in March I'm guessing, Saul may be speaking there? SAUL: Maybe, yes. Yes, actually. I'm given a keynote there on what's next in [inaudible] development, so that should be fun. PETE: I was – I'm actually [inaudible]. Mdevcon, I went there; I went # last year, I think it was last year. It’s a great conference in a great city in Amsterdam. Yeah, it’s a really good conference, so I recommend going. My second pick, I already picked this before, I'm going to pick it again because I can do that – Pragmatic Thinking and Learning is the book I referenced a little bit earlier on, at the start of the start of the show actually. It talks of the Dreyfus Model and kind of how our brains learn, and lots and lots of really good stuff in that book. I keep on recommending this book to people. It’s probably going to be – if you haven’t read it, it'll be the most useful book you read this year. How’s that for a sell? And my last pick, I'm kind of obliged to do this as an employee of Footworks; it’s a link to a presentation called, Does my bus look big in this? It’s actually an old presentation from 2008. It talks about how enterprise service buses, those kind of like big, gnarly things that we touched on earlier were actually pretty horrible to deal with. I don’t think anyone listening to this show is planning to implement a big ESP, big $ ESP, just because we were talking about message buses, but I'm obliged to tell you not to do that. Please don’t use [inaudible] or anything like that till your CHUCK: Alright, I’ll go ahead and jump in with some picks. So the first pick I have is I found it on the app store for my Mac and it’s kinda nice. Typically I'm not really using up all my memory, but sometimes I am, and it’s usually # fault, incidentally. But it is something that – it shows me how much memory I have free, and then it has some algorithms to free up memory, so I really like that. One other pick that I have: I used to register all my domains on godaddy, but between their tacky commercials and the fact that their user interface is impossible, I switched over to Hover, which is really, really nice. And I've been slowly moving my domains over, and I finally just got fed up and just wanted to get everything moved over, but I didn’t have time to go in and make sure that all of the DNS was correct before I moved it over, and so I called Hover up and it turns out they have a valet service. So I went in and changed my password on godaddy so that they can have the password – it’s not anything close to anything I've used anywhere else, and they are moving all of my domains over. So I'm really excited to be able to just be done with godaddy, and just another thing that I just love about Hover. So I'm going to pick Hover.com and we’ll let Saul give us some picks. SAUL: So my first pick is a Mac app, and it’s an iOS app, too. It’s been getting an update recently, it’s pretty nice. If you do mindmapping at all, it’s pretty cool. I use this to take notes and organize my talks for conferences and things. It’s called MindNode, and they’ve got a MindNode Pro version on the Mac app store, it’s really nice. The iCloud syncing actually works, and it’s got a Mac and an iOS app, so check it out. It’s pretty cool. My other pick is the Big Nerd Ranch. Recently I went to visit Pete up over there in San Francisco, which it’s amazingly and unseasonly warm right now, which is a pleasant surprise, but I was in San Francisco and doing some teaching for the Big Nerd Ranch, which I’ll be doing from here on end. So I’ll be learning the ropes for a little while, but I’ll be doing that as a new gig along with all the application development things that I do. So check out the Big Nerd Ranch; they do a lot of cool classes, and it should be fun. PETE: You’ve heard it here first folks! I'm exclusive, he’s exclusive now. SAUL: Yes, I scooped my own podcast. Yeah, kind of, [inaudible] JAIM: They’ll rush you out the door. CHUCK: This doesn’t go out for a week, so [crosstalk] PETE: Chuck, we gotta get this exclusive. CHUCK: Well there we go [chuckles] JAIM: I’ll do the transcript; I’ll do everything. Go! [Chuckling] I'm tweeting it right now. [Chuckling] CHUCK: Alright, we’ll go ahead and wrap this up, but thanks for coming Saul! SAUL: Sure, no problem. Hopefully I didn’t ramble too much. CHUCK: No, I think it was really good and hopefully I can make it out to Denver and we can go grab lunch again sometime. SAUL: Oh yes, especially after the Broncos win. CHUCK: Yeah. JAIM: You just have to face the number one quarterback in the game though. CHUCK: Oh man, I saw the meme on that, and now it’s a nation of Broncos fans against that guy, so I'm good. You guys can all be in the bandwagon for this one game; I’ll permit that. Alright, we’ll wrap up the show then. We’ll catch you all next week!