How I did my finance accounting for android with blackjack, SMS and FTS

Introduction

It all started back in 2011 when I bought my first Android smartphone and discovered the wonderful world of the Android Market. It was there that I found a great application for financial accounting Financisto. For several years I have been tracking my expenses and incomes in it, I was very used to it, but there were also weak points:

• the need to enter all transactions manually. Moreover, the share of non-cash payments grew inexorably, and the bank sends you a text message for every sneeze.
• There is no global view of the budget over the long term. That is, I wanted to see a table, suppose for a year, where for each month it would be clear how much was planned to spend and earn and how much came out after the fact, plus the total for all rows and columns. Here the reference was YNAB.
• No synchronization between devices. Yes, it was Flowzr, but somehow he did not go to me.

If the second problem was solved by exporting to CSV and omnipotent Excel, then the rest had to do something. The obvious option is to change the program. Having studied the proposal, I came to the conclusion that all applications are divided into scanty in functionality and expensive ones :) In the meantime, it was 2015, and I wanted to study the development for mobile devices more and more. Well, the stars converge, it was decided to cut your application!

Since my development background was associated with writing highly specialized programs on Delphi, then naturally, the first impulse was to try multiplatform development in Delphi itself. But let's not talk about that sad experience, I quickly came to the conclusion that I needed a native application and a normal tuling. So the android studio was downloaded and a new project was created. Next comes my stream of consciousness, which I tried to separate by topic.

About the application

The application has 2 fundamental entities: accounts and transactions. An account is a depository of funds, a transaction is a transfer of funds. Transactions are of three types:

• arrival - account replenishment by third parties
• expense - payment of our funds to third parties
• transfer - transfer of funds between your accounts

Actually this is the whole concept of the application. Further I will describe what was actually implemented. Some points will be described in detail below.

So, the first thing you need to simplify life is parsing SMS from banks to automatically create transactions. Then, import / export of data to CSV was made, and a subject of particular pride was custom import, which allows downloading data from CSV files of arbitrary structure. There is a scanner of checks of the Federal Tax Service of the Russian Federation and downloading information on them from the server. For convenient accounting, transaction attributes are made multi-level. For example, you can create such a category tree:

├  │ ├ ` │ │ ├  │ │ └  │ ├  │ └  │ └  

A similar structure is possible with other attributes, such as Recipients (contractors), Projects, etc. For easy navigation through the data, a system of filters has been made, according to various criteria. Implemented debt management and budgeting. In addition, there is a car and a small truck of smaller functions, which I will not list here.

Libraries and Tulling

From non-standard used libraries I can distinguish ButterKnife and EventBus. Although they look like anachronisms in 2018, they looked promising at the time they started development. Now I am not ready to implement full-scale refactoring. He experimented with RetroLambda and Rx, but cut them out as not appropriate for the task. As a result, the project is now pure Java 7, although there is a great desire to succumb to HYIP and try Kotlin.

The io.requery: sqlite-android library turned out to be very useful, allowing you to always have the current version of SQLite. The application implements entity trees (for example, nested categories) with no depth limit, and it is very efficient to use recursive queries to select such data. Unfortunately, they appeared in fairly recent versions of SQLite and are not available on older versions of android. Requery solves this problem.

Currently in the code 39 external dependencies. Yes, it is a lot, and I spend systematic work to reduce them. But, nevertheless, I believe that the use of third-party libraries is effective with the rapid build-up of functionality.

I'd like to introduce a normal DI, but again, there is no time for that yet.

A few words about tuling. If in 2014-2015 you could still hear about what you need to develop in Eclipse, and Genymotion was musthave for the developer for android, today Google has eclipsed everyone. Android Studio is very fast and convenient, but like the built-in emulator.

I would also like to say thanks to kaftanati for his tool . It allows you to maintain a Google table with string resources in different languages ​​and convert it into xml files. Very simplifies the localization process. By the way, the application is currently available in 2 languages: EN and RU.

During the development process, I mastered Git quite well, it turned out to be an irreplaceable thing.

Performance

Performance optimization has been given a lot of time. Highlight the following points that have had a significant impact:

• Depth of nesting layouts. Less is better. The problem almost disappeared after the introduction of the constraint layout.
• Database Optimization. Indices are our everything.
• Profiling TraceView is a very useful tool for understanding what is happening in the depths of an application.

In general, I am now satisfied with the performance. My personal database, which is at the same time test, contains a transaction archive for 5 years (> 7000 transactions) and at the same time does not slow down on the fastest phones.

Design

Personally, my design is bad. Perhaps that is why the first version turned out to be so vivid. However, it more or less corresponded to the norms of material design). This version lasted about two years, when at last I realized that I needed to change something. Since experience has shown that I myself can not cope, the cry was heard among freelancers. Such one was quickly found and redrew all the screens to me for reasonable money. I got the result in psd, but since I had already heard about such a wonderful tool as Zeplin, I quickly exported and redesigned everything into it. I like the present much more, besides, in the process of processing certain internal gayliney were formed, so now creating a new screen is not a problem.

It was and became:

The first version of material design consisted, in fact, of only one guideline, with which the developer was left alone. Therefore, many libraries have spawned, which offered the implementation of UI. This problem did not bypass me as well. In the desire to implement as close as possible to the standard, many libraries were imported. But Google is correcting and moving towards uniformity and simplification in the development process. The modern version of support'a allows you to do with virtually no third-party components.

Parsing SMS

Most applications practice SMS parsing with predefined formats. That is, the developer takes an SMS of a specific bank, writes the rules of how to disassemble it into parts and sews it into the code. Sometimes such rules can be edited by users, but this is a very complicated process. The advantages and disadvantages of this approach are obvious: if the developer has implemented the support of your bank, then everything is fine and works quickly. However, if the bank suddenly decides to change the format or your bank is not known to the developer, then everything stops working abruptly. I decided that the application should not know anything about the SMS format and put everything on the user, trying to make the task as easy as possible.

So, the general concept is as follows: you receive an SMS, for example, with the following content: "VISA1234 01.01.18 12:00 purchase 106.40r SUPERMARKET Balance: 6623.34r" (Sberbank). Obviously, here you can extract the following information: card number (account), date and time, the recipient of funds, the amount of the transaction and the balance on the card. The user's task is to set keywords (markers) correctly: select "VISA1234" and put a marker on the score, put a marker on the "SUPERMARKET" Recipient, etc.

The application remembers all the markers and thus learns. Experience shows that after a week or two of training, 90% of transactions are created automatically without user intervention. Yes, some effort needs to be spent, but independence from third parties seems to me worth it.

The users also like it, there are a lot of "helpers", for example, they were implemented: import of previously received SMS, parsing SMS from the clipboard, etc.

Loading of cash receipts of the FTS

Last year, the Federal Tax Service of the Russian Federation presented to all sellers a gift by obliging to send all cash vouchers in electronic form to their servers. Ordinary people also got a little bit of an official mobile application where you can check the check for authenticity and, most importantly, download it yourself in pdf or json formats. Not once this topic has been discussed here, however, in brief: there is no official document for receiving a check. It may be in some of the CRFs (fiscal data operators, through which checks are received from the cash registers at the FTS), but so that they would not receive and receive any check in one place. BUT, there is an official mobile application that works via http, with the usual http-authorization, which has long been used by good people who listened to traffic and put it on public display. Everything is simple there. You can create a new user by receiving a password via SMS, you can download the contents of the check according to his data, and you can download all the checks for a certain period previously uploaded by this user. To facilitate the task, a QR code is printed on each check, containing all the data needed to receive the check.

Then everything is just qrcodereaderview + retrofit and the contents of the check in our hands. In connection with the ability to load the list of goods in the check, the opportunity was realized to attach these goods to the transaction. That is, now you have a transaction can be not just a sum, but a composite amount, for example, 1 - + 2 - + ... And each product can be assigned a separate category and project, which can be very useful when shopping in supermarkets, when a lot of different goods are taken at one time.

Automation

One of the interesting requests from users turned out to be the desire to automate the creation of transactions by means of intents, which was actually done. You can create an intent with the amount and attributes of the transaction in any application and send it to my application, after which such a transaction will be automatically created. I myself, frankly, do not use such a method, but there are people who parset emails in the tasker and then create transactions based on them. Or another option - the creation of transactions by voice through Dusya.

Unfortunately, while there are problems on the 8th Android, since the background execution of intents was prohibited there. In the next versions I plan to make the launch of the foreground process to those users who want this functionality.

Synchronization

Synchronization, as much in this word ... Maintaining a common base was one of the main tasks of creating a project. Unfortunately, it has not yet been implemented. The reason is too complex a task for the petition of one person. Attempt was. And even had a working version. I did it on Firebase. At first glance, it looked not difficult. There is a giant json in which the common bases lie. All authentication is done by the 10th line in the security rules in the console. Api is very simple and convenient. The algorithm was about the following:

1. The user logs into the Realtime Database using Google account.
2. A node is loaded into it, into which its entire base is unloaded.
3. Then he gives permission to modify his database to other users, just by gmail.
4. Other users, when connected, indicate that they want to work with a foreign database and enter the address of the first user, then connect to his node and can add delete information.

Then the problems started: how to make a distinction of access rights ?; large bases had performance problems; It was supposed to offer synchronization in the form of a subscription, for this, verification on the server is needed, that is, a backend is also needed. Of course, all these problems were related to the lack of my experience and the lack of time for a full-scale study of the issue, but Google’s statement that the relatime database is now a bullet to the head is to do everything on the Firestore. In general, while this idea is paused, I continue to explore solutions. At the moment, I see the following options for implementation:

• To try all the same Firestore, they introduced the collection, simplified work with complex data structures.
• Spit on everything and make your backend. So far, Postgres + Postgrest looks like a good candidate. A minimum of development, more control, but again there are incomprehensible moments.
• An exotic option - xmpp server. Do not store data on the server at all, but only transfer it between users. It is fraught, in my opinion, with loss of consistency, but there are also pluses (although how to look) in the form of a complete lack of backend.

In general, I would be interested in your experience in solving this problem, who can guide you on the right path.

Promotion and earnings

Probably the weakest side of my project. To my great regret, it is much more interesting for me to develop than to sell. The traffic is extremely organic. The project is presented at w3bsit3-dns.com, a database of loyal users was formed there. Significantly increased the number of installations of the publication, again at w3bsit3-dns.com, as part of the developer support program. I can say that the money spent on it paid off, but no more.

Initially, the program was conceived as an educational project, so it was not a question of making money on it. However, in-app purchases also need to be studied, so the concept of Pro-functions, that is, paid features, was added. The feature is so far the only one - it is an opportunity to build graphical reports. I planned to make a subscription to synchronization, but for lack of a feature, there is still no subscription.

Github

For a long time I could not decide to open the source. Well, you know, hack purchases, will laugh at the code, etc. But then it came to the understanding that open source would be a blessing, so it is available by reference .

Conclusion

The main goal that I set myself when starting this project is accomplished - I learned the android. And, you can say, even succeeded in this. For the full title of success story, of course, there is not enough commercial success, but, nevertheless, I am glad that I managed to develop the project and bring it to mind. It also warms the thought that I am doing something useful for people.