I have a dynamic loaded fragment inside the activity. The fragment contains one SurfaceView in the bottom and it contains some text image. I used ExploreByTouchHelper for Talkback. It can read the context but can't draw the green square on SurfaceView. But if the activity contains some components(like buttons) below this SurfaceView then the green square can be drawn.
So it seems that the Application doesn't know that the space on screen for SurfaceView belongs to this Application. If some components added below, only then it knows that itself owns that space.
So anything I can do to get this green square back?
Many thanks.
It seems that SurfaceView by default will not enable drawing on it's surface so the talkback can't draw on it's surface. To enable this you have to call setWillNotDraw(false).
I am taking a surfaceview in xml file and drawing text,rectangle on the surfaceview by overriding ondraw() method and I want to make some part as a scrollable at surfaceview.
for reference--
https://www.youtube.com/watch?v=ycYp356qrno
in this app one page where all task are display and progress status is scrollable
pls help...
Problem statement: I would like the canvas to have the same size in both horizontal and vertical orientation. The size should be fixed and based on the vertical orientation (an A4-like canvas). Hence, I need the ability to scroll over the canvas in the horizontal orientation. But there is a conflict between the touch event used for scrolling in a ScrollView and the one used for drawing in the canvas.
What I need: I guess most could settle with this solution: fingerpaint within a horizontalscrollview and simply adding a button for allowing the user to scroll. For me this is a little counter-intuitive. What I would like is to have a thick scrollbar constantly visible on the side of the canvas, like in this app:
Following, this should also be the only way that the user can scroll.
What I have tried: Since the scrollview consumes all the touch events, I have tried overriding the scrollview's onTouch method. But this leads to the whole scrollview being unable to be touched - that includes the scrollbar.
Questions: Is it not possible to implement this with a ScrollView? Do I have to create my own scrollbar widget and align it horizontally (LinearLayout) with the view that contains the canvas? Or is there some way to have the ScrollView only consume touches on the background?
In onTouch override, you can check the coordinates and decide whether the touch was on the scroll thumb or on rest of the view.
In my android application I am stuck in a problem and nothing seems to work for me.
I have an ImageView on the top of another ImageView inside a relative layout.
Now I need to resize the imageview on top when user touches one of its corners and drags.
Just like a cropping frame we generally see. When we drag any one corner, then the diagonally opposite corner must remain fixed and the resizing must be done across the corner which is being dragged.
What I am doing is setting OnTouchListener and getting new/dragged coordinates on Action.MOVE then I tried to resize using Bitmap's createScaledBitmap. This does resize the image view but not across the corner which is being dragged. I am totally confused .
How I can use the coordinates to draw an Image View just like we do it while drawing a rectangle using Canvas.
Please help.
I wouldn't do this in an ImageView. I would subclass View and override onTouchEvent and onDraw to handle the input and draw all the various components. You have to break this down into it's components and manage a number of objects in this view.
You have a Rect that represents the size of the crop area. This probably defaults to the size of the control. In onTouchEvent, you need to test for an area around each corner and then keep track of which corner is being dragged to resize your Rect appropriately.
You don't have to call createScaledBitmap each time you draw it, and you probably shouldn't because you are flirting with an OutOfMemoryException at that point (clean up your Bitmaps too slowly and you'll find out the hard way what this is). Just decode the Bitmap when the control gets created and draw it to the canvas using a destination Rect.
Lots of code to write, but it sounds like a fun project. There's no easy way to drop in a control like this (if I'm understanding you correctly). You have to manage the touches, drags, and the destination rectangle inside the custom View.
I have a FrameLayout containing first a SurfaceView, and second a RelativeLayout which in turn contians various Buttons and TextViews.
Upon the canvas of the SurfaceView I am drawing numerous Bitmaps, and, via Touch and Motion Events am allowing the user to drag them around.
These Bitmaps, when dragged around pass underneath the Buttons etc that are inside the RelativeLayout.
Now, it's my (possibly mistaken) understanding that the "Z-level" of the SurfaceView, or whatever it has that passes for it, is entirely unrelated to the actual Z-level of the rest of the Layout. Is this the case? If so, how may I get around it, so that dragged Bitmaps are drawn ontop of other Views? Or what other way can I implement a full-screen canvas and yet not have my buttons etc act like the controls of an overlay.
I guess what I actually need is an underlay, where touch events can still be picked up by the Buttons etc underneath. But I don't know how to achieve this, as, when redrawing my Canvas, I have to also redraw the background.
Can I swap the order of the RelativeLayout and the SurfaceView inside the FrameLayout, and then make the background of the Canvas transparent? If so how? Will touch events still "fall through" to the buttons underneath?
Thanks for bearing with me, I know I'm a bit of a waffler.
SurfaceView doesn't work that way.
SurfaceView has two parts, the "view" part and the "surface" part. The "view" part is a transparent hole that is laid out with the other view elements, and composited onto the view layer. The "surface" part is a completely separate layer that will be positioned and scaled to match the "view" part, and composited by the system compositor rather than the app.
You can control the Z-order of the "surface" layer when the SurfaceView is first created, but it's going to be above or below all View elements. It can't go above some Views and below others because they're completely independent layers. The "surface" layer does not catch input events, so having it on top (via SurfaceView#setZOrderOnTop()) doesn't affect input focus.
For API 14+, you can use a TextureView, which behaves in a more View-friendly way.
Edit: for full details, see the much longer explanation.
Can you clarify a little bit more? In your SurfaceView do you have a background assigned? If not, you could probably also use AbsoluteView if your intention is to simply drag pieces around. If there is no background, you should be able to place the entire view above the RelativeView that you have and only have the various Buttons and such drawn on the view on top, which would be draggable and remain above everything else.