Testing functions that have Android device specific side effects

Question

Take the following function as an example:

public static float convertPixelsToDp(float px, Context context){
    return px / ((float) context.getResources().getDisplayMetrics().densityDpi / DisplayMetrics.DENSITY_DEFAULT);
}

In the function above, px is altered by context.getResources().getDisplayMetrics().densityDpi and DisplayMetrics.DENSITY_DEFAULT .

If developers use the same emulator, then a test could be written that works across developer machines.

That being said, is there a way to configure mock devices or default values for display metrics within a testing framework that can yield the same results as the latter?

Answer 1

To start, I'll admit that your question goes a bit over my head. I do know, however, that the reason for that method's existence, and the existence of DP altogether, is to (in part) solve the problem of scalability. I will answer the question (I think) you are asking. If the answer doesn't make sense to you, it is the question didn't make sense to me. I am confident enough to answer but not enough to bet on that answer...

Regarding your question, If you want to give a default value for a device's physical properties. You need to alter the Device profile for your AVD. You can do it via the AVD manager interface, but you have much more options via the command line. The command line will also let you automate any changes via shell scripts. Since I am not completely sure if this is what you are looking for, I will also provide some additional info regarding px, dp, and scalability. If it doesn't help you, I am sure it will help some of the thousands who will end up at this page in the future...

Using pixels doesn't give consistent display across devices, since the amount of pixels in a given area is different from device to device. Or in other words, the pixel density isn't standardized. The dp makes up for this. The function you mentioned above works great for situations where you know how many pixels you want on your device. If you convert to dp, you will not have to worry about your images being displayed differently on devices with different pixel densities.

We also have sp, or scaled pixels. this also takes into account the user's font size settings.

However, using dp, or even sp, isn't going to make the problem go away completely. If your resource is 3" tall on one device, it will be 3" tall on EVERY device. Obviously, that will look a lot different on a device that is 5" tall than it would on one that is 13" tall. So if your goal is to make your asset appear as the exact same size, regardless of device, then you're good. However, the goal is more often to display it at the same relative size.

Android screen sizes, as I'm sure you know, are as far from standardized as they could possibly get. Therefore, you will need to supply multiple versions of your visual resources, in addition to using dp, to better display them across devices. If supply multiple versions of an asset and place each in it's corresponding folder, when that resource displays, it will be displayed more consistently across devices. In the resources folder of your app, you will find 5 different folders. These will each display only on a certain portion of size ranges. The folder marked 'extra large' (or something similar; I do not remember the actual names, but I do remember that they are pretty self-explanatory, so it shouldn't be a thing.)

If you make 5 versions of each of your images (and gifs, etc.) in 5 separate sizes, and place each image in its correct folder, you should end up with a result that, while not completely consistent, should at least look "right" on almost any device.

It should be noted that this isn't the only way to achieve scalability of your images. Android also provides an abundance of scalable layouts, and the options keep getting better with time. If you use layout nesting creatively, you can achieve just about any affect you can imagine, regardless of the content that you are scaling.