Jeff Burtoft: Scaling Mobile with YUI

>> JEFF BURTOFT: All right, welcome to Scaling Mobile With YUI. My name is Jeff Burtoft.
I'm a developer; I'm the lead frontend developer for a company called USAA, located in San
Antonio, Texas, and I've been a frontend developer for a number of years now. Probably about
16 years I've been working the frontend. My first job was as webmaster of my university.
Anyone else ever carry that title? Pretty cool times -- cool titles if nothing else.
It was back when only kids were allowed to work on websites because real programmers
were busy doing things that were much more important, but it was a good opportunity to
get in the door and really build a love for development and working with a client.
I live in San Antonio, Texas. Do we happen to have any other Texans here with us today?
All right, good to see you guys. I'm assuming the rest of you guys are from California -- safe
assumption? We have a name for California in Texas: we call it Far, Far West Texas.
We actually have a name for Californians as well: we call them pre-Texans, they're people
who haven't yet moved to Texas. OK. Public speaking 101: start out by insulting your
audience and you've got them for the rest of the time.
All right, well we're really talking about mobile today. USAA -- we're a company, maybe
the biggest company you've never heard of. We're a Fortune 500 company; we're number
145 in the Fortune 500 list. We sell banking products, insurance products and investment
products to military members, veterans and their families. Now, there is something unique
about USAA for a company our size: we're privately owned, which means that we don't have shareholders
that we report to. Instead we have customers and we call them members. Those are the people
that we're reporting to. Do we happen to have any USAA members in the room? Wow, it's always
a pleasure to present to USAA members. Thank you very much.
USAA, because of the nature of our customers, our customers tend to get deployed a lot and
move around a lot, and they will a lot of times only have their phones or maybe even
their tablets with them to connect to the internet, so mobile is very important to us.
It's a key strategy for us to be able to connect our membership to the services they provide.
We're very particular about the quality of our applications and the quality of the work
we do. This is a few of the accolades that USAA has as a company. For the last two years
we were voted the number 1 place to work for in IT. I can tell you it's a very great place
to work for. It's in the great state of Texas and it's fun because you really have a lot
of diversity in what you're working on, and you have a really great mission of serving
the people who are in the military.
We're going to talk today about mobile applications from a corporate perspective, and what it
takes to make some really good applications. We're going to start out by looking at what
Fortune 500 companies want from mobile. What is it that they're looking for? Is it web?
Is it native? What's the best delivery for a company to go into as a strategy for mobile?
First of all, looking at the native side of things, if you're going to build a native
application, there are certain benefits that you get from building that native application.
First of all, the experience of a native application is very hard to match. You get instant access
to data, smooth transitions, loading an application within seconds -- there are a lot of very
pleasing and pleasant experiences that you can get with a native application that's very
difficult to recreate with web. Second of all, you get access to the hardware. iPods,
iPads, iPhones, Android devices have accelerometers and compasses and cameras and hardware that's
very key to access to be able to get a lot of the different features to work together
in your application. When you're writing a native application, you have access to everything
that's in that hardware layer. That's not so in the web.
The app stores is another big one. Being able to put your application into one of the app
stores and have your members go there to find it is important for a company. Today the average
person will go to look for an application not to Google or to Yahoo! or to Bing to search
for it, but they're going to go into the app store to download it. They want to know, is
there an app for that? So as a company, having your app in the app store is a big benefit
for a native application.
SDKs are also very important. The software development kits give a standard set of visual
components that the developer can utilize within their application, and what that does
is it gives a consistent experience across the different applications. You can have application
A built by one company that has buttons that look exactly like it does in the OS, and exactly
like it does with another application built by a different company. Consistency of experiences
is provided by the SDK.
Then, of course, brand recognition. Everyone wants to say that we've got an app in the
app store, every company wants to put on their marketing materials that you need to go download
our app. That's a big feature of a native application.
For the web side, you wonder, well what's left as far as the benefits go? There's quite
a few. Easy delivery is one of the big selling features. When you have a web application,
it's easy for a person to just go to your URL, load the application, and it downloads
immediately to their device. They don't have to go through the app store, they don't have
to go through a big process to get access to your application.
No potential pay walls. Whenever you build a native application and deliver it through
one of those marketplaces, there's going to be a company who controls that environment.
Today they may have made decisions that make it easy for you to do business within that
controlled environment; tomorrow they may not make it as easy for you to do your business.
The web doesn't have those limitations, so you know that you're going to have the freedom
in the future to do what you need to do with your application and for your business that
you don't necessarily have within the native environment.
Easy maintenance. Has anyone ever built a bug into an application? You don't have to
answer that -- answer's obviously yes. If you deliver it through a native application
that goes into an app store and has to be downloaded by a user, if you find that bug,
you then have to submit a new version of your application to the app store and hope that
your users go and download it. It may take days, weeks, or even months for a user to
go and download those applications. Every once in a while I'll grab my wife's iPhone
and I'll go into her app store and she has about 45-50 different applications that she's
never downloaded, and I spend the next hour updating all of them for her. But there are
a lot of people out there like that, so you can't be guaranteed that when you submit a
bug fix that it's going to get to your users. On the web, the delivery mechanism is much
more controllable for you as a developer. If you have a bug fix, if you have a defect
that you need to address, you can submit it in your code base, and the next time the user
comes to load your code from your website, they'll get the new version of the application.
Higher reusability. When you write a native application, it's generally distributed for
that device and not reusable to another device that's made by a different company. When you
write with the web, just like we had with desktop computers, we have with mobile devices
as well. You're able to write once and use it everywhere.
Then lastly, it's public. There's often an uncomfortable nature for a user to go to a
company that they don't already do business with and download their application and install
it on their device; it takes a level of commitment by that user to do that. Websites are different.
Customers feel comfortable going to a website and visit it even though they don't currently
do business with the company. Having that public access to your application is important
on the web.
What is it that companies do want? Well, obviously we want both. We want the best of both worlds.
We want everything. Those are all good features to desire, so what we see on the rise is we've
seen the hybrid application develop. A lot of companies today will take the best of the
web and the best of native and put them together. Hybrid application usually starts with a native
base, and it's the native code that might give you access to certain APIs, or handle
some advanced animations, or even certain larger sections of your application.
Then it gives you webviews into your web applications. A webview is basically a window. It can cover
the whole application, or it can cover just a section of the application in which you
make a request to web technologies. That may mean a web page that's stored within the application,
or it may mean a web page that is pulled from your web site. So the webviews allow you to
have that flexibility to update applications, ones that may change quite a bit, without
the user having to download a new application, and the native application gives you the ability
to submit it into the app store, distribute it through the different environments. It
kind of gives you the best of both worlds.
Some of the trends that we've seen lately in hybrid applications is the web is able
to perform a lot more of what we used to have to do with native. I've got to be honest,
Apple is one of the biggest contributors to this change because they're giving us more
and more access to APIs and hardware functionality within the webviews that we didn't have a
few generations ago. So you're seeing more functionality being done in the web, which
leaves less that has to be done within the native application itself.
We're going to be looking at how to maximize that functionality. How do you maximize the
web? We're going to look at four keys to maintain quality whenever you're scaling with web on
mobile. As you write more and more applications, it's important that you have some ways to
maintain that quality. For a company like us, we write a lot of applications, we have
hundreds of developers, and people count on our applications functioning consistently.
The first thing we're going to look at is reusability. It's key to be able to write
something once and use it over and over again; you don't want to have to take a functionality
that you've written once and rewrite it just to use it in another portion of the application
or another application itself. Compatibility. You not only want your application to work
for everyone, but you want it to work well for everyone. Flexibility. Know that within
your environment, there isn't going to be one size that fits all developers; sometimes
you need a lot of structure and a lot of rules, and other times you don't. Then last but not
least is performance. We're going to look at managing memory, loading quickly, and making
sure that your application works elegantly on the devices that you're intending to support.
OK, reusability. When you build hundreds of applications you don't want to start from
scratch every time. What I have here is a little chart that we use that talks about
some of the different technologies that we put together at USAA and stack to build our
web applications. The basis of those is based off of a framework called Wicket. It's a client-side
framework. Do we have any Wicket users out there, anyone with experience with Wicket?
All right.
Wicket is not always the first framework you would think of when you think about combining
a client-side framework with YUI. But what it does bring to the table is it brings a
really great structure for componentization. You can take a piece of code and write it
as a component where it doesn't have any other ties, or any other dependencies to other components
on the page, and put those components together to build a page and deliver it to your members.
Likewise, YUI gives you that same extensibility. You can take a component and built it so that
it doesn't have any other dependencies and move it from page to page, from application
to application. We take these different technologies and we stack them on top of each other, and
we build components, throw them in our own library, and have all of our other developers
access to them.
This is kind of how we break it down when we're using components. There are different
levels of skills, and different amounts of time it takes to build or use a component
at USAA. The heaviest here on the right is to build a component. It takes the most time,
it takes the most varied skill set, to build that initial component. You may require the
Java skills to build the Wicket application portion, HTML5, YUI, CSS3, and that often
doesn't lie within just one developer. It often means a team of developers working together
to build this initial component. It takes a lot of time, it takes a lot of energy, but
once it's complete, it's put into a library for reuse. It follows then under one of the
other two categories, where you can either take a component and extend it, or take a
component and reuse it exactly like it is.
Extending a component doesn't take near as much time and near as much of a varied skill
set as it does to build that initial component. It takes fewer developers to extend the component;
you may have a component in your library that almost meets the needs that you have. Instead
of starting from scratch again you can take that component, extend it, add the features
that you need to it, reuse it yourself, and then put it back in the library as an extended
component. Other times, all you need to do is pull that component out of the library
exactly like it is and use it on a different page or in a different application. That doesn't
require a lot of skill set at all; it usually just requires someone who's a Java developer
to take that component and extend it into their own application. So componentization
gives us a structure to our teams where we can save time with different groups by allowing
them to use something that already exists.
I want to focus a little bit on the YUI layer of this, and look at a case study here of
the use of the YUI widget. What we have here are screenshots from one of our personal financial
management applications. This application was delivered as a webview inside of both
Android devices and iPhone devices. Each of these components here, these visual components,
were all built off of the YUI widget. Some of them were pie charts, some of them are
bar charts, some of them are list legends. They have a varied functionality to them,
but they all come from the same base.
This is how we started out. We took the YUI widget and we extended it. We made our own
USAA base widget for this application. Inside of that extended widget we were able to stick
our standard list generator, a basic template, and our touch and click events so that this
component would know when it should use touch and when it should use click. We added the
ability to have a ScrollView within each of the components, and a few other base functionality
that we knew we would need in most of the visual components on the page.
We then took that application and we extended it. We added a model to it and created a new
template. In that new template we had the CSS classes that brought in the right look
and feel, and updated the structure to present the data that we needed. We were then able
to take that same USAA base component and extend it again. The first time we created
a list element that listed out the different transactions from an account. We were then
able to extend that same base component again and be able to build a pie chart from it,
extend it again, and be able to build a bar chart from it.
We then found out that some of the other components we had had more in common with an already
extended component than it did with just the base component. We were able to take some
of those extensions and extend them again, so a pie chart could then become a legend
by updating the template a little bit and removing the ScrollView. Then we found out
that as we were building all of these different components, we found other functionality that
were in common from each of those other extended components. So we were able to take that functionality
and move it back into our base extended object so that all of the different components would
have access to that functionality.
What we were able to do is we were able to take a single object that was extended from
widget and extend it again and again, and inherit functionality that was common across
all of our components. We built our pie charts, our bar charts, our transaction rows, tables,
everything from that one component. Not only did it save time in developing the component,
because that code didn't need to be written over and over again, but it also saved page
weight, because we didn't have to reproduce code, we didn't have to write the same thing
and deliver it twice because it was in two different applications.
Additionally, it gave us some very strong patterns to the way we wrote these applications.
Each of these components were based on the same widget; attributes could all be accessed
the same way, they all had getters and setters, and it was a very common interface for a developer
to work on a component that another developer had written and be able to jump in and know
exactly how that component was going to work. It made for a very reusable environment within
the application.
Moving on to compatibility. Compatibility is essential within mobile applications, and
I have a bit of a pet peeve when people write applications that only work on one device.
If you're writing code that is only intended to work on the iPhone then you should probably
just write native code, because that's what it's for. It's for writing something that
works specifically in that environment. The web has a lot of flexibility to it, and it
should work across browsers.
A lot of times, from a business perspective, they look at the mobile frontier and they
think that there are two devices that they need to support. This is probably a good time
to poll the audience here a little bit. I used to ask how many Apple fanboys I had in
the audience, but it turns out that's apparently a derogatory term to fanboys. If you find
that a derogatory term you're probably a fanboy; it works out that way. But who carries an
iOS device in their pocket today? OK, and who carries an Android device? OK, well we're
pretty heavily weighted to iOS. Android people are usually offended when I talk about this
next section.
The iPhone. Supporting the iPhone is not just supporting one device. First of all, you need
to be clear which devices you're going to support. Since Apple brought out the iPhone
they've had the five different generations of it, from the original iPhone through the
3G, 3GS, 4, and the 4S, and if you're working with a webview that's inside of your native
application, that native iPhone application can be downloaded onto an iPad and used on
an iPad or an iPad 2 as well. Those become different environments that all have their
own special rendering that they do for the webviews. You have to be aware that all of
these devices are on the market and being used today, especially if you're supporting
international users. We see a lot of original iPhones and 3Gs being used in the international
markets. So if you're going to support iPhones, you need to support all of these devices,
and don't forget about the different OS versions. As hard as it is to get someone to upgrade
your application, it's often harder to get them to upgrade their operating system. Within
these different devices you also have a myriad of different OS versions out there.
For Android, it's not as easy. We have a variety of manufacturers, which is a good thing; we
have a lot of variety in devices, and those manufacturers will ship sometimes the same
phone to different carriers under different names that behave just a little bit different.
In any given year, you can have a new phone released with one of five different OS versions
of Android running on it, so it's very difficult to say that you're going to support Android
devices without knowing what environment it is that you're going to test it on.
I'm going to look at a case study here on ScrollView. The same application that we built
and showed you the screenshots for before, the personal financial management application,
we ran into a little glitch whenever we were using ScrollView. This is the YUI ScrollView
component. We had it built into each of our components. Whenever we were testing on the
browsers on the phones themselves, we didn't run into any problems. As soon as we brought
our application into the webviews of the native applications, we ran into problems on three
of our phones. Three of our most popular phones had difficulty using the ScrollView. It was
pretty easy to diagnose; we had plenty of view but no scroll, so you would touch the
screen and nothing would happen.
I was working with a team, I was leading a team of developers for this, and being the
frontend developer that I am, I consider one of my key skill sets to be troubleshooting.
I told the team to step aside and allow me to take this on, because I knew how to fix
bugs. I went through the process and I pulled the code apart, tried to understand everything
I could about ScrollView, looked at the different events that were being utilized at different
times, thought about all the other events that may be taking the touch controls away
from the ScrollView before it could be used by the JavaScript component itself, and tried
to prevent any events that I could, and I couldn't get anywhere. I just assumed that
ScrollView itself was broken, that it wasn't written very well by the YUI team or something
of that sort, so I went out to some of the other scrolling JavaScript libraries out there.
I pulled in iScroll first. I don't know if any of you guys have used that before. I loaded
iScroll in instead, and it didn't work either. I couldn't get it to scroll on that. I decided
I would take a look at Sencha and see how Sencha solved the issue. They worked on a
lot of webviews. I loaded a Sencha application inside of my view and couldn't get the Sencha
to scroll. We then tried an application that we had written ourselves to handle scroll,
threw that in there, and I couldn't get any of these ScrollViews to work.
So I moved on to step three, which was to cry and get a couple of gray hairs. At least
I didn't have to go as far as Dav did and lose part of it. I went home, complained to
my wife, but unfortunately she's neither a developer nor a YUI contributor so she had
no help for me there. Then finally I moved on to step four, which was to provide an alternative
experience for some of these devices. Devices that supported the ScrollView, and it worked,
got the application. The other devices were moved to an experience that provided them
this functionality without needing the ScrollView.
It is important to know that you can't fix everything. Not every phone is going to support
every version of JavaScript, and it's not going to support every feature that it is
that you want to use. In fact, you don't always want to fix every feature. Sometimes fixing
a feature for all phones means not being able to use some of the newer technologies for
some of the phones that can adopt it. It may mean making the environment worse, or heavier,
for devices that don't need that fix in there.
What was the problem exactly? I mean, aren't all Android phones created equal? Let me walk
through the process a little bit of what happens with an Android device. Google produces the
operating system, and they put all the finishes on it and then release it to the manufacturers.
It's then plain and has potentially all the functionality working in it. It's then sent
over to the manufacturer, and the manufacturer will put their layer on top of it. All the
manufacturers want ways to differentiate their device from the other devices, so they may
add additional functionality, update the UI, and do things to it that will make it stand
out in the marketplace. Well, then they pass it over to the carrier, and the carriers themselves
will often put code on top of that, and it may push you towards specific services that
they have contracts with on that carrier, or it may add some additional functionality
that will draw you towards that carrier. A single device that has an operating system
that's produced by Google, manufactured by a manufacturer and then sent to different
carriers, will have different functionality.
What we found with this particular issue is that the three devices that didn't work were
all from the same manufacturer. We assumed that there was something about the manufacturer
install that we were missing, so we tried every device we could from that manufacturer
and still found out that really only those three devices had this problem. We then realized
that those devices were also all produced by the same carrier; they were all released
on the same carrier. So the same operating system from the same manufacturer, on the
same carrier, all had this same problem.
Luckily we had a little bit of a relationship with that carrier, so we worked with some
of their developers and realized that there was a bug within the layer that they had put
on top of the device that was stopping the touch events from falling down into the DOM
layer. Once the initial touch event was captured by the screen, it was never passed down to
the DOM itself. At that point in the webview, only click events were getting through. They
had also updated it in newer versions of their phones, so we were happy to know that the
choice to provide the alternative experience for those users really was the best choice.
There was nothing that we could have done in our code to get that working. The best
thing we could do is provide a different experience for those users.
Taking compatibility one step further to adaptability. YUI is definitely the benchmark for this;
they do really great at packaging code based on the functionality of that device. The more
you know about the device that you're using and what it supports, the more you can send
down a code base that is built especially for that device. If you have a larger screen
size, you want to take advantage of that screen size. If you have a phone size screen size,
you might want to build your component a little bit different. If you know what your device
is up front, you can lay out the screen differently.
So it additionally allows you to adapt to the environment. If you can take advantage
of CSS3 transforms, it's important that you would do that. If you use 3D transforms that
will take advantage of the GPU of the device, you should do that, but not all devices will
support CSS3. If you know from your client's prospective that it does or doesn't support
CSS3, you can appropriately send down code that will help that code base adapt to that
device: use the GPU if it can, fall back to JavaScript animation if it doesn't.
We use YUI heavily here to fill in the holes, so some of the devices with earlier operating
system versions that don't support some of the features we want to use for our users,
YUI will often provide that code that fills the gap and allows us to provide that functionality
a different way for those users. Whenever you have an environment that will adapt to
the user, it's going to bring you as close to a write once environment as you can get,
where a user can go and visit one site and you'll cater the code to them. Instead of
sending desktop users over to this site, mobile users to this site, and tablet users to this
site, it allows you to send them all to the same place and let the code determine what
it is that it wants to provide for them.
All right, moving on to flexibility. Not all developers are created equal. This is my example
of that. You probably know the guy on the left: he's the one who discovered that JavaScript
has good parts. This guy on the right, that's me. He's the one who built all the bad parts
into the same application. So just because you have a good developer, doesn't mean that
he's going to be a good JavaScripter. A lot of times the best developers that I work with
who are Java developers know to call a JavaScript developer when they need something done in
JavaScript. Again, to quote Douglas Crockford, "many people write JavaScript; few know how."
We really are big fans of Douglas Crockford at USAA. I pass out little bracelets to all
my developers that say WWDCD: What Would Douglas Crockford Do? I make them wear it. It's great.
That's not entirely true; I don't make them wear it, they really just want to wear it.
We're going to go back to this chart here. When you have developers with varied skill
sets, and we looked at what it takes to build a component, extend a component, and use a
component, USAA is primarily a Java shop. The majority of our developers are Java developers.
We have maybe 30-50 frontend developers right now who are working on this, so when we're
building a component, it's important that we get all of the developers who have the
right skill sets to work on that component and put that component together for the initial
development. When you extend that component, you generally don't need as many skill sets;
you can do without some of your YUI experts if you don't need to extend the YUI layer
of that component. Additionally, if you're just picking that component up off the shelf
and using it as it is, you really just need the Java developer skill set.
It's important whenever you're scaling, when you're writing a lot of applications, that
you have the flexibility. It's not a good idea to assume that all of your developers
are going to have strong skill sets in all the different technologies that you want to
use. If you do that, one of two things is going to happen: either you're going to limit
the number of technologies that you can use, because if you're only going to use technologies
that all of your developers are familiar with, it's not going to be many, or you'll be disappointed
and you'll get some poorly written code from developers that you might expect more from.
So it's important to have a flexible environment.
At USAA there are three different flavors of JavaScript that we use on different pages.
It really depends on who's writing those pages and what that page is going to be used for.
First of all, the full YUI version. We use YUI3 on all of our mobile applications. If
we're writing anything with a client-side MVC, anything that has advanced functionality
or that takes a data object input, it will use the full YUI. If we have a page that might
just have a little bit of functionality, and especially marketing pages that may only be
around for a few days or a few months, don't require the specialized skill set, we'll pull
out simple YUI for those pages. It doesn't require all the complexity of YUI itself,
so it opens up to the number of developers who can write it. Then some pages we just
have very simple pages that have simple JavaScript needs. Sometimes you don't have any JavaScript
needs at all. If we just need to validate a form or have a very small portion of the
application that would require any behaviors, we'll just use JavaScript for those pages.
So we have a flexible environment that allows us to use complexity when we really need it,
build structure into the application when we really need it, and then go without it
when we don't.
Last but not least is performance. Performance is very important when you're using mobile
devices. I haven't mentioned this a lot in the talk, but one of the keys to maintaining
quality is testing, and testing often. It's difficult, I know, to get your hands on a
lot of devices. Some of the guys from my shop make fun of me because I basically have five
or ten different devices on me at any time, from tablets to phones, because I like to
see how applications are going to work on all of the different devices. There are companies
out there like Perfecto Mobile that will provide you access to a lot of the different phones
and tablets out there on the market so that you can test your application on them. But
it is important that you test on an application itself. Don't assume just because it works
in a browser that it's going to work inside of the browser on a phone, and even more so,
inside of a webview.
We're going to look at three things here. Memory management. Devices have resource constraints;
we all know that we have a limited amount of RAM within the devices. The processor is
limited. The amount of power that you have access to, or the amount of power you want
your application to utilize, is important to be aware of. Loading quickly, making sure
that you're loading small packages. If you have a lot of functionality in your page and
you have a lot of JavaScript to run it, it's going to take a lot of time to load it. No
matter what techniques you put into place, a lot of code generally takes time to download.
Building into a single request and reducing the dependencies certainly does help that.
Then also you want to make sure that it works elegantly. Sometimes you can have code that
works on an iPhone 4, or an iPhone 4S, but it works very poorly on an iPhone 3G, or 3GS.
So it's important that if you're going to support those older phones that your application
will work well on it.
A little bit of data for managing memory. These numbers here... The iPhone itself will
allow you 10 megabytes of memory per window, so if you open up a browser window you can
have up to 10 megabytes worth of memory within that window before it starts to do some pretty
wicked memory management, and deleting things from your memory, for you. That's not a whole
lot to work with. It may sound like a lot, but when you start to add up the footprint
of your JavaScript and DOM and the amount of images that you have in there, it starts
to be eaten up pretty quickly.
It gets even worse when you move inside of a webview. Webviews have even more constraints
on the amount of memory and the functionality that you have available in those webviews.
From experiential data, an iPhone webview has less than that; they have about 6 megabytes
before you start to run into memory problems. Now, if you were on an iPhone working inside
of a webview, once you start hitting that ceiling of memory, usually the application
will crash. I've seen applications crash just because the images inside of them were built
for a Retina display, and were too large for the webview itself.
Some of the Android phones are a lot better, especially the newer ones on the market. The
Nexus S has 20 megabytes of memory per window available to it. You have to keep in mind
that this is all pending the available system memory, so if your iPhone has a lot of applications
running in the background then the amount of memory that you're going to have left for
that window that's on top may be smaller than it needs to be.
Moving on to loading quickly. Your JavaScript frameworks can be quite heavy. This is a challenge
I've put out there for anyone who works with a JavaScript framework, especially obviously
YUI: do whatever you can to make that file size smaller. YUI, please continue to componentize
and work towards that effort to make those requests smaller, because that's very important
within the mobile device. Whenever you load these different frameworks... And I kind of
have the sizes there: YUI itself at 21 Ks, simple YUI at 36, backbone at around 7 K,
and Sencha at 120 K, that's just to get your functionality starting. Now, whenever you
start pulling in other modules and other functionality, and then your own JavaScript code, that time
goes up.
Whenever you're loading an application, you want to consider both the load time and the
time it takes to render that JavaScript as well. If you're loading your JavaScript in
5 seconds, but then it takes another 3 seconds to render all the JavaScript that you loaded,
to a user, that's an 8 second wait time. So make sure that you consider that initial render
time it's going to take within your load time.
Just to give you kind of a frame of reference, our standard for a mobile application page
weight is 20K. We really don't have any applications that have been able to meet that standard
yet, but that's our goal; we want to see each of our pages get down below 20K.
A question that's often asked to me is about AppCache, because I've heard many times people
say with HTML5 AppCache, it really mitigates the need for the small files and to be concerned
about the file download sizes. This chart up here kind of demonstrates what it's like
using AppCache within a dynamic environment. If you have a page that's dynamic and that
page could have different markup that's delivered for a different user, it may mean that you
have your initial JSON object on the page and that'll be different per user, or it may
have date time stamps or something that changes. Anything that's going to change about that
initial page, if you're using HTML5 AppCache and you have your manifest file on your initial
page, that initial page will automatically be cached with all of your other assets. So
you can't place it on a dynamic page.
One way around that is to insert a jump page. So your application would hit a jump page
first, which may be just a loading screen, but an opportunity for you to go and request
all of the assets for your application and load them on that jump page. That jump page
will then be cached along with all the other assets, and then you can forward yourself
onto your dynamic application, which will then be able to pull all of its assets from
the AppCache. There is a workaround for it. It's a little bit difficult.
But there are other things you have to consider when you're using AppCache. Obviously we looked
at why you can't load from a dynamic page. But it's also problematic with server-side
states where the URL doesn't change. If you have ever seen an environment where you will
reload the URL and the URL will be the same but the data on the page will change -- maybe
you're going through an application and it always uses the same URL with a postback that
then loads the second page of the application -- that doesn't work with AppCache, because
it looks at the URL that's being requested and ties it to the data within its AppCache.
So you can't use it to store resources of a page that is dynamically generated but has
the same URL, or you may be caching the wrong page.
It's also difficult to manage the manifest file. In our environment we do releases, and
the releases are all automated; they know when to update the expires, headers for all
of the assets, and they will know when to tell a user to download new assets. Obviously
you want your manifest file to change at the same time, so it's difficult to systematically
know when you're going to update your JavaScript files and make sure that you're going to reload
the right manifest file so that the user doesn't get a mix of new JavaScript and old JavaScript.
The last thing is webviews. If you're using AppCache within a webview, webview will have
sometimes surprising behavior in the way that it will cache your data. The cache life may
be based on factors that are outside of your control. A user may have limited system resources,
they may have installed and reinstalled your application; there's a number of different
things that can trigger that cache to be deleted that you don't have control over.
Moving on to working elegantly. Again, if you support the different devices, you want
to make sure that your device works well within that application. If you have an Android phone
or an iPhone, the amount of memory that is available for your application will be dependent
on the number of applications that are running within that operating system. If you're doing
all your testing on an iPhone that only has your app on it and isn't running anything
in the background, you're probably not simulating true user data. You want to make sure that
you take those things into consideration to know how your application's going to perform
on a real user's phone.
You want to make sure that you take advantage of HTML5 features when you can. If you can
utilize the hardware acceleration, you want to do that. Use 3D transforms whenever you
can.
Quick render time. Again, whenever you load JavaScript, take into consideration, as well,
the amount of time it's going to take your user to render that JavaScript. Make sure
that you're loading treatments at the appropriate time, as well. If the first thing you do is
render your JavaScript and then you render a loading treatment, your user may be looking
at a blank screen for quite a while. You want to make sure that the very first thing you
do is load your loading treatment. A lot of the time I like to recommend to our developers
to build their initial interface with markup so that the user has something that they're
looking on, something usable on the page, while they're loading that JavaScript in the
background. Of course, it must manage memory and resources.
Know the limitations of the devices that you're using. Battery life is important. You don't
want something that always has the GPS on that's going to be draining the battery of
the user. Screen size will vary from device to device, and you want to make sure that
you're not loading data that you're not going to use. Most users in the US, and just about
all users outside of the US, pay for their data, and if you're loading data that you're
not going to use in your application, or if you're doing too much pre-loading, you might
be disadvantaging your user because they're loading a lot more data and paying for a lot
more data than they're going to need.
Wrapping up here: making the web work for mobile. Reusability, again, is real key. You
want to make sure that you're not starting from scratch every time that you write an
application. When you write an application, think about the number of ways that you might
be able to reuse that component in the application that you're writing, or within other applications.
Compatibility. Make sure that your device works well across all the devices that you
say you're going to support. It's difficult when you look at a user agent string to tell
the difference between an iPhone and an iPhone 3GS and an iPhone 4, so you want to make sure
that you're appropriately providing experiences for the different users.
Flexibility. Not all developers are created equally, so you want to make sure that you
have an environment that utilizes the skill sets of the developers that you have available.
Then performance is always key within mobile. Whenever you're developing for mobile applications,
make sure that you're not writing an application that works well on the desktop, or even works
well in the browser, but doesn't work well in the webview. Make sure you test it within
the environments that you're going to use it in.
A few of the credits for the images and logos that we utilized here. Then this is how you
find me. I'm not much on social networks. I think I only joined Twitter to find out
what Justin Bieber had for lunch one day or something, and I've had that account ever
since. You won't get much from me, but please follow me if you're interested. I do more
retweeting than anything.
OK, well, we are out of time. If you have any questions I will hang around up here.
Thank you all for coming to the presentation today.