Is there any way of disabling / enabling the touch events in a certain activity
without disabling certain buttons. like if the phone is "frozen" on a certain activity page for limited time?
I need that the user wont be able to go back on page, slide out or any other events.
Is it possible? (I'm using android studio, java)
Thanks in advance!
Any answer would help :)
It's possible.
Actually there is no special function to make it.
To make it, you can make a full screen button with transparent background.
And you will define a function of the button.
Of course, it will be an empty function.
Well, you can do nothing on the screen.
and then you can hide or visible the button according to your necessary.
I needed to keep screen on while displaying my application so I disabled Dimming using this code :
getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
the problem is that when I close the application, dimming is still disabled
and I want to re-enable screen dimming for power saving is there a code to reverse it ?
note my application has services working in background all the time,I think it's irrelevant as I put the code in an activity class;
You should use the View function setKeepScreenOn(). It's more friendly.
I know this may not be an appropriate question, but I want to know how a touch enabled OS like
android detects a button in an app and calls the appropriate handler? When programming an app we just give the alignment information of a particular button. So, how android keeps the mapping between a button and screen position? I think this is kindof dynamic because if you change the screen orientation or use zoom or something like that the button positions are changed dynamically. So, android must look at the touch position and decide whether a button is there or not and call the appropriate handler. How this all things put together?
I appreciate any reply.
I've been working on a drum machine app, and the latency between the time you press the button and the time the sound plays is unbearable. I have seen some people use multitouch and gridviews, and make several buttons able to be pressed at the same time, but I honestly have no knowledge of those. How could I set up multitouch or gridviews to reduce the latency?
I would guess the multitouchable buttons are a very custom implementation. You won't ever be able to touch two ordinary buttons simultaneosly, since they are made for single touch and are based on focus gain etc.
Here's my idea behind a multitouchable implementation:
You create a very custom view which will draw all buttons you need. This view should override onTouchEvent and react on multitouch. I never tried that, but this is the only option I can think of.
I'm facing a head-scratching moment similar to what this person (from Jan 2008) experienced when I realized that there is no cancel button in Android's progress dialog or spinners. It is now July 2009 and I've just installed the cupcake version of Android. Has this thing changed? If not, are you adding a cancel button into the dialogs and how do you do it?
not sure about the whole cancel button...i've heard reports of the onCancel() method not firing properly. my solution just consists of making a normal button on the dialog with a call to return whenever the button is pressed.
private void createCancelProgressDialog(String title, String message, String buttonText)
{
cancelDialog = new ProgressDialog(this);
cancelDialog.setTitle(title);
cancelDialog.setMessage(message);
cancelDialog.setButton(buttonText, new DialogInterface.OnClickListener()
{
public void onClick(DialogInterface dialog, int which)
{
// Use either finish() or return() to either close the activity or just the dialog
return;
}
});
cancelDialog.show();
}
then just use a simple call method from elsewhere in your activity
createCancelProgressDialog("Loading", "Please wait while activity is loading", "Cancel");
rather simple solution, but it does the trick ;)
also just to note that cancelDialog is an activity wipe variable, if you dont need to call it from elsewhere, then you should be able to get away with just limiting the scope of the variable to that method.
I'm no Android user or developer, but I think the answer given in the linked-to thread is pretty decent: there's a hardware "back" key on all Android devices. Users are supposed to know to press Back to back out of whatever activity they're currently in.
Thus, the UI designers feel it's unnecessary to include a GUI back/cancel button. This could be viewed as the UI application of the DRY principle; if there's already one way of doing something, that's enough.
The hardware key is the answer here. I'd be careful about generalising the DRY principle to UIs. There are plenty of cases where you need to hammer, hammer, hammer the same point to the user repeatedly via headings, body text, colours and images.
Users dont "read" UIs the way you read a novel. They scan read.
I can't speak for other apps, but in mine anything that might cause the UI thread to wait is executed in a seperate thread. The most I'll do is show a small progress spinner in the titlebar to let the user know something is going on in the background.
As an Android user, and developer, I can say, in my opinion, and based around my understanding of the platform, that there is a good reason for not having a cancel button by default on the cancel-free progress dialogs.
As a developer, these dialogs can not be cancelled by default, that is, you have to explicitely set them as cancelable.
This makes sense, because their purpose is to alert the user, via the UI thread, that some work is going on elsewhere that is important to the updating of the UI thread, before the user should continue their use of the application.
For example, when fetching a list of data to occupy an empty screen, there is nothing to interact with, and the user needs to be made aware that something is going on, and to expect there to be nothing available to interact with until this process is complete.
However, there may be cases, such as data retrieval from the internet, where the process is "sketchy" and due to connectivity issues, you may not be able to complete the request, and get stuck here.
This as a develop is where you enable the dialog to be cancel-able.
Now as a user, one that clearly understands the UI paradigm of Android, I know that if I want to go back to what I was doing before, or "cancel" the current operation, I should hit the back key.
As a user, it's no different to knowing that in Android, the menu key can often reveal hidden options, some times on a seemingly blank screen with no way to interact.
This is the behaviour a user expects, and the way the platform is designed. You could very well add a cancel button, but from a users perspective that understands their phone, this makes no difference, the back key is clearly the intended choice for this purpose.
Activities and UIs have a flow, you flow through activities and UI "screens" which are "stacked" and the back button essentially "pops" the last thing off the stack to return you to where you were previously. If you see the dialog as another of these activities, you want to pop it from the top of the stack to return to what is underneath, or an activity previous to that.
If a developer has a dialog that can not be cancelled by back, it is either, by design, for which there can, in cases, be very good reason for, or, it is poor development and an oversight on the devloper's part.