It seems that multiple invalidate will be coalesced for performance issues, but i'm encountering a case where this optimization will cause problems.
Say i have a custom view and it captures keydown and keyup event. in keydown, the view is in blue and in keyup it becomes red. But sometimes during the down and up processing, the onDraw will only be called once, it is likely because the two invalidate are coalsced. The result is that the view never becomes blue.
Anyone knows how to fix this?
Layout should happen very fast, even if it is said at some point in the future in the documentation.
Therefore, missing some event as you said implies that the redraw happens so late after being requested that the user see it, likely 1 second.
This hypothesis is only possible if you make huge work on Ui Thread, or something in your app slows the Ui Thread abnormaly.
So these considerations aren't to be taken into account in my opinion.
You should track the current color of your view using a boolean and when the view is actually drawn in the future, just draw it in the current color.
Changes being missed this way, should indicate they happenned so fast that the user cannot see them, which seems hard because the state of your view is based on user input.
Related
From Activity lifecycle we know, that in onResume the UI is visible. But if I set a breakpoint on onResume, I still don't see it, only after that. I heard there's some method which can check it, but I can't remind how it calls. We used it to make better animation. So how can I be fully sured that UI is ready?
Add global layout listener on view you want to check. Also please make sure that you remove listener once your work is done else it will keep getting called multiple times.
#onik shared a good link that should solve your problem
This ensures lay-outing. Drawing happens continuously and frame are refreshed according to sys clock.
I recommend watching: https://www.youtube.com/watch?v=Q8m9sHdyXnE
This will give you good idea on android drawing and layouting
Background
There are some nice apps out there that show some layout on top , while the user is making a call or answering one (like "current caller id").
I need to create an app with the ability to show something on top , during a call, and allow it to be interactive.
The problem
Using broadcastReceiver ,foreground service and SYSTEM_ALERT permission, I've succeeded showing something on the screen during calls.
As long as the content being shown is static, I have no problems.
However, I've noticed that when I try to make the content being shown to be interactive , I face some problems:
Everything is jumpy and this includes not only animations, but also setting visibility to visible/gone. I hate to think how it would work like when I need to make things draggable.
Not sure if this is the reason, but using the SlidingDrawer make the entire width belong to the SlidingDrawer and you cannot click through it. This means that if its location is at the bottom, you can't touch the "answer" button when someone calls you.
The question
What is the reason for those problems?
How can I fix them and be able to show things right?
How do other apps handle it right ?
EDIT: about the SlidingDrawer , it seems that it has terrible bugs about its location and size, and the content area, even when it's not shown to the user and the user can see through, it cannot be touched through. Still, I don't know why, and how to fix it, and I also don't know why things are so jumpy compared to normal apps (probably because of over-drawing, but it's really really slow).
Maybe this question should be more general: how to make a floating window like on AirCalc, that can be moved easily yet still be quite fast.
For the dragging functionality, I've tried to get the layoutParams of the root view (which is of type WindowManager.LayoutParams ) that I show, update it and set it again, but for some reason it didn't do anything. Wonder what I'm doing wrong.
EDIT: it seems that i should be using windowManager.updateViewLayout for updating the layoutParams. Using this post , I've made it perfectly draggable.
Ok, I've come up to some conclusions about this, first to answer my original questions:
it's probably because of overdraw and the views i've used. I wanted to try out libraries that could replace the slidingDrawer , but each had a different problem. using simple views proved that the idea in general works.
in the case of visibility changes, it was jumpy because the size of the view wasn't able to fit using the current WindowManager.LayoutParams size.
slidingDrawaer does have issues since it uses the whole size it get when closed or opened.
now to the rest of the issues :
unable to drag ? instead of the regular setLayoutParams , use windowManager.updateViewLayout .
unable to touch outside of the view ? set its minimal size according to your needs. you can also set the window flags so that touch event would go through .
want to listen to calls events ? you can use the broadcastReceiver for triggering the showing of the app, but I suspect that hanging the call might cause the intent be received later sometimes. I think you can use telephonyManager and listen to events there, using the service you run in the foreground (that i've created just to make sure the app won't close in the middle).
if anyone else has questions, i can help.
I'm curious guys,
What are the exact cases doTraversal -> performTraversals is called? Since I have pretty heavy Activity, I want the application to call onDraw or the sort. performTraversals is pretty heavy, it is trying/measuring if it should resize views, stuff like that I guess. And I don't need it when I'm making some view, that no other view is dependent on, GONE, but I guess I can't skip that. So before digging into the source of Android, I want to ask. If you know it, please feel free to share :)
Thanks,
Danail
performTraversals() has many jobs but its three main roles are:
Measure views
Layout views
Draw views
Every time Android needs to redraw a window, performTraversals() is invoked. It does not mean however that measure/layout happens every time performTraversals() executes. You cannot skip performTraversals() if you are using a standard views (only SurfaceView lets you bypass this when drawing.)
My answer to this question was just accepted but I started to wonder when exactly one needs to invalidate() a View and when it is not necessary?
After a bit of thinking I came to realization that it should work more or less like this:
actual drawing of "everything" occurs after onResume()
in "free" time parts of the screen can be redrawn but only those that were invalidated (and everything underneath)
Therefore, it would seem, if I change something after onResume() (e.g. as a response to a button click, I should invalidate() the changed View).
However, from what scana in this question says, it must be more complex then that and it depends somethimes on what method one uses.
E.g. on whether one uses
lastClicked.setImageBitmap();
or
lastClicked.setImageResource();
So, when it's necessary to execute invalidate() on a View and how does it really work ?
(Do consider accepting some answers)
Generally, invalidate() means 'redraw on screen' and results to a call of the view's onDraw() method. So if something changes and it needs to be reflected on screen, you need to call invalidate(). However, for built-in widgets you rarely, if ever, need to call it yourself. When you change the state of a widget, internal code will call invalidate() as necessary and your change will be reflected on screen. For example, if you call TextView.setText(), after doing a lot of internal processing (will the text fit on screen, does it need to be ellipsised, etc.), TextView will call invalidate() before setText() returns. Similarly for other widgets.
If you implement a custom view, you will need to call invalidate() whenever the backing model changes and you need to redraw your view. It can also be used to create simple animations, where you change state, then call invalidate(), change state again, etc.
Usually, the system handles resizing, hiding, showing and a ton of other things for your widgets automatically but it sometimes has issues if the underlying buffer for drawn pixels or backing data has changed or is stale (you swap the image resource on a View or the raw dataset changes). This occurs because there is no way that the OS can know that the data changed in the specific manner that it did.
In these cases where you are dealing with drawing, you have to tell the system that its underlying data is not in a good state with Widget.invalidate() and the re-drawing gets queued on the main thread just as you mentioned. Depending on the system implementation and Android version what is tracked for changes by the system varies but what I normally do is assume that system resources (byte arrays, char arrays, resource indexes, manual drawing on the context) are not tracked and need an invalidate and everything else will be handled by the system.
Please remember that drawing on the screen is frequent process, whenever you update a view, that change should be propogated and redrawn to notify such change right. invalidate() is a trigger method,that signals force reDrawing of any view you wish to show changes for.
I had this problem when I wanted to draw a textPaint!
My code was
canvas.drawPaint(textPaintNumber)
canvas.drawText("MyText", 30F, 63F, textPaintNumber)
I cleared the first lint and the problem was solved
canvas.drawText("MyText", 30F, 63F, textPaintNumber)
I'm reading up on SurfaceView and how to use it, and I've come across some information that states that a SurfaceView has View#willNotDraw() set to false by default, and that it's up to you to call SurfaceView#onDraw(). I also read that RomainGuy said that this is done by default because it is more efficient. My question now is, when should you handle calling SurfaceView#onDraw() in a separate thread, and when should you just set View#willNotDraw() to true, and just call SurfaceView#invalidate(). Is there a difference between the two, and does one improve performance more than the other?
See:
http://developer.android.com/reference/android/view/View.html#setWillNotDraw(boolean)
I'm not sure where you got your information, but at least the javadoc says that most users will set this to false to get Android to send it onDraw events itself. As for your question about when you should do this, I would say it comes down to why you're using a SurfaceView.
If your view is displaying something dynamic (e.g. for a game or something that has a tight event loop), you'll want to be controlling exactly when updates happen, especially if you'll have the information to use one of the more detailed forms of invalidate to save redrawing the entire View. You won't want Android to call invalidate for you, and that's why the flag is there.
If, on the other hand, you are simply drawing something static, it makes sense to let Android's UI stack control the invalidations.
By the way, invalidate only posts a request to re-draw the View, so be aware of this if you intend to use the event-loop style (onDraw will be called sometime after you call it).
Edit: some clarifications.
Using SurfaceView.onDraw() and SurfaceView.invalidate() will make SurfaceView behave like a normal View and you will pay for the extra overhead associated with SurfaceView. If you want to draw from the UI thread, use a regular View instead. It's easier and cheaper.