I have created my own custom view class by extending "SurfaceView." I then override the onTouchEvent method. Two questions.
(1) Should I even both calling the super.onTouchEvent even though I handle everything (I think) I need? (2) Should have the work done in a new thread? I am receiving many Skipped 32 frames! The application may be doing too much work on its main thread Is the onTouchEvent called from the UI thread?
My view is nothing more than a joy stick and on the on touch event I simply move the coordinates of an object with 3 or 4 lines of code.
Here it is not necessarey to call superOnTouchEvnet.But remember that if you return false it wont work. so it is better to return super.OnTouchEvent after finishing task if you want to handle the event. If for some casees or for some input you dont want to handle the touch event then without using the super method just return false.
yes. this method is handled by main UI thread. so for long tasks use any safe methods like using different threads, asynctask or handler.post.
Related
I am trying to make some application in android (some kind of calculator app). In the app, on pressing the buttons a lot of conditions get checked using if-else. I am using onClickListener with the buttons, and so they are taking a slightly longer time to respond. So should I use multithreading to separate the logic from the main thread or rather use an onTouchListener with the buttons?
For the click event, keep using onClick, onTouch is used for tracking gestures.
It's not a good practice to do any logic operation inside the Main Thread. Leave it just for user interaction. You should consider use threading to avoid ANR (Application not responding). A good start is AsyncTask, that has it own method to do logic in a separete thread and update the UI on the Main Thread.
Please follow this link to get help with AsyncTask: https://stackoverflow.com/a/18827536/4973904
Hope that this could help you!
you should not do too much work on Main thread.The problem is not if else statements because conditional statements execute very fast but the logic you have written inside the if else blocks .may be your logic taking to much time to execute.
Solution:
if you want to perform extensive task , you should use some background thread or an alternative of this like Async task or Loaders.
I am programming a simple game and has to draw animation on the screen and currently calling invalidate() method from within onDraw(). I simply wish to periodically update my canvas.
I would like to move the invalidate() call somewhere else as calling within onDraw() is rather bad. However, my target platform is android gingerbread and I probably can't utilize those methods which involve multithreading.
Is there anyway to setup a timer outside of onDraw() which invalidate() if the time lapse interval meets my desire without involving multithreading?
I probably can't utilize those methods which involve multithreading.
That's not true. It is not what you need though. If you need to call invalidate periodically on your view, you can use the View's internal handler and its postDelayed method, to invoke invalidate(). The runnable runs on the UI Thread.
Wouldn't it be an idea to call invalidate() after an user input?
If you want a timer look to this:
https://developer.android.com/training/scheduling/alarms.html
This method should be viable with your android version.
I was wondering what is the correct way to handle screen rotations while waiting for an asynchronous callback. The callback tries to touch some UI elements on the activity, but as it gets destroyed I get a null pointer exception.
I'm not sure how the logic of your code it set up, but I wouldn't have the callback methods directly touch the UI elements. Instead, have them touch your Model, and when the onCreate method in your Activity is called, you then take the data out of the Model. That way you don't have to rely on the UI elements to be there - you just rely on the Model.
Hope this was helpful - if not, let me know.
Using a Headless Fragment with SetonRetainInstance (true); or Loader, or using the otto library are good ways to accomplish this
When RoboGuice fires Event, where will my event callback be executed, in which thread?
For example, I have an activity which has do(#Observes OnUpdateUiEvent e). I also have a background thread which fires new OnUpdateUiEvent("data"). So, my do() method will be executed in bg thread as I understood? What will be, if I annotate do() with #Background from AndroidAnnotations? Should preprocessor make call to do() in runInUiThread()?
If everything is right, I think this pattern will provide the easiest way of communicating between threads.
As far as I can see here and there, you can specify the way threads should mix with events in RoboGuice, by using #Observes(EventThread.CURRENT), #Observes(EventThread.UI) or #Observes(EventThread.BACKGROUND).
The default is "CURRENT", which means that if you didn't specify anything, the event listening method will be executed in the same thread as the method receiving the event.
So yes, if you fire your event from a background thread, do() will be executed in a background thread.
If you add #Background on the do() method, then it will always be executed in a separate thread, different from the one where you fired the event.
If you're not sure, put a breakpoint and watch the thread names :-) .
Did that answer your question?
I'm new to programming androids but I have quite a bit of experience programming blackberries.
I created an app that has an activity class (main.java) and a view class (game.java).
Inside the view class I have some bitmaps being drawn to the screen. I created a thread and I'm moving the images around in the thread. However when I call invalidate() inside the thread it never redraws the screen.
Are you not able to invalidate() the screen from a thread? I know the thread is running and the invalidate is being called, it just never makes the changes on the screen.
You have to use View.postInvalidate() if you call it from a non-UI thread.
According to docs:
public void postInvalidate ()
Since: API Level 1
Cause an invalidate to happen on a subsequent cycle through the event loop. Use this to invalidate the View from a non-UI thread.