If you’re building a PhoneGap app, you’ve got an abundance of resources helping you get started–lots of information about how to set up your project and get it running on the different platforms. PhoneGap even released a really innovative way of compiling your project “in the cloud” for different platforms with PhoneGap Build (still waiting on my invitation…). But there seems to be a lack of help when it comes to structuring a PhoneGap application. There are lots of examples of simple one or two screen apps, but what about an app that may potentially have upwards of 5 or 10 different views? How do you build for that? It would potentially be an organization nightmare to plop everything into index.html–the DOM structure could get very complicated (plus you’d be loading the HTML for views the user may never even use). But, you definitely don’t want to be navigating away from index.html because you would have to wait for the webview to reload all the resources and it wouldn’t make for a very good user experience. We decided to explore some options for implementing a templating engine into a PhoneGap project. A templating engine would ideally let us build separate template files for each view (or even parts of a view). We could then load in these templates, as needed, with an AJAX request. Here’s what we love about the idea of using a templating engine: By splitting up the HTML into separate files and only loading the HTML we need, it allows us to keep our DOM clean and simple at any given time–web applications often suffer from performance issues on mobile devices because of an overly complicated DOM. Using template files will make it really easy to manage the HTML and track changes moving forward. Using a templating engine allows us to effortlessly separate the content from the presentation making it much easier to expand and add functionality to our app in the future (e.g.: adding support for localization). There are a lot of choices out there when it comes to choosing a JavaScript templating framework. One that caught our eye was ICanHazJS (…it was probably the name). ICanHaz (ICH) extends the templating power of Mustache and brings it to Zepto.js (or jQuery). ICH is a breeze to implement. First, define the template in a <script> tag in the <head> of your page: [crayon-51dd7f6773746/] When the DOM is ready, ICH takes the defined templates and creates a templating function out of them so using them later is as simple as: [crayon-51dd7f67737c0/] Where data is defined as something like: [crayon-51dd7f6773838/] html now contains a Zepto/jQuery object with the template and injected data: [crayon-51dd7f67738ae/] Unfortunately, defining templates in <script> tags in the <head> of index.html doesn’t fully solve our problem since it still potentially leaves index.html as being difficult to manage. Fortunately, ICH provides a way to define templates after the DOM is ready with ich.addTemplate(). To take advantage of this, we wrote a simple renderTemplate function: [crayon-51dd7f6773924/] When passed with the name of the template, a JavaScript object containing the data to be injected, and a callback function, the function determines if the template has been cached and if not, uses AJAX to load it from [name].tpl.html. Once the template has been loaded, the callback function is called with the rendered HTML. To demonstrate how easy it is to implement this to quickly get an app up and running, we’ve created a simple web app that simply pulls the latest tweets from the Twitter public timeline at the time of launch (check it out on your mobile device–the demos only work in WebKit-based browsers. It’s possible that by replacing Zepto with jQuery it will work even in non-WebKit-based browsers.). See the Demo See the Source (12kb, zipped) The template in tweet_list.tpl.html simply looks like this: [crayon-51dd7f677399f/] When passed data with tweets defined as an array, the templating engine loops through just the {{tweets}} section of the template creating a <li> for each tweet. To populate the template, we get the public timeline data from Twitter: [crayon-51dd7f6773a16/] Then in the callback of the AJAX request, [crayon-51dd7f6773a8c/] Take a look at the source of the demo to see the full picture of what’s going on. Granted, this is a pretty simple example, so let’s add the ability to tap on a tweet to get a little more information. See the Demo (WebKit only) See the Source (16kb, zipped) Still pretty basic, so let’s add the ability to view a user’s bio when tapping his/her profile picture. See the Demo (WebKit only) See the Source (16kb, zipped) Yes, still basic, but you get the idea. Each added function is fairly simple to implement. Plus, with each added function, the size of the web app is hardly increasing and there are really no noticeable performance impacts. After adding some animation and styling, our little demo could easily grow into an app ready for the app store. We could even continue expanding the functionality to eventually become a fully-featured Twitter client. We’re pretty excited about how implementing a templating engine will improve our PhoneGap projects and allow for easily scalable applications in the future. This isn’t the perfect solution for every app, but we believe a good handful of PhoneGap apps can/will benefit from building on a structure that’s both easy to manage and easy to expand. Update: We’ve been seeing a good amount of success based on this model of structuring a PhoneGap application. We explored a little more into the performance improvements we were seeing and discovered they were entirely related to the cost of reflow in the DOM. By removing unused elements from the DOM that weren’t being used for the current view, it decreased the time it took a reflow to occur. Have you used a templating engine in your web/PhoneGap app? We’d like to hear about how a templating engine aided (or could have aided) the development of your app. If you think PhoneGap would be something you’d want to [...]![]()
