I cannot get a view outside the view hierarchy to update it's drawing state. I have a view that i handle the drawing and measuring of as i for a couple of reasons cannot let the container view do this. This works great until i start dealing with views that contain an animation. Even though i repeatedly draw the view it's animation does not change progress. Without knowing that much about the underlying view system i am guessing that this is because animations get updated during traversal of the view tree. because my view is not part of this tree it will not get updated.
The view i am talking about is the "sticky" view in this library https://github.com/emilsjolander/StickyListHeaders
The reason why i handle all drawing of this sticky view myself is because i cannot add i subview to the ListView. Wrapping the ListView together with the sticky view in a FrameLayout has also been tried (fixing this issue but causing other unwanted ones).
So what i want to know is if there is some way to manage all this myself, preferably without the use of reflection. I am also open to suggestions of how to let the underlying view system handle this view!
Related
I'm currently trying to design a ViewGroup (specifically a subclass of FrameLayout) that can layout any number of subviews and enable them for drag/drop outside the layout group. It's almost identical to a LinearLayout:
Curently I am able to drag the views outside the ViewGroup and draw them, however after letting go of the view it can't be re-selected and further dragged around.
I'm wondering if there is a way to do this in a way that isolates the logic to the Layout subclass and doesn't involve needing to do much/any extra stuff in consuming fragments/view groups.
I've tried overriding getHitRect(Rect) in my FrameLayout subclass but it never seems to be called. dispatchTouchEvent(MotionEvent) is of course not called either, presumably because the parent ViewGroup has decided not to deliver the touch to it because it was outside the bounds. I've tried implementing a TouchDelegate as well, but I think that needs to be set on the parent view, which means needing to know about this and doing this additional step when using this Layout.
Any ideas on if/how this is possible? On iOS it can be implemented fairly easily by overriding hitTest: to take into account the frames of the child views. Is there a similar method like this on Android?
Your help is greatly appreciated!
Without any code it is very hard to see what you are doing, but best guess would be that each view should a child view of the relative layout.
I am trying to draw a View in a ViewGroup without adding it to the child list.
I am doing this because I want to display something like a ProgressBar in the exact center of layouts like a LinearLayout so I don't want the layout to handle the measuring and layouting.
I also don't want to complicate the view hierarchy by adding extra layouts just to achieve this effect so my solution was to extend the LinearLayout, create a ProgressBar and handle measuring, layouting and drawing for that view myself.
My implementation seems to work ok from what I tested but I am wondering if there is anything I am not noticing or if there are any problems that can appear in the future.
From what I understand calling addView also sets the child view's parent and calls dispatchAttachedToWindow, these methods are package-private so I can't call them myself.
Is there any side effect that can arise from calling measure, layout and draw on a view that has no parent and that was not "attached" to a window? Is there a safer way to achieve the same effect?
Thanks.
Scenario:
I am creating a drag and drop feature within a linear layout. It is a very simple layout: one LinearLayout at the root and many Views within (for testing purposes they are just instances of the View class with different coloured backgrounds). I have created the system, you can 'pick-up' a View which is caused by a long click on one of the child views. This creates the drag shadow and at this point I call removeView() on the container to give the impression that the view has been picked up. I keep this view in memory. As the view is dragged around, a placeholder view is moved around to show the eventaul drop place for your drag location if you were to let go of the dragged shadow. This also works well and the removed view is then added back at the index where the placeholder was.
Problem:
When enabling 'android:animateLayoutChanges', the animations make this whole process look a whole lot smoother. The one artifact created by this is that when the dragged view is dropped (the same view that was removed when the drag started gets added back into the container) shows a transition animation from the dragged view's original position to it's new position. When adding a new view (for instance the placeholder gets created every time it changes position) it fades in instead.
Analysis:
From the looks of it, the container is remembering the view that was removed and so when the same view is added again, the animator interprets it as a move as opposed to a new view being added.
Question:
How can I prevent this behavior of the animator interpreting removing and adding the same child as a movement as opposed to separate remove and add operations?
Answer:
This is where you come in.
Thanks in advance.
I've been working on a custom view but am having some serious UI Thread blocking issues when attaching a large number of inflated views to tje custom view (which simply extends a FrameLayout).
While I've tried moving the child view creation from the Main Thread into a background thread, to the point that everything is set up in a thread then a single ViewGroup is added to the activities content view, but the problem with this seems to be that rather than staggering the view laying out and drawing, it is essentially invalidates everything in one go.
Does anyone have any experience of staggering this or have any suggestions how to overcome this issue?
Thanks,
Matt
Can you post more details so that we can understand why the View creation is taking so long?
I don't believe that you can stagger this. Pre-Honeycomb invalidating a ViewGroup caused the entire child hierarchy to re-draw :(
See this great I/O talk for more details.
I have extended LinearLayout (vertical) to create a custom compound component. This in turn contains two children:
one custom view that is drawn directly onto the view canvas.
one HorizontalScrollView->LinearView(Horizontal)->Multiple custom views.
I would now like to redraw the custom view to match the visible contents of the scroll view. The reason for this is that the long array of custom components in the scroll view are mainly static and suitable to be drawn ahead of time, while the top view is supposed to be highly dynamic and relate to whatever things are visible in the scroll view.
I hope I made the problem/idea somewhat clear. I am not att all confident this is the best approach, and I'd enjoy hearing any suggestions on alternative solutions or perhaps some idea on how to trigger a redraw-event everytime the scroll position changes in the HorizontalScrollView.
Thank!
You can have your activity listen to the scroll view adapter. in the adapter when ever the scroll position changes you execute the delegate in the Activity.
That way the activity can update the rest of the views upon scroll view change.