да я уже пожалел что выбрал этот термин

?

в описании апа надо написать просто что приложение может тратить заряд из за использования локации, реджект 100% был не бинарника а метадаты

а текст описания для чего?

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

это типа текст в NSLocationAlwaysUsageDescription

может с саппортом поговоришь и уточнишь чего именно они хотят

может с саппортом поговоришь и уточнишь чего именно они хотят

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

просто ответа от них можно ждать хоть 2 дня , уже неделю вожусь с этим по 2 дня ревью и ответы от apple а ?

ну это нормальная практика с эпл сапортом

используй такую схему

делаешь запись через приватный контекст После записи мержи в мэин

делаешь запись через приватный контекст После записи мержи в мэин

приватный контекст всегда в одном экземпляре висит?

ты от него можешь создать дочерний

но приватный

создавать мэйн смысла нет)

а в момент мерджа в главный контекст интерфейс не будет ли так же лагать?

чтение происходит быстрее записи

Ещё есть схема

но я не работал с таким набором данных, что бы у меня загибалась core data

но ты попробуй)

какая разница если все они должны мержится

как какая? приватный (который в мэйн ветке) стянул в себя все изменения в бэке, а мейн от него пересоздался

мейн пересоздался?

с ума сошел?

набрось?

main не пересоздается, а постоянно должен висеть.

к нему например FRC подключен

все объекты захваченные текущим состоянием приложения в нему подключены

есть конечно гении, которые используют CD на манеру sql.. но сейчас не о них

раньше я писал на PL/SQL под oracle вот там были скорости

все эти orm тормознутые

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

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

думаю в инете можно почитать

да это еще хуже

то ты в один мейн мержил, а то в десяток будешь мержить

а зачем нужны несколько main контекстов

раньше я писал на PL/SQL под oracle вот там были скорости

О, я думал я один такой?

и никакого прямого обмена объектами сделать нельзя

между сущностями с разными мейнами

"разные мейны" даже звучит бредово само по себе

О, я думал я один такой?

?

эта дичь будет работать только если использовать как я выше написал, в режиме "фечнул, копирнул данные и забыл про CD"

в таком виде CD мягко говоря избыточна

если я загрузил 10 к записей, которые отображают мне реквизиты банков, нахуй мне это на главном экране? Редактировать я их буду ? тоже нет, о каком обмене сущностей идет речь?

видимо ты не понимаешь о чем говоришь

ну ок

@liiiiiiiiiiiiiiiiiiiiiiiiiiiil так а че рилм не юзаешь, он же мега крут и быстр?

ну я его не юзал(

@liiiiiiiiiiiiiiiiiiiiiiiiiiiil так а че рилм не юзаешь, он же мега крут и быстр?

в целях обучения начал на кордате. не стал сразу на realm бросаться

та говорят, что вообще пофиг, типа в топку кордату, юзайте рилм

просто ответа от них можно ждать хоть 2 дня , уже неделю вожусь с этим по 2 дня ревью и ответы от apple а ?

а что приложение делает?

вот ребята вообще два координатора юзают

почему все эти данные 7к на телефоне? это справочник?

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

почему все эти данные 7к на телефоне? это справочник?

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

а что приложение делает?

Ну вообще много чего , есть разные юзеры с разными правами и экранами, и именно где нужно следить за пользователем это юзер водитель. Когда у водителя есть заказ нужно заказчику предоставлять реальное место положения и тд

как часто ты выкачиваешь все 7к?

Ну вообще много чего , есть разные юзеры с разными правами и экранами, и именно где нужно следить за пользователем это юзер водитель. Когда у водителя есть заказ нужно заказчику предоставлять реальное место положения и тд

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

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

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

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

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

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

ERROR: S client not available

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

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к записей это все таки прилично, для одной транзакции

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

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

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

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

не используй каскадные апдейты

не используй каскадные апдейты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

репутацию восстанавливаем