I've removed my old code now as it wasn't working as I intended. I was trying to use the onDraw canvas feature within a certain portion of the screen so that I could still have buttons and other text around my drawing.
***EDIT***
I've managed to fix this issue now. A lot of what was suggested was helpful but I just couldn't get it to work with what I wanted. That's probably more my fault than anything else so thanks to all those who offered advice. Here's how I solved the issue.
*1. First Define a View in the Layout File.
<view
class="com.project.MainActivity.Drawing"
android:id="#+id/drawing_area"
android:layout_width="700dp"
android:layout_height="900dp"
android:layout_centerInParent="true"/>
*2. Then create a separate java class file with the following code:
public class Drawing extends View {
Paint paint = new Paint();
public Drawing(Context context) {
super(context);
}
public Drawing(Context context, AttributeSet attrs) {
super(context, attrs);
}
#Override
protected void onDraw(Canvas canvas) {
super.onDraw(canvas);
//Draw Image Here//
}
*3. Then call the Drawing from the main activity:
public class MainActivity extends Activity {
private Drawing mDrawingArea;
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.percentage_count_layout);
mDrawingArea = (Drawing)findViewById(R.id.drawing_area);
}
In your View class you need to override the onMeasure() method. This is where you ask for a specific View size. There are some official Android tutorials on this subject and I will edit this post once I'm at my computer with the links.
EDIT:
Take a look at this Android article about creating custom components.. Specifically take a look at the section titled 'Extend onDraw() and onMeasure()'. Quoting:
onMeasure() is a little more involved. onMeasure() is a critical
piece of the rendering contract between your component and its
container. onMeasure() should be overridden to efficiently and
accurately report the measurements of its contained parts. This is
made slightly more complex by the requirements of limits from the
parent (which are passed in to the onMeasure() method) and by the
requirement to call the setMeasuredDimension() method with the
measured width and height once they have been calculated. If you fail
to call this method from an overridden onMeasure() method, the
result will be an exception at measurement time.
Further on in the article:
Your component's onMeasure() method should calculate a measurement width and height which will be required to render the component. It
should try to stay within the specifications passed in, although it
can choose to exceed them (in this case, the parent can choose what to
do, including clipping, scrolling, throwing an exception, or asking
the onMeasure() to try again, perhaps with different measurement
specifications).
There is an CustomView example available as a demo but unfortunately the developer website has changed (for the worse!) so that it's not available except through download by the SDK Manager. See the page here for more instructions.
For example, 200 width, 150 height. Override onMeasure method in the View.
#Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
setMeasuredDimension(200, 150);
}
From your description, it seems the issue is that you aren't specifying the size of your DemoView, you are just setting it as the ContentView, which will fill the parent by default.
Specify some LayoutParams when you create your DemoView, or create a ViewGroup to give it a size.
You could also define the layout / sizing via XML, and inflate that. (You should either make it a separate class, or make it public in this case.)
Eg.
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
...
Specify container measurements
...
>
<com.yourpackagename.MainActivity.DemoView
...
Specify layout height / width, etc.
...
/>
</LinearLayout>
In Android, layout stuff like what you're trying to do is usually specified in xml. The idea is that you set up your layout in xml (there should be a layout directory in the res/ directory in your project) and then connect your code to that layout.
Take a look at this page. If you scroll down there's a section on layout position, size, and padding.
This is a method you can override in view to get the screen devices information, goes once per device
#Override
public void onSizeChanged (int w, int h, int oldw, int oldh)
{
super.onSizeChanged(w, h, oldw, oldh);
screenW = w;
screenH = h;
scaledCardW = (int) (screenW/8); //or whatever scale you need for bitmaps
scaledCardH = (int) (scaledCardW*1.28);
bitmap = // load your bitmaps
}
You are using setContentView() which in itself means that the whole view is full screen. if you want the image to be set only a certain size you need to draw it that way.
onDraw(Canvas canvas)
{
super.onDraw(canvas)
//This code is for straight centering
//Also please do math outside of onDraw
//also below math is pseudocode not actual android code
canvas.drawBitmap(yourImageBitmap,
(screenSize.width / 2) - yourImageBitmap.width/2,
(screenSize.height / 2) - yourImageBitmap.height / 2),
yourPaintObject)
//The above code should draw your bitmap image in the center of the canvas
}
Also like answers above and below me say, if you wish to change canvas size then you need to use onMeasure and set those properly. Your best bet would be to look at the source code of the ImageView class http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/1.5_r4/android/widget/ImageView.java
and see how they do it
Related
I know there are a lot of libraries about that on GitHub and several questions on stack overflow about this argument. But no of those fit my needs.
I just need to draw something like this :
The progress line must be yellow with no thumb.
Thank you in advance.
You can use something similar to what I explained here.
Just use a rectangle instead of a circle. Use on-size changed to compute the actual size of the rectangle and have a method to change the percentage and re-compute your rectangle size / recreate your path.
When you change the path you just have to call invalidate() to cause a re-draw.
Pseudo code:
public void setProgress(float progress) {
this.progress = progress;
refreshProgressBar();
}
#Override
protected void onSizeChanged(int w, int h, int oldw, int oldh) {
super.onSizeChanged(w, h, oldw, oldh);
this.currentW = w;
this.currentH = h;
refreshProgressBar();
}
private void refreshProgressBar() {
path.reset();
// build your clipping path using progress / currentW / currentH
path.close();
invalidate();
}
You can do all with a single custom view or have 2 views on top of each other, the one containing the "fill" of the bar is clipped with the method I explained above.
Keep in mind the clipping happens on the Canvas. So if you you use a custom View just set the clipping before drawing the progress view and remove it when you are done (you can also directly draw the color in this case - but if you have a complex color pattern it may be easier to clip). If you use a clipping ViewGroup like in the link I gave you you'll have to build your layout accordingly so that the clipped view is only the progress one.
If you play a bit with math you may also be able to draw a path that match your art work and use it on a full color rectangle on top of your layout.
If you add together a Rectangle and a circle and then remove a circle (use the OP for adding / subtracting / multiplicating on the path) you should obtain a Path (shape) that resemble the one in your hand-drawing.
Good Luck.
You should create a view for this.
Take a look at Android creating custom view
Also, a more easy solution i can think of is to create a rectangular progress bar that occupes the whole width and draw on top on the middle, the play button
Android View has three versions of invalidate(): one that invalidates the whole view, and two that invalidate only a portion of it. But it only has one onDraw(), which draws the entire canvas. There must be some use that the system makes of the hint that I only want to invalidate part of the view, but I'm unclear on what it is.
I have a view that does custom drawing in onDraw(). Do I have a way to find out which parts of the canvas are invalid, so I only draw those?
When Android gets ready to render changes to the screen, it does so by creating a union of all of the individual rectangle areas of the screen that need to be redrawn (all the regions that have been invalidated.)
When your view's onDraw(Canvas canvas) method is called, you can check to see if the Canvas has a clip bounds.
If there is a non-empty clip bounds, you can use this information to determine what you will and won't need to draw thus saving time.
If the clip bounds is empty, you should assume Android wants you to draw the entire area of your view.
Something like this:
private Rect clipBounds = new Rect();
#Override
protected void onDraw(Canvas canvas)
{
super.onDraw(canvas);
boolean isClipped = canvas.getClipBounds(clipBounds);
// If isClipped == false, assume you have to draw everything
// If isClipped == true, check to see if the thing you are going to draw is within clipBounds, else don't draw it
}
There must be some use that the system makes of the hint that I only want to
invalidate part of the view, but I'm unclear on what it is.
Yes, it is. The method invalidate (int l, int t, int r, int b) has four parameters which are used by the View's parent View to calculate the mLocalDirtyRect which is a filed of the View class. And the mLocalDirtyRect is used by the getHardwareLayer() method in the View class, here is its description:
/**
* <p>Returns a hardware layer that can be used to draw this view again
* without executing its draw method.</p>
*
* #return A HardwareLayer ready to render, or null if an error occurred.
*/
HardwareLayer getHardwareLayer() {
Means that Android can refresh part of your view without call the View's onDraw() method. So you don't need to try drawing part of the View yourself, because Android will do it for you when you tell it the dirty part of your View.
Finally, I think you can refer to the source code of View and ViewGroup for more details, here is the link that you can read them online:
https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/android/view/View.java
https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/android/view/ViewGroup.java
Video of the issue here
Link to the library
The video might be a little hard to see, but what is happening is the content in the ScrollView is clipping strangely when I add a new fragment to the Activity. Instead of smoothly animating down, creates an extra margin of about 55 px (on a 720 x 1280 phone), then corrects itself once the animation completes.
I dug around the source code and found that if I comment these two methods out of the onSizeChanged() method of the PullToRefreshBase class, the animations will work correctly:
#Override
protected final void onSizeChanged(int w, int h, int oldw, int oldh) {
if (DEBUG) {
Log.d(LOG_TAG, String.format("onSizeChanged. W: %d, H: %d", w, h));
}
super.onSizeChanged(w, h, oldw, oldh);
//TODO both of these methods below combined cause the glitchy issue
// We need to update the header/footer when our size changes
refreshLoadingViewsSize();
// Update the Refreshable View layout
refreshRefreshableViewSize(w, h);
//TODO both of these methods above combined cause the glitchy issue
/**
* As we're currently in a Layout Pass, we need to schedule another one
* to layout any changes we've made here
*/
post(new Runnable() {
#Override
public void run() {
requestLayout();
}
});
}
The refreshLoadingViewsSize() and refreshRefreshableViewSize() methods are what cause the problem, together. But, when I comment them out, the PullToRefresh functionality doesn't work anymore. This is because the first method, which sets the header size, isn't being called. This means the header height is always 0, which breaks the pulldown functionality, which relies on the height of the header to work. Furthermore the header itself won't even show up, and that doesn't work.
Commenting just one out will make the clipping problem even worse, unfortunately.
I also tried a hacky fix, where I run those two methods only on the first call of onSizeChanged, and ignore them afterwards. Like this:
if(mFirstGo) {
// We need to update the header/footer when our size changes
refreshLoadingViewsSize();
// Update the Refreshable View layout
refreshRefreshableViewSize(w, h);
mFirstGo = false;
}
This works great except for one problem. When the fragment is added, the padding is incorrectly set so that the content of the ScrollView is higher than it should be. This is because the padding is set the first time, but then is never reset again. It's like if the padding is 0 the entire time that isn't a problem, but if it is set at first, it needs to continue to be reset each time the view size changes.
I think the cause of this issue is the padding change happening independently of the view change, but I'm not exactly sure. If anyone has some insight here I'd really appreciate it. Thanks!
I've got a bunch of tiles that make up a single image, that are rendered on request (by what's portion of the total image is visible on screen). The composite image is significantly larger than the screen. Each tile is positioned tightly next to its neighbors to create the illusion of a single image (the single image, if not tiled, would be too large and have OOM errors).
These are ImageViews inside a FrameLayout, positioned with top/leftMargin.
Targetting API 2.2 / SDK 8
I'm trying to scale the total image in response to user events (button presses, pinch, etc).
Apparently setScale isn't available until API 11. I tried using canvas.scale in onDraw of the FrameLayout with setWillNotDraw(false), and onDraw is being called, but no scaling is being applied (I assume because the layout itself doesn't have any graphic information? I had assumed it'd render it's children as well, but I guess not unless I'm doing something wrong here also).
I guess I could iterate through each tile and scale it independently, but would need to reposition each one as well, each time.
I have to think there's a way to scale a parent View (ViewGroup?) so that all of its children are also scaled (like every other language responsible for managing a GUI). What am I missing?
Thanks
For reference, the approach mentioned above (using onDraw of a parent ViewGroup) does in fact work. I had been using canvas.save() before the transformation and canvas.restore() after (based on some examples), which was incorrect.
The following is a generic subclass of FrameLayout that will scale it's children
package com.whatever.layouts;
import android.content.Context;
import android.graphics.Canvas;
import android.widget.FrameLayout;
public class ScalingFrameLayout extends FrameLayout {
private float scale = 1;
public ScalingFrameLayout(Context context) {
super(context);
setWillNotDraw(false);
}
public void setScale(float factor){
scale = factor;
invalidate();
}
public float getScale(){
return scale;
}
#Override
public void onDraw(Canvas canvas){
canvas.scale(scale, scale);
super.onDraw(canvas);
}
}
I've seen a few people ask how to zoom an entire ViewGroup (such as a RelativeLayout) in one go. At the moment this is something I need to achieve. The most obvious approach, to me, would be to hold the zoom scale factor as a single variable somewhere; and in each of the child Views' onDraw() methods, that scale factor would be applied to the Canvas prior to graphics being drawn.
However, before doing that, I have tried to be clever (ha - usually a bad idea) and extend RelativeLayout, into a class called ZoomableRelativeLayout. My idea is that any scale transformation could be applied just once to the Canvas in the overridden dispatchDraw() function, so that there would be absolutely no need to separately apply the zoom in any of the child views.
Here's what I did in my ZoomableRelativeLayout. It's just a simple extension of RelativeLayout, with dispatchDraw() being overridden:
protected void dispatchDraw(Canvas canvas){
canvas.save(Canvas.MATRIX_SAVE_FLAG);
canvas.scale(mScaleFactor, mScaleFactor);
super.dispatchDraw(canvas);
canvas.restore();
}
The mScaleFactor is manipulated by a ScaleListener in the same class.
It does actually work. I can pinch to zoom the ZoomableRelativeLayout, and all of the views held within properly rescale together.
Except there's a problem. Some of those child views are animated, and hence I periodically call invalidate() on them. When the scale is 1, those child views are seen to redraw periodically perfectly fine. When the scale is other than 1, those animated child views are only seen to update in a portion of their viewing area - or not at all - depending on the zoom scale.
My initial thinking was that when an individual child view's invalidate() is being called, then it's possibly being redrawn individually by the system, rather than being passed a Canvas from the parent RelativeLayout's dispatchDraw(), meaning that the child view ends up refreshing itself without the zoom scale applied. But oddly, the elements of the child views that are redrawn on the screen are to the correct zoom scale. It's almost as if the area that the system decides to actually update in the backing bitmap remains unscaled - if that makes sense. To put it another way, if I have a single animated child View and I gradually zoom in further and further from an initial scale of 1, and if we place an imaginary box on the area where that child view is when the zoom scale is 1, then the calls to invalidate() only cause a refresh of the graphics in that imaginary box. But the graphics that are seen to update are being done to the right scale. If you zoom in so far that the child view has now moved completely away from where it was with a scale of 1, then no part of it at all is seen to refresh. I'll give another example: imagine my child view is a ball that animates by switching between yellow and red. If I zoom in a little bit such that the ball moves to the right and down, at a certain point you'll just see the top-left quarter of the ball animate colours.
If I continuously zoom in and out, I see the child views animate properly and entirely. This is because the entire ViewGroup is being redrawn.
I hope this makes sense; I've tried to explain as best as I can. Am I on a bit of a loser with my zoomable ViewGroup strategy? Is there another way?
Thanks,
Trev
If you are applying a scale factor to the drawing of your children, you also need to apply the appropriate scale factor to all of the other interactions with them -- dispatching touch events, invalidates, etc.
So in addition to dispatchDraw(), you will need to override and appropriate adjust the behavior of at least these other methods. To take care of invalidates, you will need to override this method to adjust the child coordinates appropriately:
http://developer.android.com/reference/android/view/ViewGroup.html#invalidateChildInParent(int[], android.graphics.Rect)
If you want the user to be able to interact with the child views you will also need to override this to adjust touch coordinates appropriately before they are dispatched to the children:
http://developer.android.com/reference/android/view/ViewGroup.html#dispatchTouchEvent(android.view.MotionEvent)
Also I would strongly recommend you implement this all inside of a simple ViewGroup subclass that has a single child view it manages. This will get rid of any complexity of behavior that RelativeLayout is introducing in its own ViewGroup, simplifying what you need to deal with and debug in your own code. Put the RelativeLayout as a child of your special zooming ViewGroup.
Finally, one improvement to your code -- in dispatchDraw() you want to save the canvas state after applying the scaling factor. This ensures that the child can't modify the transformation you have set.
The excellent answer from hackbod has reminded me that I need to post up the solution that I eventually came to. Please note that this solution, which worked for me for the application I was doing at the time, could be further improved with hackbod's suggestions. In particular I didn't need to handle touch events, and until reading hackbod's post it did not occur to me that if I did then I would need to scale those as well.
To recap, for my application I what I needed to achieve was to have a large diagram (specifically, the floor layout of a building) with other small "marker" symbols superimposed upon it. The background diagram and foreground symbols are all drawn using vector graphics (that is, Path() and Paint() objects applied to Canvas in the onDraw() method). The reason for wanting to create all the graphics this way, as opposed to just using bitmap resources, is because the graphics are converted at run-time using my SVG image converter.
The requirement was that the diagram and associated marker symbols would all be children of a ViewGroup, and could all be pinch-zoomed together.
A lot of the code looks messy (it was a rush job for a demonstration) so rather than just copying it all in, instead I'll try to just explain how I did it with the relevant bits of code quoted.
First of all, I have a ZoomableRelativeLayout.
public class ZoomableRelativeLayout extends RelativeLayout { ...
This class includes listener classes that extend ScaleGestureDetector and SimpleGestureListener so that the layout can be panned and zoomed. Of particular interest here is the scale gesture listener, which sets a scale factor variable and then calls invalidate() and requestLayout(). I'm not strictly certain at the moment if invalidate() is necessary, but anyway - here it is:
private class ScaleListener extends ScaleGestureDetector.SimpleOnScaleGestureListener {
#Override
public boolean onScale(ScaleGestureDetector detector){
mScaleFactor *= detector.getScaleFactor();
// Apply limits to the zoom scale factor:
mScaleFactor = Math.max(0.6f, Math.min(mScaleFactor, 1.5f);
invalidate();
requestLayout();
return true;
}
}
The next thing I had to do in my ZoomableRelativeLayout was to override onLayout(). To do this I found it useful to look at other people's attempts at a zoomable layout, and also I found it very useful to look at the original Android source code for RelativeLayout. My overridden method copies much of what's in RelativeLayout's onLayout() but with some modifications.
#Override
protected void onLayout(boolean changed, int l, int t, int r, int b)
{
int count = getChildCount();
for(int i=0;i<count;i++){
View child = getChildAt(i);
if(child.getVisibility()!=GONE){
RelativeLayout.LayoutParams params = (RelativeLayout.LayoutParams)child.getLayoutParams();
child.layout(
(int)(params.leftMargin * mScaleFactor),
(int)(params.topMargin * mScaleFactor),
(int)((params.leftMargin + child.getMeasuredWidth()) * mScaleFactor),
(int)((params.topMargin + child.getMeasuredHeight()) * mScaleFactor)
);
}
}
}
What's significant here is that when calling 'layout()' on all the children, I'm applying the scale factor to the layout parameters as well for those children. This is one step towards solving the clipping problem, and also it importantly correctly sets the x,y position of the children relative to each other for different scale factors.
A further key thing is that I am no longer attempting to scale the Canvas in dispatchDraw(). Instead each child View scales its Canvas after obtaining the scale factor from the parent ZoomableRelativeLayout via a getter method.
Next, I shall move onto what I had to do within the child Views of my ZoomableRelativeLayout. There's only one type of View I contain as children in my ZoomableRelativeLayout; it's a View for drawing SVG graphics that I call SVGView. Of course the SVG stuff is not relevant here. Here's its onMeasure() method:
#Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
int widthMode = MeasureSpec.getMode(widthMeasureSpec);
int widthSize = MeasureSpec.getSize(widthMeasureSpec);
int heightMode = MeasureSpec.getMode(heightMeasureSpec);
int heightSize = MeasureSpec.getSize(heightMeasureSpec);
float parentScale = ((FloorPlanLayout)getParent()).getScaleFactor();
int chosenWidth, chosenHeight;
if( parentScale > 1.0f){
chosenWidth = (int) ( parentScale * (float)svgImage.getDocumentWidth() );
chosenHeight = (int) ( parentScale * (float)svgImage.getDocumentHeight() );
}
else{
chosenWidth = (int) ( (float)svgImage.getDocumentWidth() );
chosenHeight = (int) ( (float)svgImage.getDocumentHeight() );
}
setMeasuredDimension(chosenWidth, chosenHeight);
}
And the onDraw():
#Override
protected void onDraw(Canvas canvas){
canvas.save(Canvas.MATRIX_SAVE_FLAG);
canvas.scale(((FloorPlanLayout)getParent()).getScaleFactor(),
((FloorPlanLayout)getParent()).getScaleFactor());
if( null==bm || bm.isRecycled() ){
bm = Bitmap.createBitmap(
getMeasuredWidth(),
getMeasuredHeight(),
Bitmap.Config.ARGB_8888);
... Canvas draw operations go here ...
}
Paint drawPaint = new Paint();
drawPaint.setAntiAlias(true);
drawPaint.setFilterBitmap(true);
// Check again that bm isn't null, because sometimes we seem to get
// android.graphics.Canvas.throwIfRecycled exception sometimes even though bitmap should
// have been drawn above. I'm guessing at the moment that this *might* happen when zooming into
// the house layout quite far and the system decides not to draw anything to the bitmap because
// a particular child View is out of viewing / clipping bounds - not sure.
if( bm != null){
canvas.drawBitmap(bm, 0f, 0f, drawPaint );
}
canvas.restore();
}
Again - as a disclaimer, there are probably some warts in what I have posted there and I am yet to carefully go through hackbod's suggestions and incorporate them. I intend to come back and edit this further. In the meantime, I hope it can start to provide useful pointers to others on how to implement a zoomable ViewGroup.