How we at Parcsis develop Android programs

On June 21, we had an open day at Parcsis , where I, among other speakers, told how we develop programs for Android. Under the cut is the text of my speech, somewhat supplemented and revised taking into account the questions asked.

Of course, you should start the story about software development with a description of business processes. So, let's begin!

The working process

For the developer, we have two important documents.

The first is the backlog . It is a simple spreadsheet in Google Docs in which the project manager enters high-level tasks as they appear. Nothing complicated.

The second most important document is the application layout , drawn by designers.

The layout is a pdf document, each page of which is one of the application screens in one of the states, rendered pixel-by-pixel how it should look on the device. Looking ahead a bit, I’ll say that often we ask designers to save each page of the layout as a separate png image, so that later we can use Pixel Perfect to correct it vertically.

The development process is divided into iterations. Each iteration is two weeks. Before starting the iteration, the lead developer, together with the manager, selects tasks from the backlog that should be implemented. Based on them, Jira starts tasks for specific performers. The time for the task is determined based on the experience of previous developments and the skills of a particular developer, plus risks. No tasks are assigned for more than a day (eight hours). If suddenly the assessment of the task exceeds eight hours, it is divided into smaller ones.

The first week of iteration is reserved for development, the second for testing and bug fixes.

We have two phases of testing: functional testing, performed by the testing department, and design review (including usability testing), performed directly by the designer who created the program layout. Bugs are put on both phases in Jira.

Iteration does not necessarily end with a release. The completion of the iteration means only the completion of some small functionality.

In our work, we actively use prototyping. If it is not clear how to implement this or that functional, or it is not clear whether the implementation is possible at all, we create prototypes.

The source code is stored in svn. For complex tasks and for prototypes we create brunches. Brunches live until the task is completed, then they freeze with a trunk and are deleted.

Difficulties

Next, you should talk about the difficulties that an android developer faces daily.

Layout

The first difficulty is layout. There are hundreds of different screen configurations for android devices. Ideally, the program should work correctly on any device. It should be noted that the division of devices into phones and tablets is very formal (no matter what marketers say about it). From a software point of view, both phones and tablets are the same devices, with the possible exception of the third Android, which works exclusively on tablets.

Fortunately, the entire set of screens is divided into groups according to two criteria.

The first sign is the physical size of the screen.. Now on sale there are devices with a screen diagonal of three to ten and a half inches. The whole set of screen sizes is divided into four large groups. These are small (small), normal (normal), large (large) and very large (xlarge) screens. And do not forget about the two screen orientations - landscape and portrait.

For screens of different sizes and different orientations, different usage scenarios are characteristic. For example, devices with a small screen are usually held in one hand, with a large one with two hands, or placed on a table or on your knees, and so on. Accordingly, for each size and each orientation of the screen you need your own layout and your location controls.

The second sign is screen density, that is, the number of pixels per unit area. Now there are four screen densities: low (ldpi), medium (mdpi), high (hdpi) and very high (xhdpi). This parameter should not affect the location of user interface elements. For different densities, different graphics are used. That is, in the ideal case, any picture, any icon, should be included in the project four times - once for each of the possible screen densities, with different sizes and different details.

On the portal for Android developers, statistics on the use of devices with various characteristics are regularly updated .

Memory management

Having dealt with the layout, we are faced with the peculiarity of freeing memory.

Nobody likes to close programs. For example, on a desktop, some accountant can keep several dozens of Word, 1C, Outluk and Lines documents open. But on a mobile device, resources are very limited, and many unclosed applications can significantly slow down. In the Android OS, this problem is solved very elegantly - the operating system decides at what point to close the application. Each running application is given a priority, and in case of insufficient memory, applications are closed according to this priority until there is not enough memory. The application that is currently displayed on the screen closes last.

The problem arises when the screen is destroyed, which is regularly updated from the background process. For example, progress bar file download. To solve this problem, asynchronous processes should be untied from the user interface - for this, Android has a standard tool - services .

Networking

According to Murphy’s law, trouble always happens. But especially often, trouble happens when we use a GPRS connection. On a desktop, as a rule, everything is simple - the Internet is either there or not. But in the program for a mobile device, it is not enough to provide for the possibility of disconnecting at any time. It should also be foreseen that the connection speed will become extremely low, but the connection will still not be disconnected (many tariffs with “unlimited” Internet will fall in speed). Sometimes mobile operators invade the transmitted traffic by inserting, for example, balance information into the service’s responses. This situation should also be kept in mind.

In addition, frequent network connections quickly drain the battery, so it is advisable to minimize the number of connections by caching data.

Data storage

The difficulty is that the speed of access to the memory card is very dependent on the model of this card. Now on sale there are cards with a read speed of 10 to 50 Mb / s and a write speed of 2 to 40 Mb / s. The difference is 5 times for reading and 20 times for writing! As a rule, even users of top-end device models do not think about the used memory card at all. If the application is too active to read or write to the memory card, the work will slow down. Again, as with an Internet connection, a caching mechanism should be considered for commonly used data.

Conclusion

For Android, we have been developing a little over a year. Now we have five apps uploaded to the Play Store :

• Pravo.ru - a client for the reference legal system of the same name
• Two versions of the Arbitration File Cabinet - old and new
• Where is the court? - reference information on any of the 113 vessels of the Russian Federation
• Selloby - mobile service of private announcements

We are actively developing these applications, listening to all the wishes of users. And on the way are a few more programs, which I will not talk about yet.

^{Photo at the beginning of the article - Dmitry Nechaev}