I've been developing a web app using JQM to target iOS and Android devices. For much of the start of the development, I have developed and tested using Chrome (currently v13) on the desktop. As we get closer to our production release deadline, I have increased testing on physical iOS and Android hardware; the difference in performance between the desktop and mobile browsing experience is enormous.
The client/server interaction is very simple. The client requests a set of views, which the server returns. The client can then request the set of nodes associated with a particular view, which the server will return in a single payload. The client then generates the DOM for each node from the corresponding XML.
I have begun testing with XML payloads at or greater than 400kb. On the desktop, in Chrome, this is no issue. On mobile, in Mobile Safari, my DOM load times alone can be close to 12 seconds. Interactions with the DOM (which trigger updates to the XML, cached in localStorage) can take up to 5 seconds per click.
While I can think of half a dozen different ways to optimize my client/server communication--I can't figure out how to measure the expense of my individual method calls from the mobile client. I know that a 400k payload is too much for the iOS Mobile Safari, but I don't know whether the performance cost I'm incurring comes from traversing the DOM or manipulating the XML.
How can I perform metric analysis of my mobile web app from the perspective of the mobile client? Performance tuning to the desktop isn't getting me anywhere, and I don't have an equivalent developer console/FireBug on the mobile side.
How do other mobile developers solve this problem?
I've decided to add a simple start/stop logging button, which calls a logging function which stores method timing data in sessionStorage. On stop logging, I ship this to a web service for analysis through a desktop browser.
Edit: I did try JsLitmus per this SO post, but I concluded that the only performance test that really matters on mobile is the time to execute any particular function. Once I had this information exported out of the client, performance tuning was trivial.
I don't know what sort of XML parsing JQM uses, but if it's using a DOM style parser, performance will suffer for sure. Mobile clients deal better with pull style parsers (they're less memory intensive). DOM style parsing of XML is really slow in native clients, I bet it will be even slower inside a browser.
A 400 KB XML sure sounds like quite a big chunk of data. Do you really need all that at the same time?
Heavy DOM manipulation has never been cheap, I expect performance will be pretty affected in a mobile device.
I guess this doesn't really answer your question, but it was pretty long to just place inside a comment.
Related
We are going to redevelop one website we developed as an ASP.NET website to be a mobile one.
So, I'm wondering how does the development of a mobile website differ from a normal one?
Also, what is the best approach to do this taken in consideration that this mobile website will be browsed mainly from iPhone?
There are a number of differences between a mobile device and a standard computer.
The screens are much smaller (fewer pixels to display your page). You should put fewer elements on each page.
They are typically viewed in portrait mode (narrow display - narrow page). You should plan on using the full width of the screen instead of setting a fixed page width like most people do on standard web pages.
People use finger gestures to manipulate the page instead of a mouse (buttons/links should be larger)
They can include additional features such as geo-location, telephone, etc. that you can incorporate into your app to be easier to use. There are some libraries available to help you use these, such as jQuery Mobile.
Users are concerned about battery life plus the CPU tends to be slower. Make sure you keep animations and client side processing to a minimum.
Users are concerned about data usage. Keep ajax calls to a minimum (don't ask the server for data every few seconds!) and use graphics sparingly (it's better to use html/CSS to make the page attractive).
Flash isn't supported on iPhone and is not well supported on other devices. However, most mobile devices have decent support for HTML5, so you can typically use that instead.
Users on smartphones are used a different experience.
In addition to Brian's answer I'd add:
Screens are not resized but scrolled, however sides scrolling is not generally a good experience
Screens orientations can change, but the same scrolling rules apply
Consumers are used App like behaviour and as such less information with backwards and forwards between pages is common and between sites
Consumers generally have data concerns so data traffic needs to be minimised
Controls/buttons/selections/data entry need to optimised for hand gestures - for example think of what happens with the keyboard pops up to allow data entry, how much screen is available - can the see all their input easily if they need to?
I suggest that for developing a mobile website is to use the target smartphone for a few weeks to understand how the device is used in the real world.
I'm afraid you cannot use current asp-View to mobile especially for iPhone. There's special control set for iphone development - componentone.
If you web application is based on MVC or MVP patterns then moving will be not difficult.
Recently we have developed a site for iphone users, we are using asp.net/sql for normal site.
But when you look at mobile sites, mobile normally have small screens and some time optimization problem.
We use jqtouch for mobile development. A JQuery plugin for mobile web development on the iPhone,Android, iPod Touch, and other forward-thinking devices.
Learning Video
Getting started
Establish the context for the mobile site: is there subset of information that is more relevant to your mobile users? Maybe your regular site has apps that are irrelevant on mobile devices? Either way, you should create your mobile site separately in a mobile folder! You can then use a sub-domain to reach it: for example, http://m.mysite.com
You can use a combination of CSS Media Queries and 51degrees.Mobi to detect browser features and render the correct size layout depending on which type of device the user has.
http://html5boilerplate.com/
http://www.modernizr.com/ (this is included in HTM5 Boilerplate)
http://51degrees.codeplex.com/
Do not make the stupid mistake of following current fads like "Responsive Web Design" which attempts to squeeze a desktop version of a website into a mobile screen. Above links should get you started.
It is generally said/accepted that a native app would always have a better/smooth performance compared to a web app..
Is this statement true across all the platforms (iPhone/Android/BB,etc) ? Does this not apply correctly for an iPhone i.e. to say that for iPhone web app, it utlizies some kind of GPU acceleration or something (though not very sure how that works) and hence the performance gap is not much ?
Could you please elaborate on the same. Essentially I wanted to understand if I have a high performance app (which would include lots of animation/high memory usage,etc), is it better to have that as a native app OR if the target audience is only iPhone, even a web app would perform good..Having said that, will Android also reduce the performance gap between native and web in the near future?
Also any examples of really high performance web sites which I can try viewing on iPhone/Android to compare the differences?
You're asking a big question there :)
Web apps are all the hype because you don't need to learn Android or obj c so people with skills like web design and scripting can make apps fairly easily. The problem with web apps I find is that you have to be very conscious of how everything works as everything has to render every time.
I've found some web apps crash when you do too much too quickly, even with HTML 5 there's some bugs. On iPhone and Android devices if your app was say a shopping app you could pre render results for a query and only show them when required.
Another problem with web apps is connectivity. I know some people say the internet is everywhere but what if you;re abroad and your carrier charges roaming for bandwidth? I know the ones in Ireland used to charge 10e a meg to uses the internet. Fair enough if the app whether native or web required a connection both will suffer
As for the cpu and gpu performanance that will mostly rely on the model you're using. The iPhone models speak for themselves but there's sooooo many Android phones with different processors it's hard to benchmark. Also take into account internet connectivity..... a lot of factors
With both platforms there are endless pros and cons. I find web apps are quick and easy but can fall short of the nice functionality in Android and iOS APIs. On the other hand the Android and iOS APIs can be head wrecking and cause weeks of headaches
My web site has a different mobile version that's suited for iPhone/Android devices. The problem, however, seems to be in the site's performance. It's really slow and heavy, even though I'm not loading any images.
On the other hand, when I use Gmail's or YouTube's mobile version, they're so fast they almost perform like a native mobile application.
How do they do that?
Your help is much appreciated :)
See my comment. Also, if the slowness you perceive is when interacting with the site it could be that it lacks the ability to accept touch events. On mobile web, if you have not wired up the UI for js touch events the experience will seem slower because the device browser has to fall back to standard click and other mouseevents which are not optimal. Frameworks such as mootools and jquerymobile/jqtouch have these events baked in. Take a look at the mootools solution which has quite a good write up: http://davidwalsh.name/mootools-touch
They probably making use of local storage http://dev.w3.org/html5/webstorage/
Are your pages too large? Try to use gzip and/or reduce output
Your server's connection speed may also be responsible of slowness
Well, You don't need to include any javascript framework to make it fast clickable.
By implementing some JavaScript you can achieve that. Google has released a solution for that
https://developers.google.com/mobile/articles/fast_buttons
This will allow visitor to interact with application native way. From Android 4 (as far as I remember) version by setting viewport meta tag the browser will automatically apply the fast click functionality.
For the animation issue always use Hardware accelerated animation with a fall back for older mobile browser. Using hardware accelerated animation it will make your application smooth as silk.
Follow this guideline and you can make your application as fast as gmail / youtube mobile version.
http://www.html5rocks.com/en/tutorials/speed/html5/
Best of luck.
Your webapp is consuming too much RAM. Don't use so many libraries and don't attach so many event handlers.
What is the biggest limitation of making/using webapps?
I'm thinking that when you use localstorage, offline-browsing and geo-abilities thaht you get from html5 the differences are quite small (except for games).
The great benefit from using webapps is that they are cross-platfrom compatible!
One of the biggest limitation is access to hardware. You can't access USB ports, specialized hardware you might have (printers, bardcode readers), and other stuff, and of course, you don't have access to some very important APIs that you need today to run games (DirectX, OpenGL).
But I agree: every day they are fewer reasons to not go with a WebApp instead of a Native APP.
For iOS: When using geolocation for webapp, the user will get prompt about giving location access every time, which could be annoying for the user. Native app, only the first time.
The UI performance is also not as smooth as native. Scrolling in webview has a "slower" acceleration compared to native view scrolling.
Performance is one major difference. I see from around 20X to over 200X speed improvements when converting from Javascript to compiled C/Objective C code. One can also do real-time audio and video processing in native code, as well as low-level networking, etc.
One interesting limitation (HTML5-wise) I see is from a point of intellectual property. Since a lot of code (raw JavaScript + HTML) is exposed to the user, you have to carefully decide which components will be "open" to end users. Not aware of any standard way to lock or hide your IP once it leaves your server.
Webapps are great for reaching multiple hardware devices, you can update your app a lot faster, thus feedback is quicker. However, your users will require an always-on internet connection to use your webapp, that's probably the biggest negative about them in comparison to a native (offline) app.
My wish is to know how I can program a mobile website, that fit to all mobile phones.
Are there any special approaches to recognize a device and render the code according to it?
Which tools and coding languages are required?
My first thought was to hold the website in XML, which would be parsed depending on the device.
You have to consider old phones, even devices with only wap support.
For example: The mobile website has to recognize Nokia N75 and render/send the code that looks optimal for this device. Same thing with an iPhone or a Motorola Razr.
There are all sorts of problems associated with developing mobile websites. Doing it well takes a lot of time and effort, as phones have such varying support of web standards. There are tools that do it for you, such as the Mobile Web Toolkit and Vodafone's PartnerMl. These tend to force you to write your pages using dedicated XML tags which describe a limited set of elements and styles that can be rendered on the page. The phone requests these xml pages, and the server side software intercepts the request, examines the type of phone (the User Agent), and serves back markup appropriate to that phone. The disadvantage of this system is that it is very inflexible; you are limited to the set of XML elements that the tool supplies, rather than the full flexibility of HTML.
If you want to do it yourself, essentially, you have to do the following.
Using server-side code, examine the User Agent in the Http Header. This tells you what kind of phone/browser made the request
Output appropriate markup and CSS for that user agent.
Useful tools are the User Agent Switcher add-in for Firefox. Using this, you can, for instance, visit the BBC's website, pretending to be various devices. You will see that the BBC outputs 3 or 4 versions of its markup, as well as 3 or 4 different versions of the CSS, depending on the user agent.
mobiForge contains useful information. WURFL and DeviceAtlas are databases that allow you to determine the capabilities of the device that has made the request.
You will quickly realise that you will have to keep your design simple, and it's best not to rely on Javascript, as only the most modern phones can handle it well.
XML is the way to go.
From there, you mosey on to parsing out and acting upon the Agent tags in the request.
From there you can choose (assuming the device supports it), having the device render it via XSLT, or you can apply the XSLT on your end and stream down the appropriate markup language for the device.
In the end, you end up with a specific "rendering" per device. Ideally, the more compatible the devices are with normal browsers, the close the final XSLT is to each other. But you'll still likely have a version for each device that you support.
The beauty of this is that you can add devices incrementally, as time and demand permits. And as devices converge, you gain value by being able to converge your renderings. Also, your back end stays the same no matter what.
Finally, it also works great for non-mobile as well.
Yea, it's a burden to support the different devices, but that's just a truth of the marketplace.
One way is to use strict html with very clear semantics and minimum of css tricking. Do only use relative measures (for example em and %). Trust the browsers default values, because they are in one way optimal for every device, more or less.
Nowadays there isn't exist good tools to do this.
A good practice is to respect the different W3C standards about the accessibility (like the WCAG, the XHTML, etc).
If you made your web site the most accessible as possible it'll be more adaptable. (independently from device, screen size, with or without screen touch...)
If you want more information you can read one of my article about the web accessibility here if you want: Guideline to move a website on a mobile device.
However you can use some meta tags to allow the web browser of the phone to adjust the content like this for the iPhone:
<meta name="viewport" content="width=device-width">
You might wanna check out WURFL