Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
Right now the state of Mobile Devices and their implementations of the browser especially when you get into hybrid apps, you know the UIWebView isn’t as good as Safari for example, but there is a lot of black boxes, a lot of undocumented things, a lot of just trial and error to get the right performance out of it, but once you start understanding some of the ways that browsers are implemented, utilizing things like the GPU which processing power is so important on Mobile Devices because there is so much less of it, and so optimizing the use of that can lead to great speeds but the problem is that these browsers are not really, they don’t give you those features without being a bit hacky.
4. I think what you are saying is that by hacking you can achieve the performance that you want, can you achieve the functionality that you want, can you get at the lower layers, the particulars of a device?
5. Now going back to some of what you’ve said in your talk today, the app that you created or you are part of creating with Belly is for iOS exclusively. Most of the reasons as far as I understand that the people do Hybrid Apps or do Web Apps is for portability. Clearly you had other aims in mind, can you explain?
Barry: Ok, so let me see if I can rephrase what you were saying and understand more clearly, you are developing for iOS, so you don’t have fragmentation issues and you need to scale for basically one platform, different releases, different generations of that platform and you still feel that developing native iOS code wouldn’t be the way to go.
We would have to rely on, let me preface with the fact that we locked these iPads down, so the merchants themselves couldn’t even if they wanted to update any of the software. We do that so that we ensure that our application is running at all times, and some clerk at at a 7-11 isn’t checking their email or playing a video game. So you can’t physically update it, manually the merchants couldn’t update it, but even if they could they probably wouldn’t as often as we would need them to, so we either have to call them and walk them through the process which is quite difficult or send people out to actually manually update them and we have over 7000 merchants, so doing that costs us a lot of time and a lot of money, and how often we want to update these applications it just would not make sense.
So if you are going to develop a Mobile App and you’ve never done it before?
Barry: Well I’m just taking the brute force approach. What is the typical mistake that developers make that gives apps that aren't as performant as they should be.
So I see a lot of web developers think that they can tackle a Mobile Web app by means of the processes that they're used to, the tools that are used to, sort of the same paradigms that they are used to, but the fact is we’ve become so comfortable with the processing power and the tools that we have available to us on the desktop, and so once you move that over to the Mobile Web there is a lot of things that happen that you would never expected, because you’ve just haven’t had to deal with it before, maybe due to just the quirks of that environment or the low processing power.
For example when it comes to rendering performance, the rendering performance is incredibly slow, unless you make use of what I was mentioning before, the compositing and make use of the GPU, but also memory, I mean it’s rare for most web developers to ever consider memory because of the massive amount of memory that we usually have on the desktop, which is you know, can easily, quickly slow down any mobile app. So you kind of have to stop thinking about being a web development in the same way, I tell people to start thinking like Mobile Engineers. Mobile Engineers will think about memory, they’ll think about the GPU, they’ll think about those things and it’s a little more hacky for us to do it but as long as you are looking at those things and experimenting with it and with those things in mind, you’ll start to develop some techniques for dealing with some of those things.
The DOM is not exactly the most efficient and performant document, so we wanted to avoid that as much as possible, so we broke everything out in small components, every little view is its own component, with its own controller and when we needed that to be inserted into the DOM it would be any of its child components, anything that was surrounding it, its children, its parents were all compiled into one document fragment, and then I can do things like pre-cache references to elements that I needed or setup event listeners prior to it actually accessing the DOM, all in memory, and so that was very, very fast and then injecting that at once causing only one reflow. So things like that I just focused on building a framework that works well for the performance in Mobile.
We looked at a bunch of things like JQuery Mobile, I can’t even remember some of the names, I mean Angular hadn’t even come out or at least it hadn’t been announced really. Ember was around, but Ember I think was trying to do more than what we wanted at the time, and Backbone just seemed to fit, and so we also use Zepto so that we didn’t necessarily have to create our own library for DOM manipulation or we didn’t have to do it natively which we could and there is probably the best decision but we do that when there is a performance hit, for the most part, Zepto worked really well for us.
JQuery Mobile was trying to be the solution for all devices and all we wanted was to support iOS, and they would make decisions that would affect iOS, that would make the performance, there is a performance impact just so that they could support Blackberry or older Android devices or whatever they are supporting. So there is a lot of legacy code there and they are making decisions based on that and we wanted to be very, get the most performance that we could out of iOS.
Barry: Dave thank you so much for your insights today!