Does anyone know how to forcefully unload a ByteArray from memory in AS3?
I have tried (without success):
byteArray.length = 0;
byteArray = new ByteArray();
and
for ( var i:int=0; i<byteArray.length; i++ ) {
byteArray[i] = null;
}
Any ideas?
First of all dp != px
Read this http://developer.android.com/guide/practices/screens_support.html
You do not have to provide different layouts for different screen sizes, however the possibility of say a tablet displaying more data over a phone is there - so you may want to give the user more options or show the navigation constantly.
AS for handling images, at the above link, you should take the xhdpi/hdpi size and recreate it at x0.75 (ldpi), normal (mdpi), x1.5 (hdpi) and x2.0 (xhdpi). You then can reference the single image 'R.drawable.logo' and the phone will pick the most appropriate available resource from the relevant drawable folder (e.g. drawable-hdpi).
Plug moment, we have build an alpha tool to do the resizing based on c# .net 2.0 we will publish Alpha version at http://www.wiseman-designs.com/downloads/android-icon-creator/, EDIT: which is free for everyone for anything - source will be released after xmas.
It's caused by Screen Compatibility Mode
http://developer.android.com/guide/practices/screen-compat-mode.html
The only way to avoid it is to use the different drawable folders, but you can just do medium, which is the default, and xlarge and just have Screen Compatibility Mode handle the rest
Related
I making an app for tablets. and want to use a PNG file for some of the buttons. What size the button must be? Based on Android size it should be at least 48dp x 48dp and with converters 48dp is different in different sizes of android devices. This is a calculator: Link
ldpi # 48.00dp = 36.00px
mdpi # 48.00dp = 48.00px
hdpi # 48.00dp = 72.00px
xhdpi # 48.00dp = 96.00px
So Should I make 4 different files for my png files with top pixels ? for example a version with 36px x 36px for the ldpi folder? or just make the biggest size like xhdpi (96px)?
Thanks in advance.
You CAN just make one large button size and get away with it, but thats not best practice.. You should have different sized images for different resolutions.
From Android:
Although the system performs scaling and resizing to make your application work on different screens, you should make the effort to optimize your application for different screen sizes and densities. In doing so, you maximize the user experience for all devices and your users believe that your application was actually designed for their devices—rather than simply stretched to fit the screen on their devices.
More info on supporting different devices and best practices.
Android Practices
Ya. Better Use 9 patch Images as the background for the buttons. So it will expand/ behave according screen size . Check this Link .
I just use the highest resolution and let Android scale it down. Doing it this way makes the download (file) size much, much smaller than having a different image for each resolution. And the quality as it's scaled down is no worse than it would be if you scaled it down yourself in MS Paint.
i just released my app on android and have problems with customers with high density displays.
i added a debug thing to see what's going in, here is one sample output
Device: Nexus 10 Android version: 4.2.2
DisplayMetrics{density=2.0, width=2560, height=1504, scaledDensity=2.0, xdpi=298.275, ydpi=298.823}
MainView w=1900 h=1342
mDrumKitMode=BIG
KitView w=640 h=1266 x=1920.0 y=0.0
the main view is the music notation area on the left of the screen shot, its 1900 wide (MainView w=1900 h=1342) the drum kit is a bitmap that is 640w and 640 high. somehow, the display is scaling it to be full height of the parent, (KitView w=640 h=1266 x=1920.0 y=0.0). this doesn't happen on displays where density=1.0.
i have no way to test this since i can't get the emulator work on big displays for some reason and i don't have a high density tablet.
does anyone have an idea what could be going on? thanks
and here's another customer with a similar problem
Device: A700 Android version: 4.1.1
DisplayMetrics{density=1.5, width=1920, height=1128, scaledDensity=1.5, xdpi=224.73732, ydpi=224.11765}
MainView w=1260 h=1044
mDrumKitMode=BIG
KitView w=640 h=968 x=1280.0 y=0.0
i think its the scaledDensity=1.5 parameter, maybe i need to do something to disable automatic image scaling, i.e. set scaledDensity=1?
i should add that the entire application is based on exact pixel positions, both for the music notation display and the drum kit display which overlays images on top of the base drum kit image (you can see the drum pedals are in the wrong place on this image too). i don't want automatic scaling as i handle scaling inside the app for different display sizes and user preferences.
i should also add that all my drum kit images are in drawable-mdpi and all the other dpis are empty. this is because i scale images programmatically based on screen size and user preference BUT i think maybe the problem is a need to put some images in xhdpi? i guess i can do that but it will be a lot of work.
PS, i guess i found my answer here http://developer.android.com/guide/practices/screens_support.html
Provide different bitmap drawables for different screen densities
By default, Android scales your bitmap drawables (.png, .jpg, and .gif files) and Nine-Patch drawables (.9.png files) so that they render at the appropriate physical size on each device. For example, if your application provides bitmap drawables only for the baseline, medium screen density (mdpi), then the system scales them up when on a high-density screen, and scales them down when on a low-density screen. This scaling can cause artifacts in the bitmaps. To ensure your bitmaps look their best, you should include alternative versions at different resolutions for different screen densities.
i wonder if simply copying all the -mdpi images to -xhdpi will work?
If you intend for this app to be used across devices you have no choice but to put in images for all the various density folders that exist (xhdpi,xxhdpi, hdpi, mdpi). It's also worth considering that you may want to change the actual layouts you include, to offer different ones for different devices.
Consult the documentation for how to handle this.
http://developer.android.com/guide/practices/screens_support.html
If that creates an apk that's too heavy (I have no idea how many images you have) then you can go the other way and specify a no scaling drawable folder which will just use the images in their native density across devices. It's definitely wrong to use ONLY mdpi unless you intend to support only mdpi devices.
I'm trying to specify the art sizes for an Android game with ~10 screens. I want the game to run on API 8+, and on all size screens except "small".
Since we're using API 8, I use the old "4 categories of screen" feature - I plan to support
normal (480 x 320, and up to 640 x 480)
large (640 x 480, and up to 960 x 720)
xlarge (960 x 720, and up to 1920 x 1200)
A 1920x1200 png file is ~4.1MB. So 10 of them is 41MB, and we've almost blown our 50 MB app size limit (Play Store).
So three questions:
1. how do people support detailed artwork for game screens? Do I have to use bland colored 9 patch pngs files for the backgrounds? Or is it feasible to store all art at the 960x720 size, and allow it to be resized by Android for large and normal screens? 10 background files of this size total to about 15 MB, which leaves 35 MB for everything else.
What if I used jpgs instead of pngs? How much quality would I lose? Since I would only ever be downsizing, this should be OK, right? 10 jpgs of 960x720 is only 4.3MB.
If I allow Android to resize it, how do I support screens that have a different aspect ratio than the 4:3 of 960x720? Is there a way to specify in the layout XML "use the drawables from the large folder, but "letter box" it onto the screen, so that the longest dimension just fits" ? (And for xlarge screens bigger than 960x720, just put the drawable in the middle of the screen - don't stretch it at all)?
DPI resolution of the screen doesn't factor in this at all? DPI only needs to be taken into account when you want something to be roughly the same size on different res screens, like an icon or button. Correct?
Seems like this should be a solved problem with a well known pattern or template to follow. How have other people done it? Does everyone use either huge downloads post install (want to avoid) or 9 patch backgrounds?
Thanks in advance for any advice. I searched here on several terms, and looked at about 25 past answers, without finding what I am looking for.
Peter
Resurrecting the dead (thread): one way of doing things could be to provide just one set of bitmaps and do the scaling yourself. You can either provide large bitmaps and scale them down, or provide middle of the road bitmaps and scale them up (for large screens) and down (for smaller sizes).
The benefits of the former are that your art looks great on large screens and you are a bit more future proof (if you provide for this in your code). The downside is that you could (and actually likely will) run into Out Of Memory/Exceeding VM errors when decoding/loading these bitmaps on lower-end devices, even when doing it carefully. So I usually go for the second approach.
Scaling up can be done a number of ways, but one is to just load in the bmp at it's default size (use getResources().openRawResource(id) or BitmapFactory.decodeResource(etc) or even better use inputstreams or [according to some the best method] load/create using the FileDescriptor methods) and then scale it either by creating another bmp using createScaledBitmap() or if drawing to a canvas draw it to a destination Rectangle (better memory wise).
For scaling down you can either use BitmapOptions like .inScaled or, again, use a smaller destination Rect in your canvas drawcall.
Doing it this way is way better and (for a game) faster than letting Android scale for you using those buckets (hdpi etc) and uses less memory if done right.
But beware as some bitmap loading methods are a bit buggy and create 'the bmp is too big for the VM' errors. Also learn to dispose of your bmps properly; a lot of people and Google/Googlers say Android does this and you don't have to set your bmps to null and recycle() them, but so far I've found that you do. Another caveat is to set the proper options (filtering/antialiasing etc) to prevent blurry bmps. And take care of un-optimal color/format/dpi settings on BitmapOptions/canvasses/SurfaceViews and even windows.
There's much more, but this should help anyone get started.
i will be targeting my app to all the android devices, what is the best way of doing it? so far i will be targeting Android phone and Kindle-fire and here is my thoughts.
android phone and its working as expected with images,font size etc... so i thought to test my app for kindle-fire:
create AVD emulator for kindle-fire with the below specification but i have few problems testing on the kindle-fire:
the images are stretched out (not sure if the images size should be increased for kindle-fire?)
font size is smaller then android phone (which i have tested)
i have no back button in my activity so i assume the user will be able to use the back arrow button in kindle-fire but in the emulator there is none showing.
Here are the specs of the Kindle Fire
Width: 600px
Height: 1024px
Abstracted LCD Density: 169
Target: Android 2.3.3 - API Level 10
RAM: 512 MB
what do i need to do in order to look and feel on both android phone and amazon kindle-fire?
should i create two separate projects and target font-size and image-size?
i am not sure what else i need to consider.
For the font, be sure to use the sp unit of measurement.
For the images, you can store them in different folders and name the folder using different attributes.
http://developer.android.com/guide/topics/resources/providing-resources.html
I will say though, I had a difficult time differentiating between the kindle and my 10 inch tablets, because they are both judged to be large by android. So I just created different layout for them and checked for screen size in the onCreate. Here is the code.
Display display = ((WindowManager)getSystemService(Context.WINDOW_SERVICE)).getDefaultDisplay();
if(display.getWidth() <= 600 || display.getHeight() <= 600)
{
this.setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_SENSOR_LANDSCAPE);
setContentView(R.layout.kindle_fire_layout);
}
else
{
setContentView(R.layout.anything_else);
}
To test on the emulator, use the code bellow to avoid android recognizing it as a xlarge device. Then you can put your resources where they should be.
Also keep in mind the the kindle fire ui takes some pixels off the view for the bar, etc, so you might want to also consider that
final Configuration config = new Configuration(context.getResources().getConfiguration());
config.screenLayout = (config.screenLayout & Configuration.SCREENLAYOUT_LONG_MASK) + Configuration.SCREENLAYOUT_SIZE_LARGE;
context.getResources().updateConfiguration(context.getResources().getConfiguration(), context.getResources().getDisplayMetrics());
I'm writing a game for Android and can now test it on a second device, the Nexus 1. The game uses fix pixel-values, just using bigger cutouts of the background for high-res devices. So I thought there would be no problems. Somehow, however, the nexus 1 is making a specific image bigger than it should be (261*66 instead of 174*44). The picture itself as a resource is 174*44, so it's being stretched. Why? What can I do against it?
Edit:
Spritesheet = BitmapFactory.decodeResource(res,
R.drawable.bird_spritesheet);
Is the used code.
Edit 2:
Is there no way to tell the software to just use the size the picture is? I don't want to bloat my software by adding multiple pictures (/drawable-hdpi/ answer).
The pictures are supposed to be smaller on bigger screens.
what drawables folder to you have the picture in? If you put a copy of it in drawables-hdpi I think it will show up real size. It is really better to set things up in such as way that the final size in pixels it ends up is unimportant. Using pixels values is going to ensure that your app looks wrong on at least some of the screen sizes out there.
Because Android runs on multiple screen sizes and you use device independent pixels (DIPs), images get scaled to ensure they look the same on all devices. To avoid this, you can provide alternative resources for high density screens (in your case) and for low density screens.
More info about screens here