почему нет пагинации и тп? Юзеру нужны все эти 7к?

То есть оно в бэкграунде отправляет на сервер местоположение?

Да если есть заказ

ну конечно есть ленивый БЕ, ну то такое

один раз авторматически, а далее по требованию. но тормоза не в момент скачивания из сети. тормоза, когда например нужно все 7к файлов связать с какой нибудь записью. Создается промежуточная сущность 1 к 1 для каждого файла с указанием даты создания, номера и пр. А от нее уже много к 1 к созданной записи В этот момент лагает. То есть создается дополнительно 7к записей и проставляются две связи с другими таблицами.

Да если есть заказ

requestAlwaysAuthorization - покажи как запрашиваешь

requestAlwaysAuthorization - покажи как запрашиваешь

locationManager = CLLocationManager() locationManager.desiredAccuracy = kCLLocationAccuracyNearestTenMeters locationManager.distanceFilter = 200 locationManager.allowsBackgroundLocationUpdates = true locationManager.requestAlwaysAuthorization() locationManager.pausesLocationUpdatesAutomatically = false locationManager.delegate = self

один раз авторматически, а далее по требованию. но тормоза не в момент скачивания из сети. тормоза, когда например нужно все 7к файлов связать с какой нибудь записью. Создается промежуточная сущность 1 к 1 для каждого файла с указанием даты создания, номера и пр. А от нее уже много к 1 к созданной записи В этот момент лагает. То есть создается дополнительно 7к записей и проставляются две связи с другими таблицами.

ну я понял, что проблема в момент записи. а ты смотрел, сам процес записи отнимает много времени или может при мапинге что то жует время?

фильтр на дистанцию 200 метров и точность 10, одно из них избыточно, но это не в этом дело.

Потом должны быть 4 дескриптора

желательно локализованных

Да да есть это асе

Когда приложение стартует первйы раз покажи экран

где оно запрашивает разрешение

на английском покажи

ну я понял, что проблема в момент записи. а ты смотрел, сам процес записи отнимает много времени или может при мапинге что то жует время?

треть времени занимает обычный insert и проставление двух связей, которые заранее известны. Треть занимает мердж(сохранение) из фонового дочернего контекста в родительский главный (начинаются лаги ui), последняя треть возникает при записи в persisten store (сохранение главного контекста).

на английском покажи

Приложения только для россиий и русско говорящих предназначено С момента принятия заявки и до ее окончания нам необходимо отслеживать ваше местоположение в целях контроля процесса перевозки груза. Это текст

Приложения только для россиий и русско говорящих предназначено С момента принятия заявки и до ее окончания нам необходимо отслеживать ваше местоположение в целях контроля процесса перевозки груза. Это текст

Покажи на русском

Но фишка в том, что даже отбросив процесс вставки, простое удаление тоже долго работает. Все эти 7к записей связаны с одной записей с каскадным правилом. Одна компанда удаления этой записи, приводящая у удалению связанных объектов, уже приводит к лагам

ручной фетч и последовательное удаление так же работает примерно по скорости

Приложения только для россиий и русско говорящих предназначено С момента принятия заявки и до ее окончания нам необходимо отслеживать ваше местоположение в целях контроля процесса перевозки груза. Это текст

Все правильно, что тебе отказывают. Где ты тут обосновываешь необходимость использования background location service?

единственное, что интересное, это NSBatchDeleteRequest, но оно только с ios 9. Но это все только касаемо массового удаления

Это индусу ни о чем не говорит

Если ты претендуешь на always, ты должен точно написать зачем тебе фоновый режим. А твое описание подходит под активный и фоновый тут нахер не нужен.

И напиши для индуса на английском

Если ты претендуешь на always, ты должен точно написать зачем тебе фоновый режим. А твое описание подходит под активный и фоновый тут нахер не нужен.

Ну ок попробую спс

в описание добавь строчку

которую все добавляют. "Внимание! Постоянное использование службы определения местоположения (GPS и Глонасс) в фоновом режиме может значительно уменьшить длительность заряда и срок службы батареи."

единственное, что интересное, это NSBatchDeleteRequest, но оно только с ios 9. Но это все только касаемо массового удаления

там есть несколько новых классов, NSBatchUpdateRequest еще

помоему в WWDC 2015 их презентовали

которую все добавляют. "Внимание! Постоянное использование службы определения местоположения (GPS и Глонасс) в фоновом режиме может значительно уменьшить длительность заряда и срок службы батареи."

ок благодарю !

там есть несколько новых классов, NSBatchUpdateRequest еще

update с ios 8. Но он для массового изменения проперти на одно значение у всех записей в запросе. Довольно специфический юз кейс мне кажется

В чатике жизнь кипит

Даже Дима помогает

Но фишка в том, что даже отбросив процесс вставки, простое удаление тоже долго работает. Все эти 7к записей связаны с одной записей с каскадным правилом. Одна компанда удаления этой записи, приводящая у удалению связанных объектов, уже приводит к лагам

тоже удаляй в приватном контексте. Мейн контекст он от того мейн, что работает с главным потоком

тоже удаляй в приватном контексте. Мейн контекст он от того мейн, что работает с главным потоком

ну я так и делаю. Зависит все от схемы стека кордаты, которую обсуждали выше

ну я так и делаю. Зависит все от схемы стека кордаты, которую обсуждали выше

ну если заюзаешь схему с двумя координатами - напиши результат)

ну я так и делаю. Зависит все от схемы стека кордаты, которую обсуждали выше

На пакеты поделить не получается? тип важное сперва сохранить, а остальное где-нибудь в бэкграунде?

да, вариант)

да, вариант)

есть инфа что будет все так же

Сначала MR юзают, потом наследуются всю жизнь от одного контекста

ну хотяб попробуешь скажешь, получилось или нет)

Сначала MR юзают, потом наследуются всю жизнь от одного контекста

в каком случае ты решаешь что нужно создавать еще один контекст,а не использовать уже существующий ?

На пакеты поделить не получается? тип важное сперва сохранить, а остальное где-нибудь в бэкграунде?

ну.. тут нет неважного. можно сохранять то, что юзер не видет сейчас. Но все равно, сохранение пойдет через main контекст в той схеме стека кордаты. Тут разница лишь в том, когда юзера заставить страдать: включить сохранение во время его действия или чуть попозже)

как там в МR стек собран main context -> private context -> coordinator->store ?

как там в МR стек собран main context -> private context -> coordinator->store ?

вот у меня сейчас такая же. От main отщипляются фоновые воркеры

хотел сказать AR?

хотел сказать AR?

Все правильно MR - MagicalRecord

Для работы с кордатой

хотел сказать AR?

MRC 😂

нет, лучше ActiveRecord на свифте 😄

зачем все эти обертки?

нет, лучше ActiveRecord на свифте 😄

Не говори ничего про свифт, а то Виталий налетит и обругает🙈

Не говори ничего про свифт, а то Виталий налетит и обругает🙈

а он знает что я специально 😄

Слушайте а у меня вот вопрос - мне никогда не надо было работать с массивами данных на ios, а человек, который меня учил, всюду ставит Realm по умолчанию. Скажите, а что бы вы использовали для задачи "загрузить с сервера немножко данных и сохранить их ненадолго". ну там приложение для новостей, например, простейшее?

зачем все эти обертки?

Ну не хотят выстраивать это все сами и юзают готовое)

Слушайте а у меня вот вопрос - мне никогда не надо было работать с массивами данных на ios, а человек, который меня учил, всюду ставит Realm по умолчанию. Скажите, а что бы вы использовали для задачи "загрузить с сервера немножко данных и сохранить их ненадолго". ну там приложение для новостей, например, простейшее?

У меня еще не было ситуаций, где CD подводила бы

в чистом виде? или с обязкой в виде того же MR?

+

у realm стек поменьше будет

чистый

херак херак и в продакшн

в чистом виде? или с обязкой в виде того же MR?

Ну как хочешь, данных немного же)

ага, понятно. Спасибо!

когда научишся кордате можешь и MR, но скорее всего уже будет свой экстеншен)

назревает спор типа юзать аламофайр или идти с урлсесшен)

назревает спор типа юзать аламофайр или идти с урлсесшен)

а ты подстрекаешь уже смотрю который раз

😄

все я работать)

если прыгнишь в MR начнутся проблемы с контекстами)

какие проблемы?

я как увидел как весь coredata стек сетапится, сразу же стал искать что-то вменяемое

в непонимании

для не знающего человека будут большие головные боли, да

как их сохранять и тп

мы же про magical record жи?

так там те же самые контексты

да

ну вот, если ты не шаришь CD, то все же черный ящик.