The panelists discuss VIPER with Conrad Stoll and Jeff Gilbert.

Transcript

PETE:  We had a huge fight, things were broken [laughter]; TV’s thrown out of the window.[This episode of iPhreaks is brought to you, in part, by Postcards. Postcards is the simplest way to allow you to feedback from right inside your application. With just a simple gesture, anyone testing your app can send you a Postcard containing a screenshot of the app and some notes. It’s a great way to handle bug reports and feature requests from your clients. It takes 5 minutes to set up, and the first five postcards each month are free. Get started today by visiting www.postcard.es]**[This episode is brought to you by Code School. Code School offers interactive online courses in Ruby, JavaScript, HTML, CSS and iOS. Their courses are fun and interesting and include exercises for the student. To level up your development skills, go to freelancersshow.com/codeschool]****[Would you like to join the conversation with the iPhreaks and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at iphreaksshow.com/forum]**CHUCK:  Hey everybody and welcome to episode 64 of the iPhreaks Show. This week on our panel we have Jaim Zuber. JAIM:  Hello, from Minneapolis. CHUCK:  Alondo Brewington. ALONDO:  Hello, from Atlanta. CHUCK:  Pete Hudson. PETE:  Good morning from Alamo Square. CHUCK:  I’m Charles Max Wood from DevChat.tv and this week we have two guests. We have Conrad Stoll. CONRAD:  Hello, from Austin CHUCK:  And Jeff Gilbert. JEFF:  Howdy, from Austin. CHUCK:  Do you guys want to introduce yourselves really quickly? CONRAD:  Sure I’ll go first. This is Conrad. I’m an iOS architect here at Mutual Mobile. I have been doing iOS development for a few years now and I feel like for the intro that I’m missing out – not listening to the intro theme. I think we have to type that in somehow. I’ve been listening to the podcast for few months now and really have enjoyed it so it’s a pleasure to be on and get to talk to you guys. JEFF:  This is Jeff – also an iOS architect been doing iOS for about four years now. I started doing my app stuff way back in ’91 so I’m definitely a fan and familiar with the Apple platforms. It’s a pleasure to be here and talk to you all. CHUCK:  Awesome. So we brought you on today to talk about VIPER. Now I’m not sure how many people are familiar with it and I think most of us have briefly looked at it. Do you want to give us a little bit of introduction to what it is? CONRAD: Yes. It’s sort of an application architecture – a way of structuring your application and it’s based on an Uncle Bob’s clean architecture – if you’re familiar with Uncle Bob. It’s a use case sort of an architecture where you take your use cases – the main features of your app – and that forms the central point that you focus on. That’s just where your core business logic, or what we call the interactors, and then from that you take your user interface to access the plugin to the application. We tend to follow model representer or MVP, and so your presenters are sort of the presentation logic that could get beta the user, feed it into the interactors to process, and then it takes results and formats it for display. Lastly, you have [inaudible] UI widgets. The main benefit of that is it makes it easy to split out your business logic and presentation logic, and allows you to use TDD to try to develop one of those classes.JEFF:  So the full thing stands for Viewer Interactor Presenter Entity Routing. As Jeff likes to say, it’s actually a backronym which means that we came up with the term VIPER first to fit Viewer Interactor Presenter and then Entity Routing I think describes all two additional components that end up being very important, which is how you model data, which is referred to as the entity and then routing, which is sort of a way of talking about navigation. It’s how you transition from one screen to another, and that’s where things like a wire frame class come into play, so there’s a couple of different ways you can do that with VIPER. JAIM:  Okay. You just said a lot terms that are probably outside with what a lot of iOS community is used to hearing. Interactor; presenter is still kind of new; routing – can you give an overview of what these sections are? What were you talking about? CONRAD: So the interactor is basically your core business logic. Let’s say you’re writing a banking app and one of the features is you want to transfer money from one account to another.  The interactor would be the core business logic that’s independent of any user interface and that’s actually the problem that has existed for the bank forever, is how to do this. The business logic involved in transferring money is, you have to collect a “from account” and a “to account” and the amount that you want to transfer. It involves things like making sure you have that much money in the “from account” and all that. All these business rules don’t care about the UI and [inaudible] maybe talk to database – those are web services – so that feature, you can use TDD or test-driven development to drive out the implementation and expose all the dependencies that you need like a database, etc. Once you have that core functionality working then you can wire it up to a particular user interface. From that you may develop a presenter next which is responsible for gathering input from the user and preparing it; getting it in a format that is convenient for the interactor to consume. The presenter is basically responsible for the interaction designer. I don’t know if you wanna step back –. In Mutual Mobile, I have the luxury of large teams. We actually have [inaudible] developers, we have interaction designers, we have visual designers, and of course we have our clients – we refer them as the business designers.CHUCK:  I like that term, business designers. JEFF:  Oh thank you. So in that sense you sort of have the designers – the ones that are actually designing the solutions. So you have your business designers – the client – that have their real business need; you have the interaction designers and the visual designers that design the UI – they are the ones that actually are responsible for all the requirements of the system. Once they have all the requirements then it’s up to the developers to turn all those requirements in the source code. So in a sense, the interactor is responsible for the business designers and the requirements of the business designers comes up with are implemented in the interactor. The requirements of the interaction designer come up with our example of transferring funds between accounts. They may say, “Okay, I want to let the user type in their account numbers and the amount”, for example. All the logic of gathering input, that data from the user, and sending it to the interactor to process and then the interactor will run its business rules or business logic and then send the raw results back to the presenter. The presenter would format that in a way that’s easy to explain your user interface, so if you have currency values that’s where you’re going to use your NSNumber formatters to format that into a string. Then, the presenters simply tells the view, “Here, display the screen as the current balance”. Again, all the presentation logic in the presenter is also independent of any actual UI widgets, so it is also easy to use TDD to drive the development and design that class. PETE: What’s the relationship between the presenter and a traditional UI view controller? [inaudible] UI view controllers in this model, or is it totally divorced from that?JEFF:  When you’re developing the presenter you’ll sort of drive out a view interface, in abstract view not in UI view, and so your view may have things like setCurrentBalance and setAccountNumber or whatever. You’ll have an implementation of that view interface and that will be implemented as a controller. CONRAD:  The presenter, in effect, kind of drives the view controller itself so the view controller, in single responsibility terms, is mostly responsible for layout and for receiving user touches and input – what it’s meant for is receiving touch events. Then the presenter is what knows, “Okay so this is what data needs to go where”. So it has the ability to tell the view controller what actual string to display in a certain label. Also, when a certain event happens, let’s say the user tapped on a cancel button or send button to execute that transfer. What actually happens after that, the view controller will tell its presenter, “okay this is what happened”, and then the presenter can decide, “Okay, a button was tapped and so I know I’m going to take some action like execute a web server request”. So it removes a lot of that responsibility from the view controller and out into different objects. PETE:  So the presenter’s kind of the bridge, in some sense, between the UI and the core domain application logic? JEFF:  Yes. It also conforms to the single responsibility principle. If the views are responsible to the visual designer, and presenters are responsible for the interaction designer, and then interactors are responsible to the business designer. ALONDO:  In this approach the entity is not seen by the presenter of the view, correct? JEFF:  Correct. The entities are only manipulated by the interactors so they may load up a number of entities from the database or web service or whatever, manipulate whatever it needs to, and then when it sends the results back to the presenter, it will just use a simple data transfer objects, or structures or just simple NSObjects. CONRAD:  And kind of one way where you can see that in practice is using something like core data. You may want to use core data for persistence and structure if you want to have object graph with relationships from various objects to other ones, but you may not want to expose the complexity of core data to your UI and certainly you don’t want to have a lot of strong references out there to NSManagedObjects; it could get kind of changed and invalidated out from under you. That’s another case where the separation in the layers using the data transfer objects to transfer information between the interactor through the presenter to the view, is actually a really good architectural benefit that you have because you don’t have to worry about having still data and things that stay that shouldn’t really be persisted. In that way, you have a little bit more control and flexibility about how data goes from your model layer to your tier view layer. ALONDO: So would that be considered in the sense of view model [inaudible]?CONRAD:  Yes, I think so. PETE:  I’m cheating and reading about blog post introductions to VIPER, blog posts and stuff on the Mutual Mobile engineering blog, a link to that would be in the show notes as I posted. From reading through this, this isn’t like a framework where there’s a presenter superclass that you derived from an interactor super class. Most of these are just regular old objective C classes, right? JEFF:  Correct. It’s just more sort of a guideline. The9 main concept to drive home is just the fact that you want to separate those concepts of your business design from your virtual design and from your interaction design. So even if you have a current project that has a massive view controller where you started doing all that at once, you can even start to apply that simply with a current system. Say, if you have one method that is mixing business logic and presentation logic, if you can just start to identify these are the parts, this is what an interactor would be responsible for, you can just start to pull out those methods even if they stay within your view controller. You can just end up with lots of smaller methods, each one targeting either features of the interactor that this design or the presenter of the interaction design and that would be a good first step. Once you have all these small methods targeted at different responsibilities, then later you can start to pull those into separate classes. PETE:  What I’m hearing from you reading between the lines is you’re kind of modeling the architecture of the classes a little bit based on the people who are working on that area of the application. I think that’s a really interesting approach. That’s kind of like using Conway’s Law to your advantage. Like, saying these people are interested in this part of the application and so I’ll shake the application so that that different parts are in different areas within the app. JEFF:  Yes. If the interaction designer needs to make a change you sort of know which class. You say, “Okay I need to go make that change in the presenter”. Ideally, it won’t have any effect on the interactor because the interactor doesn’t really know what the presenter is doing and it may or may not have an effect on the visual design. JAIM: It sound like this a really clean way to break up a massive view controller, like you were talking about. A lot of things don’t really fit into MVC [inaudible] do the things like talk to a web service so the question has always been, “Where do you put this? Do you put it in the model?” It actually always just throw in the view controller so the interactor and presenter kind of break out different things that generally would go in the view controller and just make it humongous. So the  presenter and interactor are two different parts of that.JEFF:  Yes. From the point of view of a view controller, you think that the presenter is an implementation detail of “What content do I need to display on the screen?” Since that is an implementation detail, you have the option of I have the data from the user, “How do I operate on it?” That is really just an implementation detail that you can split out into an interactor. JAIM:  That makes sense. So something like with our banking example, maybe the user enters an account id and maybe they had entered something completely wrong but that would be handled maybe by the presenter if that’s something that would not even conform to a regular account id. Can I get past that layer and then go to the interactor and behind the interactor is maybe a web service, which is calling to make sure they have money in the bank or something like that? Is that how things lay out? JEFF: Yes. The interactor can be designed to only operate on valid data. It’s up to somebody else to do that validation, to make sure that only valid data makes it to the interactor. That would be the role of the presenter and so the views are rather dumb. The passive views and MVP [inaudible]. So if the user types data into the field, they gets passed to the presenter and he sort of holds onto that state. When you say “transfer,” the presenter can run all of these validation logic to say, “You entered a positive transfer value” or it can make sure the account numbers are valid. Once it’s happy [inaudible] user, then it can pass it on to the interactor and if not, then it could just present appropriate feedback to the user.JAIM:  So talking about MVP which is Model View Presenter. Do you draw a distinction between that and like MVVM – Model View ViewModel? Do you think they kind of like ball together? Or do you make distinction? JEFF:  Not really. As you say, together with the view and the presenter, they work together to implement the UI and the whole UI acts so they plug in to the application with the interactor actually being the application itself. So if at that point, if you’d only use MVP, if you don’t want to use MVC just as a presentation architecture or MVVM, it’s certainly a bit easy enough to just plug those into the interactor instead. JAIM:  OK PETE: These interactors are more like [inaudible] coming from a domain-driven design [inaudible] – I guess they’re like service, right? They’re not like domain objects representing an account or a user. They’re more verbs than nouns. Is that accurate?JEFF:  Yea. Basically they are the implementation of a user’s story. They’re basically your application logic. CONRAD:  I like the analogy to domain drive design. That’s one of the ways I think about some of the inspiration behind this. If you’re designing for a specific screen – let’s use the example of the transfer screen again, you can think of it very much from a domain driven design standpoint and there will be certainly some model objects indicate like a transfer or an account and things like that. Then the interactor is certainly going to be built around the goal that the user’s trying to achieve on that particular screen and then the presenter is going to be all about making sure that the data related to allowing the user to reach that goal is presented and formatted and displayed in the appropriate way. I think that the domain-driven design philosophy definitely still applies here PETE:  I guess I’m still trying to make sure I understand all these stuff so I’m going to keep on asking silly questions. Maybe not silly. The entities – are those more like domain objects in the DDD kind of sense like a rich domain object, like an entity in that sense or are they something kind of like an interface? Do they map directly to kind of core data or something like that? JEFF:  They’re probably what most people classically refer to as model objects. Most of these terminology views, interactors, presenters and entities that comes from clean architecture as defined by Uncle Bob. So basically, entities, they are your model objects, and they would contain the application independent business logic. So if this model object or this entity were to be used in multiple applications, then that bit of logic that would be used across all those application would be the entity. But then any application dependent business logic – that will belong to the interactor. CONRAD:  So one interesting application of this is if you consider an iOS app that needs to work across iPhone and iPad and we even decide some of the adaptive UI principles from ios8 at WWDC this year. Let’s say there is a case where you have to provide a different UI implementation for iPhone versus iPad. But most likely what’s going to be the case is that your business logic and everything surrounding that for the actual feature will likely be the same; just the visual implementation will be different. In that case you can use the same interactor to implement the business use case and have a different presenter view which will end up being in a different view controller to actually implement the feature visually. I think that is one case where we have seen a lot of benefit to using VIPER, is in projects that we now need the support that type of structure. PETE:  Interesting. I’m sure that that you’d still be able to reuse a lot of these stuff, but in the example where – we’ll keep using our account banking application example. Let’s say you’ve got on an iPhone a three-screen flow to transfer money so you have to select some stuff and then go to the next screen and then type in some values or something and then go to the next screen and then confirm your payment. But then on the iPad, you’ve got extra screen on the real estate so you can shrink it down into two screens. Would you still be able to reuse everything all the way back to the interactor, or would that mean kind of rearranging a few other things as well? CONRAD:  I think we’d be able to reuse everything. What you might end up doing – just to make things simple – is you might have a presenter or maybe an interactor, but most likely a presenter that would know about multiple other presenters that it might use to format itself. Let’s say you have the standard split screen approach with a list on the left and the detail on the right to control both of those separate screens. You might have a single parent presenter on iPad that has access to the two different presenters for those different screens that are used on iPhone. I think that’s something that you can do, which is okay, that you’re creating a new class and composing it from the two other presenters that are used more on iPhone and you could follow a similar pattern with the view itself when you have a single view controller that contains two separate view controllers and you know that stays consistent there. The interactors, you could probably most likely use unchanged because what those are really doing under the hood are doing things like managing access to data and making requests and things like that. So that’s the type of stuff that’s unlikely to change anyway. PETE: And going back to that thing, kind of the representation of a use case or a user’s story – the use case is the same, you want to transfer funds from [inaudible] to savings. It’s just the UI for that, the way you achieve that goal, would be different on an iPad versus an iPhone.JAIM:  Does Mutual Mobile do most of their apps using their architecture? CONRAD:  At this point, yes. I think maybe, Jeff you want to go into a little bit on the history behind this but we’ve been certainly using this for over a year now on projects internally. JEFF:  The way it came about, going back to Uncle Bob, he has a video series called the Clean Code video series and one of the things he talked about in there is the notion of this clean architecture. When I saw that, it became apparent that it does make TDD a lot easier, which historically has been something considered very hard to do on iOS typically due to the massive view controller problem. For me, trying to implement clean architecture which is VIPER, is our implementation or applying of the clean architecture to the iOS environments and frameworks. To me, it’s really just a means to understanding how to make better use of TDD in the systems. CONRAD:  I think that was definitely where it started to take off a little bit is certainly in the community. You could tell that the iOS community was getting a little bit more serious about testing in general but also TDD. Going back, I think around two years ago, that really started to take hold and we were looking at that internally and trying to figure out how to apply that to our projects. We went through a lot of different efforts trying out all sorts of different testing frameworks, whether it was GH unit or using something like OC-mock or trying out completely different types of testing using UI animation or KIF or even Kiwi – it was another one that we tried out. The testing frameworks were all great and helpful but certainly the way that the app is actually structured and architected tends to matter a lot more for how easy it is to test versus what framework you’re using. I think a lot of it which is juswas just our internal figuring out how we are going to write code that’s more testable. PETE: I can imagine because most of these are just regular odd objects. Its way easy to test and you’ve got this nice, passive view thing which just slices out any sort of framework [inaudible] sp you don’t have to deal with that in your test code. With this architecture the view part becomes super-duper skinny, right? The stuff that is actually involved with Cocoa Touch framework, or sorry, with UI kit becomes very skinny. Is it even worth writing tests at that point? Or the view is so dumb that you can just test them at a higher level?JEFF: To me, one of the benefits of TDD is it helps you drive out the interfaces of your collaborators and so while you develop the interactor, you sort of drive out the interface that you need for the presenter and then as you implement that, you sort of drive out the interface that you need for the view. And so by the time you get to the view, there has no more dependencies so you could stop there. In a lot of times, I will continue to write tests to make sure it communicates properly back to the presenter so that when you tap a button [inaudible] all right and a test to make sure it actually calls the appropriate method on its presenter, but is [inaudible] necessary.JAIM: Yea I found those types of tests actually pretty valuable. It seems pretty redundant to make sure your connections are tested and I think they seemed very simple but when you get into a piece of code and you need to change it or refactor it or someone else that hasn’t worked on it before does it, it’s nice to catch those changes right away. “Oh I didn’t hook up this thing” versus it’s in a different screen that only happens in certain conditions that you don’t really run across. So I found testing the views [inaudible] pretty valuable.JEFF: [inaudible] serve as good documentation have in those tests, like this is how I expected you to behave.PETE: Yes. I’ve had the same experience of being kind of surprised because it seems – I felt like a bit of a TDD kind of dogmatic zealot doing it, so I stopped for a while to see what would happen and it turns out that I accidentally break stuff quite often when I don’t have tests [laughter]. And the feedback loop is worse when it just randomly crashes because I renamed the thing that the nib was trying to bind to or whatever.JEFF: I’ve noticed that I spend a lot less time in the simulator because I spent all my time hitting command view, so by the time I developed the interactor and then the presenter and then the view, at the end of all that, I finally get around to running the app in the simulator and it usually works the first time because all the tests, [inaudible] that it’s going to work. [Crosstalk]ALONDO:  I was going to ask you, for an organization that may not fully adopt testing and may not be sold on it. How would you approach them and convince them that this is the right way to go both in terms of VIPER and in terms of TDD? JEFF: That’s a good question. It still can even be a challenge internally to get everybody sold. I finally understand why I can actually save me time in the long run. I can see why people think spending extra time writing the tests will actually take you more time but I think if you just straighten off that time, you’re not spending as much time in the simulator or in the debugger, so that time you save not running in the debugger all the time to drill down to screen, you’re actually working on that time is what you spend instead of writing tests. The benefits are you get a better design system and you also have a nice regression suite. So that when the changes come along later, it will be used to make those changes and know you aren’t breaking anything. If you do follow TDD in the old refactor after every time you get a test going [inaudible], if you refactor, then you always keep the code clean. When you do have to make that change 3 months from now, the code is in a good state so it’s easy to find what you need to make that change.JAIM:  Yes a very common anti-pattern when you’re trying to start testing your apps to not refactor after you have written your tests. You know - refactor your code and also refactor your tests so those are clean as well. JEFF:  Yes. JAIM:  If you don’t do that, then you will have too messy code bases and to test really won’t help you at all JEFF:  To me, refactoring is the fun part; when you see the code actually getting prettier and prettier, to me that’s rewarding. But I can see why people are easily skip that step.  For sure I don’t want to mislead people – learning TDD is hard and it does take a lot of practice but if you stick with it, it is definitely important in the end. JAIM: I found even if I’m not writing tests for our project [inaudible] it has improved my approach to writing code so I’m writing better code automatically even if I’m not specifically writing tests – a side benefit, which isn’t always thought of.JEFF:  It definitely changes your thinking approaches to code design, I think both the active writing tests, the training of learning how to write tests and also learning how to write clean code in general. Even if you’re not doing it at the moment, it definitely helps you think through because you follow the same thought process of thinking through the edge cases and the scenarios that you would be writing tests for anyway. I think certainly the tests pay off on projects that you’re going to be working on for a long time and going to be maintaining for the long haul. It’s definitely worth it and it pays off, but even if you’re just working on something small for yourself that isn’t going to be maintained long term, it can still help you save a little bit of time there by just making it easier to work on for the short amount of time that you’re working on building the first draft. PETE: Getting back to Alondo’s question, like convincing people to go with TDD, does Mutual Mobile [inaudible] work for clients or you are kind of handling the entire development cycle?CONRAD:  Right. So we do custom software for other people so whether it is building a new version of an existing app or building a completely custom product from scratch, we cover the whole gamut there. We have really done all different kinds of ways here whether it was a project that was started from the get-go with a TDD style approach. Certainly, we have done a couple of banking and finance and healthcare type of products and so I think those are, in particular, prime candidates for that style. I think for something that a banking app that is going to be so large and complex but also need to support a rich user experience, you kind of intuitively grasp that having tests and having a really robust clean code base would be nice to have. But until you actually see the final product and see that the code base is still easy to change and easy to interact with. I think that’s when you understand the full value, is seeing what it’s like in the finish line. Anybody can imagine the effects of working on a poorly-designed code base that that’s large but once you see it actually well-done, I think it can be very eye opening to everybody. The whole organization can learn from that kind of success. JAIM:  One of the groups I see that adopt TDD are companies like yourself that do development for other people and can they can kind of define saying: “Hey, this is how we develop software; it’s more reliable.” That’s why another group of companies that are accepting of TDD and IOS are maybe bigger ones that do TDD in other areas. I don’t see it very common where we have some random IOS developers saying “Hey we should do TDD” and having that work, I think there’s a lot of resistance to it. CONRAD:  Yeah I think the main argument I would make for it is you start to realize once you have been developing on IOS for a while, I think that early on people, have the impression that this is just kind of baby software. It is just something small, it’s just in your pocket, it is not a big deal, it’s low cost of ownership but the longer the platform has been around, we see that that’s really not the case. Every year we are seeing rapid improvement and change in innovation for Apple on the side of updates to the IOS Operating System. You see that if you are really serious about having a product that exists on the app store, it does require continual investment to keep it updated. It is not just to write it once and leave it out there for 5 years and expect it to survive. It is going to require continuous work and upkeep and taking the time and putting the thought in to build a reliable code base with a clean architecture and hopefully also the test is going to make that easier to maintain over the long term. JEFF: I think one issue that can make it harder for any developer to adopt is [inaudible]. They are sort of wearing all the hats. They are the developer amd they’re the visual designer and the interaction designer and maybe even the business designer if they are writing around apps. It is easy to blur those lines and not realize which hat you are wearing at any given point in time. I guess if you did adopt something, try to adopt VIPER, it would just encourage you to be more explicit about which role you are fulfilling at any given point in time when you are developing your app.CONRAD:  It is also about where do you invest your time learning something new. Are you going to invest a few months learning TDD or few months learning iOS8 extensions or something else? – Like that some of the feedbacks we get internally. Where do I find the time to learn this new development methodology as well as everything that’s coming out every year that is new on iOS? JEFF:  That can be a tough question to answer too, but I think that one thing that’s great about TDD at least is it’s something that applies to all platforms and technologies. It’s a practice that once you learn it on iOS, you can apply it just as well on another tool chain. Or if you learned it before, likely you will be able to apply that just as well to iOS these days, given the tools that we have. I think that’s one positive – the technology here, it’s a bit of a training that you can do for yourself that will make you a much better all-around engineer. JAIM:  So when we are talking TDD, are we talking like the strict write your test first approach and let that affect your design or is it more of a relaxed use of the term? JEFF: I follow in a strict sense where I will use the requirements given to me to –. I’ll first write some tests that express those requirements and then ticket those tests to pass all – drive out the design and I follow sort of via Mock Roles, Not Objects [inaudible] – by the guys that wrote the GOOS book, Growing Object-Oriented Software Guided by Tests. As I understand that I need some collaborator to help me out with this implementation, then I will start to create mocks at that point to implement the interface that is just now growing in existence.PETE:  I am curious, can you do that inside out or outside out that they advocate in the GOOS book where you start with a high-level test that fails and then spiral into doing a bunch of low-level tests that fail? I find that challenging in iOS because it’s harder to write those high-level tests. JEFF:  So right now I do more of an inside-out, but I would like to get to an outside-in approach, starting with these high-level acceptance tests which, I think, then becomes acceptance test-driven development. And yes, you say it is hard to find good toolchains to do those high-level acceptance tests. I am starting to explore fitness – you use wikis your acceptance tests, then you automate those and then you would fall into a TDD loop to satisfy one of those failing acceptance tests, but I am sure that would be a long journey. PETE: Actually that makes me think of wacky ideas of things you could do once you have this VIPER like approach, where you have this very clean – one of the things I really like about this is there’s a very clean separation between the view layer – sorry, I am trying to figure the right word to use – the UI kit stuff and the rest of the application. The stuffs that knows about the UI kit becomes very, very skinny right? Like it is the opposite of a massive view controller; it’s a very, very skinny view controller. Could you just replace the view implementation with a driver – like a window driver, in Martin Fowler lingo – and actually drive the whole application, so have the entire app running top to bottom [inaudible] everything else the real implementation  of things, but just the face of the application is replaced with a test driver and do some acceptance testing in that way?JEFF: Yeah, I think that would be certainly feasible. It’s like your presenters, they know nothing about the existence of UI kit, but they certainly deal on foundation objects, so your presenter knows about formatters and strings and numbers and all that. Since you have a nice interface as a protocol, yeah, you could easily just have your factories if you want to load up the app and have your factories create, instead of UI views, they could be effectively your test runners. Your test runners could basically load up the presenters and interactors and wire them together and then just drive the [inaudible] this value where I’ve said I wanted to transfer the value, transfer the funds, so then you could actually have the actual presenter and interactor logic run as your test.PETE: It would be interesting to see that. I have worked with similar, but very different, frameworks or methodologies in the past where we’ve had that same very strong separation between UI kit and the rest of the app, but we went ever further and just replaced the rest of the app with JavaScript runtime instead. One of the really nice benefits of that is you can test, do really high-level, almost poking the UI type acceptance tests. Because you got this really, really aggressive segregation between the UI and the real application, it is possible to do that. It seems like if you follow this VIPER architecture, then you’d get to the same place where you could just pretend to have test drivers – little test drive things that pretend to be the UI, that pretend to be those views and then you can test everything else exactly the same as it would be in production as it were in [inaudible] but without having to deal with all of the really fiddly annoying stuff of the acceptance test, which is driving UI kit.**JEFF: **Yeah, [inaudible] that’d be pretty interesting.PETE:  Yeah. CHUCK:  So I don’t know if anyone asked about this, but does Swift change anything about the conversation at all? CONRAD: One of the things that we did is after Swift was announced is we rewrote the sample projects in Swift and I think that was certainly interesting for me to see. One of the things I am super excited about with Swift is kind of a lightweight structs that are also a little bit more interesting in terms of they can have methods and so on and so forth, so I think the structs fit very well into some of the data transfer objects for example that VIPER tends to make heavy use of, that a lot of those feel very natural is with structs, which I think is really great. Yeah, I think the structs are definitely interesting. The type safety is most likely a plus when you have this many layers as you end up with in VIPER. I think the type safety will more likely help you solve more problems than it would cause, since it is always possible you could slip up and have something come through one layer that’s the the wrong type for something else [inaudible] they was expecting something different.  We are certainly pretty excited about Swift here as everybody else as well. It starts doing something different. Certainly your test could also fix those problems, but it never hurts to have a little bit of extra layer of support there. We are certainly pretty excited about Swift here as I am sure everybody else is as well and we’re looking forward to seeing what it is going be like for VIPER. We’ll most likely end up having to really build a whole project in Swift to see how it is really going to play out. The biggest concern right now is the fact that there is no access control; there is no private protected public right now in Swift and that’s something they’ve promised that’s going to be added hopefully before the final version or the 1.0 Version shifts this fall. That would definitely be something we would like to see, although it does support protocols, which is something that VIPER does tend to make good use of, so it’s certainly impossible to user VIPER with Swift. It’s just not ideal until we get a little bit more access control.PETE:  Can you elaborate on that a bit? I am slightly surprised to hear that because I feel there is a strong correlation between people who are into Uncle Bob style things and – I guess maybe I am more of a background in Ruby where people do not get into public private stuff anyway. What’s the concern there with VIPER and private methods? JEFF: I just tend to write lot of private methods. I write lots of very short methods that just do one thing and that sort of [inaudible] makes a distinction between high-level policy and lo- level implementation detail. All your crucial public methods, those should be written in terms of a high-level policy of what you are trying to implement, and then they’ll end up calling one or more private methods to actually implement the individual steps of that policy. And if all your methods are public in Swift then it’s easy to maybe call the methods that you should not be calling.CONRAD:  Yeah, I think it is less about trying to prevent access to some methods but also it is more about making it clear what it is. ALONDO:  Public API. CONRAD:  Right. PETE:  I suspect that – well, maybe I haven’t used Swift a lot in Angular, but I suspect that because writing Swift code is going to be more pleasant than writing objective C code just in terms of the noise, I think what we might find is that when we stop writing lot of little classes, that stuff that you don’t want in your public API would become a different class that you are using like the stuff that right now is in the private bits of your class. I see a lot of smaller classes with each class obviously having its public API but the high-level classes don’t expose the low-level classes that they are using. Maybe. I don’t know. We will find out. JEFF:  Yeah, that’ll definitley be an interesting journey to get there. JAIM:  It is a useful dream at least. JEFF: Yes [laughter].JAIM:  It might get nice. I was wondering – you guys talked that you do a lot of mocking. Are you seeing any mocking frameworks or any activity on that with Swift that’s going to change a lot of things? CONRAD:  Certainly is. I have not actually seen anything yet. JEFF: I haven’t noticed anything either, so I don’t know if the – I’m sure [inaudible] another statically typed languages, but it seems like mocks are easy to deal within a more dynamic language like objective C, so we have to see what Swift comes up with.JAIM: Yeah, most of the goodness of OCmocks and things like that are the objective C runtime things, that dynamically [inaudible] stuff, which makes it very nice to write tests for. But you have static type, and I think the type system itself is – the runtime, how they create these structs is more [inaudible] C++ with their virtual tables and things like that which you can mock in C++ but it is difficult, so I’m looking forward to seeing what happens with that.PETE:  Yeah, I am a little bit nervous CONRAD:  Or We may have to go back to manual test levels and just write your own spies and things like that. PETE: I think I read somewhere that they are going to – it’s stuff where you don’t have to do interrupt with objective C; there is not even a dynamic [inaudible]. It’s like hard-wired and compiled [inaudible] it’s got no option in terms of mocking things. Maybe I’m just [inaudible].JAIM:  There is always an option. It’s just how deep you want to go. PETE:  Yeah. JEFF:  Apple seems to be more involved in, like XT test. They are continuing to expand that, so maybe they will add their own mocking framework to the XT test library. PETE: I don’t trust Apple to get that right. [aughter]**JAIM:  I think I agree with you. PETE: **OCMock has been around for 10 years they’ve had 10 years to –. Apple loves to reinvent tools that are already there and working; they’ve decided to build their own CI framework. They’ve had 10 years to build a mocking framework and they haven’t done it. I’m not sure they will do it and if they do, I am convinced they will get it wrong. [Laughter] That’s my micro rant over for the day.CHUCK:  Well, there you go. PETE:  I got one last quick question. Hopefully it won’t be too long. So playing devil’s advocate here, and I very much am playing devil’s advocate because I really like some of these ideas, but I also know that there’s a pretty large contingent of the Apple development community who want to do as much stuff the Apple way as they can. If I was to pretend to be one of those people, I would say, well, I have to do all these extra stuff and make all of those extra things like why can’t I just use view controllers and stuff like Apple wants me to do? Also I don’t believe in testing, so don’t try convincing me that testing nonsense. Is there like a good argument beyond the testability to sell someone, if I wanted to sell someone on this, I guess to counter the thing that I hear a lot basically when I talk about architecture in general. It’s just like, “Oh, there are so many moving parts. It’s way simpler if I just build everything into the view controller.” What techniques have you guys found arguing the case for this? CONRAD: Certainly one of the cases you can make is if you are working with a development team – if it’s more than an individual – then the benefit of having everyone doing the something in the same way can pay off. That way, let’s say, Person A implemented something for the first time, then Person B needs to go back and modify it or fix an issue then if everyone agreed on an architectural style of what goes where, then it can be a lot easier for person B to come in  and still be really effective. Obviously the case can also be said for if everything is always in the view controller, it’s easy to know where to fix it. [Laughter]PETE:  It’s all in one place! CONRAD: Right. I think we’ve all seen where that breaks down and doesn’t take a whole lot of experience on iOS to see where the pitfalls are with that kind of approach. I think most people are starting to [inaudible] that. Once somebody has that epiphany, that that’s just not the right way to do things, you can make proposals like this. I think once you try it out and see it in practice, it’s really not that much of a learning curve as it sounds. Looking at the 4000-word article on objc.io, it can seem like a very daunting process to architect an app this way, but when you look at it in practice it is only something like 6 or 8 classes in a little group in Xcode. All of them are pretty much NSObjects or UI view controllers already, so once you actually implement it in practice, it comes a lot less intimidating.JAIM: Yeah, and at a certain point if a 3000-line view controller doesn’t scare you, there is probably no help. [Laughter].JEFF:  There’s no coming back. JAIM:  It’s perfectly fine to have something this big. At that point you just don’t even bother trying to give us some of anything. CONRAD:  Yeah. CHUCK: What you do is you wait a few months then come back and try [inaudible].**PETE: **Yeah, how’s that been working out for you? [Laughter]**JAIM: **You [inaudible] one little feature. No, it’s probably 5 different things.CHUCK:  Alright. Well, it sounds like we have pretty much wrapped this up. Should we get into the picks? ALONDO:  Sure, sure. CHUCK:  Alright. Alondo what are your picks? ALONDO:  I have 2 picks this week, and they’re tools which I use frequently, actually; I used them boththis morning. The first one is Charles. It is a web debugging proxy application and basically it is a good tool to sort of monitoring your HTTP, SSL, GPS traffic between your client machine and the Internet. You can also filter through your mobile device as well, which is what I used it quite a bit for when testing. The second one is – a lot of times I just need to test REST API calls separately, so I use a tool called Rested, and it allows me to create simple payloads to make requests and see the responses so I can make sure that things looked the way that they should. It is pretty lightweight and it’s a really easy app to use. It is in the Mac App Store. Those are my picks. CHUCK:  Jaim, what are your picks? JAIM:  Since we got in the TDD mode, I am going to pick 2 things that really helped me along the path to learning to write unit tests for iOS development. One is a screencast from Jon Reid where he talks about test driving UI View controller. Before I saw this I’m like, “How would you even test your views?” I had no how that would even work. He kind of goes through it for an hour or so, and I haven’t look at it for a while, but I assume that it is still good but it definitely help way back when. My second pick is a book, which is as far as I know, is the only book on testing iOS stuffs by Graham Lee – Test-Driven iOS Development. It is a great book. It is not too long, it helps you figure out how to test things like scroll views and things like that, table views, how to test those things. The good news is if you are transitioning to Swift, none of these guys use mocking framework – OCmock or anything like that – so their concepts will translate pretty clearly to Swift. So those are my picks. CHUCK:  Very cool. I am going to give Pete a few more minutes and do some picks on my own. I have been – as many of you know - listening to several audio books. I am a big fan of Audible, so I’ll probably make that a pick. I am going to pick a few books I have read lately. One of them is Wheat Belly. I have a brother and a sister who are wheat intolerant and I have been feeling kind of sick off and on and just not good for a while. I have type II diabetes and I think some of it was that, but it had been steadily getting worse and I couldn’t quite put my finger on what the issue was. So I decided to try going off wheat and I have been feeling quite a bit better. I have been off wheat for about a week and a half now. So I read this book Wheat Belly, it was very interesting, so go ahead and read that. He does cite some studies related to the stuffs, but I haven’t actually looked up the citations and read these studies so take that with as much salt as you want or go check the studies if you’re inclined to do that. Another one that I have really been enjoying isThe Way of Kings, which is The Stormlight Archive by Brandon Sanderson. I will put some links to the show notes as well. Finally, I am not sure if I picked it last week or just mentioned it when we were talking about all the tools we use but I started using Redbooth.com. I think I mentioned it has a Gmail plugin. It has just been very, very helpful. I am going to pick that as well. And finally my last pick, I have been working with Mandy, who is my assistant for quite a while now, and we were talking about putting together some retreats for coders where you basically come and do activities in the area and spend some time hanging out, coding with other coders and stuffs like that, and she has been tremendously helpful with that as well with everything else. I am going to pick DevReps. If you are looking for an assistant or some kind of help with your business then I cannot recommend them highly enough. It’s DevReps.com and we will put a link to the show notes as well. Pete you have picks for us? PETE: I have picks. We’ve been running like a Swift learning group in my office. We had someone come in last night and talked to us about functional programming in Swift, which was very interesting, so I guess I am going to pick functional programming in Swift using functional programming paradigms in Swift as one of my picks. I am going to include a link to one example of that, which is using optional –. The optional thing which is everyone is really excited about in Swift – great thing! I’m using it as a real Monad. I am not going to try to explain what Monad is, but it doesn’t act as a Monad by default but it is actually really easy to make it into a Monad by using an extension. There is a link to [inaudible] that shows you how to do that. My second pick around this – we talked a lot about unit testing today, TDD. There is a website called iOSUnitTesting.com. It is a good resource with basic information. It’s got links to some books and a good resource in general, it looks like. My last pick is the Adafruit Neopixels. So Adafruit is this really awesome company that sells electronic gadgets and gizmos, so Raspberry Pi’s and Arduinos and components for building your own electronical wonders. One of the cool things that they sell is these things called Neopixels which are these little RGB LEDs that you can easily control and change the colors of each LED individually. It is hard to describe how fun they are, but if you go and look at the AdaFruit website, you could see some really cool examples of what you can really do. I am picking those because I just built a really cool but pointless toy my son using these Neopixels which he is enjoying a lot less than me. But that okay because I am enjoying it.CHUCK:  Alright! Conrad, what are your picks? CONRAD:  We got to keep the beer pick tradition alive, aio my beer pick is the 512 Pecan Porter which is a brewery right here in Austin, Texas. If you’re ever in Austin or around the central Texas area, definitely check out the 512 Pecan Porter. It is a very easy drinking kind of porter, it’s got a darker feel, and a nice pecan kind of flavor to it; it’s one of my favorite beers lately. My second pick is kind of jumping off of Pete’s pick a little bit on functional programming with Swift. The fine folks at objc.io, are in the process of writing a book on functional programming with Swift. Obviously the book is not done yet, but what they’re doing that’s really cool is you can pre-order the book and they will actually give you access in GitHub to their repository so you can have early access to read the various chapters and also comment and provide feedback on the books, so it is a really cool process that they’re doing. If you are interested in Swift in general, especially functional programming with Swift, then definitely check out that book. There will be a link in the show notes. My last pick is a little bit different side of things from the technology side; it is something called the GORUCK Challenge. The GORUCK Challenge is sort of a team-based endurance challenge that is really an event like nothing other. It is probably like nothing most people have ever done before. So if you are looking for something that would really challenge you and help you accomplish something that you really didn’t really think it was going to be possible, then this might be the event for you. I just completed my second challenge 2 weeks ago on July 4th so I can definitely recommend it if it looks like it might up your alley. So, Goruck Challenge. CHUCK:  Cool. Jeff, what are your picks? JEFF:  I want to talk about Pete’s pick of iOSUnitTesting.com. That actually written by my boss here, Ron Lisle. It’s a good pick – good pick there. CHUCK:  Pick your boss. I like that. PETE: I did it for him. [Laughter]**JEFF: So my picks – Uncle Bob’s Clean Code Video Series. He goes into a lot more depth on test-driven development architecture, design patterns, clean coding practices. It may not be for everybody’s taste; they are kind of real silly, funny and campy. He uses a lot of different characters, but they’re a lot of fun to watch. For a book, I like Agile testing. A lot of it is focused on the role of Q/A and in Agile development process, but also talks about things such as acceptance testing and the Agile testing quadrant, which is all of these different types – all of the different spectrum of tests you could have. Even just trying to just implement that, I think, will make us better development [inaudible] whether we get there in the end. For beers, I am a devoted hop head, so I am going with the Hop Delusion from Karbach Brewing, which is down in Houston. It is over 100 IBU and 9% alcohol, so it is not a session beer. It is certainly tasty nonetheless. And also one of the things that I like to do for the different project teams I work on is I like to make homemade ice cream for them, because everybody seems to love homemade ice cream. The book I use most often is called the Perfect Scoop. It is an ice cream recipe cook book, but even if you can’t cook, there are a lot of them that you just throw a few ingredients in a blender and whiz them up and then turn them into ice cream. It got something for everybody.CONRAD:  You definitely want to work on a project team with Jeff. JAIM: Mm, ice cream [chuckling]. Sounds delicious.JEFF:  Those are my picks. CHUCK:  Alright, thanks for coming guys. It was a great discussion, really interesting stuff. PETE:  Yeah, super interesting. ALONDO:  Really Great. CHUCK:  If people want to follow up with you guys or Mutual Mobile, what are the best ways to do that? CONRAD:  mutualmobile.com, you can check out the website. For me this is Conrad Stoll and I am @conradstoll on Twitter and conradstoll.com JEFF:  And for Jeff if anybody wants to continue the conversation, you can email me at jeff.gilbert@mutualmobile.com. It was a blast talking to you all. CONRAD:  Yes, it has really been fun. Thank you guys again for having us. CHUCK:  Yeah, thanks for coming. We’ll catch everybody next week. [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]**[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more]