Определитель номера 2gis iphone

Как в iPhone настроить определитель номера?

Довольно часто нам звонят абоненты с неизвестных номеров, зачастую относящиеся к спам-звонкам с предложениями различного рода товаров и услуг. Как узнать, что «скрывается» за тем или иным неизвестным номером? И есть ли способ отличить важный звонок от назойливого спама?

Разработчики компании Apple предоставили возможность сторонним приложениям использовать расширения для стандартных звонков в iPhone.

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

Конечно, такие справочники не отличаются высокой точностью — все 100 % входящих звонков идентифицировать, к сожалению, не получится. Так или иначе, они могут быть очень полезны!

Настройка определителя номера с помощью приложений «Яндекс» и «2ГИС»

В настоящее время одними из лучших приложений, имеющих большую базу телефонных номеров различных организаций, являются приложения «Яндекс» и «2ГИС» («2Gis»). Для настройки определителя номера Вам потребуется:

1. Скачать приложения «Яндекс» и/или «2ГИС» в каталоге App Store;

2. Перейти в «Настройки» → «Телефон» → «Блок. и идентиф. вызова»;

3. Для указанных приложений активировать переключатели, отвечающие за доступ к блокировке и представлению ID абонента.

Готово! Теперь номера всех абонентов, которые внесены в базы «Яндекса» и «2ГИС», будут автоматически идентифицированы.

Источник

Выбираем менеджер звонков для android-устройств: 2GIS Dialer, ExDialer и Phone (FUG)

Оглавление

Вступление

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

реклама

Как и прежде, мы поговорим о приложениях для односимочных смартфонов и найдем двухсимочные решения. Таким образом, критериев для «звонилок» несколько – выполнять главную свою функцию, функционально быть совершенней стандартного решения Google, потреблять минимум ресурсов и по возможности быть бесплатной программой.

Начнем с 2GIS Dialer – приложения именитого разработчика, призванного стать верным помощником не только рядового пользователя, но и делового человека. Второй подопытный – старый добрый ExDialer, рассмотренный в прошлый раз; стоит выяснить, что в нем изменилось, что стало лучше, а что хуже. Ну а Phone (FUG) предлагает схожую функциональность, однако главная ставка в программе делается на красивый интерфейс, фото вместо звонков и видео-оповещения. И, как всегда, определимся с тем, каким он должен быть – идеальный номеронабиратель. Приступим.

В качестве тестового оборудования использовались планшет DEXP Ursus 8EV2 3G (Android 4.4.2, процессор MT8382, 4 x Cortex-A7 1.3 ГГц, видеоядро Mali-400 MP2, 1 Гбайт ОЗУ, аккумулятор 4 000 мАч, 3G-модуль, Wi-Fi 802.11b/g/n) и смартфон Homtom HT3 Pro (Android 5.1 Lollipop, процессор MT6735P, 4 x Cortex-A53 1.0 ГГц, 64-бит, видеоядро Mali-T720, 2 Гбайт ОЗУ, аккумулятор 3 000 мАч, 4G-модуль, Wi-Fi 802.11b/g/n).

Источник

Все «радости» CallKit или как мы делали определитель номера на iOS 10

2ГИС давно хотел поделиться с пользователями айфонов своими знаниями о телефонных номерах компаний из справочника. Android-платформа давала такую возможность, а вот под iOS подходящего инструмента долго не было.

В июне мы ездили на WWDC 2016, и на одной из сессий ребята из Apple обмолвились, что наконец-то можно делать «gorgeous astonishment» — определитель номеров под iOS 10. Радости нашей не было предела, но до поры до времени: как Apple любит, фичу она предоставила с рядом ограничений.

Прототип

Первая «радость», с которой мы столкнулись — «богатая» документация, а именно:
→ CXCallDirectoryExtensionContext

И всё. Ну что ж, могло быть хуже.

Из этого видим, что dialer под iOS — это расширение приложения, которое крутится отдельным процессом, его можно перегрузить и получить его статус. Похоже на то, что нам нужно.
В самом же экстеншне можно добавить номера в виде «телефон/имя» и добавить номера для блокировки.

Первый прототип был готов за 30 минут. Один личный телефон, зашитый в экстеншн, один тестовый телефон добавлен в блокировку, всё завелось с первого раза, радости не было предела. Будущее выглядело крайне радужным — мы уже представляли, как всё это попадёт в ближайший релиз на следующий день.

Пока не столкнулись со второй «радостью»: мы не можем включить dialer из основного приложения. Нужно отправить пользователя глубоко в настройки, что явно не идёт на повышение конверсии этой фичи.

Потом начали добавлять пачку номеров и выяснилась третья «радость»: все номера нужно записать в базу до того, как они будут определены (это как раз знаменитая безопасность Apple — чтобы мы не получали доступ к входящему callerID). А наша база — это около 4 000 000 номеров с подписью. То есть 140 Мб текстовой информации, или 40 Мб, если пожать по самой жести, и всё это нужно каким-то образом доставить в расширение.

Вооружившись этим знанием, мы приготовили данные в виде «телефон/имя» и начали пилить уже более реальный прототип.

База данных

Сначала решили тупо добавить все номера, и вновь неожиданность — номера должны быть добавлены не абы как, а в порядке возрастания: 01, 02, 911 и т.д. В противном случае экстеншн падает. В первой бете 8 xcode экстеншен падал вообще без ошибок.

Далее выяснилось, что мы ограничены 1 999 999 номерами. Да, именно 1 999 999, а не 2 000 000, что тоже не совсем равняется нашим 4 000 000 номеров. Хотели сначала сделать три расширения, наполниться каждое до 1 999 999 номеров и в ус не дуть. Потом решили разделить по регионам: Москва + Питер, остальная Россия, зарубежка. Но от этого решения отказались, потому что нужно было придумать более сложную доставку и делать фичу еще менее стабильной, и работа нескольких одновременно работающих расширений тоже не была стабильной. Да и заставлять пользователя включать все три расширения тоже не хотелось. В итоге решили оставить только номера установленных у пользователя городов.

Поначалу хотели доставлять данные через SQLite. Собрали простую базу в 100 000 номеров из Новосибирска, написали логику работы с базой, запустили демопроект, и… ничего. Ошибок нет, всё ок, а номера не определяются.

Покопав это дело, выяснили, что при попытке вытащить данные из SQLite в ascending order база создаёт кеш на 30 Мб и экстеншн падает по памяти. Покопав форумы Apple, поняли, что лучше не вылезать за 5 Мб оперативной памяти. В итоге при объединённой базе для Москвы, Питера и ещё пары городов нужно будет сильно усложнять запросы к базе, строить хорошо оптимизированные по памяти и скорости фетчи, и усложнять процесс тестирования. Делать все это было совсем некогда, неохота, к тому же моих компетенций в околобазаданных технологий явно не хватало.

Запилили свой тупой, как бревно, формат данных в виде битовой последовательности:

[uint16_t: Размер блока][unsigned long long int:Phone][String:Name]

Да, по идее нужно использовать кеш, читать блоком по 8 Кб и всякие такие дела. Но такой алгоритм пробегает по базе в 2 000 000 номеров за 10 секунд в отдельном системном процессе, не затрагивая никак основное приложение, притом происходит это один раз за обновление, поэтому решили сильно не заморачиваться с оптимизацией.

Ура! Теперь мы умеем безопасно парсить номера телефонов из базы, спокойно укладываясь в лимит 5 Мб памяти. Но время идёт, а фича всё ещё не готова.

Доставка данных

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

Оказалось, что за нас уже всё придумали и есть замечательная штука App Groups, которая позволяет шарить данные между двумя приложениями от одного разработчика.

Можно положить в основном приложении файл по пути:

а в экстеншне достать его через:

Хоть проблем с доставкой не было никаких, и на том спасибо.

Дальше мы приготовили данные в нужном формате. Если не сильно углубляться, 500 Мб файл в формате .tsv нужно раскидать по 108 регионам, перегнать в бинарный формат, заархивировать и создать джобу на дженкинсе, чтобы не делать всё это руками и иметь готовую портянку данных для каждого релиза без особой боли. Короче, на это мы тоже потратили прилично времени — около 90% от всей разработки.

Встала задача доставить эти данные в телефон (вторые 90% разработки).

Сначала решили использовать технологию «On demand resources», а заодно и узнать, зачем нужна третья, вечно пустая вкладка в xcode — Resource Tags.

Эти ребята расскажут лучше:

• Документация;
• Видео с WWDC 2015;
• Видео с WWDC 2016;

Если коротко, Resource Tags для нас — это просто манна небесная (а именно Download Only On Demand). Она позволяет пометить некоторые ресурсы приложения тэгами, указать их тип, и при заливке приложения в стор он не будет включать их в бинарь. Потом их можно докачать при помощи NSBundleResourceRequest и получить через [NSBundle mainBundle]. То есть вообще не нужно пинать другие команды, придумывать, как их хранить и как доставлять до пользователя. А Apple сам хранит все данные + предоставляет очень адекватное API для их получения. Что сулило быструю интеграцию хотя бы здесь.

Но не всё оказалось так радужно: в первом релизе эта технология показала себя крайне паршиво, и примерно 20% пользователей тупо не смогли ничего скачать. Покопав форумы Apple, выяснили, что не у нас одних такая проблема, а они очень давно её не чинят и никак на неё не реагируют.

Resource Tags пришлось выпилить и доставлять данные другим способом. В итоге вшили данные в базу обновления городов. Теперь вместе с обновлением города пользователи получают новые базы номеров.

Всё впереди

Худо-бедно dialer попал в AppStore, и тут нас ждала четвёртая «радость».

После успешной установки мы удаляли базы, так как зачем хранить то, что уже и так находится в памяти телефона. Оказалось, не всё так просто: если пользователь зайдёт в настройки, выключит и включит экстеншн, то вместо того, чтобы просто включиться, экстеншн идёт по полному сценарию обновления. My bad, мы это не учли, и все, кто так делал, теряли базы без возможности их обновления. В следующей версии мы это оперативно поправили и теперь оставляем данные в телефоне, пока они ещё актуальны.

Мы постоянно получаем жалобы, что определитель не работает, или вопросы, как его включить. Пока, как промежуточный вариант, сделали отдельный пункт про определитель в настройках 2ГИС.

С iOS 10.3 Apple подкинула ещё проблем: если обновиться до этой версии, то определитель пропадает в настройках до тех пор, пока пользователь либо не переустановит приложение, либо не накатит обновление. Экстеншн в целом ведёт себя нестабильно. Периодически (по непонятным причинам и законам) он выключается или вовсе пропадает из настроек при обновлении. Иногда, в процессе обновления номеров, система молча прибивает экстеншен с кодами ошибок:

Ещё в октябре мы создали пару радаров в Apple с просьбой дать нам ручку, чтобы позволить пользователям включить dialer из самого приложения, и по поводу баги с 10.3. Первый тикет Apple игнорирует с октября, а второй находится в ооочень длинной очереди.

Так что в ближайшее время мы вряд ли сможем сделать продукт лучше для пользователя.

Как всё это в итоге работает:

1. Пользователь качает город/города;
2. Из города достаётся база номеров в нашем формате;
3. Смотрим все базы, которые установлены у пользователя (мы храним их в общем UserDefaults между экстеншном и основным приложением);
4. У каждой базы есть хэш. Если хоть один хэш не совпал или появился новый, мы записываем все новые базы в общее хранилище и помечаем их как готовые к установке. Это нужно на случай, если пользователь не активировал экстеншн, а свернул приложение и включит его потом;
5. Если экстеншн активен, перезагрузим его через:

В самом экстеншне, когда он получает:

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

Помечаем базы как установленные;

Повторяем процесс для каждого обновления;

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

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

Вместо заключения

На данный момент фича завершена, в ближайшее время планов по её доработке нет. Но всё ещё хочется сделать выборку по самым определяемым номерам — где-то в районе 100 000 номеров — и зашить их сразу в экстеншн, чтобы пользователи сразу получили минимальный функционал без необходимости скачивать регионы. Ещё у нас есть довольно много данных о «токсичных» номерах: коллекторские агентства, различного рода опросы, разные финансовые пирамиды и другие неугодные номера, на которые пожаловались пользователи Dialer на Android. Их мы тоже можем доставить отдельным пакетом всем желающим.

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

Источник