I am working on some online shopping application. In this, we have Update Remove quantity buttons to manipulate cart quantity.
This works fine in normal flow. but when accessibility is enabled, It got quite complicated as user needs to go back and forth on plus and minus buttons to adjust the quantity after that user needs to remember to hit Update and Remove buttons.
I was thinking of a solution if we can override "SWPE_UP" and "SWIPE_DOWN" gestures after some view clicked so that the accessibility user can easily manipulate quantity by swiping up or down and once the quantity is set, respective buttons can be clicked programmatically on double tap.
I have gone through some articles and searched behavior in similar apps, but couldn't find enough reference material. They won't have similar problems as most apps don't have Update or Remove buttons.
If anyone can help me to find a solution or provide some reference material then it would be a great help!!
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 have an action bar with a button to flip between two different views (list and tree). Should the button show (a) the current view or (b) the view that will be shown if the user clicks the button?
This is an age-old UI problem with no "right answer", only UI standards, so I'm trying to understand if there's any standard on this in Android.
I agree on the 'age-old' part. Myself I'm still questioning - when acting as a user, not a developer ;-) - what the button in front of me will do when I click it: turn on Shuffle or turn it of.
Now very pleased to come up with a feasible answer.
Since the user has a clear visual clue on the state the current presentation is in (List or Tree) the button would show the alternate option. Then the user knows that there is an alternate option and hopefully the button displays where it will take the user.
For more unclear situations I would still go with this approach. The user either knows or perhaps can deduce the current 'state' of the app ("hey it plays a whole different song now, so it is in shuffle"). So the button will bring me to another state, the one displayed.
Why display what the app is already doing and not displaying where a buttonpress will take the user?
Please don't delete it because its a duplicate. I am an android developer with little experience. I have an app with 2 screens. The first has a bunch of options in a TableLayout each selected using a RadioButton.
What I want to do is, when I select one option and click a Button which appears below, the View should switch to the next screen showing some related data and when a Button is clicked I want it to come back to the same screen but then the rest of the options should be available to me so as to repeat the same process with another one of the options selected.
In short I want to be able to maintain the state of the first screen. I can't seem to be able to decide between using ViewSwitcher, ViewFlipper, or multiple Activities or using a single Activity which is what I am doing right now. But as my app gets bigger its very difficult to handle it. Please suggest the best way to do this. I am confused and desperately in need of help because my job depends on it. Thanks in advance
Use 2 activities. Launch the 2nd activity when the user clicks the button. When the user clicks the "back" button (or some other button you offer him) the 2nd activity finishes and the first activity (which was underneath it) is shown.
Note: You've not given us much information, so I can't guarantee that this is the best solution. From what you've said this is the solution I would recommend though. As they say in advertising "Your mileage may vary" ;-)
I apologize if I'm just missing the obvious. I'm fairly new to Android development, and while I searched for this particular topic, I wasn't exactly sure what to look for (in terms of a "name").
In an application I'm writing, I have a section where the user can enter the names of players. However, this can range anywhere from 1 to whatever, no limit. However, I'm not sure what the best approach for this kind of feature is, or if there's a component that already does something like it.
Basically, the functionality I'm looking for is similar to what you can see in the Edit Contact screen of the phone book; for the phone numbers and email addresses, you can push a little plus button to add a new number/address, or hit the little minus button to remove a number/address.
I can think of several ways to potentially implement this, but in the end I think wrapping it in a custom component would be best (so that you could call "Get Players" and have it return a list of strings by going through each of the inputs and getting the values).
Am I just overthinking this? Is there a component that does that already? Is there some example code that demonstrates a good way to do this?
Thanks!
Could you just use ListView and add a menu with a "Add Players" option? You could customize the list view to have a little checkbox, for example, and then begin the game by pressing the menu ... or add new players dynamically by pressing another menu button.
After playing around with some ideas, I came across a solution that I think will suit what I'm doing. I created a custom component extending LinearLayout. As part of the creation of the component, it creates a row that says "Add new..." with a plus-sign button. Pressing the plus sign button then creates a new row containing an EditText and a minus-button which will remove the row.
I then created a method for this component called getTexts() which returns a List that has all the non-empty Text values from all the components. Testing it in a dummy app, it seemed to work fine.
I think I need to make tweaks to make it more robust (like the ability to add rows programatically, listeners to alert other components when a row is added/removed, and the ability to set the individual EditText values, for instance), but this functions as I imagined.