Kontur.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’ll talk about why we abandoned the mobile version of the site in favor of applications, what kind of rake in the development process came and what came of it.

    The article will be useful:
    • Android developers
    • Web services development managers who are considering entering the mobile market;
    • Entrepreneurs who have long been looking for a way to "push their business into the phone."

    Kontur.Elba is a web service that for more than 4 years has been helping individual entrepreneurs and small organizations conduct business and submit reports via the Internet. Elba began as a service in which it was possible to solve one single task - to submit a USN declaration. And today we are able to generate and submit via the Internet almost all the reports required by small businesses to the regulatory authorities. In the system, you can also manage documents, cash receipts and write-offs, employees, goods in the warehouse ... in general, the full “living wage of a businessman”.

    A 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: it would be possible to immediately cover all possible devices and save 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 on the mobile device and computer are very different: the phone is used more for viewing / reading / tracking changes, while the computer is used for active actions like generating a report, 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 a very limited amount). And, of course, in the mobile version, working offline would not work.

    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: there are slightly more Android smartphones and tablets among them than devices on iOS or Windows Phone. So I appeared in the team :)


    What is already possible in our application (many screenshots!)
    Do not wait for details and immediately download the application here .

    The first and most important thing that can be said about our application is that you can work effectively with it even in the absence of the Internet. At the first start, the application downloads all documents, invoices, contractors and other data to your phone. Now they can be managed (edit, delete, change status) regardless of the presence of an Internet connection. All changes will be saved on the phone and will be sent to the server as soon as possible.

    Almost all the most important data from the system is available in the application, in particular, receipts and write-offs, documents, and contractors:


    Information can be conveniently filtered, searched for and, of course, edited.


    You can see the operational information about those sent to the tax reports, as well as a list of current and upcoming tasks. In addition, from the program you can send a document or your own details to the mail of another person:


    The application can receive push notifications, so you will know almost instantly about a change in the status of a report or the receipt of money in a current account.


    If your counterparty is calling you, we can show an additional dashboard with information about it on top of the main call window:

    If you are worried about data safety, you can put a pin code on the application. Well, of course, all these features are configurable.

    Rookie Rake


    New people in a team are always wonderful: new working hands, new ideas and new approaches to work. And, of course, new errors and problems. This time, I’ve guessed that I’ve turned out to be a "newbie", but the mistake was to start developing on the first day of work in Elba.

    The fact is that TK does not work in our team for many reasons: here there is a lack of a single customer, and designing the interface in pieces, and generally dislike for programmers to read multivolume tasks. Therefore, the main way to transfer tasks from interface designers to developers are prototypes - we even wrote about it .

    The disadvantage of this approach is that you need to have a context of what is happening in the system, to understand how not only this screen works, but also those that are associated with it, because you cannot depict everything on the sketches - something is considered obvious. But not for the newcomers to the team ... As a result, I had to redo a lot, 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. You can search for them either by parameters (date, counterparty, document type, status), or by the text of the document.



    It was obvious to me that you can search all over immediately. And having spent some time developing and debugging, it was very disappointing to find out that in Elba full-text search and filters were intentionally made mutually exclusive. This was done not just like that, but 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 specifics of the project, which I ignorantly ignored.

    The conclusion may be obvious, but repeating it 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 it is much more offensive to spend time on alterations.

    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 to switch between the main pages, documents, money, reports ...



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

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

    With permissions, we did just that: the main screen was initially prepared for a resolution of 480 × 800, after which it was checked how it would go into 320 × 480, and, if necessary, fit to it. We do not support resolutions below 320 × 480, and there is no special tablet version either.

    Harsh technical theme (almost no pictures)


    The application is written in Java, no multi-platform layers, and supports Android 2.3 and higher. Whether we will continue to support 2.3 - I do not know yet: our active users on this version of the OS 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. Layout caused the main problems, but with the fresh API or its backport, everything was far from smooth.

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

    We collect reports on uncaught exceptions (as well as parts of quite caught ones) using the ACRA libraryto your own server, the results are aggregated and sent to the developers by mail. Why are we not limited to the usual collection of exception information on Google Play? Because users don’t like to click on the “send report to developer” button. For example, we have a ratio of the number of real errors to reports sent by users - somewhere around 100 to 1. So I highly recommend using ACRA or a similar library. I don’t see any reason to write my own bike - ACRA is very finely tuned.

    We collect application analytics using Google Analytics. There are no surprises, everything works as expected: custom events allow you to track almost any scenario interesting for research. Although analytics documentation surprised: try following the link, and then click on the links in the left block regarding the Android SDK. Links will lead to documentation for the 3rd version of the library, although the 4th version has been relevant for a month now. A trifle, but a jamb.

    We also have our own warm and lamp-like approach to the 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 of the form drawable-hdpi, drawable-xhdpi, drawable-mdpi, etc.

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



    And now a tip for those who wanted to make a feature with information about the call: windows of class TYPE_SYSTEM_ALERTYou can draw 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 countless emulators, 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 testing some new theory about the interface or testing something cool, such as call information, devices from around the floor gather on the table!



    That’s all. I will be happy to answer questions both on the technical and not very part of the application development. In addition, an article is being prepared on the preparation and evolution of application design.

    Also popular now: