I have a preference that represents some complex notion.
I'd like to explain it, and the explanation is a bit long.
When I add the explanation to the summary of the preference it gets cut off.
Is there a standard for Android having long summary/description/explanation?
Thank you.
You could create your own preference widget: http://developer.android.com/reference/android/preference/Preference.html#attr_android:widgetLayout
I couldn't find any standard for long settings explanations.
My solution
I set the summary to be the value chosen by the preference and added a dialog with a long message to explain the chosen setting when it is chosen.
This kind of keeps the settings UI standard without the need to custom the standard preference layouts.
Material design says that you should make the preference open a separate screen that includes the description:
Settings that require longer explanations may add a description on a second screen.
Underneath the label, show the status text of the switch as "On" or "Off.”
Add the switch itself and a longer description to a second screen.
For an example of this, go to Settings -> Accessibility -> Magnification Gestures.
Related
I have a button in Android which has text "Next" written on it.
when, I have the accsessibility cursor focus on the button, it reads out "Next button". This is something I don't want. I want whenever, the cursor to have focus on the "Next" button, it must read out as "Next button. Double tap to select". This I can easily do, by setting the
btn.contentDescription("Next button. Double tap to select"),
but then it reads out as
"Next button. Double tap to select button", means it additionally reads out the last button, which seems very odd, with the "button" text getting read twice.
Is there any way, by which I can stop the last button to be announced?
You're trying to do things that are the responsibility of the AT. The AT knows that the object is a button due to its class type. The AT knows that it is clickable, because Clickable is a valid accessibility action.
TalkBack will then share this information, here is the breakdown:
"Next button, (pause) double tap to select"
"Next" -> Content Description/Text. This is the part you control.
"Button" -> Calculated in TalkBack based off of the valid actions and type(class) of the object.
"Double tap to select" -> This announcement is based off of Clickable being a valid accessibility action.
SO, when you set the contentdescription to "Next ....." you end up with an announcement of "next ....... button (pause) double tap to select" and no, there is no way to override this.
IF you are absolutely intent on making your app less accessible, you could create a custom control, write your own gesture recognizers (as in not using "onClick" events, because this would make your element accessibility clickable) to recognize tap gestures. And then write your own content description, that includes name, role, and instructions yourself.
This would be very silly in my opinion! Just let the content-description be "next" and let TalkBack tell users that your element is a button and how to interact with it. While perhaps not the "perfect" wording you/whoever this requirement came from's vision. It will be the way TalkBack users are accustomed to having this type of control announced. Consistency is sometimes more important than having things "just so".
I know I'm way late to the game, but posting an answer here for anyone that may happen to come across this post.
The others are right... we should not be putting the type of widget or how to interact with the widget in the content description. However, all is not lost.
Starting with API 21, there is a way to customize the interaction text through AccessibilityNodeInfo. You can use this class in two different ways:
AccessibilityNodeInfo has a getActionList() method. You can add customize the text that is read out by TalkBack by adding a new item to that list:
info.getActionList().add(new AccessibilityNodeInfo.AccessibilityAction(AccessibilityAction.ACTION_CLICK, "select");
The above code should change "Double-tap to activate" to "Double-tap to select". I say should because I'm just writing that code from memory... I haven't verified it's 100% correct, but it should be something along those lines.
There are two ways to utilize that class, and the one you choose is going to depend on your situation.
Method 1: Subclass your view:
If you create a subclass of the view you are using (in the case of the OP it would be a subclass of Button) then you can override the onInitializeAccessibilityNodeInfo() method and put the code there.
Documentation: https://developer.android.com/reference/android/view/View.html#onInitializeAccessibilityNodeInfo(android.view.accessibility.AccessibilityNodeInfo)
Method 2: Create a view accessibility delegate
This can be a bit more tricky and involved, but it does offer a ton of flexibility because you don't have to subclass the views you are working with.
Every view has a method that allows you to set an accessibility delegate, which acts like a man-in-the-middle and you can tweak things for accessibility purposes before the info goes to TalkBack.
Documentation: https://developer.android.com/reference/android/view/View.html#setAccessibilityDelegate(android.view.View.AccessibilityDelegate)
So basically you create a subclass of View.AccessibilityDelegate and override it's onInitializeAccessibilityNodeInfo() method with the code I posted above.
Documentation: https://developer.android.com/reference/android/view/View.AccessibilityDelegate.html#onInitializeAccessibilityNodeInfo(android.view.View,%20android.view.accessibility.AccessibilityNodeInfo)
Last but not least...
I did come across a way to stop the "Double tap to activate" text from being spoken out by Talkback. This should only be used when it really does make sense to remove it.
I repeat... this is not normally something you want to do.
I did recently come across a case where it made sense. I was using a TabLayout, and I noticed that Talkback would always read out "Double-tap to select" when the focus was on the selected tab (yes, I had used the method described above to change the text). Well... we don't want to tell the user to select a tab that is already selected, especially when the action results in a no-op. So, I used this little trick to get rid of that, but only for the currently selected tab. I left the unselected tabs alone so that Talkback would still give them the interaction text.
In your onInitializeAccessibilityNodeInfo() method, you can put the following code to remove that text:
info.addAction(AccessibilityNodeInfo.ACTION_FOCUS);
Again, I'm writing this code from memory, so I don't know if that's 100% there, but it gives you the gist of what to do.
Try to uncheck the setting in TalkBack -> verbosity -> speak element type -> uncheck. Now talkback will not announce class type of view at end of content description.
What you want to do is employ android:hint to provide information on inputting information (instead of adding it to the label).
Your label would be "Next" (either using labelFor with an onscreen label or android:contentDescription for hidden labeling)
Then your hint would be "Double tap to select" (using android:hint)
Following Android's design guidelines, I ran into this part https://developer.android.com/design/style/metrics-grids.html, where they use a view that I believe is a Spinner in order to show and possibly select the date.
Please guide me in the right directions as I'm not 100% sure this is a Spinner, and also, checking the Calendar app, it seems once you click on it, a DialogFragment pops up, with a single DatePicker (or TimePicker for the hours), but I am not 100% sure of this either.
Thanks in advance
Take a look at the docs, you can specify the Spinner mode. Whether you choose to make it a dialog or dropdown is up to you. Either way, you don't have to worry about setting the value after user has selected it.
http://developer.android.com/reference/android/widget/Spinner.html#MODE_DIALOG
I checked different options that are available in PreferenceScreen (eg. CheckBoxPreference, EditTextPreference, etc.) but non of them give me the possiblity to obtain a simple dialog with just 2 buttons. I would like to use it to implement a basic “Yes, reset my app” / “Cancel” features. How to make this preference option easily?
Its tricky check this answer.
Well I've implemented EditText Preference which shows 2 buttons ok and cancel but in middle there is Edittext.
In my Preference activity, say I have two checkboxpreference. If I select the first one, the second one is enabled, but if I deselect the first one, the second one is disabled.
My question is, if the first one is deselected and someone clicks the disabled second preference (it's greyed out), is it possible to attach a hint to it when disabled to tell the user that they must first select the above preference in order to enable the second one?
I looked in the Preferences API, but could not find anything to match this requirement.
Any tips?
Thanks!
Use the preference's summary as your hint. This will provide some text below the checkbox and its title in smaller print.
By xml:
http://developer.android.com/reference/android/preference/Preference.html#attr_android:summary
By code:
http://developer.android.com/reference/android/preference/Preference.html#setSummary(int)
In the system-wide search on my HTC Desire (Froyo), I see a little drop down left to the search input field that allows to select where I want to search (All, web, apps).
How can I implement this in an application of mine? The search tutorial on the Google developer site does not address this.
So in a scenario like the following, taken from the Android docs,
I would like to click on the books and then get some sort of menu to e.g. select "words", "headings" as search mode.
Update: I am not looking for the QuickAction dialog itself, but rather how to attach something to the books icon that reacts on touch, so that I could attach the QuickAction or a new activity or ... And I want to use the standard Android Search Dialog as described in http://developer.android.com/guide/topics/search/search-dialog.html
You can't modify the system's search dialog. So if you want customizations like making a drop-down menu appear when the user touches the icon, you'll have to implement your own dialog. This would make your search non-standard so I wouldn't advise it.
However, if I can't talk you out of it, you can see how Android's built-in search dialog is implemented here:
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/app/SearchDialog.java
In Android 3.x this gets a little easier with the introduction of the SearchView class.
It is just a custom view that get rendered when you hit that button with a fancy animation.
It has nothing to do with the search framework per se. You just show a custom layout (with a fancy animation if you want) and set a value by clicking on one of the icons. Thats it.
I think what your looking for is called a "quickaction dialog".
Here's a tutorial that should have you well on your way.
Updated by question asker (paste of comment):
ah i see. well somehow you need the id of the icon in order to implement the onclicklistener(). you may be stuck just going with a search widget and implementing most by scratch. Or perhaps, with the search dialog implemented and running, use hierarchyviewer to see if the icon has an id. Maybe you'll be in luck and it'll have a unique one. I'm out of ideas for now.
Those options (and their icons) are determined by the searchable items list in the android settings (Settings->Search->Searchable items at least in my phone). If you want to add a search action to that menu, take a look at this:
http://developer.android.com/guide/topics/search/adding-custom-suggestions.html#QSB
Enabling suggestions on a device
When your application is configured to
provide suggestions in Quick Search
Box, it is not actually enabled to
provide suggestions in Quick Search
Box, by default. It is the user's
choice whether to include suggestions
from your application in the Quick
Search Box. To enable search
suggestions from your application, the
user must open "Searchable items" (in
Settings > Search) and enable your
application as a searchable item.
Each application that is available to
Quick Search Box has an entry in the
Searchable items settings page. The
entry includes the name of the
application and a short description of
what content can be searched from the
application and made available for
suggestions in Quick Search Box. To
define the description text for your
searchable application, add the
android:searchSettingsDescription
attribute to your searchable
configuration. For example:
http://developer.android.com/guide/topics/search/searchable-config.html
Quick Search Box attributes
To make your custom search suggestions
available to Quick Search Box, you
need some of the following
attributes:
android:includeInGlobalSearch
Boolean. (Required to provide search suggestions in Quick Search
Box.) Set to "true" if you want your
suggestions to be included in the
globally accessible Quick Search Box.
The user must still enable your
application as a searchable item in
the system search settings before your
suggestions will appear in Quick
Search Box.
android:searchSettingsDescription
String. Provides a brief description of the search suggestions
that you provide to Quick Search Box,
which is displayed in the searchable
items entry for your application. Your
description should concisely describe
the content that is searchable. For
example, "Artists, albums, and tracks"
for a music application, or "Saved
notes" for a notepad application.
android:queryAfterZeroResults
Boolean. Set to "true" if you want your content provider to be invoked
for supersets of queries that have
returned zero results in the past. For
example, if your content provider
returned zero results for "bo", it
should be requiried for "bob". If set
to "false", supersets are ignored for
a single session ("bob" does not
invoke a requery). This lasts only for
the life of the search dialog or the
life of the activity when using the
search widget (when the search dialog
or activity is reopened, "bo" queries
your content provider again). The
default value is false.
So if you want to add an option to search for words or headings, and you have an activity that allows that search, then you can add that Searchable item(s) to the list. They will be available only if the user wants, though.