i have done a view apps with setContetnView and the xml layouts... Actually I do some steps in opengl. Now i want to have one background image, a video area an the opengl 3d navigation element beside the video area to control the videos.
Is it necessary to do the whole work in opengl, or is it possible to put the opengl part over an existing view?
Where can I find more infos on this?
You can place the OpenGL view over top of the other views. I worked on an app that placed a OpenGLView over top of a VideoView. There may be some performance issues, so I would recommend adding the hardware acceleration attribute to your AndroidManifest.xml (under the application element):
android:hardwareAcceleration="true"
One thing that you will need to know to get the layout you expect is that the SurfaceViews do not conform to the normal view hierarchy, so you will want to set the z-order of the view programmatically, using the method setZOrderOnTop:
mVideoView.setZOrderOnTop(false);
mOpenGLView.setZOrderOnTop(true);
Related
I am trying to implement the above layout in my Android app.
Basically its two images filling the whole screen, but with a "slider" that is draggable and masks one image over the other. The labels are just some text relating to the image, and should also be masked over when dragged.
So far I haven't been able to see how best to do this using standard layouts, and have been thinking of how to implement this using Canvas.
Any help/tips on the most efficient way to implement this would be appreciated.
NOTE: The slider is supposed to work a lot like the one in the gallery image editor in stock android gallery - except that it stays in place after letting go.
I ended up using LibGDX and making a custom scene for everything.
Didn't find a way to do this using built-in layouts.
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 have a CustomIcon class that displays a png using ImageView. I m going to want to be able to place another image view overtop of it on the fly and be able to hide/show the overlay. Can someone point me to a good tutorial to get me rolling?
It sounds like you would be well served by a RelativeLayout. This layout allows you (among other things) to place Views on top of each other.
You can see some "official" docs, and also a tutorial from Learn Android.
I have a 'Portrait mode' tabbed based application that contains a SurfaceView (with a camera preview on it) within one of the tabs. I have been creating my camera code from the Android API Demos and I have it all set-up working correctly bar one thing. The resulting camera preview is stretched and scaled making the preview look off.
Ideally I want to render the SurfaceView at the native preview size defined by the camera within the tab. However that would involve making the contents of the tab larger than its parent! (Or rather larger than the FrameLayout the tab activities are contained in).
How can I go about Achieving this?
Image of problem:
Make the FrameLayout the root object, then pile the camera view in it, then header and the tab widget. You may have to do some fancy work with gravity settings and stacking the header/footer in linear layouts but it definitely is possible.
aka:
frame.addView(cameraPreview);
frame.addView(header);
frame.addView(footer);
This will draw the objects in layers.
EDIT: If you don't want to use your current frame layout, just make another one. Stack the header, frame layout, and footer inside a linear layout. Create a new frame layout, add the linear layout to it, then add the preview onto it to draw over it.
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.