built an app i jquery mobile, it is almost finished, and after deploying the app to phonegap we discovered that the scrolling and the total feeling is not smooth and the scroll is slow and feels weird.
i have tried almost everything,
1) $document.bind("touchstart", function(event){})
2) $.mobile.buttonMarkup.hoverDelay = 0;
3) using scrollview.js
4) removed ul > li and placed divs instead, removed anchors <a>
all of the above and nothing has changed, scroll still stuck. do you have any idea?
try browsing the app in safari in your iphone to see what i'm talking about.
http://saloona.co.il/mobile
thank you
jquery.mobile-1.1.1
removing the content wrapper fixed it for me.
<div data-role='content'> </div>
it scrolls just as smooth as a webpage in safari.
There are a few issues with poor performance and scrollview, especially on android. Generally, the more complicated your DOM gets the less performant scrollview becomes.
The JQM team addresses this in their last major release:
Alternate approaches use JavaScript-based momentum scrollers to achieve true fixed toolbars, but these only work on a small subset of platforms, have non-native scrolling physics, and can introduce performance and usability issues in less capable devices.
Therefore they switched to real fixed toolbars (position:fixed) in the newest release, which is pretty much supported by the most devices in use. I think this is the best way to go.
Related
So I'm not really sure how to explain this but I will try my best.
I created a jsfiddle: https://jsfiddle.net/xghar755/2/
As you quickly hover over each text, you can see that the background color changes. This is just a simple div with a css hover property. Here is the kicker though, go to your address bar and type in any letter and you get a drop down of items, like so.
Now, quickly hover your mouse over the items in the dropdown. And then go back to the jsfiddle and hover your mouse over its items. You can tell that the chrome versions` background color feels more responsive. It's rarely noticable, but I can tell. Why is that?
Is this because Chrome's a Native application that doesn't rely on CSS or the DOM? If so, does this mean that native apps are generally more responsive in user interface applications? Thanks ~
Chrome is a software program running on your device. jsfiddle is, in part, a program that communicates with Chrome via the internet. Each transaction between the browser and jsfiddle takes tens of milliseconds, perhaps hundreds, and there can be a multitude of back and forth operations to serve one page and its in-betweens. In addition, Chrome is written in a language that runs in your machines native processing language while communication with jsfiddle is all interpreted by Chrome first, not to mention some processing is done on the jsfiddle server before being sent to your browser.
tl,dr; Programs running on your computer can do things a lot faster if they don't have to communicate with other programs over the internet.
I'm developing my project in Codename One. UI creating from code, not GUI Designer. Application consists of three forms, as navigation I use Hamburger sidebar. The emulator works fine, but the builded application works very slow. Application was tested on Android. The degree of brake application depends on the number of components in the form. The situation has changed a little after we changed android.asyncPaint to false, but the operating speed remains slow.
Above all, Hamburger sidebar animation works strange. At first shows previous form, and then only shows the selected form. But this problem is not as important as the terrible brake application.
In 9 our of 10 cases this is caused by developers using gradients which are notoriously slow. It can also be triggered by tiling very small images or too many layers of transparency.
We have a performance monitor tool in the simulator that exposes some of these issues. You should also watch this video which covers most performance issues: http://www.codenameone.com/how-do-i---improve-application-performance-or-track-down-performance-issues.html
I used Highslide JS about 5 years ago on this site: http://wela.ctc.edu/academy12-13.aspx (example page). Now I'm redesigning the site use Twitter.Bootstrap and am trying to figure out how I can tweak the Highslide popups to work in a small device width. Is this possible or should I use find another solution to implement? I've played around with the setting parameters in my highslide-with-html.js file, but the results have been unsatisfactory. If it is possible to use Highslide in a responsive design, would be grateful for any URLs to look at.
The short answer is that Highslide adapts very well to small devices if you're opening images. The expander is purpose-built to do just that - display the image as large as it can without exceeding the boundaries of the viewport.
But when opening anything else - an expander with HTML content, an iframe, etc. - the expander must initially be a fixed size. You can put a resize handle on it, but that's not really good enough for handling everything from a smartphone to a large monitor.
Without rewriting Highslide JS, overcoming this limitation would require that your page do its own detection of the viewport size, then either modify the call to htmlExpand() on the fly, probably with some jQuery manipulation, or change the .highslide-html CSS class width. The latter approach (targeting the CSS) seems like it would be easier.
I have went all over the web to find a solution for this one ...
i want to create a fixed bottom menu for my web application,
As i learned the support is not cross platform and each device and browser presents a different obstacle,
I have placed an element with
position:fixed;
bottom:0;
left:0;
problem : it is very buggy on some browsers (pops to place after the scroll ends , stays on the center of the screen, etc ' ...)
is there a good solution for this issue , or should i give it a rest :-) ?
thanks
There is no cross-platform solution for this, mainly because many devices still do not support touch events, that's why iScroll fails on WindwsPhone for instance. I predict native position: fixed; won't be implemented for at least one year (even iOS did it recently, other mobile browsers are way behind; we can expect WP8 with IE10 will support it and some other browsers, but that is not enough). I suggest you keep your toolbar at bottom and keep you page height small enough so people do not have to scroll down a lot - your app will look same on all mobile platforms.
I'm retro-fitting a website for Mobile First Responsive Design (MFRD). My question is - how far do you go with the "Mobile First" part?.
For example - on the homepage I plan on having a list of upcoming events, say 4 or 5. On the mobile version I thought 2 would be enough to save screen real-estate. Should I load the other events in dynamically for the larger views, or should I just hide them since it will only be a few elements anyway?
Loading them dynamically for larger sizes means I have to attach an event to the window resize which typically gets fired every pixel. Even though I can offset that with Timeout, that's still a lot of client side checking is it not (even though it's not like users are constantly resizing their browsers).
I mean, even though you're designing for mobile first, you also have to consider the larger sizes right? Obviously larger JavaScript libraries and other assets that are needed for larger only you want to pull in later and not load for mobile - but how crazy do you want to get with the bandwidth saving?
What is the target market for the website? Are you making a completely responsive website that encapsulates smartphone to desktop? Or are you just concentrating on smartphone to tablet?
Mobile First really just means start your styling and content views at the smallest form factor and work up as the device dimensions get bigger. HTML, CSS (media queries) and jQuery all play a part to expand the UI and manipulate (show/hide) content elements as the browser gets bigger.
Take a look at Smashing Magazine, their responsive layout is one of the most extensive I have seen so far, it will give you an idea of how far you can take the MFRD or DARL (Device Agnostic Responsive Layout) methodologies.