Is there something for the Android OS with which you can implement scroll pagination?
*Edit
With scroll pagination I mean pagination like on the homescreen, you can swipe right and left and go to the next or previous page.
You can take example on the source code of Launcher at android.git.kernel.org. Look for the classes called Workspace and CellLayout.
According to Apple, UIPageControl does not implement "scroll pagination", at least how I would interpret that phrase. UIPageControl tracks a number of pages, shows dots based on the page count/current page, and fires events when the user taps it. It does not actually implement "pagination" (you have to handle that yourself) and has nothing to do with scrolling.
All that being said, there is no "show a bunch of dots" widget built into Android with the same or similar API to UIPageControl. Creating one for your application would be fairly simple, using a set of ImageViews, watching for taps, replacing image resources to change dot colors, and firing events to registered listeners.
Related
short version: navigating into a RecyclerView with TalkBack gestures forces you to swipe through every item before you can move on, is that normal? Is there a standard way to navigate out and onto the next element?
I'm trying to get accessibility features working smoothly in an app I'm working on, but I've run into a problem with part of the UI. I'm using RecyclerViews sized so you can only see one item at a time, snapping to the centre, so you can swipe to change the current value from a range. It's basically the NumberPicker approach but directly in the UI, instead of a separate dialog.
The issue is by doing swipe gestures (Default linear navigation) through the UI, as soon as it lands on the RecyclerView, it starts on the current item and then navigates through every single item in the list. It won't exit the RecyclerView until it's hit the last item and has nowhere else to go.
My question is, is this normal? I'm new to TalkBack and I can't find much info on what's expected in every situation. I know my situation is a little unusual (since navigating the RecyclerView implicitly means changing the current item) but just being trapped inside the list until you go through every item seems a really strange way to navigate in general.
I know there are solutions like adding navigation headings etc (which is how the Play Store seems to handle this with their "infinite" horizontally scrolling app selections) but I just wanted to check I wasn't missing something. TalkBack announces "in list" and "out of list" when you tap on/outside of the RecyclerView, so it seems like there should be a way to explicitly navigate in and out with a gesture too...? Would users be used to switching to Controls or Headings navigations to do this?
Thanks! I really want to make this work for everyone but it's hard to know if I've done something wrong, or if I'm just bumping into limitations with the standard components
Use case:
Enable the Google TalkBack accessibility service and navigate to an
app (e.g. Google Messenger)
In this app, assuming that you'll be presented with a list of items
to select, arbitrarily navigate to one of them using Talkback gestures (swipe right or just click once on one of them)
Rotate the screen
Expected behaviour:
The previously highlighted item should still be highlighted; the user
should be able to continue it's navigation
The Google Messenger app is a perfect example of this correct
behaviour
Messenger After rotation
My Sunshine app behaviour:
The previously highlighted item is not highlighted after Screen
Rotation
The user has to navigate again to the previously selected item
Depending on the screen, finding and having an item selected again can be a pain... not what we want to induce to our user
Sunshine After rotation
How should we implement this?
I'm thinking, as a solution, at Accessibility Events and intercepting them... but this doesn't seem to be right, doesn't seem to be "best practice" (e.g. creating a Custom View and implement the methods handling these Events)
! Note that the green highlighted list item doesn't seem to be focused (getCurrentFocused() returns null)
! Note that the list items become focused if we use D-Pad navigation, instead of TalkBack navigation (but this is another discussion...)
L.E:
I've spend a whole day on this, trying to "get the focus" of the
highlighted item, but the item is NOT focused. This is why I assume
that this feature must be tackled in some other way and I would like
to know your (!) experienced opinion before I spend another 2 days
re-creating all the used Android components (as I assume it could be done - this doesn't sound very "best practice", doesn't it ?)
This is NOT a homework, there's nothing wrong with my current code
(so, there's no code to post, unless one would like my whole project)
and, given that this is my first post, I could not attach more than 2
pictures (this is why the "before" screens are missing)
Just give me a good hint, based on experience, and I will implement it and post the finished, working code here.
It should work out of the box if you implement stable IDs in your RecyclerView.Adapter (and potentially disable the ItemAnimator on the RecyclerView (rv.setItemAnimator(null)) which you can do conditionally if TalkBack is enabled).
Here's a blog post I wrote about the item animator bug.
I ran into the same problem while working on the same project.
Hint: listView.setItemChecked(int position, boolean value);
Good luck :)
I want to add a sliding panel view using cocos2d for android. Any suggestions.
The way i've achieved this in one of my previous android market apps for paintball field designing is to have a separate CCLayer class added as a child to the main scene, and have the main scene responding to the CCTouchesBegan. if the location of the touch is within the co-ords of the visible panel, then call a 'touched' method inside it passing the touch co-ords, so that it can deal with it's own content.
On another panel at the bottom I had a button, which showed or hid the side panel, so it didn't 'slide' or support being 'flung' across the screen, but rather was shown or hidden.
Sliding it or flinging it on/off the screen could be written relatively simply i believe, using a combination of CCTouchesMoved and CCTouchesEnded to track the slide/fling and perform translation on the layer co-ords.
There's nothing to have prevented me implementing a slide in/out using some simple animation, but I had no requirement for it in the app, and hence didn't implement it.
Hope this is at least of some use,sorry i can't provide some worked examples right now, busy with work.
I have an app on iPhone with cascading design like on the picture, and I'd like to port it to Android. Is there a simple and recommended way to do this?
The section menu on the left (Section A, B,C,D) is the first that the user needs to select, then the user needs to pick a category in the middle (all, popular, pc, xbox,...), then he is presented with a list of articles for chosen category.
I could imagine doing it with three ListViews, but then the app could also listen to a swipe gesture to make the rightmost ListView "full screen", and hide the first two listviews. I could implement a swipe listener for the whole activity and set first two listviews' visibility to hidden, right?
Are my assumptions correct and would this be the right way to do this?
It could definetly work the way you explain it - if the design is good is another discussion. Personally I'm not a fan of throwing in endless amounts of data in one screen, when the space is as limited as it is on most mobile phones (I would probably do it with 3 different screens with a ListView on each)
Implementing the mentioned swipe gesture is doable and you could certainly just hide the two other ListViews with the function setVisibility( View.GONE ).
Hope it helps.
You might want to use the new fragments API, it's specifically built for this kind of thing (and it's compatible all the way down to Android 1.6). Also, as KasperMoerch says, putting all that info on a small screen can get ugly. Using fragments will make it easier for you to gradually increase the amount of information displayed as the screen size increases.
I'm not sure you can just listen for a swipe gesture over an entire activity like that. I think you have to wrap the fragments in a custom view (for example an extended LinearLayout) and do the swipe listening there. However, achieving a finger-tracking animation (i.e. where the rightmost pane follows the finger precisely as it swipes across) is a pretty daunting task (I wouldn't really know where to begin, probably in the custom view though). The best way (I think) to do it is to make a compromise and just start an animation (right-to-left slide) when you detect a swipe. However, the simplest solution is to not animate at all.
You can also take into consideration dropping the swipe gesture altogether and just providing an "expand" button.
I am writing a PhoneGap app on Android. I am trying to stay pure HTML+CSS+JS, without calling specific PhoneGap APIs. So the app is somewhat an embedded web page, more or less.
The page has some "buttons" on it, which are actually table cells with some CSS attributes (among which cursor: pointer) and an onClick function.
I have noticed that when I touch a button, it "flashes" for a second or so, then its corresponding action is performed. By the way, I don't like this very much, since it causes a delay in the UI.
Some of the "buttons" activate a menu. I handle the menu by making visible a semi-opaque black div that covers the whole screen, and above it a centered div containing a table containing the menu items. (the black div and the centered div are hidden, normally).
The problem is that when I touch a menu item, it does not flash; one of the underlying buttons flashes instead (that is, one of those that at the moment are covered by the semi-opaque black div, and are supposed to be inactive). Nevertheless, the correct action is performed, in other words the onClick function of the menu item gets called, not the one of the flashing button .
So my question is two-fold:
1) Is there a simple way to make the right item flash (I mean the menu item instead of the underlying, semi-covered button)?
2) Is there a simple way to totally disable button flashing, so that the UI would speed-up and problem 1 be solved too?
Many thanks
You should be using the touch events, which are supported on Android WebKit. This will prevent the select + touch behaviour that you're seeing on your HTML elements that the onClick event causes.
Android versions past Android 1.5 support touch events such as touchstart and touchend. I recommend using them, and reading Apple's documentation (yes, I know it's weird, but Google's Web App documentation is still poor with respect to touchevents.)