So without a screenshot you guys won't know what I'm talking about.. So here we go:
This particular part of my application I need to do an overlay over the camera interface as seen in the screenshot. 2 rectangles - And when you take the picture, I want to end up with 2 images, the cuttings taken from the 2 rectangles.
If this doesn't make sense, please comment and ask for clarification. I honestly don't even know where to begin with this one. What would be a good starting point? Is this even possible?
I guess you will have to create your own Custom Camera:
http://developer.android.com/guide/topics/media/camera.html#custom-camera
where you can implement your own preview layout - thus you can put those frames over camera preview as you wish
but it won't be easy as many of devices exists with many different camera resolutions, some work only in landscape, even though their native interface is portrait, it's a fake landscape; and also aligning those frames with the picture you'll be actually getting will be a challenge; but definitely this is Custom Camera - good luck
I have a basic noob question which I'm sure many of you can easily answer.
I am finishing up a game I am making in java. It is a windowed game, and I am not using any flow layouts. In other words, I am placing the images and buttons myself using setbounds, etc. I want to port this game to android, where it will be full screen.
I have heard that I should use Eclipse or libgdx to do this. My question is, will my game still retain its dimensions on an android phone? Will it scale to a viewable size
or will I have to adjust everything on my game to make it fit?
I'm also wondering how difficult is it to port it.
Thanks for your help.
will my game still retain its dimensions on an android phone? Will it scale to a viewable size? Or will I have to adjust everything on my game to make it fit?
Yes. If you use a camera in libgdx (which you should!). It will scale everything to fit the screen, stretching it. But you can easily set it to keep aspect ratio and show black bars at the sides. For example this.
I'm wondering how difficult is it to port it.
The library is very easy to use, it depends on your current game design/implementation. But yeah, it must be very easy.
If you are not using libgdx at the moment it will be hard to port it to libgdx. May be a big part of your game has to be rewritten. But if you are allready using libgdx for the desktop version of your game you only have to handle the different input type (most times on android phones you use touch input instead of keyboard). If you are using libgdx but you are not using camera, you should definitly modify your game to use camera. By doing this you do not depend on screen aspect ration (One possible solution). Also you should then keep in mind, that on android the method pause() is called when call is incoming or homebutton is pressed and resume() is called when user returns to game. Hope this helps.
I have multiple geo-locations that have a weight of +1 or -1 in an android app. I'd like to be able to plot these points as an overlay to a google-maps activity. I thought that the best way to view the data is not on a point-by-point basis but by shading regions depending on the average density of its values. I have done a few searches and I want a heatmap-like rendering and was wondering if anyone had any direction as to how to accomplish this.
If you are okay with using a library then you can use Mapex.
https://code.google.com/p/mapex/source/browse/MapExLib/
I'm making an app in which I would like to implement an offline map service for the city Rome, I thought the simplest way to do this was to implement an high-resolution map-picture of the city, but now I am getting into two problems:
If I add a picture in eclipse to my app it is being scaled down to the size of an icon and when I scale it up again it has very low resolution, how can this be solved?
Do you have any experience with multi touch or zooming possibilites? Because when you have the map people would like to zoom in to see street-names in detail. I know you have to give the fingers coordinates x,x and y,y but is this the easiest way and how should I continue?
When designing an UI, we need to target many android mutations and various screen resolutions.
How to differentiate layout for 480 * 800 and 480 * 854 screen resolutions in android?
how to layout support for various screen in android?
Both questions above recommend to use different Layout code for different screens. Is it really necessary?
http://developer.android.com/guide/practices/screens_support.html
recommends to
Provide different layouts for different screen sizes
Provide different bitmap drawables for different screen densities
But I still think, we can support multiple screens without creating standalone layout for each screen resolution. Or am I wrong?
I know, and I do use, 9-patch for scalable background images (or form inputs, and so on)
and I do use dp (density pixel) to declare sizes relatively to screen density
But what are next best practices ?
I think the answer to this has changed recently, but I'll go over historical solutions.
Pre-Honeycomb, the solution was to create a dynamic layout that could adjust itself to the size of the screen (using 9-patches, dips, layouts that expand/shrink, etc.). This meant that none of your Views could be "pixel perfect", but you could adjust to different aspect ratios that you encounter. Sometimes you would come up with different layouts for landscape and portrait, but beyond that customization wasn't necessary.
With the release of Honeycomb, the problem got a lot more complex. Now you've got dramatically different screen sizes, where your app stretching doesn't look good at all. You've got tablets that stretch from 7" to 10" - which one is "large" vs. "xlarge"? 3.0 and 3.1 were an awkward period, where you had to detect the API version/screen size and configure your app accordingly (supposing your app supports both phones and tablets).
However, everything's changed in 3.2 and beyond. Now, the best practice can be described thus: think like a web designer, not an Android designer. Instead of thinking about phone vs. tablet vs. landscape vs. portrait layouts, think instead of layouts that work on particular screen sizes.
This thought process is detailed by this blog post, and these slides, but I think it's best demonstrated by going to some sample web pages and seeing it in action. Try visiting this page (or this page, or this page) and changing the size of your browser. Notice how they dynamically change layout based on the width - this is what you want in Android as well.
So now you've got a layout that works between screen width 150dp and 400dp; another one that works between 401dp and 800dp; a third that handles 800dp and 1000dp, etc. This way of thinking does not end up with you, as a developer, doing too much more work than before - instead of defining a phone layout, a tablet layout (each with a portrait/landscape layout), you just define a few layouts that work with different widths.
Right now we're in an awkward transitional stage as most people don't have devices that support this practice. So "best practice" is essentially all of the above. In a few years, when everyone's got ICS and beyond, then we can all breath a sigh of relief.
(I apologize if you were looking for specific solutions; this answer ended up being relatively theoretical rather than having concrete answers, mostly because I felt the question was pretty open-ended. If you've got a specific problem you want to solve, I can try to address that elsewhere.)
If you build your views using "dp" it would, basically, be the same size for eack screen size.
In most cases you will prefer that your view will resize itself proportional to the screen size.
Of course, in most cases you will need to build separate layouts for tablets.
But, besides I can recommend you to do the next steps:
1. Add this library to your project.
2. Now in your layout you can write views like that:
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="I'm scalable!"
android:textSize="#dimen/_12sdp"/>
In this example your TextView will scale on each screen size.
These are some suggestions, in random order:
Avoid AbsoluteLayout, I know that it is deprecated, but you can still use it; forget it and use LinearLayout and RelativeLayout instead
Use 9-patch to create buttons and backgrounds, so that they will appear the same for each resolution
Use DisplayMetrics() to get informations about the screen, to show different things in different screens (i.e. to show AdMob "Banner" in smartphones and AdMob "Leaderboard" in tablets)
Create WVGA layout first (this is only a personal opinion, but I've found it a nice way of working): as far as I know the most smartphones are WVGA or at least HVGA (QVGA is not so frequent), so creating a perfect WVGA layout will make you able to satisfy lots of phones, than you can create a different layout for lpdi-screen and tablets (that are a market-share minority too, at the moment)
In conclusion I recommend you to create a layout for phones and on for tablets, that can adjust itself to screen resolution: this will fit the most devices; for borderline devices (i.e. 7" tablets or 5.3" phone) I'd work with different drawables/different XML layouts.
I would suggest as much as possible use Relative calculations rather than Absolute. Avoid Hard coding of numbers for padding, margins etc. Simply give them a value in relation to desired property like Width, height of screen or any component.