I'm trying to figure out how to enable vertical scroll for an Android widget.
From what I read in the documentation and this post it's possible to do that only from Android version 3.0 and up.
However, I saw a phone (Motorola Razr) with Android version 2.3.6 that had a Gmail widget with a vertical scroll.
So I can't understand if it's possible or not? And if it is possible, how to implement it?
Manufacturers generally build out Android from a custom version of AOSP. Since the entire source for Android 2.3.x is available, it is quite possible that Motorola simply added support for scrolling widgets by modifying the source for their own devices (potentially using the same techniques that AOSP 3.0 does). And if this is indeed the case, that will require changes in the underlying operating system and hence will likely not be available to you if you are building the widgets using the SDK.
If by widgets you are talking about ? extends widget.View, you can always build you own View that does vertical scrolling.
This envolves parsing onTouchEvent (and probably onDispatchTouchEvent) and a lot of math.
I did it myself at work.
Related
I am going to create an app for devices with Android OS 2.1 and higher. As many developer I met layout problems and after reading about that in the official android documentation I decided to follow a way; I created 6 directory one for every screen density (ldpi,mdpi,hdpi,xhdpi,xxhdpi,xxxhdpi). What I want to know is if I did it right, I know that layout could be not exact at 100% but could I'll meet serious problems doing that?What I should do?
The second problem is checking app in many devices in the same time, I use Android Studio and I am able to create devices and use emulators but there is a plugin or a website or something else I can use to test quickly the app in tens of Android devices without set all manually?
Thanks in advance!
My problem is described in the following.
I recently developed a Phonegap app (Android and Ios are the target platforms) and deployed it on the markets. My app mainly consists in an event list.
The list is obviously scrollable. The purpose is to give a native feeling experience to the users or at least something close to it. Actually, I would like to enable inertia for most users (everyone would be awesome!).
The app can’t be downloaded by android < 3.0 phones, so it doesn’t matter if the solution excludes android 2.X users. In addition, for the moment the app is not design for tablets so I don’t mind if the solution doesn’t works with android < 4.0.
I use the following CSS property on the scrollable div:
overflow: scroll;
-webkit-overflow-scrolling: touch;
On Ios, there is absolutely no problem. It is fast and inertial scrolling is enabled.
With Android, I'm still having problems with some phones. Here are my tests:
Nexus 5 (Android 4.4) : inertia Ok
Sony Ericsson (Android 4.0.4) : inertia Ok
Samsung galaxy Trend (android 4.0.4) : inertia Ok
Samsung Galaxy Note 3 - SM-N9005 (Android 4.3): No inertia
Samsung Galaxy S4 (Android 4.3): No inertia
I don’t’ use any JavaScript library for scrolling (for example Iscroll ect…) and I don't want to do so except if it is a really lightweight librairy. In fact, I have tried Iscroll and the result is unusable because it is too slow and jerky. By the way, the event list contains gradient, images, text, shadow ect…
I have done a lot of research on the internet. And now, I feel lost!
I even don’t know if the problem is related to:
The manufacturer layer
The Android version
The default browser on the phone (I think not because it appears
that Phonegap doesn’t use it)
The embedded PhoneGap webKit rendering engine
Deprecated CSS properties : see this article
Something else?
It is a bit weird because it works on 4.0.4 and 4.4 but not on 4.3… I start to think this is related to manufacturer…
Any help, solution or information about the above would be really appreciated.
Not sure if you have solved your problem yet, but I just came across this issue.
I was using Hammer.js to detect drags for the sidebar, within doing so, I called preventDefault() which affected scrolling inertia in the android default browser, but not chrome. Removing that call fixed the issue.
I had the same problem. I looked into it for quite some time and the only solution I know is using a scrolling library. The best one I found is Overthrow: http://filamentgroup.github.io/Overthrow/
Cool thing is that it uses native scrolling whenever it can and only reverts to javascript when needed. Even works for me on old Adroid devices, while keeping that native scrolling feeling on iOS.
I developed an application for android using jquery mobile and phonegap.
I deployed the app to my device over usb. The performance of the app ist really bad, especially while scrolling a longer list.
The strange thing is: The whole app runs smooth if i just open up the browser on my phone and access the index.html directly. Same technology, same content. I do not use the phonegap native api or anything similar.
Tested with phonegap 1.5.0 and 1.7.0rc1, jquery mobile 1.1.0 on android 4.0.2.
Any ideas?
On honeycomb (3.0), Ice cream (4.0) and posterior devices, you can boost performance by adding the following in the < Application ... > tag:
android:hardwareAccelerated="true"
You could set the minSdk to 8 (Android 2.2) for compatibility and the targetSdk to 15 (Android 4.0) and that would make hardware acceleration work when its available on the device only.
I believe that with this flag the performance of my apps is equal to running them in the browser, so I guess its because the browser was coded with hardware acceleration :)
I had a similar problem: a page with a longer list of "medium complex" themed divs. The browser of HTC phone had no problems in displaying. But within the phonegap app rendering failed completely. I saw a kind of WSOD, which disappeared only after touching the display. After touching, the page was displayed correct.
The problem was not in place, when I shortened the div-list to one or two div-elements or when I reduced the sub elements within the divs and reduced the render effort caused by the css complexity.
The white screen looked like, if the whole body was invisible, since only the documents background-color was displayed (I added a light pink for this). So I guess, the rendering was the problem after reading this thread
I tried the various proposals I found in this thread to make the app work without the "WSOD". But nothing worked. Some of them made the app displaying really worse.
Finally, after a whole day of searching, I made it. I set within the tag (not the tag) of my AndroidManifest
<application android:hardwareAccelerated="false" ...
Now the app behaves in the same fast way as my webbrowser. Seems like, if hardware acceleration is not always the best feature...
My versions:
phonegap 3.5.0, Android 4.0.3, jQuery v2.1.0, HTC Sense 3.6
Found an answer here: http://groups.google.com/group/phonegap/browse_thread/thread/94da1cf881abe995/6d4f7aea7aeba523?lnk=gst&q=performance
There is probably a difference between the native browser and the webview in terms of javascript performance.
If you can confirm the browser performs better (that it's not something suboptimal in your code frustrating one but not the other), you could consider deploying as an html5 offline application so that you will actually run in the browser.
We bumped into performance issues while scrolling the same amount of list items with jquery mobile. The performance was so poor (we didn't even try in PhoneGap environment) that we rewrote the app using iScroll library... now the app scrolls really smoothly.
If you are at the beginning of the development, you could try to change the UI library.
After this situation we deploy our apps to test devices quite often to manage performance issues in time... this became a "policy" :)
The Android Browser can't scroll inner divs. That means using SlickGrid with its default configuration is impossible.
Fortunately, SlickGrid has an autoHeight argument that makes it not use inner scrollable content, so it works on the android. Unfortunately, when autoHeight is enabled, onViewportChanged gets called once to span the entire viewport and is never called again, so it attempts to load all the data at once. I'm lazy-loading and displaying so much remote data that if you try and load it all at once it crashes mobile devices, so that's a no go.
If SlickGrid were smart enough to know what's on the screen even if autoHeight is enabled, that would solve my problem. I'd love it if that was a feature in core, since that would solve many problems on the desktop as well as on Android devices.
I also tried using iScroll 4 to get around the Android limitation. Unfortunately, it doesn't trigger onViewportChanged at all when I use iScroll.
I will probably have to solve this by ditching or modifying onViewportChanged to handle my own scrolling events. I was wondering if there is an existing solution for this though.
I ended up writing my own version of slickgrid for this purpose. Also, this will become irrelevant when Google Chrome becomes the default browser, as it actually has decent support for scrolling.
I would not recommend using SlickGrid for apps/pages targeting mobile devices. The grid was not developed with mobile devices in mind. They require a completely different approach optimized for that particular use case.
I'm working a personal project that's going to include a home-screen widget updated with information from a service - I'm developing using a Android 3.1 tablet (physical) as well as an Android 2.3 emulated phone.
For the Honeycomb version, I'd like to use the StackView, building up 3-4 pages which the user can swipe through, whereas this isn't supported on pre-Honeycomb devices, so is there an easy way to
have Honeycomb devices use a StackView but have Gingerbread/earlier use a TextView (I think this can be done by using res/layouts-v1{1,2,3,4}
Have the RemoteView detect which it is and clear/create the StackView items or set the text on the TextView
You can indicate different layout for pre and post Honeycomb by using the v11 qualifier in your layout names. You can also use the Build class to detect what Build version you're running on and then load the appropriate layout.