Well, like you said, I'm Saul Mora and I'm an independent iOS developer. I do a lot of consulting and I see a lot of iOS code. Yes, and that means that what's been on my mind lately is how to write the code and write it better and make it easier to refactor things and organize things and follow good coding principles in general. That leads me here to QCon and doing a whole talk on design patterns for mobile applications.
2. Are the design patterns for mobile different from design patterns in general?
Right. That's the end of the talk. Actually, you're kind of fast forwarding a little bit, but the talk explores the practical implementation of design patterns for a sample mobile application. Really I say the same thing. It's like basically what's old is new again. Design patterns are time-tested solutions to age-old problems in development in computer programming. Just because we're on this new mobile hotness -- mobile is the new fancy technology -- it doesn't mean that a lot of these old solutions don't apply. A lot of times, they do apply and a lot of times they're better than a lot of solutions that a lot of the newbies come up with these days. The gist of it is that, yes, it's old, yes, and it's from a previous era in computers, so to speak, but all that knowledge, all that history definitely applies to everything that we do today in mobile development.
3. So when you say previous era, can you give an example?
I equate design patterns to an era when -- design patterns are originally -- the original concept came out around I think 1995, '96. If you think about the hardware at that time, it was -- Intel 486s were top of the line. Maybe Pentiums had just entered the market. Four megabytes of RAM was standard -- megabytes, not gigabytes. So you had very limited hardware and very limited machine specifications. It's not unlike how mobile devices started out; very limited CPU power, very limited RAM. In a way, it's perfectly suited. It's a very at parallel between how the evolution of mobile devices and the evolution of the original PC and its rise to popularity.
In a sense, that's really what I'm thinking about is design patterns came out around at a time when things were limited and even then when they did come out, they solved the problems as needed and, if not, better. It allowed them to adhere to really SOLID design principles, things like single responsibility, DRY, all the things that go into writing the SOLID types of code. I forget all the items in the acronym, but I know those are in there. But that's really what it is. What's old is new again. There's definite parallels from mobile, the rise and popularity and mainstream evolution of mobile devices and applications to the original PCs especially from a technology standpoint.
The Gang of Four book is definitely one of those inflection points in programmer development history. But since then there's been a lot of other books and a lot of other approaches to design patterns. And for as off-putting as that book might have been for some people especially for those who don't write C++ code, there are definitely books that go over the same patterns and introduce new ones because the end of the book basically left it open-ended as like, well, there's more patterns to discover. Discover them yourself and report back. People have and they've written all these other books.
The Design Patterns book, there's certainly a good foundation and a good place to start. You can start on a more current level with maybe a writer who has a different style or explains things in slightly different way or present some more examples which is what I do on my talk. I go through how I have used design patterns writing iOS and Cocoa applications. I explain quite a number of the design patterns that are already present in the Cocoa frameworks and just how ingenious this framework is just out of the box. For one, if you learn what patterns are and what they look like and how to identify them, then you can start to look for them in the frameworks that you're already using and then use them to their maximum ability for all the things that you're trying to solve.
I would say design patterns, that the core idea, I would say yes, there are design patterns but I don't know if we really identified those, if they are different or not. This is going to take some experimentation to see. Maybe there are like a person locator pattern or some kind of battery optimized pattern that we can apply to our code that says, "Hey, this particular section of code is draining my battery, and I can tell this with all my analysis tools that measure battery life when this code is run." And maybe there's this pattern that says, "Well, when you're doing this, drop this thing and do this line of code and do some weights or something," whatever it is, those are yet to be discovered and identified so that yes, then we will have really specific mobile patterns for these mobile problems that are very specific. Like you mentioned, network and battery are really the two -- they're constraints and they're new constraints that are very, very mobile specific.
6. Can you give me an example of a pattern that applies especially in today's mobile environment?
Well, it seems that the majority of people still adhere to MVC and that's kind of the grandfather of all patterns. Few people realize that MVC is kind of like this collection of some of the base patterns. There's the Observer pattern. There's the Command pattern, Strategy pattern. The mediator is the Controller. Patterns are meant to be used as a group and to mix and match to achieve an end result, and these groupings of these patterns facilitate creating and implementing the actual MVC pattern.
Oh, man! I guess my favorite pattern -- I don't know. That's the thing is like there's a pattern for every -- it's interesting. If there is only one pattern, if I was specifically on a desert island, so this particular problem, I would want the Observable pattern. I want people to find me on the desert island. I want other people to subscribe to me and observe, "Hey, I'm on a desert island. Come and get me." I want them to get my messages. So, yes.
Yes. I would say that there are certain patterns, and I went over the patterns that I have found extremely useful and the ones that I go to time and again when I'm developing mobile applications. A lot of these are built into the Cocoa framework. Again, you have to know how to find them. But the one that I use quite often is the Command pattern and the Chain of Responsibility. Chain of responsibility is built-in to Cocoa. Most Objective-C/Cocoa developers know this as the responder chain. This is built-in for you and it's really generally one line of code although for non-Objective-C people, it might look like three or four. It is just one method that you send a message and it goes up the chain, somebody handles it, boom.
That's built-in. There is no -- you don't need to write any loops. You don't need to do any structures. It's already there for you. The Command pattern lets you encapsulate a lot of the messages that go up the chain. And those are two really important patterns that I see as a perfect fit for iOS applications considering the fact that iOS applications, they generally should have one core beta functionality. They should talk to a service or perform some sort of function and that needs to be the heart of the application.
There is a place for this heart to live, and it's on the AppDelegate of an iOS application. When you have multiple views, you're tempted to really just have a really hard link to that heart so that you can always have access to that piece of functionality or that data when in reality, the best -- a really great approach is to decouple all of these views and all this other application structure from the core bit of functionality. We can do that by utilizing the chain that's already present.
So you have all these different views and they want to send a network request with particular properties, you create a little message over here on this view, kind of bubble it up the chain and eventually goes to this controller and does stuff over there. That is something that I don't think is utilized very well in a lot of iOS apps considering a lot of the code they've run across, but I'm trying to spread the word that this is possible and it's already there for you in Cocoa and Objective-C.
Yes. Objective-C gets a bad rep. I think the square braces turn a lot of people off and the things that look like named parameters. There's a lot of oddities with the Objective-C syntax, but Objective-C is super powerful. I like to say that Objective-C is like Ruby and C and Smalltalk. Objective-C, Ruby and Smalltalk are all very related. Objective-C is really awesome because not only do you get the power of Smalltalk/Ruby, very similar language like that, you also get straight access to all the native low level bits.
So if you have really low-level libraries, static libraries and things that you're linking into your app, you need some low-level device functionality, there's no bridge. There's no JNI thing you have to import and manage. There's no native extension that you have to write for Ruby. It's all there. You have C and you have Objective-C. It's all one package. There's no step three for this, for handling these scenarios. It's all inclusive. Once you learn how to harness the power of Smalltalk in Objective-C, the code really becomes beautiful, in my opinion. It's really nice. And the thing is Objective-C has a lot of patterns built-in as well. It has the Observer pattern built into the language and this has been added by Apple, I don't know, not too long ago but things like that. They're in there and they make extensive use of these things. Patterns are everywhere.
10. I'm going to play the devil's advocate. How easy is it to shoot yourself in the foot in Objective-C?
It is quite easy to shoot yourself in the foot with Objective-C because it is a C-based language and it has the complexities inherent in C with pointers and memory management although memory management has somewhat been fixed by Apple with the release of ARC, Automatic Reference Counting. There are still ways. A lot of times, you will get a crash. You will get a crash and you won't know what's going on or where it crashed, how it crashed. It's an embedded platform. You're talking to low-level bits, but the beauty of this combination is you're talking to low-level bits in a super powerful, high-level language. Some people might say that it looks weird and something, but you think about what it's accomplishing and how it's doing it. To me, this combination is just super powerful. I'm happy to be doing it.
So iOS application, right? There is a certain core functionality. The canonical example is a Twitter client. The Twitter client is responsible for presenting and displaying tweets and messages and things. It has all these different views. There's all this different kind of ancillary functionality around just seeing this stream of consciousness downloaded onto your screen. But the heart of the app is connecting and talking to Twitter itself over the network. That's the heart of the application, all the communications so that communication layer needs to be at the center of your app. All that stuff has to go somewhere.
That's what I'm really talking to. An app really should just do one thing, at least in the mobile app just because you have more than one piece of core functionality, just split that into different apps. If you have multiple bits of functionality, it really starts to confuse people. They don't know how to get to things. It makes the user interface a lot more difficult to navigate and get to things quickly. There are inherent complexities that you want to eliminate when you start adding more and more functionality to an app.
The thing about having a mobile application is it's really quick to get into, quick to get your task done and quick to get out of. If you add a bunch of things on it, then it gets a little more complicated to get in there and get out fast.
Well, as far as application development it does seem that apps are getting a bit more complex, and I think it's kind of by necessity as far as market factor is but I don't know. I don’t know if I see anything there. Well, application development is also -- you've got -- it's more from -- my perspective is more from the business side of things where I see a lot of companies merging, people going. They're slowly moving away from the one and two-man shops to you know 5, 6, 10-man shops.
A lot of my friends are in -- they've now formed this 20, 30 40, 50-person companies. What happened to the good old days where it was just bunch of developers in a room, cranking out quality stuff, having a good time and doing that? It just seems like things are maturing, and I think the evolution of mobile development is going to follow the same as personal computer, classic development. It seems to me like to be very similar.
13. Have you looked at other people's mobile code and critiqued it?
Oh, yes. I do that all the time. A lot of people don't like when I critique their code. I'm brutally honest.
14. What do you normally find in other peoples code that impresses you one way or the other?
Generally, the thing that I find most often is an abuse of the language or a misunderstanding of certain paradigms in the language or the frameworks. The other thing I'll find is that people are manually writing code to do something that the framework already does, and they're doing it a lot more poorly not because they're not good at it. It's just that there are so many other levels of complexity and use cases and edge cases that the frameworks handle that you're not able to. Trying to fight the frameworks is definitely something that I find all the time.
15. Do you have an example at the tip of your tongue?
Not at the tip of my tongue. Maybe a good example is Core Data. Core Data is a very powerful data persistence framework by Apple. Most people think of it as Apple's version of an ORM. It should generally be thought of as an object persistence graph. So your app and the business objects contained therein are generally a network of objects, and this framework helps you persist those objects to disc.
Generally, what I find is that people think about Core Data as a database, as an ORM and they think about tables and rows versus objects and sets. That misunderstanding leads to an abuse of the code and especially when it comes to threading and all the other complexities inherent when using Core Data and threads and things like that. It's hard to describe code without actually writing the code out, but it generally comes to -- the most frequent thing is in Core Data and seeing how people don't understand how to do it right. I've done my part to try to help people understand. I've written a little open source framework called MagicalRecord that helps hide and clean up a lot of the boilerplate code that does cause confusion when you're getting introduced to Core Data.
Yes. A good question to ask is how would they implement a network call? It's just one example. Knowing that you could just download some open source framework that is very popular, another one, called the AFNetworking is an okay answer; but I would really want to know what's the low level way of writing that network call so that when that framework is not available which can be the case in a lot of client apps, they don't want other third party open source code, you can just write something based off of the core bits.
Yes. I don't have any temper towards Android. I tend to think -- and this is one of the reasons I really enjoy being in the Apple community -- is that competition is good. Friendly competition is a great thing to help everybody. There is enough room in the pond for all of us. As far as the way Android works, there's a certain difference. I don't use Android. I've never really played with one. My impression is just what I see from afar, and it just seems to me it's for a different kind of user.
I originally moved to iOS and Mac because I had been in that kind of techie Android type of world for a long time. I built my own computers from spare parts, did everything from scratch. I know how to mess with all that kind of stuff, build my own operating system kind of things. I had done that for a long time. And then Apple started using Unix as the foundation for their operating system. Having the power of Unix with the nice pre-packaged hardware and software and development environment and the attention to detail and the whole experience really sold me on that way of thinking.
Yes, there is limited functionality or control or ability on certain way in certain things, but at the end of the day those things don't really -- they don't matter and I just want to make those decisions. Having these decisions made for you is really key for kind of going to that next level, and that's the reason why I do it and that's the reason why I prefer iOS. Like I said, I don't hate Android. I just don't think that they've gotten above that level that all this flexibility, all this configuration, all these different options, they don't matter. You make a choice that's good enough or frankly is really just the best choice for the 80%, 90% of people out there and then you can get moving to something that's even bigger and better. It's kind of how I see it.
Yes. Maybe I am -- better wasn't my intention. It's just iOS is more mature than Android in just that it's been around a little longer so it's evolved. Android will evolve in similar directions, not exactly the same direction. Better was not my intent. It's really just -- they're growing at different rates and all that stuff. The reason that I picked iOS for myself is just attention to detail in certain parts of the experience and certain choices in things that I don't have to make. I don't have to -- in the early days of Android you had to root your phone. I've never had to root my phone to do anything. Really I can get a developer account and have that to my heart's content.
The second question is about audience. I do think that the Android audience is generally a different audience than the iPhone audience and the iOS audience in general and the Mac audience for that matter. That audience is for people that are looking for that attention to detail. Like I said, they want a great experience and it's reflected in the way that -- sure Apple, this is the Kool-Aid directly from Apple; that they're all about the experience and the things that you can do. Android seems to be about giving you the power to do anything you want.
It sounds great but if you have -- it seems like sometimes when you have a lot of choices, you have none because you have no idea what to pick. You end up picking the wrong one when in fact this other one was actually better for you. It's this kind of weird thing of human psychology, right? If I know that there's somebody more qualified than me picking, making this choice -- and this sounds weird, right? It's like I'm a developer. I should want all this power. And again, it comes to making certain choices for everybody that aren't that important but are important enough that we still have debates on them.
This is reflected also in the Ruby on Rails framework. This is one of the things that DHH harps on a lot is that you don't need to decide what the database ID column is. It's not property_id or propertyId or it's not a foreign key or it's not a particular type. It's just I need something and it has to be this convention, and that's done for all eternity. We have figured out how to properly name our primary keys in our databases. I don't need to concern myself with that level of detail anymore. To me, those are the kinds of things that Android users need to worry about. An iPhone is that curated experience, that curated ideal that draws a lot of people to it.
Barry: Saul, I want to thank you very much for being here.
Thank you.