Каков наилучший способ загрузки 1000+ записей на сервер, который также содержит изображения для каждой записи из приложения iOS/Android?

Ответ 1

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

Если у вас есть мультимедийные вложения, отправка каждой записи займет в среднем 2 секунды, если вы загружаете через мобильный интернет со скоростью ~ 2 МБ/с. Если вы отправите большую партию записей по каждому запросу, вы должны иметь стабильное соединение в течение длительного периода.

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

Также вам не нужно проверять подключение к Интернету или использовать приемник для отслеживания изменений состояния подключения. Вы можете просто использовать эти библиотеки для запуска запросов синхронизации:

• JobScheduler
• Firebase JobDispatcher
• Evernote android-job

Ответ 2

Я бы предложил использовать API базы данных Firebase. У этого есть прекрасная реализация в режиме offline/online/sync.

https://firebase.google.com/docs/database/

И можно читать/записывать данные с помощью Admin SDK для вашего сервера NodeJS:

https://firebase.google.com/docs/admin/setup

Ответ 3

Сохраните свои записи в локальном Db и используйте для этого ORM. Используйте Retrofit, которые предоставляют метод onSuccess и onFailure для вызова Webservice. Чтобы отправить данные на сервер с регулярным интервалом, вы можете использовать адаптер синхронизации.

Ответ 4

• 1st Мне нужно знать, как вы сохранили изображение в локальном db?
• Вам необходимо создать службу для обнаружения статуса соединения. Каждый раз, когда соединение установлено, вы отправляете свою запись как вид Multipart. Вы можете переустановить /Asynctask.
• Просто отправьте 1 запись на одну дооснащение /Asynctask, она заставит вас ez обрабатывать успех/неудачу каждой записи.
• Вы можете запустить одну или несколько модификаций/асинтез для отправки одной или нескольких записей, это зависит от вас.
• Если ур данных имеет изображение, на стороне сервера, вы должны обрабатывать процесс с сервера ur на 3-й сервер (сервер для сохранения изображения).

Ответ 5

Это очень широкий вопрос, который связан с архитектурой, интерфейсом UI Experience, ограничениями и т.д.

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

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

Если это локальный db, вам нужно будет управлять открытием и закрытием базы данных соответствующим образом, и я бы предложил использовать поле для отметки любых записей sync'd, поэтому, если некоторые записи не удались, вы можете повторить их на другом точка. Кроме того, вы можете конвертировать записи в json-массив, а затем выполнять почтовый запрос. Что касается загрузки изображений, определенно нужно быть в пакетном режиме, если их много, но также следить за тем, какие из них загружены, а какие нет.

Единственная проблема, с которой вы столкнетесь, если вы поддерживаете синхронизацию с разных устройств и платформ, заключается в синхронизации синхронизируемых данных с бэкэнд. В противном случае вам придется обрабатывать этот случай, это может быть очень грязно и, скорее всего, вызывает множество странных проблем.

Надеюсь, что это поможет на высоком уровне:)

Ответ 6

Чтобы воспользоваться простым подходом, у вас есть 1 флаг в объектах ваших объектов данных [NSManagedObject] как синхронизация. При создании нового объекта/изменения существующего изменения объекта флаг синхронизации на false.

Отфильтровать объекты данных со значением синхронизации как false.

let unsyncedFilter = NSPredicate(format: "sync = %@", @(false))

Теперь у вас будет массив объектов, которые вы хотите синхронизировать с сервером. Если вы отправляете объекты по очереди в запросах. При успешном изменении флаг синхронизации в true else, когда ваша функция снова будет запущена при обновлении статуса запуска/доступности приложения, она снова отфильтрует несинхронизированные данные и начнет синхронизацию.

Ответ 7

Вы можете использовать подход divide и conquer, чтобы разделить задачу на небольшую задачу и загрузить данные на сервер. 1. Возьмите логический флаг "isFinishData", начинающийся с false. 2. Загрузите данные на сервере с 0 до 100 записей. 3. следующая запись отправляет от 100 до 200. 4. этот процесс выполняется до тех пор, пока последняя запись (1000) не будет отправлена. 5. в последнем обновлении записи установите логическую переменную true и выйдите из цикла.

эта логика будет хорошо работать в IOS/android.

Ответ 8

Как говорили другие, это довольно широкий вопрос. Многое зависит от архитектуры сервера, который получит данные, а также от архитектуры приложения.

Если у вас есть какой-либо контроль над реализацией вашего бэкэнда, я бы рекомендовал внедрить решение для хранения, которое позволяет приостанавливать и возобновлять переводы. Оба облачных хранилища Google и Amazon S3 предлагают аналогичную функциональность.

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

Здесь вы можете найти пример использования подхода pause/resume с помощью мобильного SDK с Amazon https://aws.amazon.com/blogs/mobile/pause-and-resume-amazon-s3-transfers-using-the-aws-mobile-sdk-for-android/.

Редактирование добавления ссылки на SDK Amazon iOS, http://docs.aws.amazon.com/mobile/sdkforios/developerguide/s3transfermanager.html

Ответ 9

Лучший способ - разбить файлы на куски 100 и загрузить с интервалом или когда приложение не работает.