I am trying to play a videoview on top of another video view. The first video view is paused, while the second is playing. It appears to work but no second video appears on the screen (though I hear the audio and see the controls that would normally appear on top). I am assuming this is some sort of order issue. Any thoughts. By the way, I have no problem displaying other views on top of the main video view and having the video fill the background.
That won't work - the VideoView is special in the sense that it 'punches' a hole in the normal Views to allow direct access to the display pixels (or, in android terms, the 'Surface' - VideoView is a subclass of SurfaceView). You cannot layer two SurfaceViews on top of eachother - the first one that grabs the pixels (the Surface) will 'own' it. (see SurfaceHolder.Callback.surfaceCreated() / surfaceDestroyed())
Other Views on top of a SurfaceView do work, because the framework will compose the display bits of normal Views on top of the Surface. It cannot do that with another VideoView (i.e. a SurfaceView) because there is nothing to compose.
<VideoView android:id="#+id/videoView1"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
<VideoView android:id="#+id/videoView2"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
when videoView2 starts playing setvisibilty of videoView1 invisible.
then you can make it visible when you need.
Use Thread to control both video
I don't know if this is helpful at the moment, but I managed to get something similar to what you want...
I needed to nest a VideoView on top of a SurfaceView; as long as they don't overlap 100% it can work. (what i mean is, my surfaceview is the whole screen and videoview is just a small portion of the screen)
The thing is - since you can't compose SurfaceViews, the first one to grab the pixels is the one that will be shown. Intuitiveness will drive you to Z-order your prioritized view AFTER the less-important one in the XML - but as I've said previously, the first one to grab the pixels stays, so make sure you define the smaller view FIRST, and then overlay it with the bigger one.
This will result in such behaviour that the smaller (in my case preview view) acquires the said X * Y pixels, and then the 'background' surfaceview (which is supposed to be on top of it according to the XML) takes up the rest and ignores the smaller surface.
I'm not too sure about handling events from those two though as I only have to play streams in those two views and not react to any kind of clicks/events generated by those two components, but it might be expected that if you followed this route - the bigger view will intercept all clicks made in the smaller view area (because it's on top according to the XML) so maybe you have to programatically move it on top as well upon creation.
Hope it helps.
EDIT:
Although... it like it just works once. It's a work in progress really. Upon returning from any activity, there's nothing i can do to prevent the bigger view claiming everything :/
you can add videoview a on top videoview b,like this,
parentview.removeview(a);
parentview.removviewe(b);
parentview.addview(a);
parentview.addview(b);
parentview.invalidate();
Ti's work for me. I hope it can helps.
Related
I got a SurfaceView, in which I display a bitmap that is much larger than the actual area of the SurfaceView, so I have implemented a way for the user to slide their finger on the bitmap and move it up and down. When doing so, I would like to be able to display a vertical scroll bar, preferably the standard Android scroll bars, instead of drawing something custom.
The thing is, I would like my SurfaceView to stay the size of the screen, that is I don't want to scroll the SurfaceView itself, I just want to create the illusion that the user is scrolling the contents, and therefore display the scrollbars.
I tried setting android:scrollbars = "vertical" in the layout's XML, I tried mSurfaceView.setVerticalScrollBarEnabled(true); and I tried awakenScrollBars(); whenever the user touches the SurfaceView, however none of those displays the scrollbars.
So, is it possible to display the standard Android scrollbar on a SurfaceView?
short answer is: no!
everything that the SurfaceView ever draws on the screen is whatever you directly call to be drawn using the whole lockCanvas and unlockCanvasAndPost that you know about.
Putting those parameters in the XML make it possible for you to read them in Java via the AttributeSet in the constructor, but that's only for configuration, it won't drawn anything.
I would like to make a simple Android game where a large background image is displayed and some other images are displayed in specific locations over it, where the other images may be clickable.
Here's a quick sample image of what I'm talking about:
The user should be able to tap the soccer player or the moose (ah, the classic "soccer player moose problem"!)
How should I render this screen (which layouts and views?) so the user can interact with it and it will scale properly on different devices?
I would use a RelativeLayout.
You can set the you background image to the layout (fill_parent for height and width).
You can then put your ImageViews, containing your moose and soccer player down on the layout relative to the top or sides of the sceen, or relative to each other (making sure to specify "dp" units for everything). Set the backgrounds of your ImageViews to be transparent, and there won't be a bounding box problem (and/or you can also set your ImageViews alignment to be relative to each other, ensuring they don't overlap).
I think this is the simplest way to do this - it is then super easy to attach onClickListener to your ImageViews in your Activity, and you are done.
This type of layout will work the same on all devices and screen sizes.
There are some small gotcha's with RelativeLayouts, but they are pretty simple once you get into them, and provide fast rendering (since the view hierarchy is usually shallow). Good Luck.
ImageView for the clickable elements seems like a fine choice to me. For the background I would just set your image as the background of the parent layout i.e. RelativeLayout
SurfaceView for the whole thing (with your field as a background) and regular *ImageView*s for added elements. You can easily recover the click coordinates from the SurfaceView and thus know what element has been touched.
SurfaceView might offer you additional possibilities anyway.
For most images, I'd use an ImageView for each one, like FoamyGuy said.
If they're close enough for overlapping bounding boxes to be an issue, you can still use an ImageView for each, but with a variation of this answer, testing alpha for each ImageView in range.
I would agree with both FoamyGuy and Booger that if your only goal is to place static images onto the screen that do something when you click them, RelativeLayout and ImageViews all the way.
But...
If you are looking to randomly spawn multiple images onto the screen in intervals and have them move around for the player to interact with while explosions are going off and maidens are being kidnapped, you should look into SurfaceView, Canvas, Drawable, TouchEvents, and FrameBuffers.
I wanna start a new project. A little "Jump n Run", but I have questions:
The levels will be bigger than the screen. How can I make a big Layout and edit it?
And how do the view "follows" the player, if he moves.
I dont want code samples. I only want basic ideas how to do it.
I suggest you have a look at the SurfaceView. It allows you to render bitmaps to the screen. In your case you could create a bitmap that is larger than the screen and have the user navigate it with the use of their finger (so you'll also have to also use your touchscreen). Basically what you will be changing when the user wants to go to a new location would be the src rect parameter in the drawBitmap method.
I hope this gets you started.
You could specify the layout to whatever pixel size you want (even if it's larger than any screen size would be), and then use scroll views to allow the user to scroll to other areas of the screen. Check out the Android developer docs on horizontal scroll view.
everyone. I have a project where I need to display a video within a VideoView in portrait orientation, but I've been running into a weird issue for the last couple weeks. Also note, this issue only occurs the first time the VideoView is loaded with data.
This is a very stripped version of the layout:
<RelativeLayout>
<RelativeLayout>
<VideoView /> <-- W:fill_parent, H:wrap_content
</RelativeLayout>
</RelativeLayout>
Now for the actual issue: when the VideoView is first loaded with data, both its height/width fill the entire screen (minus the padding space) for less than a second (up to 3 seconds, depending on whether it's local or streaming), then it magically adjusts itself to the intended size.
Since it takes longer for videos not stored locally, I feel as if the issue has to do with the VideoView taking time to load the video, and not adjusting its boundaries correctly immediately, which is why it expands to fill the screen, then suddenly drops down to the appropriate size.
Now, I believe the reason it doesn't do that every time is because it's still using the same instance of the VideoView each time it's loaded (since it's using a ViewFlipper and not setContentView, it's not creating a new instance of it).
However, I'm loading the data into the VideoView in the same way, and I don't understand why the issue doesn't persist, which makes me think my assumption of why it's doing that is wrong.
Now for what I've tried:
I started with a width of fill_parent and height of wrap_content for both the RelativeLayout and the VideoView, which is where I noticed this problem initially. Also note: the graphic layout in Eclipse shows the same issue with these settings that I'm trying to solve: the VideoView is expanded to fill the screen, minus the padding it has).
I've tried forcing the layout to a specific pixel dimension in the XML layout (terrible, I know), and then defining new LayoutParams for the views and setting them after the video has been properly loaded.
I've tried creating a new VideoView dynamically and adding it to the layout after it's been loaded; still no luck.
And now I'm out of ideas... Anyone else have some?
And thanks in advance for your help~
EDIT:
As a workaround in the meantime, I created an onPreparedListener() for the VideoView, and keep the view hidden until the onPreparedListener is fired off. That seems to solve the problem, but I'm more curious as to why the VideoView was doing what it's doing, not necessarily just how to fix it.
Thanks again~
This might be a "duh" question but I'm going to go ahead and ask it anyway.
I have an oversized (bigger than the screen) RelativeLayout, and I'm using swipes to start a TranslateAnimation from viewing one part of the layout to another. Say for instance the layout is two screen wide and two screens tall. After the nice animation to shift the screen, I was using View.scrollTo() to set the new position. This works fine going from the first screen (top left at 0,0) to one of the others. When I swipe to animate back to the first screen though, because the View.scrollTo() invalidated that part of the layout (I assume), that part of the layout is all black as I animate through it. I tried a couple things to get it to redraw itself after the scrollTo() but haven't had any luck, so I figured I'd ask here.
thanks!
joe d
I can't help with your specific problem since I've never tried working with a layout bigger than the screen, but there might be another way to achieve what you're trying to do. If you simply want to be able to finger-swipe from one View to another, without ever displaying part of one screen and part of another (i.e. you aren't smoothly panning around a large View but rather just jumping from one distinct section of the layout to another), then these tutorials might help, here and here. They show you how to use touch events and the ViewFlipper widget to change between Views using animations.