Join money app. Постановка задачи, возможности и ui приложения Структура приложения и решения

1. Join money app

JOIN MONEY APP
СЮКОВ СЕРГЕЙ
12.06.2017

2. Содержание

СОДЕРЖАНИЕ
Постановка задачи, возможности и ui приложения
Структура приложения и решения

3. Постановка задачи, возможности и ui приложения

ПОСТАНОВКА ЗАДАЧИ, ВОЗМОЖНОСТИ И
UI ПРИЛОЖЕНИЯ

4. Постановка задачи

ПОСТАНОВКА ЗАДАЧИ
В маленькой компании работают 5 человек. Два учредителя и трое наемных работников. Компания на
енвд схеме налогообложения, поэтому нет необходимости в налоговой отчетности за каждую денежную
операцию. В денежном обороте принимают участие все сотрудники (прием предоплаты, закупка
материалов, оплата накладных расходов, прием пост оплаты и т.д.).
Учет движения денежных средств осуществляется через одним из учредителей, остальные присылают
ему все свои расходы и доходы по смс, а он вносит их в используемую им программу для учета расходов.
Проблемы:
Второй учредитель имеет не постоянный доступ к данным программы.
Каждый из наемных сотрудников не знает о своем текущем балансе.
Трудоемкий и неудобный процесс для занимающегося внесением информации в систему учета.

5. Постановка задачи

ПОСТАНОВКА ЗАДАЧИ
Внесение данных
Вносить основные операции (доход, расход, перевод), с указанием счетов, категорий, тегов.
Просмотр остатка денег на счетах.
Просмотр детализации по счетам, категориям, тегам.
Синхронизация данных между устройствами.
Многопользовательский режим
Подключение к одному аккаунту нескольких пользователей.
Закрепление за пользователем счета.
Выставление уровня доступа пользователя. Выявлено три роли:
Администратор – может видеть и редактировать все записи.
Пользователь – может просматривать все записи, но не редактировать. Может добавлять заметки (текст и фото) для последующей
обработки их администратором.
Ограниченный пользователь – может просматривать операции только по своему счету (без редактирования). Может видеть баланс своего
счета. Может добавлять заметки.

6. Анализ существующих предложений

АНАЛИЗ СУЩЕСТВУЮЩИХ ПРЕДЛОЖЕНИЙ
Приложение
Дребеденьги
TeamSpender
Дзен-мани
Monefy
Мои финансы
AndroMoney
Журнал расходов
Personal Finanse
CoinKeeper
Синхронизация
Несколько пользователей
на один аккаунт
Распределение ролей
между пользователями

7. UI

Вход в приложение
через Google аккаунт
Регистрация. Возможность
присоединиться к существующему
аккаунту
Ожидание подтверждения при
запросе на присоединение к
существующему аккаунту

8. UI

Меню (при входе под
администратором)
Список счетов с
балансом по каждому
Список операций

9. UI

Редактирование
операции
Окно ввода суммы
операции
Окно установок
фильтра по датам

10. UI

Редактирование
пользователя
Список заметок
Редактирование
заметки

11. Решения

РЕШЕНИЯ

12. Схема сетевых запросов

СХЕМА СЕТЕВЫХ ЗАПРОСОВ
Android client
UI Thread
Activity
or
Fragments
Apache server
Background
EventBus
Request
handler
Retrofit
PHP
SQLite
MySQL

13. Схема Запросов к базе данных

СХЕМА ЗАПРОСОВ К БАЗЕ ДАННЫХ
UI Thread
StartPreparingData(){
AsyncExecutor.create.execute(…);
}
onDataPrepared(data){
// update UI
}
Background
EventBus.AsyncExecutor
EventBus.StyckyEvent
DataProvider.getData(){
// take data
…
EventBus.postStyky(… data);
}
softRef<Data>
onException(Exception e){
// handle exception
}
SQLite

14. Решения

РЕШЕНИЯ
Apache + PHP + MySQL
Рассматриваемые альтернативы:
Firebase real-time database
+ обновления в реальном времени
+ меньше кода
- NoSQL база данных. В приложении используется запросы с JOIN, который отсутствует в Firebase.

15. Решения

РЕШЕНИЯ
EventBus + Retrofit
Рассматриваемые альтернативы:
Retrofit (асинхронные запросы)
- не следит за состоянием фрагмента/активити
Loaders + Retrofit
- более сложная реализация
AsyncTask + Retrofit
- не следит за состоянием фрагмента/активити

16. Решения

РЕШЕНИЯ
Retrofit
Рассматриваемые альтернативы:
Volley
- нет синхронных запросов, а асинхронные не отслеживают жизненный цикл фрагментов.
HttpURLConnection
- Нужно вручную парсить json.

17. Решения

РЕШЕНИЯ
Для кеширования запросов к sqlite базе данных, был создан класс DataProvider. Это singleton, через
который все фрагменты запрашивают данные из базы.
В этом классе результаты всех используемых запросов к базе сохраняются в soft reference.
Если данные и условия запроса не были изменены, то в следующий DataProvider сразу возвращает
данные из соответствующей soft reference (или если система их удалили, то снова идет в sqlite)
При изменении/добавлении данных, вызываем у DataProvider метод обнуляющий соответствующую soft
reference.

18.

БЕЗОПАСНОСТЬ
Client
параметр 1,
параметр 2,
параметр 3,
…
google account token,
account id,
request sign (sha1 от всех
параметров запроса и appKey,
сложенных в одну строку)
Server
запрос
- Вычисляется своя версия request sign и
сравнивается с пришедшей
- Проверяется соответствие token и account
id
- Если access status данного аккаунта
позволяет вносить изменения в базу, то
вносятся изменения

19.

Спасибо за внимание!