I'm coding an app specifially designed for the blind and vision impaired and I'm trying to override the behavior of TextView when specific AccessibilityEvent are fired. The screen layout consists in 4 TextView arranged vertically that fill the screen. I just want to change the color of the background to reflect which one is "focused" so in my custom TextView I have this method
#Override
public boolean dispatchPopulateAccessibilityEvent(AccessibilityEvent event) {
System.out.println(event.toString());
if (event.getEventType() == AccessibilityEvent.TYPE_VIEW_HOVER_ENTER ||
event.getEventType() == AccessibilityEvent.TYPE_VIEW_ACCESSIBILITY_FOCUSED) {
this.setBackgroundColor(mColorArray[2]);
}
if (event.getEventType() == AccessibilityEvent.TYPE_VIEW_HOVER_EXIT ||
event.getEventType() == AccessibilityEvent.TYPE_VIEW_ACCESSIBILITY_FOCUS_CLEARED) {
this.setBackgroundColor(mColorArray[0]);
}
return super.dispatchPopulateAccessibilityEvent(event);
}
My problem is that AccessibilityEvent.TYPE_VIEW_ACCESSIBILITY_FOCUS_CLEARED is never fired. The three others fire correctly when using ExploreByTouch or swiping left/right up/down.
Any help would be greatly appreciated
If I understood correctly, the accepted answer from this link might solve your problem.
Be careful that if you set your target sdk to 17, there's some extra similar steps to do as described in the comments of the link.
Well I might have read this too fast, it's strange that some are fired and others are not.
Related
I have not been able to replicate this, but is anyone aware of what might cause the entire screen on an Android device to go light blue? It seems related to selecting a radio buttons and then scrolling. It happens on Nexus 5x with Android 8.
Here is what it looks like:
I have only heard of one other instance of this occurring. Could it be device specific? Strangely enough, once it happens it seem to stay this way, though the user says it is somewhat intermittent.
Update:
This only seems to happen on Android 8, if that helps anyone...
So, I eventually found the offending code. I verified this is only happening on Android 8 devices, maybe only Samsung? The offending code was:
mFormScrollView.setDescendantFocusability(ViewGroup.FOCUS_BEFORE_DESCENDANTS);
mFormScrollView.setFocusable(true);
mFormScrollView.setFocusableInTouchMode(true);
// Hide the keyboard when moving the screen up or down. This should only
// be an issue when
// on a text edit field. Also disable focus jump using
// "requestFocusFromTouch"
mFormScrollView.setOnTouchListener(new OnTouchListener() {
public boolean onTouch(View view, MotionEvent event) {
if (event.getAction() == MotionEvent.ACTION_UP || event.getAction() == MotionEvent.ACTION_DOWN) {
Utilities.hideKeyBoard(FormActivity.this, view);
}
// Keeps screen from jumping to nearest EditText
// view.requestFocusFromTouch();
return false;
}
});
The offending line is commented out - the view.requestFocusFromTouch() method, which was meant to keep the screen from auto jumping to the next text field when the keyboard was hidden and focus lost. On Android 8 this is not happening, but I need to verify with older versions.
I am facing a strange behaviour with a RecyclerView as a second child of CoordinatorLayout, just after an AppBarLayout (as described in a lot of examples).
My problem is when I scroll the recycler view and I want to click on a particular item. Sometimes I need to click 2 times to select that item, it seems to be linked to the fling behaviour. For example, if I scrolled to the bottom of the recycler view, then if I fling my finger from the bottom of the screen to the top (in order to see more data, but in my case I can't see more data since I am already to the bottom) and then quickly click on an item, it seems to stop the fling, and the second click actually select the item...
This behaviour is clearly not happening when using a simple recycler view without CoordinatorLayout.
My recyclerview is just holding a simple list of String, and using the following layout behaviour : #string/appbar_scrolling_view_behavior
Do you have any idea why ?
[EDIT]
I just tried with the Android Studio sample Scrolling Activity, and it looks like it is a bug from Google support repository.
In fact, when using support version 26.1.O (same with 26.0.0 and 26.0.2), the bug I am talking about is present, but if you try with the version 26.0.0-alpha1 or 26.0.0-beta1, it is actually working...
There is two open bugs at Google about this :
https://issuetracker.google.com/u/1/issues/66996774
https://issuetracker.google.com/u/1/issues/68077101
Please star these bugs if you are facing the same problem
Google just posted a workaround for this bug, it will be publicly released later.
https://gist.github.com/chrisbanes/8391b5adb9ee42180893300850ed02f2
If Using RecyclerView in NestedScrollView add this line to RecyclerView :
android:nestedScrollingEnabled="false"
I hope it help you.
I also found this problem ... after wasting so many hours searching and trying different things, I came out with a trick, its not pretty but it could work for someone else too.
Basically the idea is simulate a click on the nestedScrollView.
In my case after I detect the 'AppBarLayout' its fully expanded, I send a tap to the nested.
protected void onCreate(final Bundle savedInstanceState) {
getAppBarLayout().addOnOffsetChangedListener(new AppBarLayout.OnOffsetChangedListener() {
#Override
public void onOffsetChanged(final AppBarLayout appBarLayout, final int verticalOffset) {
if (verticalOffset == 0) {
// State.EXPANDED
simulatedClick(nestedScroll)
} else if (Math.abs(verticalOffset) >= appBarLayout.getTotalScrollRange()) {
// State.COLLAPSED
} else {
// State.IDLE
}
}
});
}
private void simulatedClick(#NonNull final View view) {
// Obtain MotionEvent object
final long downTime = SystemClock.uptimeMillis();
final long eventTime = SystemClock.uptimeMillis() + 100;
final MotionEvent motionEvent = MotionEvent.obtain(downTime, eventTime, MotionEvent.ACTION_UP, 0.0f, 0.0f, 0);
// Dispatch touch event to view
view.dispatchTouchEvent(motionEvent);
}
NOTE: I don't really recommend the use of hacks like this, it's unprofessional and unmaintainable, but the more you know...
After releasing my product, I've started getting complaints that a certain screen was not working for some phones. After a lot of research and a lot of attempts to fix this issue, I found out that phones that are controlled by heat instead of pressure have this issue. Unfortunately I have only identified the problem. What is happening is the mouse up and mouse move motion events seem to be the same motion. Here is how my code works:
if(event.getAction()==MotionEvent.ACTION_MOVE)
{
lockdown=true;
}
else if(event.getAction()==MotionEvent.ACTION_UP && lockdown==false)
{
...
}
else if(event.getAction()==MotionEvent.ACTION_UP)
{
...
lockdown=false;
}
This code works on a pressure touch phone like mine just fine. It's designed that while the touch is dragged certain things will not function. I could really use some insight on how to fix this issue.
after an exhuasting night of going back and forth with my testers this is what ive come up with
// somewhere in the prior code a pressure sample is needed
public float dwnPressure
if(event.getAction()==MotionEvent.ACTION_DOWN)
{
dwnPressure=float(event.getPressure()*0.99)
}
back to the code where i had problems
if(event.getAction()==MotionEvent.ACTION_MOVE)
{
if(event.getPressure>dwnPressure)
{
lockdown=true;
}
}
else if(event.getAction()==MotionEvent.ACTION_UP && lockdown==false)
{
...
}
else if(event.getAction()==MotionEvent.ACTION_UP)
{
...
lockdown=false;
}
this change works perfectly on some of the phones that had the problem prior. Some phones there is a significant performance improvement but is a bit finicky. I figured id at least share my hard work even if it isn't 100%, since this question wasn't answered as fast as im used to on stackoverflow
I'm developing an application right now and I need to disable the quick-search-box as somehow it dismisses my dialog boxes that request info to keep people who are not supposed to be using my application out [its in development, and its on the market - it makes it much easier to keep people up to date]. Listeners for all types of dismissing dialogs are never triggered - and I don't know why. I've looked everywhere and I get no result on how to disable this. (2.1 and up).
How to disable QSB..? was a good start, but it doesn't work. I don't know why google insists I use this... I have absolutely no need for this in my application.
How can I go about fixing this... or do I have to try another sort of DRM?
You can block the search on your activity or dialog by implementing this and returning false:
public boolean onSearchRequested() {
return false;
}
UPDATE:
Code works on dialogs, too
public boolean onKeyDown(int keyCode, KeyEvent event) {
if(keyCode==KeyEvent.KEYCODE_SEARCH && event.getRepeatCount() == 0)
{
return true;
}
else
{
return false;
}
}
Returning true means that we are handling the Search Event.
I'm currently fighting against the OnLongClickListener on Android Api Lvl 8.
Take this code:
this.webView.setOnLongClickListener(new OnLongClickListener() {
#Override
public boolean onLongClick(View v) {
System.out.println("long click");
return true;
}
});
It works perfectly. I can press anywhere on the WebView and the event triggers every time.
Now take a look at this one:
this.webView.setOnLongClickListener(new OnLongClickListener() {
#Override
public boolean onLongClick(View v) {
final EditText editText = getUrlTextField();
switch (editText.getVisibility()) {
case View.VISIBLE:
editText.setVisibility(View.GONE);
return true;
case View.GONE:
editText.setVisibility(View.VISIBLE);
return true;
default:
return false;
}
}
});
Assuming the URL EditText components is currently visible, it gets gone from the display and should be shown again when another long click event is triggered.
But if you run this, the event just works once (!) when one performs a long click on any position on the WebView. To make things complicated, the long click works again when it is performed on a link on the website...
Can anyone explain if it is a bug in the sdk and/or if there is a mistake in my thinking how the OnLongClickListener is working?!? :/
EDIT:
I've run now several different scenarios on a Nexus One and come to following conclussion: Changing the layout on runtime more or less kills the OnLongClickListener... I haven't found a way to get it work reliably at all...
I would really appreciate if anyone could give me a hint... I'm at my wits end :(
Personnally, I ended up by re-setting the listener after each relayout.
I've run into this issue as well. It seems that if the view layout changes in a way that child view bounds need to be modified (i.e. TextView is wrap_content width and you set its text to something longer/shorter than it was before), views in the hierarchy will have their onStartTemporaryDetach method called (most likely due to a layout pass, although I haven't dug deep enough to find out for sure). If you look at the source for View that onStartTemporaryDetach ultimately unsets the pressed state of the view.
Changing the views in your layout that will be updated periodically to have bounds that will not change regardless of the value you set, will fix the issue. Although, that is still not awesome.