Blogs

Being a web application developer in higher education brings with it numerous challenges, not the least of which is the sheer diversity of projects. Case in point: In January 2012 the Athletic Department here at the University of Wisconsin contacted my group to assist them in development of a new mobile app for fans of the football team. This presented a unique opportunity to us as our experience developing mobile apps was relatively minimal yet this app would have a very high degree of visibility. I won't lie to you - there was some amount of trepidation when we accepted the project without knowing exactly which framework we were going to utilize!

During the requirements gathering process, we quickly decided that we needed to start prototyping a variety of potential solutions utilizing the various app development frameworks made available to us. It was made clear to us from day one that we needed to push out both an iOS and Android version by a quickly-approaching launch date of mid-August. Not to mention, there was a nagging voice in the back of my head that told me we had to somehow leverage our existing skillsets developing applications on the Microsoft stack. So where do we begin?

First Attempt: Native Tools

We knew this had to be a professional-looking and native-feeling app from top to bottom. Clearly the only way to achieve this would be to develop the apps natively. Objective C can't be that bad and Java is incredibly similar to C# right? So we're good to go! Not so much. This was a non-starter from the get-go. While I have nothing but respect for native app developers, there is just no way that we could justify the amount of learning and training time we would have had to provide for a fully native implementation.

Second Attempt: Native Tools (with a .NET twist)

After our brief failed affair with Apple's tools, we decided to look more closely at a couple of frameworks we have heard a lot about: MonoTouch and Mono for Android . If you're not familiar with the Mono project, it is essentially an open source, cross-platform implementation of the .NET framework. MonoTouch is their product for developing iOS apps and Mono for Android is the equivalent for developing Android apps. It's the best of both worlds right? I get to use my favorite language (C#) but still develop a truly native app experience!

And we took off with this idea for our prototype. And we were flying with it. And then we hit a snag. And then another and another. Our prototype implementation was being bogged down by our lack of knowledge of Xcode (yes you still have to use Apple's IDE) and the lack of a presence of the MonoTouch/Mono for Android toolsets on popular sites such as StackOverflow. With all due fairness to the Xamarin team, they have done some amazing things. For us, though, we had too tight of a turnaround time and couldn't afford the risk of investing our time in a platform that was relatively new and just seemed a bit underutilized in the community at the current time.

Third Attempt: HTML5

This is where I'm supposed to act embarrassed, look down at my feet, and apologize for taking the easy way out. You've heard it all before:

• There is no way to deliver native-like performance with HTML5/JS/CSS3.
• The current crop of mobile JavaScript frameworks is too slow.
• Mobile devices are underpowered with regards to JavaScript execution.

You got me there. In fact, we had developed a few small mobile apps with PhoneGap and jQuery Mobile. The end results, while very functional and nice looking, did not feel like true native apps.

Everything changed the day I read about Kendo UI. Here was a new JavaScript framework (based on jQuery AND with a mobile implementation!?) from a company we have trusted for many years as .NET developers. The deal was sealed when I read the word "performance" on the front page of their site more than a few times. (Hello CSS3 transitions!)

Needless to say, our prototype was incredibly successful. We were up and running in no time. Soon we found ourselves:

• Developing on Windows using our favorite IDE (Visual Studio)
• Leveraging the years of experience we have with HTML/JS/CSS
• Playing around with a fun and intuitive new JavaScript framework

Upon completion of our prototype we came up with the following (admittedly-subjective) metrics:

• Application performance (including view transitions) was at least 90%-95% of what we would expect from a native implementation.
• Development time was maybe 10% of what we were seeing with the native toolsets.
• We were spending maybe 2% of our time on learning and training as opposed to 50%+.

Kendo UI it is!

Development

Fast forward a month. We have in our hands a full requirements document and are ready to start development. It's important to remember that when you are developing an HTML5 mobile app, you are actually developing a Single Page App (SPA). This was important for us as something to keep in mind regarding performance, memory-utilization and resource-management. We would have to be smarter about how we write our JavaScript and more careful in its utilization.

Before I go any further, I have been asked specifically about my development environment. It's quite simple really. Since we were developing an iOS app we still needed a Mac (although you could use a service like PhoneGap Build or Telerik's own Icenium to avoid this). After creating the PhoneGap project in XCode (see Burke Holland's post ) it was a simple matter of setting up an SFTP share on the Mac which I could connect to with my Windows PC using a tool like ExpanDrive . Make a change in Visual Studio -> Copy Web Site -> Clean and Build in Xcode -> Run in Simulator. Not quite as easy as traditional web development, but surprisingly painless. If I was testing functionality only I could usually get away with using a WebKit-based browser such as Safari or Chrome on Windows (YMMV though).

So what made Kendo UI so helpful for us? I think it's best if I show you a couple of really simple code samples directly from the Wisconsin Gameday app to really demonstrate what Kendo UI can add to your projects.

<div data-role="view" data-layout="contentLayout" id="twitterBadgerFootball" data-show="getBadgerFootballTwitter">
<ul id="twitterBadgerFootballListView"></ul>
</div>

<script type="text/x-kendo-tmpl" id="twitterTemplate">
<div class="tweet">
<img class="twitterProfileImage" src="${profile_image_url}" />
<strong>${from_user_name}</strong>
<span class="twitterFrom">@${from_user}</span>
<p class="twitterText">#=text#</p>
</div>
</script>

function getBadgerFootballTwitter() {
var dataSource = new kendo.data.DataSource({
transport: {
    read: {
        url: "http://search.twitter.com/search.json",
        contentType: "application/json; charset=utf-8",
        type: "GET",
        dataType: "jsonp",
        data: {
            q: "from:BadgerFootball"
        }
    }
},
schema: {
    data: "results",
    total: "results_per_page"
}
});

$("#twitterBadgerFootballListView").kendoMobileListView({
dataSource: dataSource,
pageable: true,
template: kendo.template($("#twitterTemplate").html())
});
}

The preceding code snippets are a simplified example of what it took us to pull in a Twitter feed on the fly. Here you will see an example of Kendo UI's template system , the Kendo DataSource component, and runtime implementation of the Kendo Mobile ListView .

The following is another really simple of example of how we can take an external data source and, using a template and a few lines of JavaScript, turn it into a functioning, scrollable, Kendo Mobile ListView:

<div data-role="view" data-layout="contentLayout" id="blog" data-show="showBlog">
<ul id="blogHome"></ul>
</div>

<script type="text/x-kendo-template" id="blogHomeTemplate">
<a href="\#blogDetail?guid=${Guid}">
${Title}
<br />
<span class="normal">
# var arrDate = PubDate.split(/[-T:]/), myDate = new Date(arrDate[0], arrDate[1]-1, arrDate[2], arrDate[3], arrDate[4], arrDate[5]); #
${kendo.toString(myDate, "dddd MMMM d, yyyy")}
</span>
</a>
</script>

function showBlog() {
$("#blogHome").kendoMobileListView({
dataSource: blogDataSource,
template: $("#blogHomeTemplate").html(),
style: "inset"
}).data("kendoMobileListView");
}

We were tasked with utilizing existing data stores that would provide us the content for our blog view, news view, schedule, concessions, etc. We handled all of this by utilizing our existing knowledge of creating WCF Services (but you could just as easily use the ASP.NET Web API). Again, utilizing the Kendo UI template system and Kendo DataSource component time and time again we were able to easily pull in this remote data and format/display it for our users. Incredibly easy to write the code and extremely fast for the client to consume and process.

Making the Leap from iOS to Android

Once we had a functionally-complete app running in iOS, we began our Android implementation. Aside from referencing the Android version of the PhoneGap library and the Android Kendo UI CSS, the extent of our Android conversion was copying our source code to an Eclipse project! (I believe we had a functioning Android version within about an hour.) I don't want to give you the false impression that we were done in an hour (there was plenty of CSS tweaking and minor JS code changes to be worked in) but when it was all said and done we had a completed Android version in probably 10% of the time it took us to develop the iOS version (the same would have been true if we had started with Android of course).

Application Release and Post-Mortem

Once both apps were released on their respective app stores, we started our post-mortem review. What could we have done better or differently? What did we learn that will help us in the future? Two big things stood out for us:

• When developing a multi-platform app, start with Android. In general, performance is not as solid as iOS so by starting in Android you're setting a minimum baseline of performance.
• Try to leverage existing JavaScript libraries such as Knockout, Breeze, etc - much work has been done to make your lives as developers easier, take advantage of this!

As an aside, I need to mention that for fun we decided to take one of our old jQuery Mobile projects and re-write it using Kendo UI. Since the two frameworks are relatively similar (syntax-wise), it took us all of 45 minutes to convert a small app (12 views). Amazing!

If you are interested in looking at the free Wisconsin Gameday app itself to see some functional examples of what you can accomplish with Kendo UI, you can download it on Apple's App Store here or on Google Play here .

I hope this helps you as mobile developers if you are considering one of the routes we took. At this point, we are not looking back. The HTML5 stack is the future and Kendo UI is providing us the tools we need to take us there.

About the Author
Rob Lauer is a web application developer and project manager from Madison, WI. He works as an IT Consultant for the University of Wisconsin-Madison. Rob only recently jumped on the twitter bandwagon - @rdlauer - be gentle!