Pull to refresh

Comments 32

пользовался одной из первых версию АОНа от 2GIS для android и замечал что ранее номер определялся в звонилке после звонка, а не во время звонка.
Сейчас это так?
В iOS нет доступа к входящим звонкам, соответственно определить тоже никак нельзя кто звонил ни в приложении ни в экстеншене, можно только сказать какие телефоны можем определить. Пока что так.
т.е в Ios и Android АОН работает постфактум? если да то это печально.
просто у стандартной звонилки Andorid 6.0 из коробки есть определение номера во время звонка. Обычные разработчики могут получить к этой фиче доступ?
1. это статья про определитель на iOS, я очень рад что на андроид все можно, на iOS разрешено только то что разрешено
2. Мы не имеет доступа к входящим звонкам, мы всего лишь «учим» систему что номер 911 это служба спасения.
3. Когда служба спасения звонит нам (приходит входящий вызов от 911) iOS смотрит базу всех номеров, которые были получены от экстеншенов (не обязательно нашего) если он находит номер 911, он вытаскивает этот номер из базы телефона (не расширения) и показывает его во время звонка (что видно на скриншоте).
4. Обычные разработчики под iOS (я как обычный разработчик вам говорю) могут получить доступ к этой фиче, курите доки.
сейчас определяется во время звонки даже если вы еще не подняли трубку при входящем.
Расширение запускается один раз за одну версию, работает от 1 до 10 секунд, больше никак не поднимается, думаю жрет в районе 0.0035% (в среднем за 8 часов телефон разряжается 1 / (8 * 60 * 60) ≈ 0.000035) за каждое обновление приложения, порядок такой.
Отдельное спасибо за инфу про ограничение оперативки в 5 мб! На днях закончил делать описанную фичу, но о таких ограничениях и подводных камнях даже не подозревал.
Включение в глубине настроек — это конечно тихий ужас, очень надеюсь они это каким-то образом оптимизируют… =\
А не пробовали поресёрчить в направлении CoreData + CloudKit? Возможно, решилась бы проблема с памятью (CoreData позволяет удобно батчить записи, хотя не уверен, что не съест те же 30 метров) и доставкой новых номеров пользователям.
Пробывали. В первую очередь, основная проблема отсортировать по номерам. Создается большой кэш, как не старался при базе в 1млн номеров вылазит за 5 метров только в путь. готовить правильно NSFetchRequest не хотелось (а если честно я CoreData прям не люблю)

У нас уже есть готовая система доставки данных, которая легко держит нагрузки в 15млн пользователей, а после того как обожглись на On demand resources, не хотелось больше ничего иметь с эппловской системой доставки.

Думаю это прям ок связка для баз в районе 100-300к и месячной аудитории такого же порядка.

А как ведёт себя система, если включено 2 определителя от разных разработчиков? Не проверяли?

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

Это была одна из гипотез как запихать 4 000 000+ млн номеров. Был прототип с 3 экстеншенами от одного приложения, все работало ок.

Также проверяли как работает несколько разных приложений с CallKit экстеншенами, проблем тоже не было.
При попытке включить в настройках «Блокировка и индентификация» появляется ошибка — «При попытке включить расширение 2ГИС произошла ошибка». Не подскажите, что в этом случае делать? (iOS 10.2.1)
Такое бывает, долгий дебаг экстеншена ничем не помог, просто падает какая то системная библиотека, помогает только включить/выключить пару раз, или переустановка приложения (без скачанного региона включится, но номера определять не будет). Других способов это вылечить мы не нашли (
Специально установил 2gis, но не нашел в статье как включить экстеншн. Он сейчас доступен?
Нужно зайти в настройки > телефон > Блок. и индентификация вызова > Включить 2ГИС
В картинках
image
image
image

Простите, возможно я неправильно прочитал, но что за 10 сек на поиск по файлу, а как же бинарный поиск по отсортированным данным? Что за ограничение по оперативке, есть же маппинг файлов в память?

Мы не ищем по файлу, нам нужно записать в память телефона 100 000 — 2 000 000 номеров, в возрастающем порядке ровно один раз, именно так работает АОН на iOS 10. CallKit не дает на лету перехватить входящий номер, от слова никак.
Для самого сложного случая нам нужно проитерировать 2 000 000 номеров. Итерация по всем номерам в экстеншене (а ему выделяется далеко не все системные ресурсы) и запись всего этого в память телефона занимает около 10 секунд на iPhone 5.
Спасибо, просто я еще не знаком с механизмом работы экстеншона этого типа. В статье хорошо было бы лишний раз подчеркнуть этот момент в самом начале.

В качестве оптимизации, предлагаю не копировать куски NSData в массивы а потом еще и в строки. Предлагаю сразу создавать NSString без копирования данных на исходном NSData через -initWithBytesNoCopy:length:encoding:freeWhenDone: https://developer.apple.com/reference/foundation/nsstring/1413830-initwithbytesnocopy?language=objc


Учитывая, что -dataWithContentsOfFile:options:error: и так маппит файл в память – получение памяти сведется к минимуму вообще.

Да, ты прав, хоть это и не узкое горлышко, фикс выкачу)
Уже дважды после обновления приложения 2ГИС невозможно включить флажок в настройках — iOS выдает ошибку о невозможности включения расширения. Причем и 2ГИС, и еще одного, которое никак с первым не связано. Помогает только переустановка iOS с последующим восстановлением профиля пользователя. Просто сброс и восстановление профиля не помогает.
Евгений, я пишу аналогичное приложение, только у меня под 10 миллионов номеров)) два вопроса:

1) Скажите, происходит ли закачка номеров в экстеншн когда приложение свернуто в бэкграунд? У меня почему ранее при тестировании происходила, потом перестала. Не могу понять или не качественно изначально протестил или она не происходит.

2) Можете дать пример файла с которого парсите номера? У меня приходятся архивированные файлы которые я распарсиваю, гоню в базу в Realm, в ней сортирую, и потом с экстеншна уже тяну отсортированные. По памяти все ок (в iOS 10.2 расширился лимит до 13-14 мб), но скорость этой операции жуть. Хочу взять ваш файл за образец.
denisenkoaj

1. Да происходит, экстеншн это отдельное приложение которое крутиться отдельным процессом и не зависит от основного. Происходит закачка или нет можно проверить посмотрев системные логи, там будет что то вроде
...5000 phones added…
...5000 phones added…
...5000 phones added…

2. Файл пожалуй не дам, но вот сниппет, который эти файлы создает. В статье есть пример парсера. По памяти там вообще нет просадки, а любая база делает сортированный прогон либо долгим либо прожорливым по памяти.
Код
@interface DGSPhonesDataWriter : NSObject
- (void)writePhone:(unsigned long long int)phone name:(NSString *)name;
- (void)saveWithPath:(NSString *)path;
@end


#import "DGSPhonesDataWriter.h"

@implementation DGSPhonesDataWriter {
	NSMutableData *_data;
}

- (instancetype)init {
	self = [super init];
	if (self == nil) return nil;
	_data = [NSMutableData data];
	return self;
}

- (void)writePhone:(unsigned long long int)phone name:(NSString *)name {
	NSMutableData *localData = [NSMutableData data];
	[localData appendBytes:&phone length:sizeof(unsigned long long int)];
	[localData appendData:[name dataUsingEncoding:NSUTF8StringEncoding]];
	uint16_t len = (uint16_t)localData.length;
	[_data appendBytes:&len length:sizeof(len)];
	[_data appendData:localData];
}

- (void)saveWithPath:(NSString *)path {
	[_data writeToFile:path atomically:YES];
}

@end


teanet Спасибо, супер! А как вы доступ получаете к логам?
Потому что NSLog от экстеншна в консоль не пишет, я отдельно сделал логирование через userDefaults — через записи них у меня экстеншн сообщает свой статус основному приложению.
Мы забили на логи, потому что на процесс обновления мы повлиять не можем, а успешный сценарий проходит всегда, так как данные заранее подготовлены.

Мы смотрели в сторону дарвиновских нотификаций, но из за нехватки времени и малой приоритетности этой фичи, не дожали эту тему.

Если Apple выкатит более вменяемый api для включения из приложения, вернемся к этой теме.
teanet У вас никогда не было такой потрясающей ошибки при обновлении ?)
Error while reloading status for тутмойбандлid extension: Optional(Error Domain=sqlite Code=11 «sqlite3_step for query 'INSERT OR IGNORE INTO Label (localized_label) VALUES (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?), (?),
и дальше много таких же вопросов,…
returned 11 (11) errorMessage 'database disk image is malformed'» UserInfo={NSLocalizedDescription=sqlite3_step for query 'INSERT OR IGNORE INTO Label (localized_label) VALUES (?)

Кажется это пустая строка или недопустимый символ в методе для поля label
- (void)addIdentificationEntryWithNextSequentialPhoneNumber:(CXCallDirectoryPhoneNumber)phoneNumber label:(NSString *)label;

Еще возникали подобные проблемы когда обновить экстеншн 2 раза не дожидаясь окончания обновления, но кажется это поправили.
teanet
я сначала импортирую номера в realm, а потом их достаю оттуда, вот значения для номеров на которых выскакивают ошибки:
中畑酒店
アラミス2
ошибка повторяется на одном аппарате 6+ у тестера, у меня на 6ках двух разных прекрасно все инсталлится. Причем то на одном номере стопорится то его проходит и стопорится на одном из следующих.
На других 6+ нет возможности проверить.

Есть идеи как можно проверку делать на допустимость? Алфавит там японский)

Просто ошибка вылетает со стеком sqlite а такие варианты я видел на форуме эпла только в постах от июня 2016 года и то после обновления ios такие ошибки со стеками исчезали.
Интересно, не думали о сборе фидбэка с тех номеров, которые не определились? я б честно говоря с удовольствием после отшивания очередного банка, предлагающего кредит, в открывающейся модалке (может еще как-то, чтобы не сильно мешало в других ситуациях) отписывал что-то типа 'в** банк спам'. Понятно, что будет много ложной инфы, но можно на big data усреднять, наверное. Итог — рост и актуализация базы за счет n% сознательных юзеров.
Повторюсь, мы не имеем доступа к входящим звонкам. Никак, от слова вообще. Есть api для определения факта того что был входящий звонок, но номер мы получить не сможем. Плюс, не думаю что нашим пользователям понравится всплывающее окно каждый раз после того как они получили входящий звонок.
И на всякий случай еще раз
image

Только сегодня узнал про эту фичу, странно, что никаких анонсов нигде не видел, они были?
Выглядит полезным, включил, потестим!

Only those users with full accounts are able to leave comments. Log in, please.