I have GroupView which contains 4 ImageViews.
When I change params of one view(for example re scale image or rotate) this causes to redraw whole Layout.
I want to prevent redrawing whole layout and want to redraw only specific View.
Sure.
myView.invalidate()
See:
https://developer.android.com/reference/android/view/View.html#invalidate()
Drawing is handled by walking the tree and recording the drawing
commands of any View that needs to update. After this, the drawing
commands of the entire tree are issued to screen, clipped to the newly
damaged area.
The tree is largely recorded and drawn in order, with parents drawn
before (i.e., behind) their children, with siblings drawn in the order
they appear in the tree. If you set a background drawable for a View,
then the View will draw it before calling back to its onDraw() method.
The child drawing order can be overridden with custom child drawing
order in a ViewGroup, and with setZ(float) custom Z values} set on
Views.
To force a view to draw, call invalidate().
Related
How can I draw (bitmap, line, etc) outside the bounds of a view? From the view's onDraw(), I've read this is not possible as everything drawn will get clipped to the view's bounds.
I did come up with one solution but I'm hoping there's a better one. What does work is to create a transparent view that is at the top of the z order and includes the area I want to draw in (the entire app client area). Then, whenever I want to draw outside some child view, I can simply translate to the coordinates to the transparent view and draw there.
I also read about SurfaceView hoping that would do what I want. But I think it's main purpose is to provide drawing in a separate thread and doesn't solve the problem I'm discussing.
To be clear, it isn't sufficient to simply draw in the parent of the target view because other views in the parent will be higher in the z order and hide the drawing.
Intuition tells me there's a "right way" to do this. Anyone know?
I'm drawing the conclusion that the right way is to do what I proposed - create a transparent view that is at the top of the z-order for the space you need to draw in.
I come to this conclusion after learning how the Navigation Drawer drawing works - exactly in this way. So, if Google uses this technique, I conclude that it's the best way available.
I want to design a gauge View in Android, for example a round thermometer with a rotating needle.
For efficiency / speed, when new data arrives I'd like to re-draw only the parts of the View that change (e.g. the rotating needle).
My initial test class extended View, and I had to re-draw the entire view (moving and non-moving elements) in onDraw() each time new data arrived.
I found an example (http://mindtherobot.com/blog/272/android-custom-ui-making-a-vintage-thermometer/) that suggests drawing the non-moving components onto a Bitmap. This Bitmap is drawn in onDraw() using canvas.drawBitmap. In this way you only need to draw the individual non-moving graphic elements (regenerate the Bitmap) when something changes the non-moving parts of the View (e.g. resizing the View).
My idea for optimization was different. I think perhaps my gauge should extend ViewGroup rather than View. Then within the ViewGroup I could create individual Views for the non-moving and moving parts of the gauge. I would draw the non-moving View once, and never force it to invalidate(). Then I would draw the moving needle as a separate View (aligned in the ViewGroup such that it overlays the non-moving View) which I could invalidate() when new data arrives, so it would be re-drawn. Am I missing something that makes this a bad way to do it?
For example, is my assumption incorrect that the non-moving background View will not need to be re-drawn (i.e. have its onDraw called) as the overlaid rotating-needle View in the same ViewGroup is changed? Or does having the needle View change force the background View in the same ViewGroup to get re-drawn as well, due to the Views overlapping?
Many thanks.
I am trying to build a simple game. I have a SurfaceView, on which I draw the background for the game:
Canvas canvas = surfaceHolder.lockCanvas();
//draw on canvas....
surfaceHolder.unlockCanvasAndPost(canvas);
I have a View that I want to 'layer' on top of the SurfaceView, but I still want to be able to see the background underneath it. How do I draw the view on top of the SurfaceView. The View has its own onDraw method, with an associated canvas, so I'm assuming that I need to place the View on top of the SurfaceView where I drew the background?
There may be a more efficient way to to do this, but when it comes to stacking views on top of one another, you could put the SurfaceView inside a FrameLayout, and then put the view you want on top after the SurfaceView in the XML, but still inside the FrameLayout (meaning it's drawn later, and thus on top). This will accomplish the stacking you desire.
If you wish to position the view that will go on top of the SurfaceView anywhere else than exactly matching it, or the top left, then you could use a RelativeLayout where you layout the SurfaceView with alightParentLeft, alightParentTop, alignParentBottom, and alightParentRight all set to true. Then again having the view you want drawn on top coming after the SurfaceView in xml will draw it on top, and you can position it wherever you want.
Now as for you wanting to the view on top of the SurfaceView to be see through, you can do that by setting it's alpha value. if you are aiming for 3.0+ you can just use a view's .setAlpha method, but if you are aiming for lower, you could set a zero millisecond AlphaAnimation to set the alpha of the view (There may be a better way to do this, but this is the only way I to set alpha on views pre honeycomb).
Hope this helps! Best of luck!
So, much to my chagrin, I found out while testing on an earlier device, that pre-API version 11, the View class has no setAlpha nor setX methods. Can someone suggest an alternative? I'm currently moving a view around by updating its X location, and fading it in and out based on user interaction.
You may use standard Animation to implement such program logic, such as AlphaAnimation and TranslateAnimation to make movement of your View. But also you should keep in mind that original position of View at it's parent layout isn't changed (only pixels are redrawn). That means, that when user would taps on new image of View, this View would not get event, as it's Rect remains in the old position.
You could relocate Views rectangle after the end of animation, using View.layout() method with 4 positioning parameters passed there, but in this case you should consider about your layout nature, because for example if you work with LinearLayout and change the position of it sibling by calling layout() method, next change of one of UI elements size will call reaqestLayout() method and your animated View will come back at it's initial position
My question is rather straightforward. I have a custom view (a rectangle), that will be rotated, translated, and scaled ontop of its parent view (RelativeLayout).
My question is what is the best way to handle these transformations. Should I:
A: Modify the CustomView's draw() and apply canvas transformations
B: Modify the LayoutParams margin for left and top.
C: Pursue an alternate approach, given my problem set.
The rest of the problem set looks like this.
1. The Custom View must be able to overlap other custom views and be able to be drawn outside the bounds of its parent view.
2. A 4 point path is generated overtop the CustomView's drawable that represents its collision volume. This collision volume is synchronized with the rotation and translation of the View by modifying a Matrix object that is then applied on top of the volume in order to accurately handle collisions and avoid false positives.
3. This custom view object will be animated using standard AnimationTranslate, AnimationRotate, AnimationScale functionality. After the animation completes the original View will be transposed to its computed location postAnimation.
Thank You for your time experts
you can read more about property animation here http://android-developers.blogspot.com/2011/02/animation-in-honeycomb.html