I've been fighting for a while with https://github.com/commonsguy/cwac-camera
Managed to create my custom CameraFragment and a custom custom CameraHost.
I've overrode getPictureSize and getPreviewSize. With those two methods I'm able to find out which Sizes are able to be used. My overall idea is to capture a square image, and also preview it before capturing.
I've been testing and no device is returning a square-formatted Size, so I guess the best approach would be taking the Size nearest to my needs. Like if I need an 800x800 squared image, I will return the nearest Size, that would be (for example) 1280x1024
So far so good. The issue is the following:
Documentation states:
Usually, your CameraHost will be called with getPreviewSize()
Damn; my Nexus5 device never triggers this method, but a Genymotion emulator does. So in my emulator I can create a custom preview size, which I can't with my real device.
So I need some help with this issue. Why is it just "usually"? What can I do to change it to "always"?
On a second term, I need some tips: If I want an squared preview size, which I know it won't be available by default Sizes returned by getSupportedPreviewSizes, what can I do to display an square? Maybe overlaying a square on top of CameraFragment? Is it even possible? Or should I go for any other approach?
Anyways, congratulations on the library; it's absolutely clear and with so many options. No need to worry about "some devices". That's great as an Android Developer.
Thank you.
Why is it just "usually"? What can I do to change it to "always"?
Quoting the documentation:
If getRecordingHint() returns ANY or VIDEO_ONLY, though, CameraHost supplies the preview size via getPreferredPreviewSizeForVideo() instead of getPreviewSize(). If you wish to use a different preview size for video, return it, otherwise return null and we will use the results from getPreviewSize() instead.
On API Level 11+, the implementation of SimpleCameraHost getPreferredPreviewSizeForVideo() delegates to the getPreferredPreviewSizeForVideo() implementation on Camera.Parameters, except for devices known to return poor values for it.
what can I do to display an square? Maybe overlaying a square on top of CameraFragment?
I would try putting CameraView directly in your own UI, then layering something on top of it, using a FrameLayout or RelativeLayout to control the Z-axis ordering.
Related
I have a custom widget. It's purpose is to display an image (with possibility of scaling, rotation etc).
My goal is to calculate initial scale of the image so its size would match widget's size.
My first attempt was to do it in constructor, but it wasn't right place (as widgets are usually put into layouts after construction, so their size change later).
Another way, which partially works is to override showEvent or resizeEvent and put there initial scaling. It works partially, because it works fine on desktop but for some reason it doesn't on android device - QWidget::size() returns the same size as in constructor.
Apparently on android first show/resize events are called before final window rearrangement.
Is there a clean way to achieve it?
You can try using a QLabel, either instead-of or inside the widget (you can set its border to 0px) and use setScaledContents.
I have made my game, which scaled accordingly to a % of the screen width with the Gdx.graphics.getWidth() method, and it works perfectly on all screens.
Now I am trying to learn viewports, but seems like there is a lot more trouble, like when does it take in world coordinated or when does it take actual screen pixels.
Do I have to constantly convert beetwen these two measurments? It seems like there is alot more trouble, than if I just scale it the old fasion way...
I can use the whole screen, and manually make the pictures non streched, if I used a FitViewport I would have like blackbars and the game would be totally different.
Any clear suggestions to why to use these ports, cause I cannot seem to understand them...
The thing is that you do not have to do anything especially making any conversion.
Viewport is a kind of tool that handling your app's rendering on many types of screens (I mean many other ratios) and you do not have to worry about it anymore.
Only thing you have to do is to "tell" viewport what is the size of your screen and to handle screen resizing by updateing the viewport. Then you are treating your app like it would be always for example 800 x 600px no matter how it looks actually.
The way your app will render depends on what viewport implementation you will use. For example:
FitViewport will fit your screen to device and add some black bars
FillViewport will fit your screen to device and cut off overflowing part
and so on...
The a look at official Viewport libGDX tutorial. Also you can take a look at this thread to get some information how to deal with viewports.
I'm making an app (a game, to be exact) where each activity uses a SurfaceView for the UI. All of the drawing is done through onDraw. I am also designing this to use no Bitmap assets, so everything that is drawn is produced directly by the app. I'm trying to design the app in such a way that it can easily be viewed on any screen size.
So here's how I'm accomplishing this: I'm doing my testing on a Galaxy S4, which has a screen size of 1080x1920. In the constructor for each activity, the width and height of the current screen are calculated and stored as ints "w" and "h" (the app is already locked in portrait). Then, whenever anything needs to be drawn onto the screen, I multiply the desired dimension (as seen on my 1080x1920 screen) by either w or h, and then divide by 1080 or 1920. Since I'm not using any Bitmap assets, I never need to worry about pixelated images or anything this way.
This gets the job done, but seems like a bit of a roundabout way of doing it. I figured there would be a better framework for getting this done, and I'm worried that these big calculations are eating into my drawing time (running at 30FPS can get a little jerky).
Is this is the customary way of doing it, or is there a better way out there?
There's a very simple yet effective way to do it, you can declare all your sizes in a dimen file for each specific density/size, as you usually do for layouts e.g:
values/dimens.xml <--- With default sizes
values-sw600dp/dimens.xml <-- Tablets sizes
(etc...)
Now before you start drawing, load all the values in your program only once, maybe onCreate of your drawing activity, using the following command:
float someItemSize = Context.getResources().getDimension(R.dimen.some_itemSize)
etc...
That way, you let the operating system do the pixels conversion for you, you should do it only once and most important, this will give alot of flexibility to your code because you will be able to change sizes from xml files without even touching your actual code, hence, the customization should be easier as well as future changes...
Hope it helps!
Regards!
There are two considerations: screen size and screen aspect ratio. If you simply scale everything to match the display, you will appear stretched a bit if you put a 4:3 device next to a 16:9 device.
You generally have two options for dealing with the aspect ratio: you can letterbox / pillarbox the output (which is fine for movies, but looks kinda lame for an app), or you can recognize that your output isn't always proportionately the same, and adjust the layout to fit nicely on the screen.
As far as size matching goes, when using a SurfaceView you can actually use a single size and then let the hardware scaler handle the rest. For an example of this, see the "Hardware scaler exerciser" in Grafika. I put a demo video here, though it's a bit hard to evaluate after getting rinsed through screenrecord + youtube. What you're seeing is the same couple of shapes rendered onto a Surface whose size has been set to an arbitrary value, and then scaled up to match the display. This is most obvious on the final setting, where it's drawing on a 106x64 surface.
With this, you could size your assets for 720p and always draw them the same way, and let the scaler deal with the stretching. See also this blog post.
I am newbi in android world and working on an android app.
I have used many of buttons and image buttons in my app.
Now i want to replace them with an background image. (So i can make nice gui easily)
I know i can use view listener and i can find the clicked x and y coordinate from onclick method.
But I want to how can i find which part of the image was clicked. Because different phones have different resolutions how can i do this efficiently ?
And one more thing, Is it good to handle gui this way ?
Thanks !
You first need to set the initial window width and height before execution of other code and load an image of quality based on the screen size. so for example you can have 3 sets of images of different size. One for 5 inch screens and below. Another for 7 inch tablets. Another for 10 and possibly another super high quality image for anything above. As many devices coming on in the near future are reaching resolutions much higher then previously developed for. Just run code initially that detects the initial window size at hand and load image based on resolution of that device. From their program as you plan to.
Also to jump on answer above. Detect rotation event and adjust image accordingly. and update accordingly. You are adding more programming of course but no reason what you are asking could not be done. Just a few extra events detection and you should be good to go to accomplish exactly what you are looking to do
AFAIK it is not good practice to handle the GUI this way. Mostly because android screen size is not standard and so you can never be sure that it will work perfectly in all the devices. You can ofcourse handle the events using onTouchListener and see which part of image was clicked from the coordinates in the MotionEvent Object. But, I would not recommend doing so.
Creating layouts of different screen sizes and handling the events using Buttons and ImageButtons will be good.
you can use android:background attribute for background images in the layout xml files...
however you also can set the background of UI element programatically
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