Архитектура клиент-серверного приложения с off-line режимом - Программирование Android

@arvalon · Регистрация: 26.10.2012

Доброго дня.
Столкнулся со следующим вопросом на тестировании:

Создаётся Android-приложение, работающее с данными на сервере. В серверном API есть команды получения, обновления и удаления данных: /item/list, /item/add, /item/update и /item/delete.
На главном экране приложения отображается список элементов “item”, которые приложение при каждом запуске должно запускать с сервера.
Приложение так же должно уметь работать в оффлайн-режиме: если пользователь добавил, отредактировал или удалил элемент, эти изменения должны сохраниться на сервере, когда появится доступ в Интернет, даже если приложение было закрыто.
Какие проблемы и сложности такой архитектуры клиент-серверного взаимодействия Вы видите? Как их решать? Знакомы ли Вам какие-либо типовые решения таких задач? Если не знакомы, пожалуйста, спроектируйте и опишите архитектуру, которая «будет работать».

Как обнаружить доступ в сеть и запустить что-нибудь при закрытом приложении есть идеи - сделать сервис в нём броадкаст ресивером ловить сеть.
А как реализовать такую "очередь" изменений, которая рассосётся при обнаружении сети? В ней по идее должны быть элементы - команды API и данные конкретного API-вызова. В общем тут мысли теряются совершенно, за что хвататься.

@vxg · 02.12.2016, 14:28

arvalon, пусть есть некие данные и их копия. при изменениях вносим их в копию. при наличии сети отправляем разность в данных на сервер. получив от сервера положительный ответ уравниваем копии.

@arvalon · 02.12.2016, 15:03 **[ТС]**

Сообщение от vxg

пусть есть некие данные и их копия. при изменениях вносим их в копию. при наличии сети отправляем разность в данных на сервер. получив от сервера положительный ответ уравниваем копии.

Это очень абстрактно. Хотелось бы поподробнее.
Вот предположим я загрузил себе методом API /item/list коллекцию каких-нибудь элементов, для простоты пусть это будет String.
Если бы не надо было выполнять все эти манипуляции с данными для off-line работы это было бы сделано достаточно просто - какой-нибудь метод в презентере (предположим что у нас реализована архитектура MVP) формировал запрос к API, получал данные, сохранял их в поле в презентере и вызывал условный метод showData из Вью (View), передавая туда ссылку на то поле с пришедшими данными. Всё просто....

Но в случае с поддержкой off-line режима работы и отправки изменений при появлении сети всё сильно усложняется. Под копией данных подразумевается второе поле в презентере? А отправлять во view отображаться тогда что, данные из основного поля с данными или из копии?

И вот далее допустим одну запись из item я отредактировал, одну удалил и ещё одну добавил. Всё это отразилось в копии, ок, сделаю. Далее, когда "поймаю" сеть, начинается самое сложное имхо. Предположим что записи в items уникальны, у записи items есть поле-аналог primary key.
Далее как:
необходимо проверить что это не первое появление сети и если это так вызвать "метод-синхронизатор" который будет попарно обходить все записи и из того что есть на сервере и того что есть в копии в телефоне. Сравнивать каждую запись и вызывать для не совпадающего содержимого. Записи, отсутствующие на сервере отправлять туда. И ещё с удалёнными что-то надо делать...

И потом ещё это обновлённое состояние данных вновь отобразить на экране - подтянуть с сервера вновь или понадеяться что всё нормально синхронизировалось, перелить копию в основные данные в презентере и отобразить на экране.

Как-то ОЧЕНЬ монстроозно получилось, мне кажется это делается гораздо проще, короче а главное надёжнее

@vxg · 02.12.2016, 15:15

arvalon, как будет выглядеть представление и отображение данных - это вам решать. безусловно, описанные манипуляции возможны только если данные могут быть идентифицированы (то есть являются как бы строками базы данных каждая из которых имеет некий ID). вот у вас есть два локальных набора этих строк. может быть даже хранящихся в базе, но не обязательно. первый из них получен полным скачиванием данных с сервера которое происходит при первом запуске программы. второй является его копией в которую мы вносим изменения. мы их вносим вносим вносим... а потом когда нужно делаем всего три выборки:
-каких строк нет в первом наборе? из этих строк мы сформируем список на добавление
-каких строк нет во втором наборе? из этих строк мы сформируем список на удаление
-какие строки есть и там и там но хоть по одному полю у них есть отличие? из этих строк мы сформируем список на изменение
посылаем эти три списка на сервер. если сервер ответил нам положительно (списки приняты и применены), то мы очищаем первый набор и копируем в него содержимое второго.

Добавлено через 4 минуты
...сбои во время процедуры не влияют на ее результат. количество появления в сети не влияет на результат. в самом худшем случае вы попытаетесь добавить то что уже есть (сервер должен ЗАМЕНЯТЬ данные) либо удалить то что уже удалено (ну и пусть - сервер должен понимать что это не ошибка) или модифицировать то что уже модифицировано (ну и пусть еще разок модифицируем)

@arvalon · 02.12.2016, 15:36 **[ТС]**

Сообщение от vxg

описанные манипуляции возможны только если данные могут быть идентифицированы (то есть являются как бы строками базы данных каждая из которых имеет некий ID)

да да, я написал что

Сообщение от arvalon

Предположим что записи в items уникальны, у записи items есть поле-аналог primary key.

Сообщение от vxg

вот у вас есть два локальных набора этих строк. может быть даже хранящихся в базе, но не обязательно

да, слой БД пока не стал вводить, это не меняло бы сути, пусть пока что бизнесс-данные живут пока приложение окончательно не было завершено.

Сообщение от vxg

а потом когда нужно

вот тут интересный момент над которым я думаю. По идее же надо же первый раз попробовать внести изменения на сервер сразу же в момент изменения копии. И только если что-то пошло не так, оставить всё как есть и положиться на сервис, который с помощью броадкаст ресивера и/или по таймауту пытается доделать всю работу.
Вот тут вот как лучше, выполнять все изменения над копией и сразу же вызывать отправку изменений на сервер. В случае успеха переливать копию в основной набор. Но в таком случае пока изменения не будут успешно отправлены на сервер - они будут отображаться как ещё не отредактированные. Мы же ведь отображаем основной набор на экране.

А если поступить по другому - отображать копию, но тогда логика вызова методов API как-то усложняется - сначала надо попробовать вызвать эти методы в момент изменений и потом ещё вызывать их же по событиям появления сети, по таймауту.

@vxg · 02.12.2016, 15:49

arvalon
-при любом изменении менять второй набор причем делать это железно (например сохраняя его в базу, шаредпреф, файл или еще как-то)
-отображать надо второй набор, то есть тот над которым мы производим манипуляции
-слать изменения можно по вашему желанию (зависит от задачи) - можно по факту изменения и в случае неудачи периодически повторять попытку. можно вообще делать это исключительно периодически.

Добавлено через 2 минуты
...я правда не знаю насколько ваша задача чувствительна к рассогласованию баз и что именно происходит на сервере при внесении изменений. в некоторых случаях вообще так делать нельзя и нужно всегда дожидаться подтверждения что данные изменены - тогда мы работаем на прямую с сервером, без всей этой возни. но поскольку вы подняли этот вопрос наверное вы можете на некоторое время рассогласовать базы

Добавлено через 1 минуту
...к примеру: мы покупаем (добавляем в базу строку с товаром) и сделать это можно только если товар в наличии. если мы будем работать оффлайн, то мы можем накидать 333 строки которые по факту будут отвергнуты сервером так как товар закончился

@arvalon · 02.12.2016, 15:53 **[ТС]**

Сообщение от vxg

я правда не знаю насколько ваша задача чувствительна к рассогласованию баз...к примеру: мы покупаем (добавляем в базу строку с товаром) и сделать это можно только если товар в наличии. если мы будем работать оффлайн, то мы можем накидать 333 строки которые по факту будут отвергнуты сервером так как товар закончился

да да, я думал об этом, насколько вообще критичны данные к таким вещам. Особенно например если данные есть, но они другие. А то так можно вообще купить что-то не то, это ещё хуже чем в конце концов просто получить ошибку.
Но в изначальном задании курсивом ничего об этом нет, видимо предполагается то что на эту тему можно подискутировать при ответе.

@vxg Модератор 3231 / 2034 / 319 Регистрация: 13.01.2012 Сообщений: 7,887
	02.12.2016, 14:28	#2
	arvalon, пусть есть некие данные и их копия. при изменениях вносим их в копию. при наличии сети отправляем разность в данных на сервер. получив от сервера положительный ответ уравниваем копии. 0

@arvalon 21 / 6 / 2 Регистрация: 26.10.2012 Сообщений: 179 Записей в блоге: 1
	02.12.2016, 15:03 [ТС]	#3
	Сообщение от vxg пусть есть некие данные и их копия. при изменениях вносим их в копию. при наличии сети отправляем разность в данных на сервер. получив от сервера положительный ответ уравниваем копии. Это очень абстрактно. Хотелось бы поподробнее. Вот предположим я загрузил себе методом API /item/list коллекцию каких-нибудь элементов, для простоты пусть это будет String. Если бы не надо было выполнять все эти манипуляции с данными для off-line работы это было бы сделано достаточно просто - какой-нибудь метод в презентере (предположим что у нас реализована архитектура MVP) формировал запрос к API, получал данные, сохранял их в поле в презентере и вызывал условный метод showData из Вью (View), передавая туда ссылку на то поле с пришедшими данными. Всё просто.... Но в случае с поддержкой off-line режима работы и отправки изменений при появлении сети всё сильно усложняется. Под копией данных подразумевается второе поле в презентере? А отправлять во view отображаться тогда что, данные из основного поля с данными или из копии? И вот далее допустим одну запись из item я отредактировал, одну удалил и ещё одну добавил. Всё это отразилось в копии, ок, сделаю. Далее, когда "поймаю" сеть, начинается самое сложное имхо. Предположим что записи в items уникальны, у записи items есть поле-аналог primary key. Далее как: необходимо проверить что это не первое появление сети и если это так вызвать "метод-синхронизатор" который будет попарно обходить все записи и из того что есть на сервере и того что есть в копии в телефоне. Сравнивать каждую запись и вызывать для не совпадающего содержимого. Записи, отсутствующие на сервере отправлять туда. И ещё с удалёнными что-то надо делать... И потом ещё это обновлённое состояние данных вновь отобразить на экране - подтянуть с сервера вновь или понадеяться что всё нормально синхронизировалось, перелить копию в основные данные в презентере и отобразить на экране. Как-то ОЧЕНЬ монстроозно получилось, мне кажется это делается гораздо проще, короче а главное надёжнее 0

@vxg Модератор 3231 / 2034 / 319 Регистрация: 13.01.2012 Сообщений: 7,887
	02.12.2016, 15:15	#4
	arvalon, как будет выглядеть представление и отображение данных - это вам решать. безусловно, описанные манипуляции возможны только если данные могут быть идентифицированы (то есть являются как бы строками базы данных каждая из которых имеет некий ID). вот у вас есть два локальных набора этих строк. может быть даже хранящихся в базе, но не обязательно. первый из них получен полным скачиванием данных с сервера которое происходит при первом запуске программы. второй является его копией в которую мы вносим изменения. мы их вносим вносим вносим... а потом когда нужно делаем всего три выборки: -каких строк нет в первом наборе? из этих строк мы сформируем список на добавление -каких строк нет во втором наборе? из этих строк мы сформируем список на удаление -какие строки есть и там и там но хоть по одному полю у них есть отличие? из этих строк мы сформируем список на изменение посылаем эти три списка на сервер. если сервер ответил нам положительно (списки приняты и применены), то мы очищаем первый набор и копируем в него содержимое второго. Добавлено через 4 минуты ...сбои во время процедуры не влияют на ее результат. количество появления в сети не влияет на результат. в самом худшем случае вы попытаетесь добавить то что уже есть (сервер должен ЗАМЕНЯТЬ данные) либо удалить то что уже удалено (ну и пусть - сервер должен понимать что это не ошибка) или модифицировать то что уже модифицировано (ну и пусть еще разок модифицируем) 0

@arvalon 21 / 6 / 2 Регистрация: 26.10.2012 Сообщений: 179 Записей в блоге: 1
	02.12.2016, 15:36 [ТС]	#5
	Сообщение от vxg описанные манипуляции возможны только если данные могут быть идентифицированы (то есть являются как бы строками базы данных каждая из которых имеет некий ID) да да, я написал что Сообщение от arvalon Предположим что записи в items уникальны, у записи items есть поле-аналог primary key. Сообщение от vxg вот у вас есть два локальных набора этих строк. может быть даже хранящихся в базе, но не обязательно да, слой БД пока не стал вводить, это не меняло бы сути, пусть пока что бизнесс-данные живут пока приложение окончательно не было завершено. Сообщение от vxg а потом когда нужно вот тут интересный момент над которым я думаю. По идее же надо же первый раз попробовать внести изменения на сервер сразу же в момент изменения копии. И только если что-то пошло не так, оставить всё как есть и положиться на сервис, который с помощью броадкаст ресивера и/или по таймауту пытается доделать всю работу. Вот тут вот как лучше, выполнять все изменения над копией и сразу же вызывать отправку изменений на сервер. В случае успеха переливать копию в основной набор. Но в таком случае пока изменения не будут успешно отправлены на сервер - они будут отображаться как ещё не отредактированные. Мы же ведь отображаем основной набор на экране. А если поступить по другому - отображать копию, но тогда логика вызова методов API как-то усложняется - сначала надо попробовать вызвать эти методы в момент изменений и потом ещё вызывать их же по событиям появления сети, по таймауту. 0

@vxg Модератор 3231 / 2034 / 319 Регистрация: 13.01.2012 Сообщений: 7,887
	02.12.2016, 15:49	#6
	arvalon -при любом изменении менять второй набор причем делать это железно (например сохраняя его в базу, шаредпреф, файл или еще как-то) -отображать надо второй набор, то есть тот над которым мы производим манипуляции -слать изменения можно по вашему желанию (зависит от задачи) - можно по факту изменения и в случае неудачи периодически повторять попытку. можно вообще делать это исключительно периодически. Добавлено через 2 минуты ...я правда не знаю насколько ваша задача чувствительна к рассогласованию баз и что именно происходит на сервере при внесении изменений. в некоторых случаях вообще так делать нельзя и нужно всегда дожидаться подтверждения что данные изменены - тогда мы работаем на прямую с сервером, без всей этой возни. но поскольку вы подняли этот вопрос наверное вы можете на некоторое время рассогласовать базы Добавлено через 1 минуту ...к примеру: мы покупаем (добавляем в базу строку с товаром) и сделать это можно только если товар в наличии. если мы будем работать оффлайн, то мы можем накидать 333 строки которые по факту будут отвергнуты сервером так как товар закончился 0

@arvalon 21 / 6 / 2 Регистрация: 26.10.2012 Сообщений: 179 Записей в блоге: 1
	02.12.2016, 15:53 [ТС]	#7
	Сообщение от vxg я правда не знаю насколько ваша задача чувствительна к рассогласованию баз...к примеру: мы покупаем (добавляем в базу строку с товаром) и сделать это можно только если товар в наличии. если мы будем работать оффлайн, то мы можем накидать 333 строки которые по факту будут отвергнуты сервером так как товар закончился да да, я думал об этом, насколько вообще критичны данные к таким вещам. Особенно например если данные есть, но они другие. А то так можно вообще купить что-то не то, это ещё хуже чем в конце концов просто получить ошибку. Но в изначальном задании курсивом ничего об этом нет, видимо предполагается то что на эту тему можно подискутировать при ответе. 0

Опции темы