Copy link to clipboard
Copied
I think it would be a great idea to implement the smooth scroll present in native iOS and Android applications for use in Adobe AIR projects.
Currently, the only way to obtain smooth scrolling lists with images is using StageWebView to show the image list in HTML format, and then awkwardly implement some JavaScript / AS3 communication functionality so the list in the StageWebView is interactive and can communicate with the main program. This is excessively complicated and very error prone (I've found some inexplicable JavaScript errors that only happen in the iPad, not in Android, and not in the PC!).
It would be way better to be able to skip all the StageWebView process altogether and being able to use a simple AS3 API to put any sprite/movieclip into a scrollable canvas which can be moved using the iOS native scroll.
Using Flash animation to simulate the scroll in a list with images is too slow in the iPad and gives a bad user experience. iPad users expect the native iPad scroll, not some poor jerky simulation. A native scroll is the only way to go.
And even though I talk about the iPad, this should be applicable to the native Android scroll, too.
Scrolling is a VERY BASIC action in a tablet, so this should be implemented as soon as possible.
Actually, I'm amazed we're already at AIR 3.0 beta, and still after all this time nobody thought of this. All sorts of fancy stuff is being added to AIR (hardware accelerated video, webcam and microphone access, etc...) but still something as basic and important as a smooth scroll, which every tablet user expects, is still not possible in Adobe AIR. We either have to implement some slow Flash animated scroll, or use the extremely complicated StageWebView with JavaScript/AS3 communication approach (I'm using a third party library called StageWebViewBridge for the JS/AS3 interoperations, which is great, but still, it's a far from ideal solution, since it's pretty fiddly and the JavaScript code doesn't always work properly in iOS).
Copy link to clipboard
Copied
Thanks for the suggestion, I agree that this sounds like a nice thing to have. Would you mind adding this to bugbase.adobe.com and posting back with the URL? I'd like to encourage others interested to add their votes and comments.
Thanks,
Chris
Copy link to clipboard
Copied
It's great to hear you find this a good idea
The lack of a native scroll is one of my biggest frustrations with Adobe AIR, and I've already lost countless hours with the workaround StageWebView implementation, which still is giving me some problems.
Here's the "native scroll" feature request at bugbase:
https://bugbase.adobe.com/index.cfm?event=bug&id=2958123
I hope more developers get interested in this.
BTW, I think StageWebView should implement easier communication with JavaScript, like the one provided by the third party StageWebViewBridge library (http://code.google.com/p/stagewebviewbridge/), since most of the times you need a StageWebView, you'll also need to add some interactivity with the AIR application (except if you just use it for HTML banners/admobs).
Copy link to clipboard
Copied
I too think a Native Scroll is a needed feature. my experience ...
my2cents!
Copy link to clipboard
Copied
hiteck7 wrote:
I too think a Native Scroll is a needed feature.
Then, please vote here
https://bugbase.adobe.com/index.cfm?event=bug&id=2958123
Still 0 votes so far...
- I am using Air 2.6, CS5.5 (tried AIR 2.7, however I lost some key features in a particular IOS app that I made and reverted back to 2.6)
What features are missing in AIR 2.7 that were present in 2.6? The only thing I noticed is the Menu button in Android Honeycomb, which is missing in 2.6 (as far as I can tell). It's worth to upgrade to 2.7.1 because of the much improved performance in CPU mode compared to 2.6. If you're using Flash animated scrolls (instead of native SWB scroll), then 2.7.x is much better than 2.6 in that respect.
- came across your notes on StageWebViewBridge and considered that until I noticed
- on a new Galaxy Tab 10.1 Android Honeycomb, StageWebView actually jerks. I notice this on my apps and on other people's MarketPlace apps
That's odd. StageWebView just uses an embedded object with the native browser (Safari in iPad or the Chrome-based Android Browser in Android). It should behave the same way as the original browser. I've tried SWB in an Acer Iconia Tab A500 and the scroll is perfect. Are you showing the SWB with a delay? (waiting for the page to load before assigning the stage or something like that).
- as a result I would wonder if the StageWebViewBridge would be equally problematic for me...
Well, StageWebViewBridge works as a layer in top of StageWebView to add interoperability between AS3 and JavaScript, but the display is still a StageWebView component, so it has the same advantages and shortcomings that a regular StageWebView could have.
Copy link to clipboard
Copied
again, hopefully something simple here or maybe the 2.7.1 will do the trick. thanks, your consideration is appreciated
Copy link to clipboard
Copied
hiteck7 wrote:
- did the vote, reiterating some of what you said as you were pretty succinct in your words.
Thank you!
Too bad nobody else has bothered to vote
hiteck7 wrote:
every time I google the 2.7 features it says improved performance in IOS only, no mention of Android. My single IOS app works fine at 2.6, just the StageWebView is not perfect in Android. I use CS5.5 where 2.7 is not an option in the Player List in order for me to easily jump back and forth between versions.. i would think that it will be easier to do this, jumping between versions in CS6..
You can switch to AIR 2.7.1 easily by closing Flash and substituting the contents of the folder AIR2.6 (inside Flash CS5.5 folder), then reopening Flash.
I have several folders created so when I need to change AIR version I just have to rename AIR2.6 to something else and then rename my AIR2.x or AIR3.0beta folder to AIR2.6, so Flash sees it (the AIR2.6 folder is located at "C:\Program Files (x86)\Adobe\Adobe Flash CS5.5"). Latest SDK is available from here: http://www.adobe.com/products/air/sdk/
hiteck7 wrote:
I would be really curious though if your Android SWV web page bounces at the top and the bottom showing a significant dark space, per the default browser, since this is a hard-to-miss noticibly objective difference that I see (and is fine on IOS SWV web page) do note that I thought my SWV Android scroll was perfect until I did it side by side with the SWV IPAD, and I'm certain most people would never notice unless they critiqued it as well.
Well, the scroll bounces in iOS, not in Android 3.0. But that's because in Android 3, there is no bounce in the browser, but a transparent blue gradient that appears when reaching the top or bottom of a page. The scroll in Android in general (even in the real browser, outside AIR) is not as great as in iOS but it's good.
hiteck7 wrote:
thanks, your consideration is appreciated
You're welcome
Copy link to clipboard
Copied
I've been doing more comparisons and checking other peoples' scrolls on IOS and Android and I am definitely leaning towards using SWV as a decent workaround to not having a native scroll, and a definite need for a native scroll. At least with IOS IPAD everyone has the same experience but even there I see very, very poor non-SWV (AS3) scrolls, while the SWV scroll on IPAD is forever good. I'm unsure why you don't see that large dark IPAD type bounce on your Android default browser, but you're right in that all I get on the Android SWV is that blue gradient. Then again, when I jump over to my Dell Streak, the Android default browser has NO apparent bounce so I kinda throw up my hands on what's going on. I did notice that we must turn on the hardware acceleration in our Android app [android:hardwareAccelerated="true"] to see Flash in SWV [Honeycomb only - see AS3 reference for SWV] so I tried that thinking that might do the trick to make the browser performances line up, but the performance was the same (though Flash did get enabled). I have to wonder though is there something else, maybe another simple variable, that has to be turned on to make them line up.
Anyways, I've been comparing very busy web pages where the performance lag is obvious... As I do my own simple web page, I'm thinking how it really does look/feel pretty good, especially as I customize the look of my list, and should be fine for now so I think we are pretty much on the same page (thx for 2.7.1 instructions, probably did similar in past but did not document)
Copy link to clipboard
Copied
Well, I might be wrong, but as far as I know, Android has never had any bounce effect at all in its applications.
In Android 3 (Honeycomb) you get the translucent blue gradient effect and in Android 2 you don't get any effect at all, but in both of them you don't have any bounce effect, not only in AIR+SWV, but in the regular plain web browser as well as any other app, there is no bounce effect in scrolls. That bouncy effect an iOS thing (I haven't tried WebOS or Blackberry, so I can't tell about those platforms).
BTW, I still don't understand is how could the guy in this video create a list with 100.000 items in AIR:
http://corlan.org/2011/06/15/adobe-air-2-7-is-out/ (minute 0:40)
Copy link to clipboard
Copied
wow, that video suggests I may be out of the game in CS5.5 except for my workaround,... i'm guessing that a Spark List Control in Flex can smooth scroll although quick googling finds Blackberry developers having a bit of problem with it. being unfamiliar with Flex doesn't help.
definitely an IOS style 1"+ dark grey bounce on my TAB 10.1 default browser
can someone at Adobe point to a similarly perfect app in the Android marketplace (or post an apk file for us to install and test) and the methodology?
Copy link to clipboard
Copied
hiteck7 wrote:
i'm guessing that a Spark List Control in Flex can smooth scroll although quick googling finds Blackberry developers having a bit of problem with it. being unfamiliar with Flex doesn't help.
If you find something interesting about that control, please get back to me. For now I'm sticking with StageWebView. Awkward as it is, having to use a HTML+CSS+JS page inside an AS3 application, it works pretty fine when the 3438753485738457 quirks have been ironed out . But still, a component for native scrolling is a much needed API in Adobe AIR. I hope the development team decides it's a good idea to implement that at one point.
hiteck7 wrote:
definitely an IOS style 1"+ dark grey bounce on my TAB 10.1 default browser
I'm guessing that's an added touch made by Samsung, so it works similarly to its competitor, the iPad. But plain vanilla Android distributions don't have that, I think. Probably, that's why when you use the native browser component in AIR through StageWebView, you don't get that effect, and get the default blue shade effect instead.
Copy link to clipboard
Copied
"The only thing I noticed is the Menu button in Android Honeycomb, which is missing in 2.6 (as far as I can tell)"
This is still an issue in AIR SDK3....unfortunately. Now I need to add in a menu button for tablet devices, so disappointed this was not caught in QA.
Copy link to clipboard
Copied
And apparently it's because they "NeedMoreInfo", as stated in the bug report status. I think we were more than sufficiently clear. What more info do they need?
Copy link to clipboard
Copied
It is driving me nuts that something so crucial for Android is missing. If they even tested the few templates they offer in Flash for Android on 2.X and 3.X, they would have discovered it. One example is actually called "Options Menu".
Wonder if there is a native extension work around for using the real android menu.
Copy link to clipboard
Copied
I added a swf and fla file for them to ADT compile in different versions. Been posting everywhere I can. 2.7 didn't have really any features I cared about but 3.0 has a few.
Copy link to clipboard
Copied
OMA2K: Have you tried:
http://thanksmister.com/2010/10/14/android-as3-scrolling-list/
or for larger data sets:
https://github.com/thanksmister/as3recyclelist
I have got both working and they are pretty well done. The only issues I am having is updating the list as my array changes.
Copy link to clipboard
Copied
This is getting really annoying.
Copy link to clipboard
Copied
@Kipup - are you referring to the menu button (thread seems to cover a few things). I did get an answer on that from Adobe and if you want the menu key, you need to target earlier versions of Android in your manifest file. If you target Android 3.0 or higher API's, there is no menu key anymore so it won't display.
Copy link to clipboard
Copied
Thanks Mola2Alex. It's the entire thread itself. I've been looking at so many scrollers and can't get anything reasonable. The Flex scroller Renaun showed looks too smooth to be true! Like a special effect as it were. All I need is a scroller! I'm 100% flash-based so no flex at all. What can I do?
Copy link to clipboard
Copied
From a list perspective, the one I used a couple posts above worked well for me and I used it in flash pro. It is pretty smooth on my apps.
Copy link to clipboard
Copied
You're amazing Mola2Alex! Please which would you recommend for a list with photos? The text in the scrolling list is device fonts.
Thanks in advance.
Copy link to clipboard
Copied
You could try either of them. You would need to change the cellrenderer to one that contained images but no reason why it shouldn't work.
Copy link to clipboard
Copied
In my experience, the only way to have perfect 100% smooth scrolling in the iPad is using the StageWebView component, but you then have to generate your list in HTML+CSS and then implement some JavaScript code that communicates from HTML to AS3. For this job, the library StageWebViewBridge works quite good, but is not really straightforward at all.
Inside Flash you can use a technique used "blitting", to scroll by painting pixels in a canvas. You can capture a sprite and then scroll through it using blitting (you can find a video by Lee Brimeow explaining this). I haven't tried this but it should be pretty fast, but you have to implement some extra calculations to know which item in the list you've pressed, plus you have to account for the press events and the scroll events in such a way that you can do both scrolling and pressing. And still, this might not be as smooth as a StageWebView.
Both setups are ridiculously complex to implement. AIR must be just about the only mobile framework that requires such complex stuff for a really basic action such as scrolling, which in any other framework it's just taken for granted without having to implement anything. There should be an API to implement iOS and Android native scrolls with any DisplayObject. I hope they finally implement it, since this must be the feature request with the most votes:
https://bugbase.adobe.com/index.cfm?event=bug&id=2958123
Please also vote here as well:
Copy link to clipboard
Copied
OMA2k wrote:
Both setups are ridiculously complex to implement. AIR must be just about the only mobile framework that requires such complex stuff for a really basic action such as scrolling, which in any other framework it's just taken for granted without having to implement anything. There should be an API to implement iOS and Android native scrolls with any DisplayObject. I hope they finally implement it, since this must be the feature request with the most votes:
I love how you put it: "Scrolling is taken for granted on other frameworks". Go figure, Adobe! If you can't scroll then, what else can you do on a mobile app?
Copy link to clipboard
Copied
I hear you guys on this one. I'll make sure to bring this up again at our next team meeting.
Chris