061 iPhreaks Show - TableView with Tony Ingraldi
The panelists discuss TableView with Tony Ingraldi.
[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 61 of the iPhreaks Show. This week on our panel we have Pete Hodgson. PETE: Good morning, from sunny San Francisco. CHUCK: Jaim Zuber. JAIM: Hello, from sunny Minneapolis. CHUCK: Alondo Brewington. ALONDO: Hello, from North Carolina. CHUCK: I’m Charles Max Wood, from DevChat.tv, and this week we have a special guest, Tony Ingraldi. TONY: Hello, from Yorktown, Virginia. CHUCK: Alright, do you want to introduce yourself really quickly? TONY: Sure. I’m Tony Ingraldi, as you've said. I'm working in software for a very long time. I go back to the 80's, actually, in starting my software career. I’ve travelled a long and winding road through various technologies to get where I am. One odd detour that I think I took in an early age – even back in the 80's – I’ve kind of had an affinity for computers. But in spite of that, I went ahead and became an aerospace engineer, thinking, "Well, gee, what a natural thing to do. Sure.” So I went to work for NASA here in Hampton, Virginia at NASA Langley Research Center. I worked there for about eighteen years, and midway into that career there, I switched gears pretty much full time. I went into software engineering from aerospace engineering. I’m still kind of attached to the aerospace world working – creating a sort of enterprise-y, in-house apps for the wind-tunnel testing community and that sort of thing. I’ve been working in Java, Python – that sort of thing. Then somewhere along the way in there, I came in contact with web objects, which came as my first taste of Apple – the next style development – the Cocoa framework, with their rendition of Cocoa framework for the web. It was eye-opening; it was a whole different way to develop and it was quite enjoyable. I left NASA about almost ten years ago now, and I’ve been hopping around doing different sort of thing at startups. Lately, for the past year, I’ve been working as a kind of a solopreneur with Majesty Software, doing consulting work. I've been working a bit with Role Model Software based in North Carolina; doing some local work here for different clients and having a lot of fun working on iPhone and iPad. CHUCK: Cool. PETE: I’ve never heard of solopreneur before. I like that. TONY: [Chuckles] I didn't invent that. I’ve heard it somewhere else. CHUCK: Yeah. I’ve heard it before. It's also Alondo’s first time on the show. Do you want to introduce yourself, as well? ALONDO: Yes, thank you. I’m Alondo Brewington. I’m a mobile developer with a company called TeamSnap. We do team and organizational management, primarily in sports, although we will allow you to manage whatever type of team or organization you’d like, spaced out of Boulder, Colorado. I was a developer since 2010 – before that, I was doing Windows development primarily in C#; a little bit of VB before that [inaudible], a little bit of a long history with some Pascal-type languages. I started going with mobile development and I've not looked back. I’ve tried solo development as well, did a little contract work in the past. Now, I'm solely focused on teamwork at TeamSnap and a couple of solo apps that I just have any apps for myself. CHUCK: Awesome. We're glad to have you. ALONDO: Thanks a lot. CHUCK: Alright well, the topic for today is UI Table View and table views in general. When I was introduced to Tony over email – it was Ken Auer, and he actually mentioned that you guys have done some work – you gave a talk about table views; you’ve done some work on your own Table View library. Do you want to talk a little bit about that and give us an introduction on where we’re going to be going with this? Because it seems like tables are more or less pretty straightforward, generally? TONY: Yeah, they are. There's nothing really mysterious in a table view. It’s a very common user interface idiom that’s going to be in pretty much any app, [inaudible] game. I guess over time – I’ve just been using them out-of-the-box UI Table Views with the most obvious way to implement two of the key methods there that deal with what cell should be displayed at a given row, and what happens when you tap on a given cell. And the most obvious implementation, just doing with the framework supplies, you end up with – for complicated table views anyway – you end up with a really nasty semi-conditionals driving the logic in the self-revision and cell-tapping methods. For the simple case, you have a single section, a single type of cell; it’s really clean, but as soon as you get anything where you have a different type of cell coming in, or if you want different actions to happen based on a cell [inaudible], that’s when you start getting really tangled up. The best way I could describe my history with it is I have developed a blindspot for this. I generally have a very high – well, I still do – I have a very high appreciation for what Apple has done in their frameworks; there's nothing like it on other platforms. It just seems like it’s so consistent over such a long period of time across a wide breadth of different capabilities. I generally don’t look at what they supply at with a critical eye, and say “Well, gee, that’s not the right way to do it. Let’s do something else.” So, I developed this blindspot where I just would write this really nasty code and kind of hold my nose and move on, and end up with, in some cases, very long methods, which is very counter to what I would normally do. If I had gone in and designed it from scratch, I never would have come up with what you end up doing by default. In interacting with Ken Auer at Role Model Software, we were having an iOS team meeting one day, and Ken would not allow Apple to get by with that. I showed them some of the code I had written, and he actually jokingly asked if was I able to sleep the night that I wrote it, because it was just so hard. I said, “Well, actually, I probably wasn’t sleeping because I was writing it up late one night.” We started talking back and forth, and he said “Now, look, we really need to clean this up, and let’s just introduce the notion of a section.” In a way, it’s such an obvious thing in hindsight, but until you bring that in, you're king of jumping a gap from a table to a cell, and there’s nothing in the middle that contains the cells. There should be a section object out-of-the-box, and I’m not sure why it’s not there. In storybuild – in storyboards, rather – there's a hint of a section in some of the way the UI lays out, but there's no corresponding object in the framework that you can actually put your hands on. Ken had that really good insight and he said we’d just introduce a section object. I went on my way and created a – there's a GitHub project called RMS Table Views that encapsulates this idea. It takes it one step further, not just introducing sections, but when it gets into really supporting the really hairy situations with the things like settings views and data editing, and things like that, where you typically have a wide variety of cells interacting with some controller logic, it tends to get really –. If you do it, like I said, out-of-the-box, you do it in the most straightforward implementations style, you’re going to end up with just really, really messy code that’s hard to look at, hard to maintain. It just becomes – things just kind of fall apart. Not fall apart, but they fall into place, rather. When you introduce the section – if you ask me for a cell at an index path which hints that, ‘hey, it’s a section in a row,’ you just naturally defer to the section and say ‘hey, give me your cell for this row.’ Anyway, it just becomes a lot cleaner and it gets rid of two of the nastiest parts about table views. What ends up happening is all that bookkeeping goes away and you’re left with your core business logic – what makes your app your app versus what's supplying details about cells. It’s hard to describe in words; it’s much easier to see it. In a podcast format, I’m not sure how best to convey the real impact of it because it’s hard to describe the before and after unless you’ve seen it. If you’ve done this sort of development, you know what I’m talking about. You’ve probably felt the pain, but you probably can’t appreciate the full impact of just looking at it in a slightly different way without seeing it, so I'm not sure how to convey that. JAIM: Describe a little bit about what you mean by a section. TONY: Yeah, a section, basically, is a grouping of cells. You might have, say, on a settings view, you might have – it would naturally fall into groups on your group table view. You’d have different sections with – you might have username, password, and then you’ll have maybe a middle section with some data about a user and then you have maybe a section down [inaudible] were you’ve got a save button, or a submit button, or something like that, so that would be a user editing view. Basically, it's a grouping of cells – is a section. Instead of jumping the gap between table view to cell, because you’re dealing with index pass which have two components to them, you’re basically supplying an object intermediate between the table view and the cell to just naturally encapsulate or contain all of the elements that are there. PETE: Is the goal – is the role of the – they kind of form sections –. Sorry, I’m looking at your GitHubs and I'm reading through the [inaudible]. Is the role of this form section to encapsulate the layout logic? Is it for UI, or is it to hold the logic behind, say, let’s say, you have like a login screen that has either login or signup? I guess that would be like two sections – there’d be the login section and then the signup for a new account section. TONY: Right. PETE: Would that be a good kind of way of modeling it? TONY: Yeah. This approach is not dealing with the pixel positioning of anything. It’s not a UI layout thing in that sense – it’s the arrangement of your cells. It’s the higher level arrangement of your cells in the table view. It leverages things – you can design a cell –. If you don’t have a custom cell – you can design the whole thing in interface builder and use a custom Nib-based cell, if you’d like. It doesn’t do away with that; it’s not a replacement for interface builder in that regard. It’s really just to address the bookkeeping tedium that generally accompanies complicated tables. Some of these you can get with a static table and storybuilder – I mean storyboards. My issue with storyboards though – I have a couple things. I guess I haven’t fully jumped on board the storyboard train, although that train seems to be taking up speed more and more now, so, I’ll get probably get on board. But the couple things that I don’t like about it, just inherently, I don’t like – it just seems wrong having your entire UI – it seems to be asking having your entire UI on one file, and I always found it kind of odd. Now, you can break it up and do things – but you lose some of the benefit when you do that. Also, one thing I found odd is if you want to have, say, a custom cell layout in two different table views in a storyboard, I’m not seeing a way to do that where you don’t have to copy and paste the entire cell layout from one table view to another. That seemed to be counter to just normal accepted practice of not repeating things in more than one place. [Inaudible] I’m sure at some point Apple will introduce something where you can solve those problems. Aside from that, I just never found the benefit of specifying segues to be so overwhelming – being specified in a storyboard versus just dealing with a little bit of the code; I didn’t see a really huge payoff there. Anyway, we went this way with what we called a form descriptor, which is basically a plist, or it could be JSON format. One interesting thing that that thing opens up that you can’t do with storyboards, at least not that I’m aware of, if you want you could actually defer the final layout of your UI until one time –. You could have, say, a backend service, vending JSON description of your UI and you might have, say, different flavors for different user-privileged levels, for instance. That would be one way to vend your UI from the backend and have it dynamically rendered at one time based on that description – that serialized description. I'm not personally [inaudible] that, but the opportunity is there to do that. It did open up some ideas in that regard, and again, I’ve found it to be extremely useful. I’ve had an opportunity to use this framework in an app since it was created. It was night and day – the development experience of just being able to not deal with just the tedium that you get into, and again, that large conditionally-driven structure that tends to be ugly to look at and maintain. It was kind of night and day describing the interface, “I want this cell here, I want this cell here, this cell here” and voila, the magic happens. It’s similar to other ideas in other technologies. One thing I came across years ago in the Java space – something called SwiXml, which is very similar in its purpose. Basically it’s an XML user interface description. There’s a little bit more swingish – and [inaudible] it’s for Swing apps, but the same kind of idea. You basically serialize a bunch of code that normally you would write – if you’ve ever done any kind of Swing development or any user development user interface at all –. I mean, we are laying out things in code; that code tends to be very verbose, very tedious, and really, it’s just data. It’s just describing an interface. This is kind of the analog to that in iOS, although it doesn’t deal with where pixels go on the screen. It’s strictly dealing with the ordering of cells and what happens when you interact with a cell when you tap. [Inaudible] JAIM: Can you walk us through a little bit on how you would set up these section that we talked about – maybe a login and a sign in form? How are we doing it differently now than the old way? TONY: If you adopt this approach, strictly if you adopt RMS Table Views, you would basically be describing the arrangement of your cells in a plist format. You would be editing a data file, essentially. You’re probably going to create some custom cells along the way and for good measure we threw in several kind of out-of-the-box cells – things like text-entry cells and switch cells. If you want to represent a Boolean value, you just use a switch cell – I think that’s what we called it. Common things [inaudible] picked from a list – we have array-picker cells, so you just supply it basically an array of objects that you want to take from. You would basically just be describing in this data file – in this plist – this hierarchical arrangement of your sections and your cells, and your code. If you use everything out-of-the-box, for instance, for a settings view, if you don’t have any custom cells beyond what’s supplied in the framework, you’d almost have no code. Actually, in the part of the demo I did – the CocoaConf Talk – we showed how to build, say, the Siri interface – the Siri settings interface from –. It basically looked exactly like what’s built into the phone and we had essentially no code. It was almost an empty class in the end that – because it was leveraging as user default for a setting, for saving data and things like that. It was extremely brief in terms of the actual objective-C code, because it all ended up being just describing your interface. I imagine this is very similar to what Apple must do with setting bundles, because basically you’re just giving it data, saying, ‘hey, this describes my UI,’ or ‘this describes the set of preferences I need to be surfaced.’ The settings bundle – all your supplies are bundles; you don’t supply UI. I imagine, behind the scenes, Apple’s doing something similar. I imagined there’s quite a bit of a difference, but the concept is the same. JAIM: So we got like a plist where we say, “Okay, I need a Boolean field here if we want to save a user’s password, so I’ve got a little thing I could put it in the plist.” Username, maybe a text field thing – you got like a bunch of canned little things that you put in to make your entry form. TONY: Right. It takes advantage of key value coding to bind the data to the UI element. And it is two way, so if we change the data, the UI would change; if we change the UI, the data would change. I don’t think it’s quite as complete as findings on OSX, but it’s a similar idea where you're not having to write a lot of extra code to do that. You just basically declare properties and key value coding; the machinery does most of the work there. JAIM: Okay. So you talked a little bit about having a custom Nib – is there a way I can integrate a custom Nib for a cell? TONY: Yes. Your cell classes can – there’s a method they can overwrite to specify what Nib describes their interface, or you can – there’s an alternate constructor –. I can’t remember off the top of my head what it was, but basically yes. The short answer is yes, you can do that. There’s provision for that and some of the samples in the framework itself actually do that. JAIM: It sounds [inaudible], at least in concept, to MonoTouch dialog, which was available when I first started developing three and a half years ago, where you could do something similar, or it was more of a code-driven thing. It started off in the Xamarin, MonoTouch ecosystem. I think it’s been imported to objective-C, but similar to where you just find your objects in code. Is that an influence, or you kind of come to it on a separate –? TONY: I actually wasn’t aware of that one. I know that there are other toolkits out that allow you to do things – InAppSettingsKit, I think, is one. There are similar ideas – I didn’t see any that had the pure plist or something similar, like a serialized descript that basically removes a lot of that [inaudible] code from the code. To me, the best way to express that sort of thing is just as a serialized form, as a data file or resource of some kind, and not put it in an actual objective-C code. Again, there are more and more CocoaPods and GitHub projects popping up all the time, so there may be something else that’s very similar at this point. But I didn’t see anything that’s quite like what I was trying to get at with this one, and that’s really just getting a total separation of the description of the layout – the ordering of the cells and the type of cells and the bindings from the code. I wanted to keep the code as free of that as possible and I think we’ve gotten at a pretty good place. It’s still a 1.0. – whatever. We haven’t made a huge advancement since the initial implementation, but I think it does achieve nearly all of what we were trying to do. And like I’ve said, I’ve had an opportunity to use it in a couple of projects since it was originally written, so I’ve tweaked it a little bit here and there to add some extra little helpers things, but fundamentally, I think it’s pretty sound. I think it would be useful to people if they’re looking for kind of an alternate way to deal with these things. ALONDO: Speaking of that setup with regard to binding that data to custom cells, I was curious about using it in this format, for instance, with an edit form, and being able to have a custom cell that may actually have a few actions that are tied to buttons inside of the custom cell. Is that something that would be supported or would that require a little extra work on our part to get the actions back out via selector, or delegate sort of things like that? TONY: Yeah. If you want to have stuff in the cell beyond what a table view would do, there are a couple different provisions in there. One is, with this approach, you tend to make the cells smarter. They can actually contain some logic in there, which is a little bit unusual since you think of a cell as, ‘well gee, that’s a UI element; why is it doing anything beyond just presenting itself?’ but there’s nothing tremendously intense going on there. We do have cells like – there’s Target Action Cell, which is pretty generic. You can bind that to anything, but that would be a single action for the tap. That wouldn’t be doing things like subcell level. At the subcell level, you’re going to want to have some custom logic or custom cell subclass to handle that sort of thing. Off the top of my head, I don’t know if there’s an obvious way to handle that other than having custom logic at the cell level, because you need to get access to the guts there. And one of the tricky parts is, these sorts of things, if you have a dynamic table where you’re reusing cells – I guess we have to be a little bit careful there – but the form types of table views tend to be fixed. There’s a fixed number of rows, so you can treat the cells as long-lived and not being recycled. And there's not going to be three thousand of them; there's going to be ten of them – and that'd be a long form. I think you can – in that case, it makes sense. It’s somewhat safe, so to speak, to put some smarts in the cell itself. But when you get into reuse – if you’re dequeuing cells in a dynamic type situation, then it can get a little hairier, but it’s probably still solvable. But my experience has been, you tend to not have a lot of wildly different cells in a dynamic table. For instance, if you’re looking at just a list of n widgets, or names, or whatever it is – those long dynamic tables tend to be the same type of cell over and over and over again, although it’s not a hard and fast rule. The more complicated situation, in terms of cell content tends to be the smaller fixed form type things, so I think it works – it can work –. If I’m understanding what you’re describing, I think it can work in that case, if you put enough smarts in the cell itself. ALONDO: Yeah, I think so. I think you’re right. I think it’s just a matter of –. The situation that we’re having with the edit cell itself is very custom [inaudible], but I agree that for the most part, this sounds like something that we could –. My colleagues had gone to the CocoaConf and brought back some of the ideas, although we’re not using RMS Table Views exclusively. Specifically, I definitely think it’s something we should reconsider. [Chuckles] PETE: Right. TONY: Yeah, if you can use it – great. Just the concept of introducing the section was really kind of the linchpin for the thing and everything else just kind of followed as a consequence of that. JAIM: So what other features does this have? We talked about building [inaudible] sections, easily add Bool text fields – is there any way that I can add a kind of validation? Let’s say I want an email address and I want to verify that – is there a hook I can put in there? Is that supported? TONY: There’s nothing specific for validation. That would probably be a good extension to it, to add some kind of standard mechanism for validation, and maybe just implement some – use some naming convention for methods like validate x or whatever. I think Core Data does some of that, if I’m not mistaken. Something analogous to that would be helpful. We don’t have anything built in there right now for that, so it would be an extension – either generalized extension that could be applicable to a large class of things, or obviously, if you adopt this framework you could just implement whatever you need to on top of that. But there’s no generic support for that at the moment. PETE: As it stands today, if I wanted to implement something like that, what would be the – where would I put that code? Would I need to put it in my regular view control, or is there some way I could subclass one of the framework, or the library classes or –? What would I do there? TONY: I think the View Controller could be a good spot for that. It might be good to have maybe a model layer inserted in there with some generic – maybe a generic model class – that provided a validation API. I might have to think about that some more before I could say for sure. It seems like a model layer would be sensible – like a generic model-base or maybe a category, so it could be used on different base classes, because a lot of apps already have a model in place. PETE: Signature. TONY: Yeah, maybe implementing a protocol, following some naming convention, kinda like a validated property name-kind of thing. Somewhere between a protocol, and probably applied to the model layer would be where that makes sense. PETE: I’m not sure I totally – I very much simplify as we’re trying to explain this over a podcast because it’s the kind of thing where you want to leap up to a white board, or crack open Xcode or something. What are the hooks for me to interact between – let’s say, the login example again. As a user I filled in my username and password and then I tapped the Login button – where do I put the logic that is going to eventually go and make a network call, and then update the UI and just say “Invalid Password” or something like that? TONY: The intermediate logic that’s dealing with the actions, say, when you tap on the login button – that would be in the Table View Controller. I would separate the actual logic that goes out to the network into probably a separate network client of some sort. The kind of a glue in between, it would be [inaudible] I have a target action cell and your action button would be something like login action. Then that would take the user input and do what it needs to do, send it to the client, and get the result back, and surface an alert or whatever. You move to the next view if it logs in successfully – whatever you need to do there. But the target – the action, the initial action – would most likely be on the UI table view controller subclass. That’s tied to that view. PETE: Gotcha. So that target action is the kind of the mechanism for bridging from this declarative – like I've set up the UI to actually doing stuff based on interactions. TONY: Right. And you would declare – your target could be a View Controller or it could be something else. In a lot of many cases it just going to be the View Controller itself, so you can target the cell and then the action – for the action in the descriptor, you just give it the string form, the name of the selector, basically, and then the underlying logic would actually turn out into a real selector and invoke it. It’s pretty wide open what you can do there – it’s just a target action-type concept. It’s similar to what you see in interface builders, so it could do anything you need to do there based on a tap. What you don’t have to deal with is, “Which row is tapped? What should I do now? Should I deselect the row?” – that kind of thing. [Inaudible] raw-handled and you just basically implement what you need to implement, which is the login itself. We would need like a holographic podcast [laughter] so we can show this stuff. CHUCK: Yeah. Of course, the beauty of the podcast is you can plug in your headphones and drive down the road. TONY: That's true. And I’m a big fan of podcasts; it’s just – some things are just hard to convey. CHUCK: Yes. PETE: We just need self-driving cars. [Laughter] CHUCK: I know. Or somebody that does screencasts on iOS. PETE: Hmmm. CHUCK: Who do we know? So are there any other aspects to this that we haven’t touched on? TONY: We spent a lot of time on the form aspect. It also handles the simpler case where you’re just dealing with different sections in a table view. It could be, say, something like your contacts. If you look in the contacts app, it’s different sections, with everything sorted by first letter of the last name, for instance. You could also deal with that case; it’s not just for the form style user interface. [Inaudible] Anytime you’re faced with – you have more than one section in your table view, then it comes in handy, because then, basically you literally create a section for each of those sections – a section object versus just dealing with the index path – section row – and it just cleans up the bookkeeping to the point where you don’t even think about it. So even in those simple cases, it’s handy because it keeps the code cleaner, and your sections are your sections. You don’t have the mix, kind of make that leap – that there’s like an air gap, so to speak, between the table view controller all the way down to the cell when there’s this notion of section in-between –. It never explicitly made it into an object level thing in the built-in framework. It’s not just for the form controllers. Anytime you have more than the simplest case, and the simplest case being you have one section and one type of cell, because in that case there’s never any hairy logic involved there. But as soon as you introduce, ‘hey, I’ve got two sections – a little more than one,’ it may not be extreme when you just have a couple and you just have to branch conditional, but you’re on your way to some pain if you continue down that path. It’s just a simple notion of introducing a section object, and instead of the table view trying to do if-else, if-else, if-else, it just says, ‘hey section, I have a list of sections,’ or ‘I have sections and I just want to ask section x for its cell at x’ and it’s really fundamentally very simple, but it’s pretty profound in the impact it can have on the cleanliness of your code and the maintainability, and just keeping it nice for people that have to come behind you and maintain it. PETE: That’s neat that it works for dynamic stuff as well. TONY: Yeah, either case – and that’s actually the case that Ken was primarily concerned with. When we were talking about this problem, I immediately jumped to the form because I’ve recently have done the mother-of-all-horrible-conditional-driven form views, and that’s like, “Well, yeah, I can really clean that up.” I went ahead and attacked that, and in retrospect, or backed out a little bit of that, refactored it to handle the simple case. It was somewhat of an afterthought, but I think it’s factored pretty well to do that cleanly, as well. PETE: I’ve got to say, I’ve always felt like I’m doing it wrong when I’m building table views because there’s so much low-level bookkeeping. I’ve always suspected that there’s something I’m doing, like I’m doing things the wrong way, but maybe it’s just that I should have been using this thing before. TONY: [Chuckles] Well, I think what’s happened is you looked at all the samples and just the way the framework is - the iOS frameworks are built for UI Table View controller – the way the data source and the delicate protocols are written, really, the most natural thing to do is to fall into that pattern where you have that single entry point: self, row and index path. If you never leave that all your logic is in self, row and index path – the odds are you’re going to have a very clumsy and messy gun, just this big conditional structure in some form or another. Some people can work – I’ve seen it worked around where, maybe they build a dictionary ahead of time with index paths as the keys and some other – maybe a method – as a value, that method name. That’s one way to clean it up, but that doesn’t get you as clean as you can be. So, really again, just this notion of section, just introduce that and voila! The fog clears, and it becomes really clean. JAIM: Yeah, it’s very easy to have a three hundred line self or row index path. I’ve also seen people do the things like subclassing different cell [inaudible] that creates different type of cells. If you have a complex thing, that’s another way to keep it. You can check a little bit, but I definitely like the declarative throwing in a plist especially the simple things that are just [inaudible] code anyway. PETE: I think the thing that always irks me about the Table View thing is not just that switch statement or your statement or whatever – it’s that you have it twice, right? So if you have the building the cells and then corresponding to [crosstalk]. TONY: Right. Those are generally the two points that's going to be trouble areas. DidSelectCell, wherever it is, for index path and self, row index path. They’re tied together, so you end up having similar conditional structures in both unidentical. Generally speaking, they wouldn’t be identical, but that just removes that; it just goes away completely to the point where you don't even implement those methods. For instance, if you adopt RMS form view controller, you don’t even see those methods in your implementation. They're just not there. You’re implementing the action methods and that’s it. You’re really down to the “what does your app do” and almost nothing else. PETE: So when are you going to import all of these to Swift? TONY: [Chuckling] Swift is definitely on my list of things to jump into. I’m looking forward to – I haven’t had enough cycles to go there. I imagined it will be a slow migration – the Swift. As new things are added –. PETE: I think the best things that we’re going to see in a short term with Swift is people writing nice little DSLs on top of existing open source tools, just like –. To this thing for example, I can imagine someone building something so that you can configure the sections and the things inside the sections using code rather than using a plist or a JSON file. Because Swift has those nice syntax for anonymous foreclosures and stuff like that, I think those can be a lot of little internal DSLs that help you build things like table views. TONY: Right. On that note – I guess I’ve neglected – you can, if you choose, to describe the interface in code, and using dictionary literals or however you want to construct your description. It does allow for that. My natural tendency is to go for the serialized version just to keep it out of the code, but you do have that option; you can generate it. You can actually generate your form or interface dynamically, if you choose to. It’s a long way around, but you can do that; you have that flexibility. It all boils down to constructing a dictionary or a higher – substantiating all these plist – all the plist objects into dictionaries and arrays in the end, and that’s what’s gets fed to the main constructor. Yeah, you can describe it in code if you choose to. ALONDO: Do you think you're [inaudible] in the implementation of the section because that’s the one place where we’ve already gained a huge benefit setting it up and we are using dictionary literals right now, but that may change in the future. Just not having to look at those lines and lines of code right now in the view controllers has been really, really helpful, and it’s made a lot – not just easier [inaudible] what’s being – what we should be doing [inaudible] debugging as well, since having to jump through tons and tons of code. Is there an opportunity – if there was a fork, for instance, if some were to add some additional table cells or custom to fork that or submit a pull request to that? Is that an active – are you actively reviewing the rebuild? TONY: We haven’t had a pull request yet, but they’re welcome. It’d be great if we can get more contributors. One thing I’ve been not as complete as I’d like to be is in the documentation area, because even when I went back and used this thing myself a couple of months after I’ve written it, I kept going to have to go back to the code and say, “How does it actually work?” so that’s not a good sign. So, pull request are welcome for enhancements in code or in documentation. So, yeah, absolutely – fork and pull. CHUCK: Alright. Anything else before we get to the picks? TONY: If you guys don’t have any itching questions, I don’t have anything I will think to add. I think we’ve covered it pretty broadly there. CHUCK: Alright. Well, let’s go ahead to the picks then. Jaim, you want to start the picks? JAIM: Sure. As some of you are aware, there’s a rather large soccer tournament on right about now, and even when this actually airs in a week or so, there will still be a large soccer tournament on. But if you’re in the United States like I am and you don’t have cable TV, you’re kind of out of luck. You either go into a bar or you’re calling your friends with cable and inviting yourself over. That’s kind of lame because ABC and ESPN have English language rights to all the broadcasts, and they’re not giving it away for free – so it goes. But they do not have the access rights for the Spanish broadcast, so you can download the Univision Deportes App and watch, I think, most of the games. It’s in Spanish which makes it more awesome, because just kicking a ball around – how much do you actually need to [inaudible] a game? [Laughter] And you get that “Goooooaal!,” which is the highlight of the whole game for me. So if you’re in the US, you don’t have cable, Univision Deportes, that’s my pick for the day. CHUCK: Alright. Pete, what are your picks? PETE: I always just want +1 Jaim. There’s lots of people that’s been watching Univision around, and a lot more people watching Univision around where I live in, normally. I’ve got some interesting picks today. It’s pride week in San Francisco this week, and so I’m going to pick Alan Turing. Alan Turing is obviously, well, hopefully obviously to people, a very, very famous computer science guy. He helped kind of shorten World War II by quite a substantial period of time, saving lots and lots and lots of people's lives by breaking the Enigma code. He also invented the idea of the Turing test, which I think recently was allegedly passed, but I’m not sure if that’s true. He was also a really incredibly smart computer science guy, who also happens to be gay and was persecuted for that by the British government, and killed himself because of that, which is really sad. So, I just like to pick him. I know it’s kind of trivial to pick someone so important, but I’m going to pick him anyway. On a lighter note, I’m going to do an anti-pick for Twitter Bootstrap. [Laughter] I see a lot of people using Bootstrap. You can actually use it the right way, but not that many people do, and they don’t really tell people how to use it the right way. If you attempted to use Twitter Bootstrap, just don’t, and at some alternatives. A really good alternative is Bourbon & Neat from ThoughtBot, so look at that first before using Twitter Bootstrap. And my last pick is a beer pick. I’m going to pick a limited release from Lagunitas, which is called Nighttime. Normally, I like to pick the session beers, and Lagunitas have a beer called Daytime, which is a session beer. Nighttime is not a session beer. Nighttime is 8.2 percent alcohol, and it’s really yummy. It’s like a very dark kind of coffee and toffee kind of beer, but it’s still got the great [inaudible] going on, because it’s Lagunitas. It’s very good if you can get it where you live, then I recommend trying it out. That’s my picks. CHUCK: Alright. Alondo, what are your picks? ALONDO: I have two. The first one is an app called Moves. It’s the Moves, moves-app.com; you could find it in the Appstore. I am not a wearer of FitBits or any other type of fitness wearable, but I was curious to know how much I was moving or not moving while I’m working during the week. I’ve discovered that I really do need to get mobile, and the Moves app has helped that a lot because it just allows me to trace the steps that I’ve had and also where I’ve been. One of the nice things I’ve done is just sort of taken a daily walk around the neighborhood to track my steps, increase the amount of fitness I guess, at some level. It’s a great app. I know there’s lots of other apps that track, but this one is free and it’s a really neat app and it’s quite helpful. My second pick is probably the antithesis to that, and it is a beer. It is the Duck Rabbit Milk Stout from the Duck Rabbit Brewery here in North Carolina – support local breweries. It’s a great, great beer, and you could probably find it in a few places. I’ve been traveling a good bit, and found them in local brew shops. It’s a delicious stout, if you like stouts. Those are my picks. CHUCK: Awesome. So I hadn’t even though about picks because my life’s been so crazy lately. So I’m going to pass and let’s hear Tony's picks. TONY: Alright. I actually have a bunch because I was afraid I wouldn’t have any. So now, I probably went and got too many. On the tech front, I got one that’s kind of an old and trusted friend. It’s an app called TextWrangler, which has its roots back in BB Edit. The product line goes back two decades, at least, I think. I just find myself using it quite a bit just for the here and there just editing quick edits and if I don’t want to fire up Xcode, my go-to editor is TextWrangler, and I recommend it. On the entertainment front, although I’m hesitating to call it entertainment because it’s Entertainment With a Purpose. I’m a big fan of the Kendrick Brothers and their films. Some of their long more well-known ones are things like Facing the Giants, Fireproof and Courageous and films that will that make you think and challenge you in what you believe, and I’m a big fan. As far as podcasts, I’m a big fan of Dave Ramsey and his Financial Peace University. He’s on The Dave Ramsey Show podcast, and also, kind of going hand-in-hand with that, EntreLeadership from his crew also. On the solopreneur front, Dan Miller is a good podcast. It’s 48 Days, [inaudible] pretty well in a podcast, and I find myself listening to him quite often, and I just find a lot of encouragement and ideas and all that stuff. CHUCK: Hey you picked some of my favorites too. We actually had Dan Miller on the Freelancers Show. TONY: You did? Oh wow! CHUCK: I'm still working on Dave Ramsey. [Laughter] CHUCK: Yeah, terrific shows. Good picks. Alright, well, we'll go ahead and wind down the podcast. Thanks for coming again, Tony. TONY: You’re welcome. Thanks for asking. CHUCK: Well, we’ll catch you on 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]