Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Web and WebWorks Development

Reply
Developer
biggerCC
Posts: 270
Registered: ‎12-13-2010
My Device: PlayBook 16GB, BB10 Dev Alpha
Accepted Solution

Prevent out-of-viewport-scrolling

[ Edited ]

Hi guys,

 

my application automatically scales to 100% of the device's width and height. Whereever needed my app embeds scrollable DIVs for larger content.

 

But still: if the user swipes top-down or bottom-up anywhere in my app, the usual (ugly) grey browser-background appears.

This behaviour might be useful in the browser, but not in WebWorks apps, right?

 

So: is there any way to prevent the browser from scrolling out of the viewport? I mean something like the "viewport" meta-tag...

 

EDIT: I'm talking about the PlayBook WebWorks SDK & emulator in the most current version.

- - -
My approved apps @ App World
Developer
ryanmc
Posts: 71
Registered: ‎02-04-2011
My Device: Blackberry Bold & Pearl

Re: Prevent out-of-viewport-scrolling

In my experience it doesn't scroll on a touch move unless it has content outside of the viewport, even if its one pixel out.So if the aplication is 100% then it shouldnt scroll - I did go down this path myself and dont recall having a problem with the page scrolling.

 

If you can't find a fix, and you don't want it to scroll at all put an event listener on the touchmove event and overide the default behaviour.

 

I've found that divs with overflow: auto; are quite buggy, they either scroll at around half the speed of the finger movement, scroll eratically, or scroll in random directions. Hopefully this is a bug in only the current version of the simulator, and future versions or the final released products behave themselves. It's so bad that at one point I was contemplating writing my own scroll handler for these divs but never really looked into it, instead I changed the interface to better suit how WebWorks behaves at the moment.

 

Rather than div's with overflows I would seriously consider a rethink of the interface to better suit the device, if you were thinking of porting the aplication to BlackBerry phones or other companies devices then the embedded div's solution might not work as well as expected.

 

Anyway if you want to go down this route then you need to put something like:

 

document.ontouchmove = function(e) {
    e.preventDefault();
}

 On everything except for the scrolling Div's, you may be able to put it on the body and then reinstate the default somehow on the div's.

 

- Ryan

 

Developer
ryanmc
Posts: 71
Registered: ‎02-04-2011
My Device: Blackberry Bold & Pearl

Re: Prevent out-of-viewport-scrolling

[ Edited ]

Sorry - double post,  I don't know if its just me but everytime I try and post it comes up with an error but seems to do it anyway.

Developer
biggerCC
Posts: 270
Registered: ‎12-13-2010
My Device: PlayBook 16GB, BB10 Dev Alpha

Re: Prevent out-of-viewport-scrolling

Thanks for your promt reply.

 

It seems that the WebWorks browser got something wrong here and interpreted my app too high (whilst Safari, Firefox and Chrome didn't). I fixed it by simply setting the overflow to hidden.

 

I also noticed the problem you mentioned (scrolling DIVs) and really hope, there'll be an fix. It scrolls in the right direction, but too slow... Unluckily there is no other way of implementing several scrollable elements on one page. I don't want the user to "turn pages" or something, not only because this it is advised against in the UI guidelines.

 

Using CSS Media queries I set up two completely different designs. It switches from a two-pane view (for devices with >=800px width) to a single pane view with the navigation at the top and variable page height (normal scroll behavior). It works quite well on my Android and webOS phone.

- - -
My approved apps @ App World
Developer
Heiko
Posts: 125
Registered: ‎01-17-2011
My Device: Playbook

Re: Prevent out-of-viewport-scrolling

@biggerCC

 

Just curious - are you referring to a specific document when you mentioned "...because this is advised against in the UI Guidelines" ?

 

(apologies about posting on solved topic :smileyhappy:  -- but always keen to get good reference links)