Android app for debt collectors
Supports old devices and works offline
API integration / Android / Data security
First of all, our app should support architecture and backend of a server developed long ago by someone else. Obviously, the service was initially optimized for web, and its API was a bad match for the mobile context. We had no chance to adapt necessary methods for mobile without adaptation of all other modules of the system.
Secondly, all debt collectors, who will be the primary users of the app, use their own different devices that come in a variety of models, manufacturers, OS versions and release years. Our app should support virtually any Android device.
Third, the limited internet was one of the most popular use cases, as many clients live in areas with slow or no mobile network. Therefore a full-featured offline sync was one of the main challenges.
The app resulted in a blend of several technically complex and non-trivial solutions that made it not only bullet-proof but also convenient.
"Despite our expectations, the full-featured offline mode (while in the field, debt collectors should be still able to have full access to app’s functions, even if network is unavailable) turned out to be not the most complex thing: all data and catalogues can just sync with server every hour or once a day. However, taking into account the volume of data, we had to run parallel processes for database transactions and request queues for the sake of speed." Diana Raspopova, Lead Android Developer.
And that's when we ran into another problem.
Can’t touch this
Offline mode implies that we keep client database on the phone, that's what the Federal law number 152 is for: the law protects user's personal data. If we encrypted and decrypted every string for several dozens of tables of thousands of values with a slow smartphone CPU, the bank would go bankrupt yet until the Second Coming. So the solution was SQLCipher that can encrypt and decrypt the entire database at once. What's important, the database can only be opened by the same app it was created in.
The unchangeable API was handled thanks to the universalization of serializators and deserializators. Parsers checked the input data type and depending on that decided on performed actions.
Can’t touch this