January 8, 2013 at 17:33Android Defeat Fragmentation
When developing for Android, many beginners encounter difficulties arising from the huge variety of devices on which this operating system is installed. This post will talk about how to eliminate most of the problems associated with fragmentation by screen resolution, performance, physical size and version of Android.
One of the main differences between Android devices is the physical size. The “device zoo” contains both tiny phones and huge ten-inch tablets. And about this extremely important point, many novice developers often forget.
The fundamental difference between phones and tablets is how the user holds them:
Usually held in one hand. Presses are carried out with the thumb of the same hand. The finger is everywhere, but the bottom half of the screen is intuitively convenient.
Usually held with two hands. Presses are made with the thumbs of both hands. It’s convenient to get controls anywhere on the screen.
Most often, regardless of screen orientation, they are held with two hands. Management is with thumbs, which cover only two arcs in the corners of the lower half of the tablet.
Sometimes, if the tablet is not very large, it is held with one hand, and control is carried out with the index finger of the other hand. It takes out a finger everywhere, but the upper half of the screen is intuitively convenient. It is worth considering that in this way people rarely hold a tablet.
That is, when designing an interface for the convenience of most users, the most important controls should be placed in the lower half of the screen closer to the edges.
This item is important mainly when developing games, not regular applications ...
With this variety of resolutions, several problems arise. Here are some of them:
In order for the graphics of your game to be good enough on any device, you have two ways. Either you draw vector graphics, or you draw, and then stretch the raster. If you chose the second path, then initially draw it for high resolution (for example, 1024x768), because when compressing a picture, the sharpness of the image suffers less than when stretching it.
Do not use any "magic numbers" in the code. The calculation of the location of the object should be carried out after stretching the graphics. The coordinates of the objects should depend on the coordinates and sizes of other objects. This is especially important if you want the round to remain round and the square to square.
Here is an example of determining the button coordinates from my next game.
In my previous game, I used the Box2D physics engine, and when testing a bug related to screen resolution was discovered. In Box2D, the PixelToMeterRatio constant is used to simulate physics. It depends on how the objects behave: like a box the size of a box, or like a box the size of a skyscraper. Initially determine this constant based on the screen resolution.
When compressing or stretching textures, it often happens that the relations of the parties change. For example, from 16: 9 to 4: 3. Because of this, some objects can become ugly. To prevent this, make the graphics minimalist, cartoon-hand-drawn. This will help the compressed image not look so terrible ...
If you are planning to make a 3D super-megashooter, then know that not all devices will pull it, but most new phones and tablets can handle it easily. Also take into account the fact that not all devices support OPEN GL 2. About 10% of devices support only OPEN GL 1.1.
The main performance problem lies elsewhere: the application has different FPS on different devices. And if for ordinary applications this is not so critical, then for games this is a very important problem. In the game that I am currently developing, I ran into a problem: on different devices, the speed of movement of the main characters of the worms is different. After much disassembly and testing, it turned out that this is due to the fact that I move the worms by a certain number of pixels per frame, and with different FPS it gives a different speed ... This bug was fixed by attaching the “step” to the current FPS:
I repeat, when developing for Android, make the code extremely soft. Any “number from nowhere” is reflected in the most unexpected places.
Here are the statistics of the versions of the operating system that my previous game was on.
As you can see, most users playing games have completely new versions of Android. So this item does not cause any problems.
Fragmentation of devices is a headache for Android developers, but if you look, the problems are easily solved. For the beta test, be prepared that despite the full compatibility declared by Google, on some devices the application will generally refuse to work, do not despair.
I hope that at least one of the tips I have outlined will help you not to make the mistakes that I came across.
1. Tablets and phones. Interface Planning
One of the main differences between Android devices is the physical size. The “device zoo” contains both tiny phones and huge ten-inch tablets. And about this extremely important point, many novice developers often forget.
The fundamental difference between phones and tablets is how the user holds them:
Phones in portrait orientation
Usually held in one hand. Presses are carried out with the thumb of the same hand. The finger is everywhere, but the bottom half of the screen is intuitively convenient.
Phones in landscape orientation
Usually held with two hands. Presses are made with the thumbs of both hands. It’s convenient to get controls anywhere on the screen.
Tablets in any orientation
Most often, regardless of screen orientation, they are held with two hands. Management is with thumbs, which cover only two arcs in the corners of the lower half of the tablet.
Small tablets
Sometimes, if the tablet is not very large, it is held with one hand, and control is carried out with the index finger of the other hand. It takes out a finger everywhere, but the upper half of the screen is intuitively convenient. It is worth considering that in this way people rarely hold a tablet.
That is, when designing an interface for the convenience of most users, the most important controls should be placed in the lower half of the screen closer to the edges.
2. Screen resolution. Texture stretching
This item is important mainly when developing games, not regular applications ...
With this variety of resolutions, several problems arise. Here are some of them:
Problem 1. Image sharpness
In order for the graphics of your game to be good enough on any device, you have two ways. Either you draw vector graphics, or you draw, and then stretch the raster. If you chose the second path, then initially draw it for high resolution (for example, 1024x768), because when compressing a picture, the sharpness of the image suffers less than when stretching it.
Problem 2. Correct location
Do not use any "magic numbers" in the code. The calculation of the location of the object should be carried out after stretching the graphics. The coordinates of the objects should depend on the coordinates and sizes of other objects. This is especially important if you want the round to remain round and the square to square.
Here is an example of determining the button coordinates from my next game.
againButton.setPosition(table.getX()+table.getWidth()/2-againButton.getWidth()/2,table.getY()+table.getHeight()-5*againButton.getHeight()/4);
Problem 3. Physics Box2D
In my previous game, I used the Box2D physics engine, and when testing a bug related to screen resolution was discovered. In Box2D, the PixelToMeterRatio constant is used to simulate physics. It depends on how the objects behave: like a box the size of a box, or like a box the size of a skyscraper. Initially determine this constant based on the screen resolution.
Problem 4. Proportionality
When compressing or stretching textures, it often happens that the relations of the parties change. For example, from 16: 9 to 4: 3. Because of this, some objects can become ugly. To prevent this, make the graphics minimalist, cartoon-hand-drawn. This will help the compressed image not look so terrible ...
3. Performance
If you are planning to make a 3D super-megashooter, then know that not all devices will pull it, but most new phones and tablets can handle it easily. Also take into account the fact that not all devices support OPEN GL 2. About 10% of devices support only OPEN GL 1.1.
The main performance problem lies elsewhere: the application has different FPS on different devices. And if for ordinary applications this is not so critical, then for games this is a very important problem. In the game that I am currently developing, I ran into a problem: on different devices, the speed of movement of the main characters of the worms is different. After much disassembly and testing, it turned out that this is due to the fact that I move the worms by a certain number of pixels per frame, and with different FPS it gives a different speed ... This bug was fixed by attaching the “step” to the current FPS:
shipConfig.setShipSpeed(activity.mCamera.getHeight()/(shipConfig.timePerCameraHeight*fpsCounter.getFPS()));
I repeat, when developing for Android, make the code extremely soft. Any “number from nowhere” is reflected in the most unexpected places.
4. Android version
Here are the statistics of the versions of the operating system that my previous game was on.
As you can see, most users playing games have completely new versions of Android. So this item does not cause any problems.
5. Conclusion
Fragmentation of devices is a headache for Android developers, but if you look, the problems are easily solved. For the beta test, be prepared that despite the full compatibility declared by Google, on some devices the application will generally refuse to work, do not despair.
I hope that at least one of the tips I have outlined will help you not to make the mistakes that I came across.