I was looking through ViewConfiguration class documentation and I found getJumpTapTimeout() method. Description says it is used to determine whether user wants to perform a "jump" tap or a regular one. The user has to complete jump tap within this time or it will be a regular one. The question is what is this jump tap anyway?
I've looked through the source, but it doesn't give any clues. Jump tap timeout is 500 ms, so is the long press timeout. So if I keep my finger for more than 500 ms on the same spot without moving, this is a long press, and it's not a tap. Tap timeout is 115 ms, so I have to at least not move my finger for this time or this won't be a tap. But then I have to do something until my 500 ms expire. Only what exactly?
It is same as tap applied to active page elements, but used in earlier versions of webview, now this parameter is simply redefined inside webview as tap_timeout, now it sess to be used only for dpads
// This should be ViewConfiguration.getTapTimeout()
// But system time out is 100ms, which is too short for the browser.
// In the browser, if it switches out of tap too soon, jump tap won't work.
// In addition, a double tap on a trackpad will always have a duration of
// 300ms, so this value must be at least that (otherwise we will timeout the
// first tap and convert it to a long press).
I have seen its usage in one of Google's open source project Eyes-Free Android Applications more specifically inside ProcessorFocusAndSingleTap.java Inside performClick(AccessibilityNodeInfoCompat node)
For clarity I am mentioning here what It was used for
If a user quickly touch explores a content i.e, (event stream < ViewConfiguration.getTapTimeout()), then to avoid sending an unintentional ACTION_CLICK they have Switched off clicking on content.
Basically , It's The timeout after which an event is no longer considered a tap
you jump from one app to the other. Jump will tell your phone that you jumped and will no longer keep the previous app on.
Related
I am having an issue where i execute the startTakeOff() method, and the callback of this method is returned before (0.5 meters) the drone got to the height he suppose to (1.2 meters) - this part is documented (startTakeoff()) - which is a bit weird. After the callback is returned i am loading the actions to the timeline (getting a success callback), and then firing the startTimeline() method, i've also registered a listener that prints all timeline's event status, and what i see is that the timeline started, then the GoToAction (first in the timeline) is started but the drone doing nothing, doesn't move or do anything.
If i clean the timeline, reload the actions, and fire startTimeline() again (w/o calling to stopTimeline()) it works as it suppose to.
My question is - is there a 'clean' way to delay takeOff's callback? Or make the timeline run w/o reloading it? By 'clean' i mean that i can set a custom timeout that will load and start the timeline, but it is not the best practice...
No the OSDK fires the callback as it leaves the ground, your only option is to observe and wait for it to reach 1.2m.
OSDK only provide you with some sample. It is not 100% sure of working. You should think and get a solution to your problem.
In your case, the delay they put is without any guarantee. you need accurate feedback to make it sable
You can use a system such as SVO to achieve this. https://github.com/uzh-rpg/rpg_svo
SVO gives you feedback of ur current drone status. So instead of using delay
start take off
while uav not at 1.2 meter -> (take off running) do nothing
while uav airbone -> do the thing you want
Additionally you can put timeout in, in case overloads and drone cant take off successfully.
I saw people getting SVO / PTAM / Vinsmono working on android phone before. So i think you could do the same.
I need to limit number of key events handled per second.
The idea is, because in my app users can use keyboard.
When user hold down on right navigation button, for example.
I don't want to handle every event, because my app can get stucked in calculation loop.
And then force close, wait dialog appears.
I want to handle 2,3 events per second and other just to ignore.
So I can add little cool down time for the app and calculation thread.
Is is possible?
I think I must use some timers or simple sleep function in my key listener, but I can't figure out right way to do this.
Any idea?
A simple solution would be doing some time comparison when you receive a key event:
// a variable in your class:
private long mPreviousKeyEventTime = 0;
// in the key event handling function:
if(System.currentTimeMillis() - mPreviousKeyEventTime < 300) return;
mPreviousKeyEventTime = System.currentTimeMillis();
300 is the time in milliseconds - change it to suite your needs.
Edit: if the keyboard is also used for typing, then make these restrictions only when navigating.
I am currently writing an app that should display a real time measurement curve in a scrolling fashion (think ECG recorder or oscilloscope). An unexpected system call in the UI-Thread makes the display stutter.
The data rolls in via bluetooth. All works fine and the display is reasonably smoothly scrolling with an average update rate of 26 frames/s. But, nevertheless the display is stuttering remarkably.
I used traceview to get more insight and according to traceview the stuttering is the result of a call to android/view/ViewRoot.handleMessage which lasts 131 ms per call on average.
If I dig down further in traceview the cycles are burnt inside android/view/ViewRoot.performTraversals. 92% of these CPU cycles are consumed in mostly recursive calls to android/view/View.measure.
From there it gets complicated due to the recursive call structure. But I can find calls to the onMeasure() method of LinearLayout, FrameLayout and RelativeLayout. The onMeasure() method of each Layout type consumes about the same amount of CPU cycles. Which is very strange since in my activity I use only a simple LinearLayout with just 2 Elements.
I just see no reason on why a supposed re-layout of a LinearLayout with 2 Elements performs calls to non-used Layouts and takes a whopping 131 ms to do that.
Further info:
Platform HTC desire HD with Android 2.3.1.
I use a handler to perform the drawing in the UI thread.
The Layout is a simple LinearLayout with 2 Elements: a custom view and a textField.
The status bar is hidden with getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN);.
The drawing is performed on each new block of data, which arrives approx. every 50 ms.
The drawing itself uses a canvas and is performant enough to keep up with the incoming data.
After that long explanation, here are the questions:
What is calling the android/view/ViewRoot.handleMessage? (the calls are relatively equal spaced every 850 ms and have no obvious link (no direct calls, number of calls and relative positions are not linked to the message handler for drawing) to any activity of my Activity)
How can I suppress the calls to android/view/ViewRoot.handleMessage or how can I make them faster (there are just 2 elements in my LinearLayout)
the calls to unused layouts first got me think of the status bar or some hidden activity (e.g. home screen), which may use such layouts. But how come those calls are part of the trace of my activity? As far as I understand the trace should only trace the active process. e.g. the calls of my service which produces the real time data is not part of the trace.
Is there any possibility to trace individual calls to some system components? When I zoom in in traceview I see this call sequence: toplevel -> android/os/Message.clearForRecycle() -> android/os/MessageQueue.nativePollOnce() -> android/os/SystemClock.uptimeMillis() -> com/htc/profileflag/ProfileConfig.getProfilePerformance() -> android/os/Handler.dispatchMessage() -> android/view/ViewRoot.performTraversals()
Off topic: Is there a possibility to export the data which is shown inside traceview (parents-children-CPU time etc.) other than a screenshot?
Ok, I found the reason for the long call to android/view/ViewRoot.handleMessage.
This was indeed caused by my application.
My App has 2 screens (Activities) one with a complicated Layout for status information and the other one the real time display of incoming data.
The data, which comes in over bluetooth contains mixed real time data and status data. When I switch to the real time Activity, I was stopping the status Activity with finish(); after starting the new real time Activity. Unfortunately this is not enough to stop also the message handler, which receives the new status information in the UI thread, and continued to update status data in an invisible and finished Activity. The relayout of this activity caused the stutter of the real time data.
This is now solved. The display scrolling is now reasonable smooth.
Thanks for your patience. May it be useful to anyone who stumbles on this Thread on stackoverflow.
jepo
I'm creating a spades app with 1 human player and 3 computer players.
The problem that I am having is, the play must happen sequentially (clockwise) and I need my program to wait on the player input. I can't use wait() and notify(). I have tried while loops to check whether the user has selected a card but those stop the program from running. I've tried recursive methods that won't return anything until the player has chosen a card. That too does not work. So what do I do? I'm stuck.
My method goes like this (leaving out the non-pertinent code)
private void game(){
while(there are more tricks to be played)
while(each player has not played){
if(human turn)
get input from player
else
computer plays
}
}
Maybe you should change a little bit your game controller. Instead of waiting for anything, have your program continuously paint the screen. If user inputs nothing, same screen is paint all the time.
Once he presses a key (or clicks a card or whatever events you have), simply modify the paint method's argument (the screen to be painted). Thus you will separate painting the screen and input handling. It's a common technique called MVC model.
Maybe this will help (it's my game creating blog, and the links inside it are also helpful):
http://m3ph1st0s.blogspot.ro/2012/12/create-games-with-libgdx-library-in.html
You don't need to adapt all your game to the game described there, only the technique of separating input from painting. As a general technique, you should NOT have input determine painting.
Hope it helps. Don't hesitate to request further help.
You can try to add Event Handlers. It will try triger a event every time the user selects a card.
Try this.
Create one thread and in that threat call sleep(1000);
I have an app out that involves keeping track of information over time. Part of the app is a reset button. In order to avoid accidental resets, I made that button respond only to long-clicks. However, that approach confused about 20% of my new users, who thought that the reset button must not be working.
Is there a more intuitive (and standard) way to protect a button from accidental presses? (If not, I can add some sort of custom message to the button I have . . . )
A Thilo said, a confirmation dialog is the standard answer.
This is good reading if you haven't already:
http://www.codinghorror.com/blog/2010/03/the-opposite-of-fitts-law.html
Basically, make it small! Long click is a good answer, but unless there's a "press and hold" label right underneath that, users are going to have trouble - that violates the user model, since users aren't used to having to do that (I probably wouldn't be able to figure it out).
On the iPhone it's fairly standard to have "slide" buttons (like the unlock) for operations like this, since it's much more difficult to accidentally slide. You could implement something similar to that, but it might be overkill for this problem.
Another vote for Thilo and a confirmation dialog.
Also Google/Android is trying to get devs to use the long press as a Quick Action UI pattern. See Android Developers Blog entry on Twitter app
All though this is kinda a workaround, it still works.
case R.id.bReset:
long startTime = System.nanoTime();
boolean running = true;
//show dialog with a single button - cancel. Outside the loop. Upon cancel, set cancelled to true.
//You can use DialogFragment or AlertDialog
while(running && !canceled){
long elapsed = (System.nanoTime() - startTime) / 1000000;
if(elapsed > securityTime && !canceled) {//set security time to amount of seconds * 1000
//Dismiss dialog
//reset
}
}
break;
From the currently accepted answer:
As Thilo said, a confirmation dialog is the standard answer.
It does not have to be a confirmation dialog, but if accidental press the user should have the opportunity to cancel the action while at the same time no further action is required if the user wanted to do it.