How we develop programs for Android in Parcsis

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

Of course, to begin a story about software development follows from the description of business processes. So, let's begin!
')

The working process

For the developer, we have two important documents.

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

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

The layout is a pdf document, each page of which is one of the application screens in one of the states, drawn pixel-by-pixel how it should look on the device. Slightly running ahead, I will say that often we ask designers to save each page of the layout as a separate png image, in order to use Pixel Perfect to adjust the hell.

The development process is divided into iterations. Each iteration is two weeks. Before the start of the iteration, the lead developer, together with the manager, selects tasks from the backlog to be implemented. On their basis, tasks for specific performers are got in Jira. The time for a task is determined based on the experience of previous developments and the skills of a specific developer, plus risks. More than a day (eight hours) tasks are not assigned. If suddenly the assessment of the task passes for eight hours, it is divided into smaller ones.

The first week of the iteration is reserved for development, the second - for testing and bugfix.

We have identified two phases of testing: functional testing performed by the testing department, and a design review (including usability testing) performed directly by the designer who created the program's layout. Jira puts bugs on both phases.

Not necessarily the iteration ends with the release. Completing an iteration means only completeness 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 implementation is possible at all, we create prototypes.

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

Difficulties

Next, you should talk about the difficulties that the android developer faces every day.

Layout

The first difficulty is layout. There are hundreds of different screen configurations of 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 (whatever marketers say). 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 signs.

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

Screens of different sizes and orientations have different usage scenarios. 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 their knees, and so on. Accordingly, for each size and each orientation of the screen you need your own layout and its location of controls.

The second sign is the density of the screen , 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.

The portal for Android developers regularly updates the statistics of the use of devices with different characteristics.

Memory management

Having dealt with the grip, we are faced with the feature of freeing memory.

No one likes to close programs. For example, on the desktop, some accountant may keep several dozen documents open Word, 1C, Outluk and Lines. But on a mobile device, resources are very limited, and many open applications can significantly slow down the work. In Android OS, this problem is solved very elegantly - the operating system itself decides when to close the application. Each running application is assigned a priority, and, in the event of a shortage of memory, applications are closed according to this priority until the memory runs out. The application that is currently displayed on the screen closes last.

The problem occurs when the screen is destroyed, which is regularly updated from the background process. For example, the progress bar of the file download. To solve this problem, you should decouple asynchronous processes from the user interface - for this there is a standard tool in Android - services .

Work with the network

According to Murphy's law, trouble always happens. But especially often trouble happens when we use a GPRS connection. On the 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 foresee the possibility of breaking the connection at any moment. It is also necessary to foresee a situation when the connection speed will become extremely low, but the connection will still not be broken (many speeds with “unlimited” Internet will result in a drop in speed). Sometimes mobile operators invade transmitted traffic by inserting, for example, balance information into service responses. This situation should also be borne in mind.

In addition, frequent connections to the network quickly put the battery, so it is desirable 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 there are cards on sale with a reading speed from 10 to 50 MB / s and with a write speed from 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 at all think about the memory card used. If the application is too active to read or write to the memory card, the work will slow down. Again, as is the case with an Internet connection, you should consider a caching mechanism for frequently used data.

Conclusion

Under Android, we develop a little over a year. Now we have five applications in the Play Store :

• Pravo.ru - client for the reference legal system of the same name
• Two versions of the card file of arbitration cases - old and new
• Where is the court? - background information on any of the 113 courts of the Russian Federation
• Selloby - mobile classified ads service

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

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