I have a wallpaper app and it seems to work fine but... when i open the app in eclipse... the app icon appears as the first image in the wallpaper. I cannot figure out what is happening. can someone help.
also the scrolling seemed to have slowed down after i added more images (40)..any suggestions. what is the recommended file size the files papers should be. I know the dimensions but what about the resolution.
The resolution isn't relevant if you already know the dimensions (if I'm understanding you correctly). For the Droid, you need 960 x 854 pixel images. When I hear resolution, I think dpi/ppi.
As far as the app icon appearing in the list...you should post some code as to how you're listing the images. Are you just populating them from the #drawables folder? That's where your app icon is stored, too.
Related
I saw many questions like these and read many docs, but I'm still not sure what is the proper way. I have application with 500 photos, and first how I was doing it was to scale every photo 5 times, to the pixel sizes for each ldpi, mdpi, hdpi, xhdpi and xxhdpi. But, after doing this, application got much bigger than it should have and since you can only upload .apk with 50MB to market, I found myself in trap.
I found several options which can be made here, but not sure which is the proper one:
Make a multiple layouts for each of this densities on devices and scale with different dp's in them
Make multiple .apk files, each for every device with different densities (still, Google is making accent on this option to make it only if you really can't make it anyhow else - why is that? this would be perfect for me, since I already have photos prepared for each density)
Make multiple pictures and put it just in one .apk - this can't work for me, since the .apk is too big
Make pictures which are good for MDPI device, put them in "drawable" and they will automatically resize bigger for other devices and smaller for smaller density devices - this makes problem since pictures, when they're being resized from MDPI to other bigger dpi devices, pictures are blurry.
So, anyways, proper way of handling this would be to follow first option, am I right? I should just take xxhdpi pictures (so they're always scaled from the best picture), put them into drawable-nodpi? However, I have some problems with scaling on ImageButtons.
Please, tell me how to make it properly.
My practice is using only one apk to keep the app simple and easy to develop and publish.
Use only one drawable, the high the better. it depends the final apk size you(market) can bear.
May be this question will help:
Only use XHDPI drawables in Android app?
An addition to the Loki's answer. You could resolve the poor perfomance on small scale devices making a cache folder for images. Downsize the image the first time the device loads it, according to the density of the device, save it to the cache folder, and the next time use the cached image.
Bonus if you make this in an batch process in the background!
I don't know but could this be done as an update to the app. You download a plain vanilla app that prompts the user to upgrade, or just does it automatically.sounds like something Google needs to improve on. When I download an app I only need one app for one language one device.sounds like Microsoft mentality
I have been programming an application for Android. I want to target it for more devices(tablets, smartphones). I tried to find some info at http://developer.android.com/guide/practices/screens_support.html but it does not work correctly.
I want to automatically stretch images on different devices, not only in my testing device. I draw images for the mobile full screen (which has the same resolution as my mobile). But, for example in the tablet it draws incorrectly. I tried to change the size and it gives several folders(lhdpi, small, ...). When I tried to start it again in the tablet, it was bigger but still incorrect (there was a black space on the edges). I have several images in my application, and I want to retain the same size as in the mobile too. Please, help me.
Sorry for my spelling mistakes.
you have to maintain aspect ratio at your own . don't put same sized images in all folder (hdli, mdpi, ldpi), if this was the case they think why android provides different foldes ? put images in ratio 0.75 : 1 : 1.5 . it will work .
additionally read about 9-patch images, this will make your life much easier .
I'm currently building an application for Android (a game). So far, I've created assets for all devices, from ldpi all the way up to xhdpi. I'm building the application for Android 2.2 and above.
Should I stop producing ldpi images?
It would cut down the time it takes to produce the graphics fairly significantly. On top of this, I don't think that very many devices (commonly used) these days actually fall into the ldpi category.
Thoughts?
There are only 3.1% of phones with ldpi screens (as of 1st Jan 2016). Here is the statistics about devices and their screens. You can decide whether to support them or not.
True, but to build your brand image, you have to do the job perfectly, for everyone. Even if there are a few tens of users who use low dpi, it's totally worth it. :-)
You could if you like. you could set a in code aspect ratio resizer, and size all the images accordingly when loading them. So no matter what screen you play on, they take up the same percentage of it. This significantly cut down graphic time, and looks great.
another way you could do it, is get Paint.net and simply build the largest graphics first. Then go into Image and Resize, and set the resize to by the ratio difference, say 75%. save this and you are done. Should cut the entire time down significantly as well, and also looks great.
I have done it both ways, and you cant tell the difference.
I have always built my code so that it fits the game to the screen.
for example in a sidescrolling fighter if a character is 5/8 the screens height, and 3/12 the screen width on my testing device, and it looks great>>> you can do a little math, figure out the h/w ratio of the screen any user is playing on, and adjust the image at load time so that no matter the device your image will take up the percentage of the screen you intended it to.
It is suitable to use all image packs, because if most devices support MDPI, but you would be losing market devices with low resolution. Use LDPI.
I am developing a live wallpaper and I would like to know how to manage high quality images. I am quite new to android development by the way.
I got 2 questions:
1)The image I use for wallpaper creation is a vector image (2560w x 1600h, 32bit, 10mb exactly), very crispy and with really high resolution. I tried it as a wallpaper and it looks just fantastic (on my tablet). I placed it in the drawable folder. This results in a high dimension .apk file (9 Mb). Is it ok to have files this big enlarge apk dimension or it is a good practice to reduce it as much as possible?
2)When building my wallpaper from the Engine class i'd like to know, after setting the above image as a wallpaper, what is the best practice to scale it fitting XY independant of screen sizes.
PS: What i found to be perfect was the default system android use when you attempt to set an image as wallpaper. What does the system do in that case?
Thanks :)
1.)Since no android device supports resoultion bigger than 1280x760 of what I know, it is not a good practice in having images with bigger size than this as they use a lot of space for nothing.
2.)The DisplayMetrics class has everything you need related to this problem.
I'm loading external images from a url, which they are all the same resolution. However, the images that are below 100dpi do not appear. The rest are 100 dpi and they do appear.
I can't wrap my head around this dpi resolution concept, and why I can't use these images even though they are the same resolution at the others.
I've added two test images. Could someone try to add these images externally to imageViews? I want to see if you are able to display them.
http://bloggr.geespot.ca/offbroadway-poster.jpg
http://bloggr.geespot.ca/eppleworth.jpg
Well it looks like dpi was not the issue after all. The cause was probably the way it was encoded, which I'm not sure how it was done. But I ran it through photoshop and all is fine now.