Mobile development-e mag-version3

THE BEST
OF MOBILE
• Hybrid Mobile Apps with ASP.NET MVC
• Bijan Vaez on HTML5
• What are the Most Important and Mature Cross-Platform Mobile Tools?
• Mobile, HTML5 and the Cross-Platform Promise
Mobile
Development
eMag
August 2013
By

Contents Page 2
P. 3–8
P. 9–13
P. 14
P. 16-17
Hybrid Mobile Apps
with ASP.NET MVC
Bijan Vaez on HTML5
What are the Most Important and
Mature Cross-Platform Mobile Tools?
Mobile, HTML5 and
the Cross-Platform Promise
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:
Platform
Primary development
platform
Primary development
language
Primary IDE Development platforms
Android Java based Java Eclipse
Windows, 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.”
Hybrid Mobile Apps with ASP.NET MVC
By 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>
SanFrancisco
NOV11-15,2013
SAVE$100WHENYOUREGISTER
WITHPROMOCODE“MOBILE”
Over100speakers|15concurrenttracks
KeyTopics:Mobile,Agile,Cloud.HTML5,JVM,BigData,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 Emulator
inside 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 Syncfusion
Twitter : @danjebaraj
LinkedIn : 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#ad
dJavascriptInterface(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.
Bijan Vaez on HTML5
Interview 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: There are services like PhoneGap Build which would do
most of the job, I guess. You give it some code and it spits out the
binaries for different platforms.
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. I still use cash so...
Okay.
Werner: That works everywhere.
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
Taming
Mobile
QConSãoPaulo
AUG29-30,2013
QConShanghai
NOV1-3,2013
QConSanFrancisco
NOV11-15,2013
QConShenzhen
9-11JANUARY,2014
QConLondon
3-7MARCH,2014
QConBeijing
17-19APRIL,2014
formoreinfogoto
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: So I guess that’s one of the big advantages of native apps
because they don’t have to ask the user for more memory.
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: You poor man...
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.
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.
SanFrancisco
NOV11-15,2013
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/
What are the Most Important and Mature
Cross-Platform Mobile Tools?
By Dio-Synodinos | August 21st, 2012

Here are the results of the InfoQ Mobile
Development Research Question

San Francisco
TAMING MOBILE
NOVEMBER11–15,2013
TamingMobile@QConSanFrancisco
Developingsoftwareformobileplatformsisasessentialasitishairy:afragmented
marketplaceandplatforms,newuserinteractionmodels,unreliableandlaggy
networkconnections,performanceconstraintsandmanymoreproblemscantake
theshineoffeventhefanciestgadget.Thistrackexplainstheproblemswithmobile
developmentandshowssomewaystotacklethem.
SAVE$100WHENYOUREGISTERWITHPROMOCODE“MOBILE”
Attendeescanexpecttoseetalkslike:
•Mobile-friendlyserverinterfaces
•Multiplatform,promisesandmobileHTML5
•DesignPatternsforMobileApps
•TheMobileWebDeveloper'sToolBelt
•GamifyingEnterpriseMobileApplications:Dowehaveawinner?
•Developing,Building,andDebuggingCross-PlatformMobileAppswithHTML
andPhoneGap
•HyperFocusedtoaFault
•TheMobileWebDeveloper'sToolBelt
•DesigningforEngagement
@

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, HTML5 and the Cross-Platform Promise
By 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.
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.
SanFrancisco
NOV11-15,2013
2013

Mobile development-e mag-version3

Mobile development-e mag-version3

More Related Content

What's hot

Viewers also liked

Similar to Mobile development-e mag-version3

More from nesrine attia

Recently uploaded

Mobile development-e mag-version3