BT

Virtual Panel: The State of the Art in Mobile Web Application Development

Posted by Dio Synodinos on Aug 26, 2010 |

To assess the state of the art in mobile web application development, InfoQ has conducted a virtual panel with the creators of some of the most popular libraries, toolkits and frameworks that target this field.

The participants and the frameworks were:

InfoQ: Can you describe the development process for someone using your project? How is a web application developed and tested?

Michael (Sencha Touch): We're a javascript framework for touch-based mobile web apps, so developers using Sencha Touch can continue using their favorite IDE and their server-side of choice. It's not any different than any other web application development, although mobile devices definitely introduce challenges on the testing side, since mobile web browsers don't have the plugin capabilities that allow desktop browsers to provide very rich debugging capabilities.

Brian (PhoneGap): The first thing a developer needs to do when developing a PhoneGap application is decide which platforms their audience requires. PhoneGap supports Apple iPhone, Google Android, RIM Blackberry, Palm webOS, Symbian, Meego and Windows Phone 7. Once the audience and platform(s) are determined, the developer should take some time and understand the input methods and screen device dimensions. For example, an iPad UI won't (yet?) work on a Blackberry. Palm devices have wonderful gestural support whereas Androids have physical buttons for main interactions whereas iPhones use virtual buttons for everything short of power and volume. One UX approach simply does not work for all these platforms.

PhoneGap projects have a single WWW folder in which the developer will put their HTML, CSS and JavaScript. The only condition PhoneGap has is that the WWW folder must contain a single index.html file. Symbian and webOS require that apps be single page and we think its a good paradigm too. (Note, you are not restricted by any other PhoneGap platforms so if you are not supporting Symbian or webOS then you

*could* do a multi-page app ...but your transitions will look bad.)

We leave it to developers to figure out their build for each individual platform mainly because we cannot redistribute the various mobile SDKs. Also, keep in mind certain platforms require certain operating systems (Apple for iOS and Windows for Windows Mobile/Phone 7). Typically, at Nitobi, we like to use one of three techniques depending which platforms are being supported.

- symlink a single WWW folder into each platform specific PhoneGap codebase

- as above but with git submodule or svn externals

- a build script that manually copies WWW into each project

Any of these techniques work very well with small teams on a single platform or large teams distributed globally targeting all the platforms. From here its just regular web development. Many PhoneGap

developers save themselves the build step as much as possible and do most of their work within Chrome or Safari. Sometimes Firefox.

Christopher (iWebKit): The development process is extremely simple for the end user. The user guide provides him with all the useable elements that are pre styled to look like the iOS interface. So all he has to do is copy a block of code over into an HTML file, change the contents of it and he is good to go! To test it he can simply use any webkit browser like chrome or safari but I recommend using an iPhone or iPod touch of any generation because the CSS file generating the layout is also based on screen size detection.

Chris (WebApp.Net): To use WebApp.Net you only have to download the package and unzip it in your development folder. Then you can check the documentation to start with it. Using WebApp.Net in a static web site is really straightforward but using it in a dynamic environement may require a good understanding of Ajax and basic knowledge of XML. WebApp.Net use XML to allow multipart asynchronous rendering and contnt update. You can for instance create a full layer content or update only text in a specific tag. Script execution from asynchronous response  is also support.

The documentation take time and I'm working on it as much as I can but it is still in work-in-progress state. The best documentation will be in the support forum which has some interesting discussions. The demo source code will help too has it implements some of the interesting features of the framework. The forum has a section dedicated to web application annoucement. The disection of those web applications is also a good start to understand the framework.

The developer can easily test his web application in a desktop browser using the WebKit engine. Firefox is also supported and a specific CSS is provided to adjust vendor specific properties.

Christoph (mootools-mobile): There are lots of different definitions for what a web application is. In my opinion a web application is not just about 'rich interaction' but also about leveraging and transforming user data or device data and about using the information that surrounds a user. I am sure everyone has a different definition and different needs. That is why I try to make everything I publish as modular as possible. The projects I release on GitHub are all standalone and only require certain MooTools Core components. MooTools, as a modular library itself, is ideal for web application development because you can customize it and build your own version.

mootools-mobile is aimed to provide low level functionality like custom swipe and pinch events. It is not meant to be a full mobile web app framework but it can serve as a base for one. The key is modularity, just build something on top of it. Modularity implies abstractions. Such a development process is much more scalable because other developers have more flexibility in choosing the right – and only the right - tools for a project.

I strongly believe that JavaScript should be separated from all content and styling. My way of development usually is to not rely on any CSS or HTML - most of the time I am also 'just' the JavaScript guy. I don't even get to touch anything else. I focus on modularity - so each browser and platform has its own set of modules. This also makes it easy to disable certain things on legacy browsers or other unsupported mobile devices.

The best way to test mobile applications is to write specs for as much code as possible and to try to minimize the need for manual testing.

 

InfoQ: Many mobile devices have input methods that include touching the screen, in some cases with more than one finger. Are those input methods available in your case? Do you think that they provide any extra value?

Michael (Sencha Touch): Sencha Touch is an app framework for touch devices, so we provide a complete touch manager for developers. We take the basic javascript touch events and abstract them into things that developers want to program against (like doubletap, tap/hold, swipes, pinches, etc.) We think touch interfaces provide the best interaction model on mobile, because they let you strip a lot of UI chrome away. We think touch/gestural interfaces is the interaction model that all mobile platforms will converge on. Having virtual controls allows more space for the content when you don't need the controls, and allows richer interactions that connect better with users expectations. Without gesture support, simple things that you need to do all the time on mobile devices - such as zooming out on content, repositioning, then zooming back in is a complex process. It's one of the reasons that mobile apps didn't really take off until we had gesture support. We think that pressing buttons, using trackballs etc.-- are on their way out on mobile for mobile web apps. Afterall, in desktop web browsers, you don't ever see a browser application doing something special when a user presses the Start Button on Windows.

Brian (PhoneGap): If the device supports touch events then so does the PhoneGap for that device. Touch experiences are definately great and we're only just begining to understand the Interaction Design of gestures. Palm's webOS is most certainly the most advanced platform in this regard and we'd love to bring a lot of this level of gesture support to other platforms.

That said, touch does not always make sense. Virtual keyboards are pretty difficult to touch type and often used keys should probably be accessible without eating the already limited screen real estate. Palm, Blackberry Android are all really well thought out in this regard too. Blackberry users tend to expect the 'Blackberry button' which is something like a context menu. Android folk expect menu, search, back and home buttons. Meeting user expectations is far more important than buzzword compliance. Virtual back buttons on Android are annoying artifacts of over infatuation with touch screens.

Christopher (iWebKit): Since iWebKit reproduced the iOS interface all elements are extremely "touchable". They fit your finger perfectly instead of you having to adapt to the site which is the main reason to use such a framework. Other multi-finger gestures are not implanted by default but can simply be added by any developer by reading apple's online guides. These gestures aren't really necessary in my opinion since the Internet right now is simply a way to distribute media like text, images and video. A simple experience is the best one for the user.

However with the arrival of Chrome OS and html5 I think we'll soon see new kinds of websites that are more "app-like" and a sub category of those will be adapted to touchscreen devices. They will be as good as native apps which is not the case right now althought it is technically possible. The market isn't there yet.

Chris (WebApp.Net): Most of the time, gestures use only one finger at a time like swipe-to-delete, pan up/down... Multi-Touch gestures are commonly use for zooming and roatating features, nothing more. The effect found in the iPad Album application that let you gather many pictures use the same behavior as the pinch gesture (zoom) but without rescaling images.

WebApp.Net currently doesn't feature gestures events but will be in a future version with fully configurable gesture and related event. Gesture are quite useful for the user experience and provide an easy and natural way to deal with the iPhone user interface. They are very effective and provide a far better productivity as long as gestures are well designed.

Christoph (mootools-mobile): While that is true, not many mobile browsers actually support touch events. Currently only mobile Safari and the Android browser support touch events, with the latter not even supporting multitouch (recent models are starting to support them finally). This means mootools-mobile is mostly aimed at these devices until browsers on other devices provide such features. mootools-mobile provides custom events for rich interaction like swipe, pinch and touchhold – with more coming soon! In addition there is an automatic replacement for all click events to overcome the touch delay on iOS. This makes mobile web applications much more responsive - simple but effective!

 

InfoQ: Functional testing on the client side is especially difficult in the case of HTML and JavaScript components, especially when there are more than one target platforms involved. How can developers cope with this problem?

Michael (Sencha Touch): I don't think there is a really good answer here yet. Traditional functional testing isn't enough on mobile: just because something tests correctly doesn't mean its fast enough to use. Simulators are available for all platforms, but again there are limitations. The iOS simulator only works on Mac: the Blackberry Torch simulator only works on Windows. The iOS simulator probably does the best job of duplicating the device experience, but you need to test on each device to make sure that everything you're using has reasonable performance. There are lots of web features on the Blackberry Torch, for example, that look good from a checkbox perspective, but have problems with performance when you try to do anything complex. And Android is occasionally a challenge because there are specific features that the phone OEMs add that can cause problems for your apps - and this is worse for native Android applications vs. Android web apps. Each device has specific quirks that the app developer must test against. There's really no alternative if you want to guarantee a particular user experience.

Brian (PhoneGap): We employ the fantasic qUnit library by John Resig for unit testing our JavaScript as much as possible. It works on all the PhoneGap platforms. Unfortunately, it is not possible to reliably automate testing of guestural interfaces and especially difficult to automate the testing of more subjective experiences like CSS animations/transforms/transitions. Getting a good 'feeling' for an app is important to its success and the best way to test that is to build it to a device and play with it. Luckily, due to the performance characteristics of devices and the available screen real estate, most mobile apps are focused on achieving one simple function well opposed to the monolithic applications we have traditionally seen on the

desktop, so testing in this manual manner is really not that tough or resource intensive.

Christopher (iWebKit): Well not really in the case of iWebKit. It works out of the box with any webkit browser which means: iOS, blackberry os6, google android, basically all major smartphone platforms besides windows mobile. Once css3 and html5 support gets implanted into windows phone 7 (or 8) some adjustments will need to be made to the current frameworks like iWebKit but it will technically work. The only limitation right now is that in iwebkit's case it uses the iphone layout but it is very easy to skin e framework so you can give it a custom look to fit all platforms.  

Chris (WebApp.Net): Developing for the iPhone, Android or webOS, the developer can easily rely on the provided emulators/simulators but the debuggin options are quite limited. As a last resort, they can use a classic WebKit based browser along with the powerful tools provided but latest WebKit's Web Inspector. Of course, the desktop version usually provide more APIs than their mobile counterparts and mobile versions doesn't implement all the same features.

Most of the time, those features are for very advanced usage and are not a problem but I remember, working on webOS that the CSS gradient weren't implemented and I had to rely on canvases to render gradients. I think there is mostly always a way to workaround a compatibility issue.

Nowadays, most browsers implement powerful debugging/profiling tools. For the Ajax stuff those tools are more than useful, but developers have to reproduce as much as possible the target environement to not be stuck on a cross domain problem when depoying. Indeed, the cross domain limitation doesn't exist with the file:// URL scheme and I know that sometimes (often) front end dev'ers try their code like this mainly when the only things to do is to render a JSON content directly from Javascript. Of course, JSONP is a great help to workaround the cross-domain limitation and specifically when a server-side proxy cannot be used.

So, the short answer is: use the provided Developer Tools :)

Christoph (mootools-mobile): As noted before, the need for manual testing should be minimized as much as possible. Arian Stolwijk, member of the MooTools team, and I have recently rewritten the MooTools Spec Engine which is our unit testing library. It is standalone, based on Jasmine and can be used in any project. It allows to run code in the browser, in node.js and via JSTestDriver (work in progress). You can find it on GitHub: http://github.com/mootools/mootools-runner - it even allows you to simulate mouse and keyboard events via a great library called Syn.js For more information and to try it out see the instructions on http://github.com/mootools/mootools-core-specs

Basically, if you decouple your DOM-interaction from the business logic, you can test most of your application's code automatically already (maybe even by just running it via node.js).

 

InfoQ: A lot of time has passed since the early days of WML and XHTML-only mobile browsers. What things do you think have changed since then? Have we learned any lessons that apply to the current situation where we have more powerful devices but even more demanding applications?

Michael (Sencha Touch): The biggest thing that's happened is that Moore's law has continued apace, bringing its continuing bounty of processor power. Today's mobile device now looks like a 2000-ish era desktop, and that means it can support rich applications for the first time. The other thing that's happened is that the HTML5 process has delivered us standards-based web technologies that are practical, useful and understandable to the average developer. It's what everyone hoped the browser could become back in the 90's before everything went off track.

The first lesson we'd suggest is that developers now need to evaluate whether they should do the work to support legacy devices that can't support good application experiences. Back in the day, WML/WAP apps were hard to use and very limited in functionality. Simply creating user interfaces that are fast, uncluttered and intuitive isn't enough, you need to create engaging experiences. Internally, we have a minimum phone spec that we check new phones against. Today Android 2, iOS and RIM OS6 are above the bar, and we expect Nokia phones to get there pretty soon. We don't ever expect to have a Sencha app running on a Motoroal Razr.

Our other thought is not to worry too much about taking advantage of OS specific capabilities. There is definitely a segment of mobile developers who conscientiously use widgets and controls that are native to each mobile platform - even when they're developing web apps. But in our mind, the web is a platform all by itself. Desktop web apps don't look different on Mac vs. Windows vs. Linux – why should a mobile web app look different on Android vs. iPhone, as long as they all have the same input mechanisms available?

Brian (PhoneGap): Device APIs are the biggest and most interesting change we're seeing

in the modern web. Everyone is talking about HTML5 but the innovation is going to happen once the web is a first class platform with access to device sensors (like the camera) and device data (photos, for example). And you can write web apps with Device APIs today with PhoneGap.

Unfortunately many of the lessons learned in desktop programming don't translate well to small screens and the language of the web that is JavaScript. Many developers are applying large systems design philosophy (insert favorite Go4 design pattern here) to the very succinct, functional and dynamic JavaScript language. Making JS into a Java or C variant cripples the best features of JavaScript while bloating the code footprint which isn't really an option on mobile devices. There's plenty of room for innovation; the developers that dare to work with the tools *we have* rather than trying to shape them into the tools *we had* are creating the future web.

Christopher (iWebKit): Technically "mobile browsers" do not exist anymore. The only difference now is the screen size and the use of touch input. The engine is exactly the same as that of desktop browsers. Have we learned any lesson? Well not really. At the time phones were slow and the user experience terrible. The hardware wasn't good enough to run big and heavy websites in an efficient way until apple decided to redesign the "mobile Internet", give the iPhone a big screen, an easy way to navigate and most importantly the power to run a "desktop" browser.

So when I say we didn't learn anything I mean we didn't improve mobile Internet available at that time but we shifted away from it into a whole new space. The applications available today are proof of that. It's not the same "thing" as it used to be. The true concept of mobile phones has disappeared, Now we have smartphones.  

Chris (WebApp.Net): The WAP was a very interesting stantard per se with good scripting capabilites and bring the Net into the mobile world. The problem was that most of the specification was not implemented in mobile browser mainly because of devices limitations and not talking about the small screen limited to only few lines of text. Also, WML was strongly XML-based, a single error made the full page unreachable. All browsers weren't featuring the same capabilites leading to fatal exception using a simple <b> when not supported. These forced developers to create a version for almost any different device! With WAP 2.0 another step toward a more user-friendly mobile web has been done. This new version use a subset of XHTML (Mobile Profile) with CSS capabilities but again implementations were quite unequal and again, disparity of screen dimensions didn't ease developer's life.

Nowadays most smartphones have a nice big screen with an advanced browser able to render properly a desktop web page. It seems that manufucaturers have understand the challenge of mobile web and invest a lot time in their mobile browser. The better example if Mobile Safari with iOS 4.x. This browser features so many features that it is hard to cope with. You can also found feature available only to the nightly build of WebKit. With this new version of iOS which bring an almost true multitasking, Web Workers are available along with very good and almost complete HTML5 API implementation.

Interest for applications seems for now focused on native development but web applications have more and more access to low level API like the geolocation API, Touch/Gesture Events or the very interesting File API still in a working draft status but already implemented in Mobile Safari. Not to mention that webOS is originaly web based only. The developmement of web applications is also, in my opinion, faster to develop and easier to release and maintain. Of course because of device limitations you will hardly create a 3D game using Javascript and Canvas or SVG but most applications can be done in HTML/JS/CSS, this is well demonstrated by webOS. Beside, Google release most of its desktop web applications in a mobile form and more and more editors are walking the step.

Many native applications use HTTP feeds to provide the application content and most of the time only few features of the OS are used. All these apps can be easily rendered using HTML/CSS so, the gap between native and web is not so big.

Christoph (mootools-mobile): To be honest, I haven't done any mobile app development until recently. I guess that is true for a lot of people and this is exactly what has changed since the early days. People finally see the potential of mobile web applications. Developing just one web app instead of multiple native applications saves a lot of resources. Consider that at the moment innovation on desktops is happening in browsers and not on the platforms themselves. I see no reason why that would be different on mobile devices. The web is a general purpose platform.

The huge problems we currently have is that mobile web development is like playing Minesweeper with 99 mines on a small field as opposed to playing with 99 mines on a large field like in desktop browsers. I think that is a nice and fitting analogy. We have almost no mobile browser debugging tools, we have almost no documentation on browser features and issues and the sheer amount of different platforms can drive a developer crazy. We are just at the beginning, give it some time.

 

InfoQ: How good do you think current Web Application Development practices scale for Mobile Web Applications

Michael (Sencha Touch): The big difference is that most mobile apps are quite simple, so mobile development today requires far less organizational scale than desktop development. For consumer iPhone apps, the median time of a user session is between 4 and 5 minutes. We'd guess that if you exclude email, you'd get similar results for corporate mobile apps. In a survey we did of our developer base, the number of screens that people were designing for was 10-20 screens at the 80th percentile. Phone screens are just too small to support sustained work.

I think as we move to tablet computing, this is going to change substantially and you'll have more complex apps with longer use sessions, and development processes and teams will look more like traditional desktop development.

Brian (PhoneGap): All the professional programming practices work very well. Get your code in an revision control system. Setup automated builds. Write unit tests. Projects that do not employ those three things might not fail but they certainly won't have predictable release timing or steadily improving quality.

Most web app practices center around good semantic markup, clear css and a decent DOM library for cross browser concerns. In the mobile world we have devices that require us to defy those practices. Good markup, while a good idea, adds lots of tokens increasing latency. Deeply nested elements increases the render complexity making CSS lookups slow. Basically, if you can do less of something in the name of performance you probably should. You may not have a choice! We'd love to be using jQuery for all our PhoneGap projects but because the library is so big the initialization time is terrible. We ended up writing our own lib for mobile called XUI to solve this. We've been using it in all our PhoneGap projects at Nitobi for two years now. It works great as a minimal DOM lib for any supported PhoneGap platform but it explicitly does not provide a widget framework.

If you are only targeting newer iPhones and you want the GUI figured out for you then jqTouch is a great option. If you are building an iPad app and want an iPad style GUI then Sencha Touch is most certainly your best option. Any of these solutions combined with PhoneGap will take you from nothing to an native app in, literally, 5 mins. No one native platform gives developers that kind of productivity let alone giving them the ability to port across platforms. But the real moral of this story is understand your audience and then build to the experience they would expect.

Every mobile project should start with audience research. Many folks coming to PhoneGap are only interested in the iPhone but once we look into their audience we almost always find the majority of their users have a Blackberry. Interaction Designers are more important than they have ever been and its their responsibility to ensure that their research goes beyond downloading iPhone stencils from Smashing

Magazine. They need to know the dimensions and pixel densities of all mobile devices. They need to know the common UI paradigms on each platform. They need to understand that mobile does not just mean

phones and that it might not mean touch interfaces. No single platform is more "correct" than another. A successful mobile app will accommodate each platform and, yes, this does mean conditional builds/code for the developer. A great platform experience could be the difference between a super successful app that is a delight to its users and a mediocre app that is the lowest common denominator of features between platforms. Which one are you going to build?

Richer clients on mobile devices are exposing new fascinating problem spaces that just do not apply to the desktop. For example, data replication and sync is a big problem. The CouchDB guys are working on this and we're pretty stoked that they are! Its a super tough problem. If you have a DB w/ a terabyte of data, what happens to the client which can only store 20 megs? Some sort of paginated sharding? What if that client is offline? Tricky stuff. Security and privacy open up a whole other can of worms.

Christopher (iWebKit): Currently only a few very specific tools are available like iWebKit or other frameworks but since a couple of months that has changed. You see a lot more major JavaScript libraries that are implanting touch gestures for example. I suspect that by next year mobile and regular development tools will be merged. The only difference will be screen size which isn't really a limitation.

Chris (WebApp.Net): Mobile Web Application need to be efficient and fast to load and react to user inputs. In a mobile situtation, the quality of the network is determinant. This is why you have to take care of what your are doing. Ajax is one of the key to reduce unnecessary traffic since you load only required contents without reloading the full page. Some framework make intesnive use of Ajax which is a good point but many have a very huge JS code to handle many features (and most never used) which may make the app long to load, at least at first load, and discourage the user. Those big file can be easily cached using the Offline Web Application feature or Local Storage API and the support for HTTP Compression may help but the way to go should be to rely on plug-ins/add-ins so that the developer can choose what to use and gather files into a single file to improve loading time. jQuery for instance is very interesting but reinvent the wheel where most popular mobile OSs feature a browser with impressive support for W3C and WHATWG standards which make most jQuery features useless. Also, the Apple's iAd framework is amazingly huge (more than 100K). this seem to be because of the use the MVC pattern in this framework which force the code to be very structured.

Christoph (mootools-mobile): I think both web application and mobile web application development

are very similar. They are just aimed at achieving different things. While normal desktop web apps may focus on traditional functionality, mobile applications can use whatever information a device provides

about the current environment it is in. About whatever context that relates to the current user situation. Geolocation is a great example. Mobile devices become more and more aware of their environment and at some point we will have APIs to access just about anything the hardware has to offer.

Personally I just look at the stuff that is new and I try to find a use case for it. Recently I have grown to like localStorage, Geolocation and history.pushState (See http://github.com/cpojer/mootools-history ).

 

InfoQ: Is your project leveraging any of the HTML5 APIs? Which features of HMTL 5 do you think most valuable for mobile devices? Can you give us a few examples of use cases?

Michael (Sencha Touch): We enable all the interesting HTML5 family techs. Geolocation is definitely the number one HTML5 API for mobile. Geo-awareness is huge for mobile because it allows you to simplify the application substantially. For example, http://www.geocongress.us is a Sencha app that tells you what your Congressional delegation has been up to lately - bills introduced and votes made. We don't have to ask the user what Congressional rep and senators they want to track, we just look up the location ad are able to immediately show just the delegation that's relevant to the user. It's about simplifying the interface, and immediately providing relevant information.

Just after Geolocation  are the offline app capabilities including cache manifests and localstorage, because mobile apps need to work when the network isn't available. Touchsolitaire.mobi/ is a Sencha app that saves your game state locally in localStorage, so you can play offline.

Beyond that, we leverage CSS3 capabilities heavily in our theming including transitions, animations and styling. We think that CSS3 animated ads could be big in mobile advertising because Flash is not available on so many phones. We even did a demonstration of them at http://dev.sencha.com/deploy/css3-ads/.

Brian (PhoneGap): PhoneGap extends whatever native browser is available on a given platform and, for the most part, that means we're based on WebKit which is definitely the HTML5 poster child. A PhoneGap project can leverage *all* the HTML5 apis that are implemented in WebKit but, as always, this comes with some caveats. For example, CSS transitions/transforms/animations and the canvas element are only hardware accelerated on the iPhone and webOS. In the future I believe the canvas will be crucially important for creating rich and performant interfaces but we're not quite there yet.

The other significant features are more around offline storage. I'm personally not very happy with WebKit choosing SQLite and not all the mobile devices support it so we wrote a library called Lawnchair to hide the storage internals. It works really well for simple persistance of JSON documents on the client. PhoneGap is working towards having a consistent FileReader/FileWriter implementation soon too.

Web Workers is another area of excitement for mobile since it could give us far better app performance. And finally we are *really* excited about the possibilities of Web Sockets for realtime applications (we already have XMPP support for iPhone and Android). Think about it: geolocation, real time messaging, contacts api, camera access...there are many very cool apps waiting to be born.

Christopher (iWebKit): iWebKit is entirely based on css3 which is one of the most important new additions to html5. The main purpose of this is to make the package as light as it can be. Only very few images are used, the rest is being generated by the iphone itself. With css3 I could also create rounded borders, shadows, auto-streching background images & custom form elements. It also has some awesome features like the detection of certain elements depending of their position on the page (odd and even elements for example) and custom styles depending on the width of the screen.

Chris (WebApp.Net): WebApp.Net doesn't use any HTML5 APIs for now. Anyway those API are already APIs and doesn't really need to be encapsulated, and again, will be more likely to be use as plugins than part of the framework like a video player for instance. Some HTML5 APIs are very specific like the Selection API which is more related to text editing. About cross-domain limitation, the Cross Document Messaging API is interesting to allow cross-origin communication but the developer as to be very careful using it and ensure security at all time. It is already implemented in iOS 3.x in a basic form allowing string based communication only and imporved in iOS 4.x implementing the full API specification. But, one of the most interesting API should be the Canvas API which allows, with the WebKit specific -webkit-canvas() CSS function, very adavanced usage. Actually, the mix between Canvas and Video is not supported in Mobile Safari leading to a security error, hopefully this will be fixed soon. For those that are not part of the HTML5 spec, the Geolocation API and all the storage APIs allow greater flexibility and access to a world formerly limited to native application.  

 

InfoQ: With the HTML/JavaScript stack having significant momentum on mobile devices, what do you think is the future of plug-in based Rich Internet Application technologies like Flash? Are they complementary or will they become eventually obsolete?

Michael (Sencha Touch): I think it's a little early to call them obsolete, but for cross-device coverage Flash and Silverlight are simply out of the question. Flash may find a home on Android particularly since Android continues to lack support for SVG - the web vector graphics standard. I would be highly surprised if Silverlight ever showed up on the iPhone or Android. We expect HTML5 and HTML5-based frameworks to soon develop the really desirable capabilities that Flash and Silverlight offer today, such as device access and content protection.

Brian (PhoneGap): Flash will work well with PhoneGap where ever (or perhaps whenever) it actually becomes available and adopted. There's already an example of an Flash / PhoneGap bridge out there. I think developers like to focus too much on 'whats dead' and other trends. Flash is a tool and as such, when appropriate, we should use it. Its a good idea to keep in mind that *all technology* becomes obsolete.

Christopher (iWebKit): I am against technologies like flash for seo reasons, so in case it's used to deliver content. The decision not to include flash in iOS is apple's choice but doesn't make it a bad technology. For specific uses like dynamic graphical parts of your site, flash or silverlight are by far the easiest ways to achieve a cool looking results. HTML5 works too but isn't necessarily more powerful or easier to use. Also for video for example, flash is the only way to protect your media. For now flash won't die but it's market will probably shrink over the years. In the end it will disappear like every technology, maybe with html6?  

Chris (WebApp.Net): Flash is good but we all must admit that it slows down a lot the web and computers mainly because many ads noadays are using this tecnology and also because some developers doesn't really master Action Script and the implication of some Flash features leading to a near to 100% CPU usage executing their code! Anyway, the web seems to go more and more in th direction of a plug-in free browser. The best example is the evolution of the HTML5 Video and Audio API and the adoption of the feature in most major video content web sites like YouTube or Vimeo. Although Canvas and SVG are powerful, they both need to code almost everything by hand where Flash has a full authoring tools. So, for the time being I will say that they are complementary and as Flash is widely used, it will still remain for some time. But software vendors are developing solutions to ease usage of Canvas or to render Flash, for instance, as a mix of Canvas and SVG. This is mainly because Flash is not supported on iPhone and iPad but also because plug-ins have proven some instabilities and using built-in browser capabilities is far more heatly.

Christoph (mootools-mobile): Openness is what defines the web. It needs to stay open at all costs, there is no place for proprietary software. That is all I have to say.

 

InfoQ: What would be your advice for teams that are currently preparing to develop a mobile web application? Which things should be their main concerns and what are some common pitfalls they should be careful about?

Michael (Sencha Touch): Be very very careful about the user experience - even for business applications. Don't try to clutter your app with too many functions. Keep your interfaces simple and the number of screens manageable. Do informal performance testing early. Be realistic about the number of mobile devices that are really "must-haves" for rich experiences – but have a plain HTML fallback for devices that can't support a rich experience.

Don't try to roll your own UI components and low level abstractions, you're recreating the wheel especially when there are things like Sencha and jQTouch to help you avoid this work.

Also just because you're doing a mobile web app, doesn't mean you can't leverage native app distribution channels as well. Phonegap does a great job at allowing you to take your web app and package it as a native app for the Android marketplace or Apple App Store.

Brian (PhoneGap): We think the best thing you can do is prepare for the mobile web. Start with a mobile web app and just view PhoneGap as a progressive enhancement technique for app store distribution and early access to Device APIs. This stuff is coming to browsers. (And no other cross platform mobile solution is suitable for this style of dev btw.) Think about who your audience is and let go of your personal device bias.

Think about Edge speeds and sketchy connectivity. Not everyone is rocking an iPhone 4, in fact, the largest chunk of your potential audience is likely packing a Blackberry 4.6 on a poor network.

Christopher (iWebKit): Besides the usual advice for building websites there are 3 things to remember. The first one is that most current smart phones are intuitive to use and deliver a great user experience. This has to be part of your app too by adapting yourself to the screen size and touch controls of the device. The second thing is that you do not want to limit your users to a minimal version of your site. Nowadays users want to fully experience your site on their mobile phones. And last, remember that a phone is mobile. It isn't as fast as a computer and networks speed are also a limitation. Make light and speedy web apps that load fast on 3G and edge and are not too processor intensive. 

Chris (WebApp.Net): I will advice to look deeply into the new capabilities offer by HTML5 and the new W3C specifications but also check the ECMAScript specification to have a good understanding of Javascript. Most APIs are already implemented in mobile browsers and will help a lot in the development process of their web applications. The developer have to know the platform he is working on the and common user usages and behaviors. For instance, use the navigation area defined by the OS and use the gestures expected by the user for a given action. Do not reinvent the wheel but be creative and inovative. You don't have to mimic the OS interface mainly because your web application can be viewed on different platform.

Check existing frameworks, even if you not plan to use them, and see how they implement specific features related to your project. Using Ajax think about search engines and user bookmarks. Depending on your web site, the user may want to bookmark -- let's say an article which has been loaded using Ajax -- and may be then disappointed is it fail to access your content. Talking about search engine be more compliant and effective using the new Metadata feature offered by HTML5.

But the most important point: always think about the user. The user experience must be the heart of your consideration when designing your web application. Do not try to put everything on the same page, focus on one think and split your content. Remember your are not developing a web site but an application using web technologies. Behavior and expectation are different. The more simple is your web application the more success it will have.

Christoph (mootools-mobile): First of all, try to get your hands on real devices as much as possible. Emulators just don't cut it. Read up on the differences of various mobile browsers. Consider to use devices with big screens because they make testing easier. Pick your target platform and try to provide separate views for older mobile browsers. For advanced mobile browsers you can (and should) add rich interaction to mimmic native applications. Quick pro tip: use css transitions and translate3d to get hardware acceleration.

 

InfoQ: What is the future roadmap for your project?

Michael (Sencha Touch): HTML5 and CSS3 has given us a bounty of technologies that we're just starting to fully take advantage of on mobile. And there are lots of areas for run-time innovation and tools support that we're looking at. The challenge is to prioritize what to tackle first! More extensive pre-built UI components, better graphics support and rich data management are probably the three themes for the next revision of Sencha Touch.

Brian (PhoneGap): Our big focus right now is making it easier for people to get started. Our docs are far more solid which you can check out here: http://docs.phonegap.com and better tooling around testing and building PhoneGap projects. We're adding new platforms all the time and the test suite is getting more and more comprehensive. Its a big project and no one person could do all this work so we need *your* help building the future of PhoneGap. Jump on the PhoneGap mailing list, IRC channel or even just ping @phonegap on Twitter if you want to help out. Lots of easy bugs to get started with.

Christopher (iWebKit): I am already working on the next update of iWebKit. Its structure will change and will use the latest HTML5 elements to make editing easier for the user and the structure easier to understand at a glance of an eye. Moreover I'm going to implant an entirely new themes system by separating CSS files making theming a piece of cake. And last it will be iPad and iphone 4 compatible out of the box. Make your site and it will work on any apple device.

Chris (WebApp.Net): I'm currently very busy writing a book about webapps development on iPhone and iPad. It is supposed to be published in the coming few months. So, I don't really have time to work on WebApp.Net and its roadmap. But my work on the book led me to create some interesting features to illustrate chapters which will be part of WebApp.Net of course. The most important work will be to revamp some of the current WebApp.Net functionalities to make them more standard compliant. Then, I'll work on the iPad support but this will require some change to the framework core.

Christoph (mootools-mobile): I I'll try to provide more useful additions for mobile web app development and I will release more generic plugins on my GitHub (see http://cpojer.net ). Once the MooTools team releases MooTools Core 1.3 (very soon, I promise!) I will start writing articles on how to put my code into use. Everything I do is targeted at MooTools Core 1.3, so be patient unless you wan to live on the edge.

You can find more information on Mobile Development right here on InfoQ!

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT