Menu
I have created one application which contains several buttons to home page clicking on one of that button my application redirects to some view which contains JQM form, with JQM calendar, text field, buttons and database etc....
My query is that when I test my application in android device on that time application works a little bit slow, even if I have not used any images,or any data which can contain more space. That's my first query and second one is that when I tested my application to android tablet on that time that form page is appearing for a while and suddenly it redirects back to home page automatically, while this same feature working well for android phone.
Why this strange issue?
If any one can guide me on it that it will be my pleasure
533
It's difficult to make assumptions regarding the slow performance and the redirection issue. Below you can find some aspects which in my opinion affect the performance of a mobile application which consists of HTML5, CSS3, JavaScript and should be taken into consideration on the analysis, the design and the development phase.
Implementation method based on the size
When developing small mobile applications the usage of a single HTML page using internal-AJAX page linking is recommended. For bigger mobile applications, a method of using different HTML pages with internal-AJAX linking is recommended. Try to create reusable page templates.
Page Transitions
As stated in the jQM 1.1.1 Docs, by default, all transitions except fade require 3D transform support. Devices that lack 3D support will fall back to a fade transition, regardless of the transition specified. jQM does this this to proactively exclude poorly-performing platforms like Android 2.x from advanced transitions and ensure they still have a smooth experience. Note that there are platforms such as Android 3.0 that technically support 3D transforms, but still have poor animation performance so this won't guarantee that every browser will be 100% flicker-free. Decide the transition type that you will use after considering the above.
Minify JS and CSS files
Each page should be as lightweight as possible. The minification’s goal is to preserve the operational qualities of the code while reducing its overall byte footprint. There are a lot of tools available on the WEB like the YUI Compressor, the Minify and many more. Furthermore there are tools like the JLint which is used to check whether JavaScript source code complies with coding rules. JLint is a code quality tool which checks for problems in the JavaScript code. The reported problems are not necessarily syntax errors but may be structural problems. Note that JLint does not prove that your code is correct. Consider it as a helping tool. Also there are tools for performing CSS optimization. The optimization helps you to get smaller CSS file sizes and better written code. You can find a lot of CSS optimizers available on the WEB such as CleanCSS and CSSTidy.
Components limits
The HTML pages is recommended to be limited to 25kb in order to gain the optimal caching advantage for the majority of the mobile web browsers. The caching limit varies depending on the OS version. For example Android 2.1 has a caching limit of approximately 2Mb.
HTML5 & CSS3
Try to create easy to read, to extend and reusable code. It is important to take full advantage of the using of HTML5 and CSS3. The HTML5 DocType declaration (<!DOCTYPE html>) should be the first thing in your HTML5 document before the html tag. It is an instruction to the web browser about what version of HTML the page is written in.
Use the W3C mobileOK Checker
The W3C mobileOK Checker is a free service by W3C that helps check the level of mobile friendliness of Web documents, and in particular assert whether a Web document is mobileOK. A Web Page is mobileOK when it passes all the tests. The tests are defined in the mobileOK Basic Tests 1.0 specification. To understand why checking a Web document for mobile-friendliness really matters, it is probably worth emphasizing a few points about the so-called mobile world. Compared to a regular desktop computer, a mobile device may be regarded as limited at first glance: smaller screen size, smaller processing powers, smaller amount of memory, no mouse, and so on. Compared to fixed data connections, mobile networks can be slow and often have a higher latency. Compared to a user sitting in front of his computer, the user on the go has limited time and is easily distracted. On top of these constraints, the mobile world is highly fragmented: many different devices, each of them defining a unique set of supported features.
Consider the appearance on different screen sizes
The screens density and the viewport size and web page’s scale should be taken into consideration when targeting different screen sizes. The viewport metadata can be used to define the viewport size where viewport is the container area in which the page is drawn. The viewport scale defines the zoom level which is applied to the web page. The target-densitydpi viewport property and CSS, JS techniques can be used to change the target screen density for the web page. There are plenty of articles on the WEB regarding the appearance on different screen sizes.
Identify the flows with potential delay
The PageSpeed Firefox/Chrome extension can be used to check the pages speed. When you profile a web page with Page Speed, it evaluates the page's conformance to a number of different rules. These rules are general front-end best practices you can apply at any stage of web development. The extension gives specific tips and suggestions on how to best implement the rules and incorporate them into the development process.
I hope this helps.
109
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
