Contour.Elba for Android. Developer Notes

At the end of last year, I joined the Elba web service team, and we started developing an “electronic accountant” for Android.

In this post I will talk about why we abandoned the mobile version of the site in favor of the applications, which rakes we came to during the development process and what came of it.

The article will be useful:

• Android developers;
• Web service development managers who are thinking of entering the mobile market;
• entrepreneurs who have long been looking for a way to "shove your business into the phone."

Kontur.Elba is a web service that has been helping IP and small organizations to conduct business and report over the Internet for more than 4 years. Elba began as a service in which it was possible to solve one single task - to pass the declaration of the USN. And today we are able to form and deliver almost all the necessary small business reports to the regulatory authorities via the Internet. The system also allows you to manage documents, cash receipts and write-offs, employees, goods in stock ... in general, the full "living wage of a businessman."
')
The natural development of the service was access to mobile platforms. The simplest and cheapest (as it seemed at first glance) scenario was to make a mobile version of the site: you could immediately cover all possible devices and save money on attracting mobile developers - everything could be done by the existing development team.

But having studied this option together with usability specialists, we saw that the scenarios and principles of our users' work on the mobile device and computer are very different: the phone is used rather for viewing / reading / tracking changes, while the computer is for active actions like reporting, input new data.

But most importantly, the mobile version does not allow you to use all the advantages of mobile devices: background tasks, push notifications, gesture control (the latter is available on the web, but in very limited amounts). And, of course, in the mobile version to work offline would not have happened.

Therefore, they decided - no half measures! Only native applications for each platform, only hardcore!

They decided to start with Android. The choice of platform was determined by the preferences of users of our service: Android smartphones and tablets among them are slightly more than devices on iOS or Windows Phone. So I appeared in the team :)

Novice rake

New people in a team are always great: new workers, new ideas and new approaches to work. And, of course, new errors and problems. This time, the “newcomer,” you guessed it, turned out to be me, and it was a mistake to begin development on the very first day of work in Elba.

The fact is that in our team, TZs do not work for a variety of reasons: here there is no single customer, and interface design with pieces, and programmers in general dislike reading multivolume tasks. Therefore, the main way to transfer tasks from interface designers to developers are prototypes - we even wrote about it .

The lack of approach - you need to have the context of what is happening in the system, understand how not only this screen works, but also those that are associated with it, because everything cannot be depicted on sketches - something is considered obvious. But not newcomers to the team ... As a result, I had to redo much, and, accordingly, the time for the first release took one and a half times more than I planned - two and a half months instead of 4-6 weeks.

My “favorite” example among all the alterations is the search for documents. They can be searched either by parameters (date, counterparty, document type, status), or by the text of the document.



For me it was obvious that you can search around at once. And having spent some time on developing and debugging, it was very disappointing to find out that in Elbe full-text search and filters were intentionally made mutually exclusive. This was done for a reason, and at the request of users, who found it more convenient when these types of searches do not complement each other, but replace them. In general, the explicit specificity of the project, which I ignorantly ignored.

The conclusion may be obvious, but to repeat it once again will not be superfluous: gentlemen, mobile developers, do not be lazy and do not postpone acquaintance with the team and the product for later - then spending time on reworking is much more offensive.

Interface

The interface from the initial sketches to the current version has come a long way. For example, in the first version we were going to use the panel below on the main screen to switch between main pages, documents, money, reports ...



But there was a problem - not all users need all the capabilities of the service: someone does not use documents, someone does not work through the application with money, and someone does not need reports. And which of the lists to do mainly in this situation? Thus, we come to the screen-dashboard with a summary of all the key information.

The bigger problem was, by the way, not the variety of resolutions, but the quality of the screens! Colors that looked great on an iPhone or monitor screen could look very different on different phones. We had to constantly double-check new interface options on at least three phones.

With the permissions, we acted simply: the main screen was initially prepared for a resolution of 480 × 800, then it was checked how it would enter 320 × 480, and, if necessary, it was adjusted to it. We do not support resolutions below 320 × 480, there is no special tablet version yet.

Severe technical topic (almost no pictures)

The application is written in Java, no multiplatform layers, and supports Android 2.3 and higher. Will we continue to support 2.3 - I do not know yet: our active users on this OS version are less than 2%. At the same time, at least 20-30% of the time was spent on ensuring compatibility, so if we started the project now, the minimum supported version would be 4.0. The main problems were the layout, but with the fresh API or its backports, everything was not so smooth either.

The database is SQLite, and without using ORM (nothing, by the way).

We collect reports on uncaught exceptions (as well as parts of completely intercepted ones) using the ACRA library on our own server, the results are aggregated and dropped to developers by mail. Why we did not limit ourselves to the usual assembly of information on exceptions in Google Play? Because users do not like to click on the button "send report to the developer." We have, for example, the ratio of the number of real errors to the reports sent by users is about 100 to 1. So I highly recommend using ACRA or a similar library. I see no reason to write my own bike - ACRA is finely tuned.

Analytics on the use of the application we collect using Google Analytics. There are no surprises, everything works as expected: custom events allow you to track almost any interesting scenarios for research. Although I was surprised by the documentation on analytics: try to click on the link , and then click on the links in the left block concerning the Android SDK. The references will lead to the documentation for the 3rd version of the library, although the 4th version is already relevant for a month now. Trifle, yes kosyachok.

We also have our own warm and lamp approach to icons. As known,

1. Android 4.4 and below does not support out of the box vector images, only PNG, JPEG and GIF
2. The normal way for the platform is to prepare several copies of the image in different resolutions and lay them out in folders like drawable-hdpi, drawable-xhdpi, drawable-mdpi, etc.

But! In Android, you can simply connect your font in the application. And in this font, you can include icons and in the right places instead of the ImageView put TextView with one character. Thus, it is not necessary to render and copy one icon 7 times in a row, and the fonts are scaled adequately - no need to think about how your icon will appear on a small or giant screen. Although during the layout process, this approach sometimes leads to amusing results: in the IDE preview mode, the custom font is not loaded and instead of icons, letters and numbers are displayed.



And now the tip-off is for those who want to make themselves a feature with information about the call: the TYPE_SYSTEM_ALERT class windows can be drawn on top of all other windows, including the system dialer. However, if you want, we will write a full-fledged tutorial on this topic with a description of the pitfalls.

Testing

So far, testing is carried out by our testers manually. Typically, the test is conducted on three phones - on Android 4.4, 4.2 and 2.3, plus an innumerable number of emulators of both native and, for example, Genymotion . The latter is a very useful thing, sorry calls and push notifications cannot be tested on it.

But when it comes to checking out some new theory about the interface or testing something cool, like, for example, information about a call, devices from the entire floor are collected on the table!



This seems to be all. I am pleased to answer questions on both technical and non-technical aspects of application development. In addition, an article is being prepared on the preparation and evolution of application design.