THE BEST OF MOBILE• HybridMobileAppswithASP.NETMVC

• BijanVaezonHTML5

• WhataretheMostImportantandMatureCross-PlatformMobileTools?

• Mobile,HTML5andtheCross-PlatformPromise

MobileDevelopmenteMagAugust2013

By

Contents Page 2

P. 3–8

P. 9–13

P. 14

P. 16-17

HybridMobileAppswithASP.NETMVC

BijanVaezonHTML5

WhataretheMostImportantandMatureCross-PlatformMobileTools?

Mobile,HTML5andtheCross-PlatformPromise

Contents

Contents Page 3

Mobile devices are everywhere

Over a decade ago, while attending a Microsoft Professional Devel-opers Conference, (who is “we”?) were shown a video on the coming mobile future. The video showcased futuristic-looking, Windows-powered phones being used for tasks such as locating the closest doctor’s office. In an era where the Palm VII was the closest thing to a smartphone, the video showcased an impressive future.

Fast forward to 2013: There is no mistake that we are living this future. Smartphones and other mobile devices are everywhere. They are available at multiple price points and are increasingly affordable. In fact, for many in the developing world, their only computer is the powerful smartphone they own.

Mobile application development: growth predictions from Gartner

Gartner predicts (No footnotes in journalism) that by 2016, at least 50% of enterprise e-mail users will rely primarily on a browser, tablet, or mobile client instead of a desktop client. Given the increase in the adoption of mobile devices, it is also expected software-application development targeting these devices will also dramatically increase in the coming years. Again, Gartner predicts mobile-application-de-

velopment projects targeting smartphones and tablets will outnum-ber native PC projects by a ratio of 4 to 1 by 2015. Gartner further says that smartphones and tablets will represent more than 90% of the new net growth in device adoption in the coming four years.

The Apple App Store is the trademark name now boasts over 500,000 apps. Android has close to the same number and the Win-dows Phone marketplace, a much more recent contender, recently crossed 50,000 and is growing at a fast pace.

Line of business mobile applications: the challenge posed by fragmentation

Given this exciting backdrop, we can be certain most line-of-business applications will be made available on mobile platforms in the imme-diate future. As with any other opportunity, mobile-application devel-opment, with all its promises, comes with its own set of challenges.

One of the primary challenges is the issue of fragmentation. Esti-mates from the third quarter of 2012 indicated a fragmented the mobile-operating-system market. Vvariants of Android accounted for about 72% of devices sold during this quarter. iOS accounted for about 14%. Research in Motion/Blackberry accounted for about 5% and the Windows Phone platform for around 2% (via Gartner).

Developing a line-of-business application to function on all these devices involves working with the following vastly different technologies:

PlatformPrimary development

platformPrimary development

languagePrimary IDE Development platforms

Android Java based Java EclipseWindows, Mac OS X,

Linux

iOS Cocoa Touch framework Objective C Xcode Mac OS X

RIM Java ME Java Eclipse Windows, Mac OS X

Windows Phone 8 .NET/native C#/C++ Visual Studio Windows

It is also worth noting there is substantial fragmentation even within some platforms, especially the currently dominant Android platform. Given that Android is open and vendors are free to make changes, there are literally hundreds of Android-based devices available on the market today. Many of them work only with specific levels of the Android API. Some of them have issues with applications that target certain features even within a supported API level. Fragmentation makes the implementation of a native solution on multiple platforms quite daunting.

“The platforms, languages and tools are substantially different, and the effort involved in producing a solution that will work on every platform is substantial.”

HybridMobileAppswithASP.NETMVCBy Daniel Jebaraj | March 12th, 2013

Contents Page 4

Mobile web applications: the solution for fragmentation?

Web applications are an alternative to native applications. All the major mobile platforms offer capable browsers and, with the notable exception of the Windows Phone browser, most platform browsers are based on the open-source WebKit browser platform that powers the desktop versions of Apple Safari and Google Chrome. There is ex-cellent support for JavaScript on these browser platforms andjQuery is fully supported on most current mobile devices. Also, increasing compliance with HTML 5 and related web standards is making the browser even more attractive as a development platform. It is cur-rentlypossible to build web sites that function well on mobile devices.

Mobile web applications: additional considerations

A mobile web site does not offer the user the same experience as a native application. Users on specific hardware platforms are accus-tomed to the enhanced experience offered by native applications. Such applications are always available on the launcher surface of the device and obey its user-interface contracts. For instance, on Android the left menu button usually displays a context menu. Users expect this. Web applications can be installed as shortcuts on the launcher surface of most devices, but they do not always obey the specific us-er-interface expectations of the deployed device. Another disadvan-tage to web applications is they have no native access to hardware beyond what is exposed by HTML and related web standards. For instance, there is no direct access to contacts, images, or the camera on the device. Many applications require access to key elements of device hardware.

Hybrid applications: the best of web and native applications

Hybrid applications are completely native applications that embed a platform-specific web-browser control. All major mobile platforms including Android, iOS, Windows Phone 8, and Blackberry support the embedding of web-browser controls. Since the wrapper is com-pletely native, users are often not even aware they are interacting with a web application. The native application can provide a seamless navigation experience.

It is also possible for web pages displayed in the browser to interact with native hardware through a JavaScript bridge, a form of which is available on every major platform. Using such callbacks to the na-tive platform makes it possible to access contacts, capture or select images, and play media. In fact, anything you can accomplish through native code can be accomplished through the bridge. The bridge code will of course have to be re-written for every target platform, but this is usually a small fraction of your total application code.

Several JavaScript bridge frameworks exist; the most popular is the open-source PhoneGap platform, which provides a substantial part

of this plumbing. We will not be using any frameworks in the example below. We will instead illustrate the concept with a simple Android wrapper.

ASP.NET MVC: an elegant framework for your backend

Hybrid applications can be built with any web backend, but who is “we”? firmly believe ASP.NET MVC is ideally suited (No footnotes!) for the implementation of hybrid applications. Some aspects that make ASP.NET MVC a good choice for such applications include:

Clear separation of responsibilities

The clear separation of responsibilities afforded by the MVC environ-ment makes it possible to precisely control HTML output. This makes it very easy to generate mobile-friendly HTML. There is no built-in, self-contained control model that makes it hard to control the markup produced.

Sharing most code with desktop or tablet web clients

If you have an existing ASP.NET MVC application that targets desktop browsers, much of the code can be shared with your mobile application. The controller and model code can be shared almost as is. Only the view needs to be changed. It is not difficult to specify a custom view for mobile clients even with the current version of ASP.NET MVC, but the next version of the ASP.NET MVC will make it even simpler. For additional details on mobile-friendly features in the upcoming version of ASP.NET MVC, please refer to http://www.asp.net/mvc/tutorials/mvc-4/aspnet-mvc-4-mobile-features.

Minimal friction with underlying web development model

ASP.NET MVC does not build layers of abstraction over stateless web applications. Instead, it offers a simple model that works in alignment with the underlying platform, making it easy to make AJAX calls or use jQuery on the client. There is no complex abstraction such as ASP.NET Web Forms’ ViewState to worry about.

It is also worth pointing out the business and database layers that already exist in your current .NET applications can be effectively reused with ASP.NET MVC applications. ASP.NET MVC is completely agnostic about the business and database layers and can work effec-tively with any system currently in place.

Contents Page 5

Figure 1. Initial screen

Sample hybrid application

We will now walk through a simple example to illustrate the devel-opment of a hybrid application end-to-end using the ASP.NET MVC platform. This sample displays information on students attending a fictional Contoso University. There are a couple of general infor-mation links as well as access to a searchable student directory In order to keep the example clear, the sample does not implement any security or error handling. There is no complex code since the objec-tive of the sample is not to showcase the power of the ASP.NET MVC platform but to showcase its suitability as a backend platform for the development of hybrid, native mobile applications. The complete code for this sample is available at bit.ly/mvc-native-mobile-apps.

Prerequisites to work with the sample code:

• ASP.NET MVC 3 with Visual Studio 2010 (any version including the Express Edition).

• Functional installation of the Android SDK and the Android Devel-opment Tools plugin for Eclipse.

Detailed instructions and requirements are available here: http://developer.android.com/sdk/requirements.html

• jQuery and jQuery Mobile. Local copy is not required since the sample code will simply reference the jQuery CDN.

The ASP.NET MVC backend

In the sample code, the provided _Layout.cshtml contains script references to the jQuery and jQuery Mobile libraries. They are not required to build an ASP.NET MVC mobile application, but they do handle a lot of the grunt work. We use jQuery Mobile in our sample to simplify formatting content for mobile devices.

<link rel=”stylesheet” href=”http://code.jquery.com/mobile/1.0/jquery.mobile-1.0.min.css” />

<link href=”@Url.Content(“~/Content/Site.css”)” rel=”stylesheet” type=”text/css” />

<script type=”text/javascript” src=”http://code.jquery.com/jquery-1.6.4.min.js”></script>

<script type=”text/javascript” src=”http://code.jquery.com/mo-bile/1.0/jquery.mobile-1.0.min.js”></script>

Most mobile web clients assume a web page is sized at about 900 pixels and will automatically scale to display the entire page on the device. With a mobile site optimized for a smaller device, we can provide a hint to the device that it should not scale but should instead use the width of the device. This is accomplished via the use of the viewport meta tag as shown below.

<meta name=”viewport” content=”width=device-width, initial-scale=1.0 “>

The default index action method on the home controller is mapped to the following view markup.

<nav > <ul id=”menu” data-role=”listview”> <li>@Html.ActionLink(“About Us”, “AboutUs”, “Home”)</li> <li>@Html.ActionLink(“Contact Us”, “ContactUs”, “Home”)</li> <li>@Html.ActionLink(“Student Directory”, “StudentDirectory”, “Home”)</li> </ul></nav>

We have a simple unordered list with three action links. We specify the list should be automatically formatted as a list view by the jQuery Mobile runtime using the “data-role=listview” attribute setting. This is all that is required to display the following initial UI on a mobile device.

The jQuery Mobile runtime takes care of formatting it as a list view. As mentioned earlier, jQuery Mobile is not needed. You can pick the formatting and scripting approach that suits your needs best.

Contents Page 6

The sample contains the views displayed when the About Us and Contact Us options are invoked. These screens are straightforward and do not require any further explanation.

The Student Directory link displays a page with student names grouped by starting letter. The page also displays the number of students listed under each letter.

Figure 2. Student directory initial screen

Figure 2. Student directory initial screen

Clicking on any option displays a list of students, as seen below.

The student directory views are also fairly simple. They iterate through and display data in a list. The view displaying student details is shown below.

@{ ViewBag.Title = “Student Directory”; Layout = “~/Views/Shared/_Layout.cshtml”; var random = new Random();} <ul data-role=”listview”>@foreach (string student in ViewBag.Students){ <li> @{var number = random.Next(1000, 9999); } <img src=”@Url.Content(“~/Content/images/UserImag-es/80-80/” + student + “.jpg”)” alt=”@student”/> <h3>@student</h3> <h4>919-555-@number</h4> </li>}</ul>

San FranciscoNOV 11 - 15, 2013

SAVE $100 WHEN YOU REGISTERWITH PROMO CODE “MOBILE”

Over 100 speakers|15 concurrent tracksKey Topics: Mobile, Agile, Cloud. HTML5, JVM, Big Data, Web

2013

Contents Page 7

It is a good idea to test the ASP.NET MVC backend in a desktop browser before proceeding to review the Android wrapper that we will work with next.

You can also directly test on a mobile browser provided the test site is accessible from your test device. If both the development PC and your test device are on the same network, it is possible to make setting changes to the ASP.NET development browser or IIS Express to allow access to the web application from your test device. Such access is blocked by default.

An easier, alternate approach is to use a proxy, which simply redirects traffic on an external port to the internal server. This is the approach (Again, who is “we”?) often use. The proxy we use is available for download from https://github.com/jocull/SharpProxy Again, no footnotes.

Android wrapper

Here is the code for the Android wrapper that hosts the web applica-tion inside a native Android application.

package com.syncfusion.contoso;

import android.app.Activity;import android.os.Bundle;import android.util.Log;import android.view.KeyEvent;import android.view.View;import android.webkit.WebView;import android.webkit.WebViewClient;

public class ContosoActivity extends Activity { WebView mWebView; private class ContosoWebViewClient extends WebViewClient { @Override public boolean shouldOverrideUrlLoading(WebView view, String url) { view.loadUrl(url); return true; } } /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); mWebView = (WebView) this.findViewById(R.id.webview); // Disable scrollbars mWebView.setVerticalScrollBarEnabled(false); mWebView.setHorizontalScrollBarEnabled(false);

// Scrollbar Overlay Content mWebView.setScrollBarStyle(View.SCROLLBARS_INSIDE_OVERLAY); mWebView.getSettings().setJavaScriptEnabled(true); mWebView.getSettings().setAppCacheEnabled(false); mWebView.loadUrl(“http://your-web-link”); mWebView.setWebViewClient(new ContosoWebViewClient() ); } @Override public boolean onKeyDown(int keyCode, KeyEvent event) { if ((keyCode == KeyEvent.KEYCODE_BACK) && mWebView.canGoBack()) { mWebView.goBack(); return true; } return super.onKeyDown(keyCode, event); }}

The code is quite simple to follow.

1. WebView is the Android equivalent of the WebBrowser control. It is a wrapper around the default WebKit-based Android browser.

2. We obtain access to an instance of the Android WebView control (defined in an XML layout file and instantiated by the Android run-time at execution).

3. We enable the use of JavaScript on this WebView instance since JavaScript is disabled by default with the WebView control.

4. We then make a few adjustments to the display of the scrollbar–basically turning it off to mimic the look and feel of a native applica-tion.

5. We then load the actual web application using a call to the loadUrl API on the WebView instance. your-web-link should be changed to point to your web application.

6. The last section of the code handles the invocation of the hardware back button and causes the embedded WebView to navigate to the previous page.

As you can see, this code is not tied to the web application in any direct manner and will not change substantially from application to application. You will only need to add additional code when you require access to specific hardware functionality on the device. We do not delve deeper into this topic here but if you are interested in investigating this further, please look up information on the addJa-vascriptInterface (footnote!) method of the WebView.

For simplicity, we have described the Android wrapper only. Simi-lar wrappers and extension mechanisms exist for all major mobile platforms.

Contents Page 8

Figure 4. Contact Us page displayed on Android 4.0 Emulatorinside a native application shell

Conclusion

Hybrid applications are worth looking into for

any line-of-business mobile application. They

are not suited for scenarios that require exten-

sive access to native hardware (such as games)

but will work well in most other scenarios. Any

solution implemented with a web backend is

also more likely to be future-proof.

The HTML standard has evolved slowly over

the years and is unlikely to dramatically change

as proprietary solutions tend to do. It offers a

stable base on which applications can be built

with the certainty that they will continue to

work for the foreseeable future. Mobile plat-

form vendors are putting an extraordinary

amount of effort into the implementation of

HTML 5 and related standards, which will serve

to make web applications more powerful and

able to accomplish a substantial subset of what

is possible with native applications.

You can leverage your existing .NET web-devel-

opment skills and produce powerful products

that work on a broad cross-section of devices.

At Syncfusion, we are excited by the immense

potential offered by hybrid applications.

View online on InfoQ.

About the author

Daniel Jebaraj -Vice President of SyncfusionTwitter : @danjebarajLinkedIn : http://www.linkedin.com/pub/daniel-jebaraj/12/342/233

As vice-president, Daniel Jebaraj leads Syncfusion’s product development. Daniel oversees overall product devel-opment and plans for specific releases. By actively engaging with customers, Daniel ensures that each new product improves based on customer feedback. Previously, as vice-president of development, Daniel focused on driving product development at Syncfusion. Before joining Syncfusion in 2001, Daniel managed development teams at Rogue Wave Software. Daniel holds a Master’s degree in industrial engineering from Clemson University.

i http://bit.ly/uIkqKR - Gartner Reveals Top Predictions for IT Organizations and Users for 2012 and Beyond.ii Ignore ASP.NET MVC at Your Own Peril: Lessons Learned from the Trenches available from http://www.syncfusion.com/downloads/resources/whitepaper/aspnet-mvc.iii For further details, please refer to http://www.codefromjames.com/wordpress/?p=97.iv http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object, java.lang.String).

Contents Page 9

We’re here at QCon New York 2013, and I’m sitting here with the creator of the Event-Mobi platform and app. So, who are you?

I’m Bijan Vaez. I’m the CTO of EventMobi and what we do is develop a platform that allows events like QCon to be able to build their own apps, HTML 5 apps, and distribute them to their attendees in a matter of minutes. We have an API that you can push all of your conference data to, and our system will generate offline-capable cross-platform HTML 5 apps that (let) you have full control over all the customizability and look and feel and all that sort of stuff.

EventMobi is essentially a web service and that creates resources that you can load on into the browser, an app so to speak. Is that right?

Exactly. We do essentially data management for conferences and turn all that data interactive through mobile apps and there are dif-ferent features that we offer events.

How customizable is that? Can I put in my own CSS or is that mostly specified by you or created by you?

So the HTML structure we have to maintain, mainly because it’s mobile web and gets kind of finicky keeping cross-platform compat-ibility, but we do have clients who do a full CSS reskin and they can really customize everything. We allow some sort of customizability through our backend so people who aren’t so techie, the graphic de-sign team, can come in, upload their icons, change color schemes, edit their branding, all that sort of stuff. So it’s fairly customizable. We’re working on making it more and more and more customizable so it’s really a self-service platform they can do everything with.

I can vouch for the quality of the app be-cause everyone here has been using it and it works. Its HTML 5, it works offline. It’s amazing. It shouldn’t work, but it does. So why did you go with HTML 5 and not a prop-er mobile solution, proper C or Java, like every upstanding developer?

I’d still say this is just as proper as any of the others. I think for us it came out of necessity in the beginning and mainly because we actu-ally started doing native apps in 2009, and we were trying to prove the business model. And being the engineers we were, we quickly realized that this gets really tedious and boring, doing similar type apps over and over again for different clients. You’re essentially copy/pasting a certain base framework of code you have and then custom-izing for a client. We thought we could auto-generate this. And to do this we’re like, okay, the web is the easiest way to manage this. So let’s move towards mobile web, build it out, and then once we prove it then we’ll come back to native. And then that’s been four years and we’ve never had to look at native yet mainly because of the way HTML 5 progressed. Itgave us the flexibility to add offline features, things that would have forced us to go native but we can now do an HTML 5. And it works fairly well and browser support is great, and we can keep innovating in this space.

And so you couldn’t have created, auto-created, these same apps. As you say, you create these HTML apps from data. Couldn’t you have also created these things, one for iOS, one for Windows Phone and so on? Is that an approach that wouldn’t have worked? Would it have been too tedious?

It would have been far too tedious mainly because when we started, Android still wasn’t around. The tooling around these develop-ers’ ecosystems in the iOS, XCode packages and that sort of thing, wasn’t really there for us to be able to automate it really nicely and then we’d require expertise in a variety of different frameworks and languages. And with two engineers, you’re kind of limited in what you can do. But, yeah, it is certainly possible, but even at some stage with native apps, you can’t automate everything.

And even the standard stuff that we take for granted on the web becomes much more difficult on the native side. Theways you do your testing and integration test, functional test, load test become much more simpler on the web whereas they’re much more difficult on native in trying to automate all of that. So for us, it enables us to move quite a bit faster, iterate on our product multiple factors faster than it would be on native, and we require less personnel to do so, so we can optimize on working on the stuff that we enjoy working on rather than tooling to just get stuff working.

Werner: And of course, it’s much easier to deploy the app because there’s no app stores you have to go through for all the madness of pushing things and signing things and stuff like that.

BijanVaezonHTML5Interview with Bijan Vaez by Werner Schuster | Jul 06, 2013

Contents Page 10

So there are tools now that do the auto-certificate kind of generation and all that sort of stuff and it becomes a pain to work with, and you need a lot of admin work around it to manage this whole process. You need people kind of overlooking it. Oh, and then, hey, Apple is going to change their certificate a little bit and everything breaks and you kind of have to go through it. And then it’s taking away from what you actually need to focus on, which is the product. That’s why we like the web and we can focus on the product and what really matters and kind of leave all the extra stuff behind. And as long as we can keep innovating in that space, I think the web makes sense. I’m not saying nobody should do iOS and that sort of thing. I think there are prob-ably use cases where native action makes more sense. But for our use case and for what our customers want, the web is a much better platform to be on.

Werner:ThereareserviceslikePhoneGapBuildwhichwoulddomostofthejob,Iguess.Yougiveitsomecodeanditspitsoutthebinariesfordifferentplatforms.

Yes, that now would make life quite simple, and we are starting to look at PhoneGap Build for some of our premium clients maybe that do that marketing kind of push to have a native app, and maybe we could eventually provide it for them. For the time being though, it’s not something that we’ve been pursuing. But, yeah, PhoneGap has really changed the landscape in kind of what you can do.

Obviously, HTML 5 has progressed far enough to do everything you need to do right now. I can attest that this thing works offline so you can kill your Wi-Fi and the data is still there. What feature in iOS or An-droid would get you to write either a native app or customize some PhoneGap code?

In terms of the type of application that we work on, we’re not doing gaming where we require low-level access and crazy hardware ac-celeration, that sort of thing. So for our UI, we can actually optimize it quite nicely to work and perform comparatively to native products. Sometimes you might just have to limit what our designers are going to come up with and then kind of manage it within that expectation.

But I think the main thing that is still kind of outstanding in HTML 5 is getting closer links to device APIs which I understand is difficult from the vendor side because they are adding so many different features - but things like push notifications I think would be huge, expanding on the idea of an installed web app. And I think Mozilla has kind of been working on some of that but expanding that idea and making it more robust and seeing what you can do when somebody actually installs it or adds it to their home screen. Opening up other functionalities to them and giving them some more device access I think would be huge.

But yeah, on the other hand, performance is also I think the main

thing that’s missing, getting that low-level access. But if you’re going to go on web, you’re probably not going to be working with crazy graphic stuff anyways. Well, I mean now there’s some really cool We-bGL stuff that’s coming out so maybe I’m speaking too soon. Forus, we have camera access now which is great. We have GPS on iPhone to get accelerometers through HTML 5. So with all these, most of the features that you need are there. I’m really hoping actually NFC gets exposed through the web as well and that would really open up some interesting things.

Since you mentioned NFC, what would that be like? –Would there be an event that an NFC tag has been detected or something?

Well, the way I would imagine it is there would be JavaScript APIs that have event handlers that you would listen to, and if you swipe something it will call that event handler and then you can just start parsing NFC, similar to QR codes, figure out what action it’s trying to do, and take that action on that person’s phone. All this stuff that we deal with - QR codes and everybody hating it but everybody still wanting to use it - I think all that will go away as soon as you have NFC proliferated not only through native apps but through the web as well. And I think what makes QR codes really powerful that everybody uses now is just that simple redirect and that’s the main functionality of QR codes. But if you can’t do that through NFC, then it’s going to be a little bit of a -I mean, there are obviously a million other uses for it, but I think that would be a really, really great use.

Do you see NFC taking off at some point? Apple has been reticent to adopt it for vari-ous reasons. Do you think they have a good reason? Are there barriers to entry with NFC?

I’m really surprised actually. I thought with the iPhone 5 release, they would have released it. I’m still hopeful that with the next iPhone they’re going to release it. I don’t see any barriers. –Anytime Apple releases a feature or kind of a small product, they need that ecosys-tem around it to make it useful. Whereas on Android, it’s all feature-packed. Everything is in there and then they’re waiting for developers to build on top. Apple wants to introduce everyone to that feature with very specific use cases and say, “This is why you need to start us-ing it now and it’s available and here’s what you can do with it.”

So I think they’re still waiting to get that ecosystem built out, and I think their main use is payments. And once they get payments kind of running and they have a nice system that they can work with, then for them they’re going to come out and be like, “We revolutionized the world. Now you can pay with everything and everything has a wallet and all that sort of stuff.” My guess, anyways. But I honestly think NFC could take off. Now most of the mobile devices have it, between Blackberry and newer Androids and that sort of thing. And it’s not a new concept and although we’ve been hearing it in the context of

Contents Page 11

mobile phones, NFC or RFID has been around for 20+ years in vari-ous different methodologies and people have implemented all sorts of different technology and different tools. And I’m actually surprised it has taken this long to catch up with consumer electronics.

Well, I guess a p worldwide standardized use case would be key for that and that doesn’t seem to exist. It’s also a problem that ven-dors or point-of-salespeople may need to install something, some hardware or some-thing that might be a big issue. Is that right or is it easier than I think?

So the NFC stickers are data, essentially, that you want to transfer in volume, and cost less than a penny per. They’re like thirds or fifths of a penny now. The last time I looked four or five years ago and it was already that cost. I’m sure it’s even cheaper now. The readers themselves can get pricier here, but now that we’re seeing them again in volume being incorporated within phones and I think that’s where a lot of new POS systems are going. They’re saying, “Hey, you guys already have these devices. You have an iPad and you have all these devices. They have all these capabilities. Why don’t you just use these instead of going and buying a $2000 POS device? Just use your iPad which has all these capabilities.” Or use this Android tablet that has an NFC in it and it has NFC reader and you can just tap stuff. So I think everything is pretty much there.

So it just needs to gather momentum or...?

Yeah, yeah. I mean pushing stuff consumer side is always difficult. There are so many different challenges. But I honestly think it will - in the next two to three years I wouldn’t be surprised if there’s a major push towards NFC. And I mean we’re already seeing it. The credit cards you use now all have that tap thing and everybody is using it. It makes life so much easier. You get something, tap it, and it just prints your receipt and all right, you’re off.

Werner:Right.Istillusecashso...

Okay.

Werner:Thatworkseverywhere.

That’s true. It does unless the exchange rate doesn’t really help.

So coming back to HTML 5, we talked about something that would be nice to have. Any-thing else? What about concurrency? Are web workers enough for you?

San Francisco

TamingMobile

QCon São PauloAUG 29 - 30, 2013

QCon ShanghaiNOV 1-3, 2013

QCon San FranciscoNOV 11 - 15, 2013

QCon Shenzhen9-11 JANUARY, 2014

QCon London3-7 MARCH, 2014

QCon Beijing17-19 APRIL, 2014

for more info go to

qconferences.com

@

Contents Page 12

So is AppCache fixable with an AppCache 2.0 or do you think a different approach is needed?

I think it’s fixable. I think everything is kind of progressive enhance-ment. I think people know where it needs to go and enough people have used it that there are a lot of people thinking about how it should be made better. I don’t think there’s any need to completely scrap it and go with a different way. I think it’s simple enough that traditional kind of web developers can use it right away. I mean, tra-ditionally, we think of these complex web applications but even if you think about standard static websites just using an AppCache, they don’t have to make roundtrips to the server because these people probably are not into high-performance websites and that sort of thing. They’re just getting their static site up and running. If every-body uses these caches very simply, we’re saving a lot of network bandwidth overall - just of stuff that doesn’t need to be sent around. So I think it’s a great spec that allows people to get up and running really quickly, but it definitely needs some improvement.

Things like telling AppCache to update cer-tain resources and things like that I suppose?

So being very granular and saying, “This one I know is out of date. So I want you to just make the single HTTP request for this one file.” I think one of the other things that could be really helpful is managing when -- being able to restart essentially a cache manifest. So right now if you have any errors midway between when the manifest is trying to cache everything it will just stop and the cache goes stale and you can’t really use it. You’re going to have to tell your users to go and clear their cache, restart the page and then restart the process all over again and that just makes no sense. You should be able to pro-grammatically see, oh, there’s a 404, take some action or remove it from the cache, restart it, whatever you need. And especially because for us one of the biggest difficulties we found is, because we’re deal-ing with 3G networks and poor Wi-Fi networks as well, there’s a high probability that the packets are going to drop, that that initial request isn’t going to make it to the server and the cache goes stale all the time and that becomes a really big problem.

Another issue that I might see is quotas, so maximum size of data that you have. Do you run into that with EventMobi or is your data compact enough? What do you think?

Yeah. So I think web workers is a great step towards where we need to be in terms of creating much more complex HTML applications. I think in terms of WebSockets as well. I can’t wait until that becomes a little bit more prevalent in terms of usage. For us specifically, it creates kind of barriers using WebSockets in the conference set-ting where very specific network infrastructure blocks out certain protocols of communication that it doesn’t know and all that sort of thing. So we’re waiting for the network infrastructure to upgrade so we can just use WebSockets. And I think once that happens, it will be amazing with not having to worry about HTTP overhead and sending cookies you’re not supposed to and all that sort of stuff.

I think that would be really cool. I think in terms of the other kind of things that come from HTML 5, I’m not sure what. yeah, this is my spotlight to ask, but I’m not really sure what I would specifically ask for.

Werner: Your app stores all the data locally and there’s a huge list of local storage options. That’s the simplest one, localStorage, basically the key/value thing. Well, then there’s Web SQL and this and that and the other. So what do you currently use or what would you like to see?

Right. Yeah, I completely skipped over this stuff that we deal with day to day because I’m dealing with it day to day. So I guess the first thing is the AppCache is a great kind of first start towards client-side persistent -- essentially it has some edge, but getting granular control over that, I think, would be huge, and actually being able to program-matically manage it rather than it’s an all-or-nothing kind of cache. And it’s a pain to deal with, I kind of mentioned in my talk as well. But it’s really powerful and I think if browsers kind of expanded on that spec and start implementing better control over it, that would open up a lot of doors.

I think on the localStorage and WebSQL side of things, I really hope a spec can be reached between the vendors fairly soon. I think really one of the detracting factors about people not moving towards of-fline HTML 5 yet is because it just seems like it’s completely in disar-ray and vendors are kind of fighting over which spec it should be. And we know WebSQL is now deprecated but then what’s the alterna-tive? Safari has no plans of implementing IndexedDB as far as I know. So we need some sort of coordination there between the vendors to get this sort of spec up and running so it can give confidence to the community that, hey, it’s set, you can use HTML 5 offline and here is all the data you need and that sort of thing.

But, yeah, I mean I think it’s a great start. There’s a ton more that we can do. We deal with a lot of issues with the AppCache and a lot of nuances here and there. But, yeah, I mean you can get up and running but when it starts getting really complicated it becomes really dif-ficult to deal with and I would love to see that kind of made easier.

Contents Page 13

We do run into that. Right now we’re actually still using just localStor-age and obviously that’s very limited in size and we are running into that. I’m glad to see now that the IndexedDB shim and polyfill are kind of matured to a point where a lot of people are using it. Well, the shim has kind of Facebook support as well and they’ve been using it in production. So it’s a great way to start making use of Web SQL and IndexedDB to get a lot more space to play with. With those technologies,I hope that stays the same where there’s no specific set limit, but you can always ping the user and ask for more informa-tion. And I think that that’s a really good way to approach this. Every website is going to be different, but some websites are just very data-heavy apps and they require to allow people to store that but ask the user kind of how they like to proceed. Yeah, I think now we’re kind of slowly transitioning that way as well. We see that we have the capability to kind of play with both and have it work fine across those.

Werner:SoIguessthat’soneofthebigadvantagesofnativeappsbecausetheydon’thavetoasktheuserformorememory.

Yeah, yeah, exactly. Although even with native apps you run into a problem if you are updating, if you are keeping kind of a dynamic app and you’re updating stuff over the wire and you have to update this and that sort of thing, it’s still very heavy process. Most apps that I see have to block the user flow, update what they need. I mean, it doesn’t have to be this way, but most of them are. Whereas with web, we’ve already dealt with all those issues and keep the user experi-ence much nicer.

So to wrap this up, are there any particular platforms that you’re looking at like Firefox OS or Tizen? Are you looking forward to them or are they going to introduce prob-lems?

I wouldn’t say that there are specific platforms that I’m looking at because mainly as much as we’d like to be super forward-thinking, we have most of our users are still very legacy using -- I mean, we look at our analytics and we get sad every time we see IE 5.5 still pop up. Not that many, but it’s --

Werner:Youpoorman...

Hey and our apps still support it. So I look forward to what the future brings, and I can see where the vendors are going. They have been very good at listening to the application developers like us and kind of what we face. I think one of the biggest issues on mobile is still the login and authentication through mobile and the mistakes people make, the lack of attention span they have to deal with authentica-tion systems and that sort of thing.

So I’m really looking forward to Mozilla’s Persona project and seeing how that picks up. For us, we’ve been tweaking our user experience on our login page and many people as soon as they get to a login page, they just drop the app. They don’t want to do data entry on a phone, and I think that sort of thing would be really helpful. But in terms of

what’s coming out, I think there have been so many advancements in terms of the platforms and how Chrome and now Safari have sped up JavaScript on mobile because there really is orders of magnitude difference in performance on mobile browsers in JavaScript and desktop. So that’s slowly being shrunk down and that’s really promis-ing to see. We’re just excited that that’s continually happening that innovation is going.

View online on InfoQ.

Bio: Bijan ( @bijanv ) is the CTO and co-founder at EventMobi, the largest app-build-ing platform for events and conferences, where he bridges the gap between mobile-web and native platforms and has spent four years deploying large-scale cross-platform mobile-web apps. Before EventMobi, He built an award-winning iOS app, was part of the AMD discrete graphics, and founded a real-time-RFID-tracking consultancy.

San FranciscoNOV 11 - 15, 2013

SAVE $100 WHEN YOU REGISTERWITH PROMO CODE “MOBILE”

Over 100 speakers|15 concurrent tracksKey Topics: Mobile, Agile, Cloud. HTML5, JVM, Big Data, Web

2013

Contents Page 14

As part of the new community-driven re-search initiative, InfoQ is (?) examining the importance and adoption level of a range of cross-platform mobile tools that aim to help developers deliver applications on a variety of mobile platforms. The tools we’re going to examine are:

• PhoneGap (Apache Cordova), an HTML 5 app platform that allows you to author na-tive applications with web technologies and get access to APIs and app stores. http://phonegap.com

• Sencha Touch, a high-performance HTML 5 mobile-application framework for iPhone, Android, and BlackBerry. http://www.sen-cha.com/products/touch/

• Mono iOS/Android, a framework for creat-ing iOS and Android apps using (?) C# and .NET. http://xamarin.com/

• Appcelerator, an SDK for developing na-tive, hybrid, and mobile web applications from a single codebase. http://www.appcel-erator.com/

• Adobe AIR, a framework to build applica-tions that run on Apple iOS, Google Android, and BlackBerry Tablet OS platforms.http://www.adobe.com/devnet/devices.html

• Qt , you can use Qt to create apps for Symbian, N9, desktop OSs and for the future

Future? It’s out now, no? BlackBerry 10.http://www.qt-project.org/

• RhoMobile, a framework for building native apps for iPhone, Android, Windows Mobile, and Windows Phone 7. http://rho-mobile.com

• Marmelade, which supports two develop-ment approaches: HTML 5 apps that are fully compatible with the PhoneGap API and fully-native C++ apps for the best possible performance.http://madewithmarmalade.com

• Corona, an SDK that aims to deliver write-once-and-build to iOS, Android, Kindle Fire and NOOK, using Lua on top of C++/OpenGL. http://www.coronalabs.com

• MoSync, an SDK for building apps in C/C++ or HTML 5, and currently supports An-droid, iOS, Windows Mobile, Symbian S60 and Java ME. http://www.mosync.com

• jQuery Mobile, a unified, HTML 5-based user-interface system for mobile-device platforms, built on the jQuery and jQuery UI foundation. http://jquerymobile.com/

• jQTouch, a Zepto/jQuery plugin for mobile-web development on the iPhone, Android and other devices. http://www.jqtouch.com/

View online on InfoQ.

WhataretheMostImportantandMatureCross-PlatformMobileTools?By Dio-Synodinos | August 21st, 2012

HerearetheresultsoftheInfoQMobileDevelopmentResearchQuestion

San FranciscoTAMING MOBILE

NOVEMBER 11 – 15, 2013

Taming Mobile @QCon San FranciscoDeveloping software for mobile platforms is as essential as it is hairy: a fragmented marketplace and platforms, new user interaction models, unreliable and laggy network connections, performance constraints and many more problems can take the shine off even the fanciest gadget. This track explains the problems with mobile development and shows some ways to tackle them.

SAVE $100 WHEN YOU REGISTER WITH PROMO CODE “MOBILE”

Attendees can expect to see talks like:

• Mobile-friendly server interfaces• Multiplatform, promises and mobile HTML5• Design Patterns for Mobile Apps• The Mobile Web Developer's Tool Belt• Gamifying Enterprise Mobile Applications: Do we have a winner?• Developing, Building, and Debugging Cross-Platform Mobile Apps with HTML and PhoneGap• Hyper Focused to a Fault• The Mobile Web Developer's Tool Belt• Designing for Engagement

@

Contents Page 17

Mobile, HTML5 and the Cross-Platform Promise—a summary by Abel Avram

During a QCon London 2012 session entitled Mobile, HTML5 and the Cross-platform Promise, Maximiliano Firtman discussed using HTML5 to tackle the challenges met when creating applications for multiple mobile platforms. He explained how HTML5 can help, and provided advice for creating cross-platform applications with it.

Firtman started by mentioning some of the challenges developers face when making their first attempt to create applications for mo-bile devices: learning new programming languages or new libraries for already known languages; testing on myriad devices; dealing with much smaller screen sizes and less processing power than the desk-top; slower networks and higher latency; using touch; and a variety of browsers, some known - Safari, Opera, Firefox, Chrome, IE - others not so known - Phantom, NetFront, BlackBerry, Bada.

Besides all that, there is another important issue to consider: na-tive vs. web development, creating one application for each mobile platform vs. one application for all of them. HTML5 is one of the candidate technologies that could be used to write once and run everywhere, the author explaining what HTML5 is, what it can do and cannot do.

According to Firtman, HTML5 is not “HTML 5” - the next version of HTML -, but a collection of older and newer web standards such as geolocation, SVG, database, JavaScript, CSS, storage, offline, audio/video, etc., actually having little to do with HTML tagging or semantics. These standards are currently in the works, but browser manufacturers have already started implementing some of them without coordination, resulting in partially inconsistent implementa-tion across browsers. Some standards have been implemented by all browsers, but others are not supported by all. For an updated list of HTML5 features and their implementation status across browsers, the author suggests consulting http://mobilehtml5.org/.

Firtman continued with advice on creating mobile applications, em-phasizing that mobile development does not mean taking a desktop application and shrinking it to fit on a smaller screen. Mobile develop-ment requires a different approach, new skills and tools:

• The application needs to support offline access, which involves data synchronization.

• Pixels are not pixels anymore. The browsers do extensive work to rearrange the content on devices with different screen sizes.

• Web frameworks for desktop development should be avoided for reasons of performance and memory consumption.

• One should use web frameworks specially designed for mobile.

• Developers need to be aware of power consumption because the battery can be easily drained.

• The application won’t look exactly the same on all devices.

• One should not attempt to emulate the native interface exactly, because changes to it make it hard to keep up.

• The developer needs to learn how to detect devices on the server side: their type; their HTML5 level of support; their screen size; etc. Recommended detection libraries: WURFL and DeviceAtlas.

• It is recommended to apply Responsive Design to create layouts ap-propriate for the screen sizes the application runs on.

• The user should not have to load the browser and type a URL but rather should be provided with a shortcut to the app or a native wrapper.

Firtman mentioned other issues with mobile development such as debugging, profiling and testing. He suggested using simulators or emulators, providing a useful online resource on one of his websites: Mobile Emulators & Simulators: The Ultimate Guide. Another option is to use real devices to be used remotely from services such as Per-fecto Mobile and Device Anywhere, the latter acquired by Keynote. Other options recommended are free testing services provided by Nokia and Samsung to test the application on their respective devices.

Firtman said that it is difficult to perform JavaScript debugging on a small mobile device. An option is to perform remote debugging from a desktop over the network. BlackBerry, Google Chrome and Opera Mobile support this operation at the time of the presentation. For iOS and PhoneGap/iOS debugging, he suggested his own tool, iWe-bInspector. Adobe Edge Inspect (formerly Adobe Edge) can be used to debug HTML, CSS and JavaScript.

One of the main problems of HTML5 applications is speed, accord-ing to Firtman, requiring Web Performance Optimization (WPO). He mentioned briefly several WPO techniques useful to speed up mobile web applications:

• Drastically reduce the number of HTTP requests due to latency reasons.

• Reduce the size of images.

• Use CSS to replace images where possible.

Mobile,HTML5andtheCross-PlatformPromiseBy Maximiliano Firtman | May 31, 201

Contents Page 18

• Defer loading content until needed.

• Include JavaScript and CSS with HTML5 instead of using external files.

• Use touch events rather than click ones because the latter intro-duce a 300-500ms delay.

Firtman only touched on these techniques, recommending Steve Souders’s books and website for in-depth coverage of most mobile web performance issues and solutions.

During the second half of the session, Firtman discussed building hybrid or native web mobile applications with HTML5.

He suggested using Adobe PhoneGap or its open-source variant, Cordova, to write a unique codebase that runs on all major mobile platforms. There are some exceptions though, especially related to UI differences and discrepancies in HTML5 implementations, forc-ing developers to write some specific code for each platform, but normally such code does not exceed 10% of the overall codebase. The advantage of using PhoneGap is that it provides a consolidated platform that runs on the majority of mobile operating systems and offers access to native sensors and capabilities, such as accelerom-eter, camera, accessing contacts, etc. Even more, the application can be packaged into a native wrapper deployed to the application store and distributed like any native application.

When building the application UI, instead of using raw HTML and JavaScript, Firtman advises developers to use a UI framework such as Sencha Touch or jQuery Mobile to take care of cross-platform discrepancies, making the task of writing a common UI across differ-ent devices much easier. When JavaScript coding is desired, Firtman suggested employing a framework like jQuery.

One problem with creating applications for multiple platforms is that each app store requires the code and resources to be packaged in a specific format. Although there are some attempts to develop a com-mon standard for packaging applications, each store currently uses its own format and there is no way around it. One helpful solution Firtman mentioned is Adobe PhoneGap Build, a service that auto-matically compiles and packages for all major platforms.

After showing how several HTML5 features work on various devices, Firtman concluded his session with some advice:

• Native code is not bad; actually it is a must for some type of applica-tions.

• Attempt to be better than average because average does not work on mobile devices.

• Performance is paramount.

• Build based on good practices.

• Develop for other platforms, not just the one you might prefer.

• Be future-friendly, considering what might happen in the near or medium-term future.

View online on InfoQ.

About the speaker

Maximiliano Firtman is a mobile and web developer with more than 10 years in the mobile field. He is a Nokia Developer Champion and Adobe Community Professional with experience in native mobile development (iOS, Android, BlackBerry, Nokia) and in mobile web technologies and HTML5. He is the author or “Programming the Mobile Web” and “jQuery Mobile: Up and Running”.

Firtman has created mobilehtml5.org, a website that keeps track of latest HTML5 APIs and their compatibility with every major mobile browser and platform. He has also created iWebInspector.com, a free online tool for debugging web and hybrid applications for iOS.

San FranciscoNOV 11 - 15, 2013

SAVE $100 WHEN YOU REGISTERWITH PROMO CODE “MOBILE”

Over 100 speakers|15 concurrent tracksKey Topics: Mobile, Agile, Cloud. HTML5, JVM, Big Data, Web

2013