I have a layout where the top part is used to display some data (eg. simple UI widgets) and the bottom part has a SurfaceView where I display a CameraPreview.
In order for this SurfaceView to extend the whole width of the screen and at the same time maintain a correct aspect ratio, the SurfaceView actually goes offscreen which is fine since I actually want the app to be divided evenly between the top part and the bottom part.
The problem is that I now want to retrieve only the visible part of the SurfaceView (ideally as a bitmap) but if I try to do it by setting a PictureCallBack, the aspect ratios of the picture data returned are just not quite the same as the ones shown in the SurfaceView (I've tried with all of the available getSupportedPictureSizes).
Any ideas how to tackle this problem? I've attached an image which better illustrates this problem.
https://code.google.com/p/zxing/downloads/list
it contains a barcode scanner project in that they have used a rectangle and capture particular area from the surfaceview it will be useful for u .. Hope so they use viewFinderView class to capture the area from the surface
Related
I am working on a widget, where I need to have a chart displayed in addition to some text fields. I have figured out how to generate a visualization of the graph and then convert it to a bitmap, which gets placed in the ImageView. The problem is the following:
In a normal Android app, I would get the width and height of the ImageView and pass these as parameters for the bitmap generation. This way, the image will be fitting perfectly within its container. Since I am using a home screen widget, this is not possible, as far as I am aware, though. As a result of this, I am trying to derive the size of the ImageView by trying to figure out what size would the text fields have, but I also have to calculate those and so far have had no luck with getting it right. What I end up with is always having excess space above and beneath the image, or on its sides and the size of this is really varying according to the screen the widget is presented on. You can see some examples in the two links below.
Example A This is the default widget size. For this screen, only a small gap can be seen on the sides of the graph.
Example B Resizing the widget and recalculating the size leads to having bigger gaps on the two sides, though. For other screens the issue can be even more jarring.
My question is:
How could I get/calculate the necessary resolution for my bitmap?
I am working on listView item in Unity and stuck at fitting the image properly in UI Image. I tried multiple things using Preserver Aspect Ratop, using Filled image type almost every thing but could not make it look fine. In android we call it center crop what i am trying to achieve. First image is with Preserve Aspect while the second one is without it.
What should i do to achieve it.
Thank you.
This is one way to do it that I can think of, using 2 images. The outer image is set at your desired size and have a Mask component:
The inner image is set at center of the outer image and scaled to fit the outer image (either programatically or by hand) It will be cropped by the outer image's mask and only display the area you want.
I'm developing an Android app that uses ZBar as a QR code library, and things are going sweet. Now, however, I'm building the interface for the app, and it requires that I show only a certain portion of the camera's feed at the bottom of the screen, something like this:
The camera view below should be full-sized, i.e. a cropped view and not a resized one. However setting the width and height of the FrameLayout has caused it to resize and squash the entire image into the tiny frame.
Is there a way to crop it? I know I could probably place an overlay over the original image, but how does one create a transparent square in the middle to display what I need?Besides, the QR reader would catch anything the camera captures, so if the user brought the QR code in front of the camera and it captured it "off screen" (by the part that's actually covered by the overlay), it would be extremely confusing.
So I guess what I'm saying is, I can't use an overlay to "crop" the picture. Is there any other way to do it?
As far my knowledge one cannot crop camera view but what you can do is re-size the frame and then capture the image.
Still i would suggest to refer this post
The first thought that comes to mind is to put your CameraPreview in a view inside a FrameLayout. Then add more views on top of the CameraPreview view to hide the parts that you do not want to be visible.
Or Perhaps just one view super-imposing the camera preview view with a PNG which covers everything with "cropped" area set as transparent.
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'm entirely new to Android development, and I'm interested in making a live wallpaper. I was thinking about looping a set of pictures instead of drawing the animation. Is this a possible approach? If possible is this a suitable or ideal way of doing it, does it eat up memory and would i need images with different resolutions because of the fragmentation?(hundreds of different devices)
Thanks in advance :)
Sure, it should be fairly simple.
The main part of the Wallpaper engine is the Drawing of course. You need to handle the drawing manually, there is no easy way to loop through images... you need to code it. You will have to continuously monitor the time which has passed and adjust the displayed image based on that. You are given a Canvas object to draw to and it is all done during run-time in code.
The Wallpaper engine class has a event called onSurfaceChanged which gives you the width and height of the Surface which you will be drawing to. It will be called everytime the screen dimensions change (like if the phone is put into Landscape mode for instance). You need to have code that will handle any combination of width or height for all the device types out there. You will need to decide if you are going to stretch, center, tile or crop (Or a combination of those) the source images to fit any particular screen size. I would recommend scale to fit so that the image is either taller or wider than the screen and center the image either vertically or horizontally (cropping the extra bits) once that is done. I personally just use one source size and resize it to fit. You can opt to use several source files if you want which is the recommended approach I believe, but it's a little confusing.
I would start by creating a Live Wallpaper which just draws something basic like a shape to the screen. Then work out how to display an custom image and take it from there.
Good luck
You will need to be very careful about memory if taking a frame approach to animation--probably will not be possible to animate full frames--much more practical to move sprites on a background. See, fr'instance: http://davidjhinson.wordpress.com/2010/05/19/scarce-commodities-google-android-memory-and-bitmaps/
what if you have a png frame animation that is set at a certain x and y position that sits in a spot on the background image, both would have to be rescaled