👃🏽 👐🏿 🚵 CallKitのすべての「喜び」、またはiOS 10での発信者IDの処理方法 👩🏾‍🎨 ☣️ 🧕🏻

2GISは、ディレクトリの会社の電話番号に関する知識をiPhoneのユーザーと共有したいとずっと思っていました。 Androidプラットフォームはそのような機会を提供しましたが、iOSには長い間適切なツールがありませんでした。

6月にWWDC 2016に行きました。セッションの1つで、 Appleの人々は、「ゴージャスな驚き」、つまりiOS 10の発信者IDをようやくできると言いました。、彼女は多くの制限のある機能を提供しました。

試作機

最初に遭遇した「喜び」は、「豊富な」ドキュメントでした。

→CXCallDirectoryExtensionContext

@interface CXCallDirectoryExtensionContext : NSExtensionContext @property (nonatomic, weak, nullable) id<CXCallDirectoryExtensionContextDelegate> delegate; - (void)addBlockingEntryWithNextSequentialPhoneNumber:(CXCallDirectoryPhoneNumber)phoneNumber; - (void)addIdentificationEntryWithNextSequentialPhoneNumber:(CXCallDirectoryPhoneNumber)phoneNumber label:(NSString *)label; - (void)completeRequestWithCompletionHandler:(nullable void (^)(BOOL expired))completion; @end

→CXCallDirectoryManager

  @interface CXCallDirectoryManager : NSObject @property (readonly, class) CXCallDirectoryManager *sharedInstance; - (void)reloadExtensionWithIdentifier:(NSString *)identifier completionHandler:(nullable void (^)(NSError *_Nullable error))completion; - (void)getEnabledStatusForExtensionWithIdentifier:(NSString *)identifier completionHandler:(void (^)(CXCallDirectoryEnabledStatus enabledStatus, NSError *_Nullable error))completion; @end

それだけです。まあ、それはもっと悪かったかもしれません。

このことから、iOS用ダイヤラーは別のプロセスをスピンするアプリケーション拡張機能であり、オーバーロードしてそのステータスを取得できることがわかります。必要なもののように見えます。

拡張機能自体では、「電話/名前」の形式で番号を追加し、ブロックする番号を追加できます。

最初のプロトタイプは30分で完成しました。延長に配線された1台の個人用電話、1台のテスト用電話がロックに追加され、すべてが初めて起動しました。喜びに制限はありませんでした。未来は非常に明るいように見えました-私たちは、これらすべてが翌日の次のリリースにどのように分類されるかをすでに想像していました。

2番目の「喜び」に出会うまで、メインアプリケーションからダイヤラを有効にすることはできません。ユーザーを設定の奥深くに送る必要がありますが、これは明らかにこの機能の変換を増加させません。

その後、彼らは一連の番号を追加し始め、3番目の「喜び」が現れました：すべての番号は、決定される前にデータベースに記録する必要があります（これは単なる有名なAppleセキュリティです-着信callerIDにアクセスできないようにするため）。そして、私たちのベースは、署名付きの約400万の数字です。それは140 MBのテキスト情報、またはブリキ自体を押すと40 MBであり、これらすべてを何らかの方法で拡張機能に配信する必要があります。

この知識を武器に、「電話/名前」の形式でデータを準備し、すでに実際のプロトタイプを見つけ始めました。

データベース

最初に、彼らはすべての数字を愚かに追加することにしました、そして再び驚き-数字はとにかく追加されるべきではありませんが、昇順で：01、02、911などそれ以外の場合、拡張機能はドロップします。最初のベータ8では、xcode拡張機能はエラーなしでクラッシュしました。

さらに、1,999,999個の数字に制限されていることがわかりました。はい、正確に1,999,999であり、2,000,000ではありません。これは、4,000,000の数値ともまったく同じではありません。最初に、彼らは3つの拡張を作りたいと思っていました。それぞれが最大1,999,999個の数字で満たされ、口ひげに吹き飛ばされませんでした。その後、彼らは地域ごとに分割することを決めました：モスクワ+ピーター、ロシアの残り、外国人。しかし、彼らはこの決定を拒否しました。より複雑な配信を考え出し、機能の安定性をさらに低下させる必要があり、同時に機能するいくつかの拡張機能の作業も安定していなかったからです。はい。ユーザーに3つの拡張機能をすべて強制的に含めたくありませんでした。その結果、ユーザーが設定した都市の数のみを残すことにしました。

最初は、SQLiteを介してデータを配信したいと考えていました。ノボシビルスクから100,000個の単純なデータベースを構築し、データベースを操作するためのロジックを記述し、デモプロジェクトを開始しましたが、何もありませんでした。エラーはありません。すべて問題ありませんが、数値は決定されていません。

このケースを掘り下げた後、SQLiteからデータを昇順でプルしようとすると、データベースが30 MBのキャッシュを作成し、拡張機能がメモリからクラッシュすることがわかりました。 Appleのフォーラムを掘り下げた後、5 MBのRAMを使用しない方が良いことに気付きました。その結果、モスクワ、サンクトペテルブルク、およびいくつかの都市のデータベースを組み合わせた場合、データベースへのクエリを大幅に複雑化し、メモリを最適化してフェッチを高速化し、テストプロセスを複雑にする必要があります。これらすべてを行う時間はまったくありませんでしたが、不本意です。さらに、ニアベーステクノロジーに関する私の能力は明らかに十分ではありませんでした。

ログのように、ビットシーケンスの形式でデータ形式をダムを見ました：

[uint16_t：ブロックサイズ] [符号なしlong long int：電話] [文字列：名前]

トラブルのない非常にシンプルなパーサー：

  @interface DGSPhonesDataReader : NSObject /**   ,    next,  0 */ @property (nonatomic, assign, readonly) unsigned long long int phone; /**   ,    next,  nil */ @property (nonatomic, copy, readonly, nullable) NSString *name; - (instancetype)initWithFilePath:(NSString *)path; - (BOOL)next; @end

  #import "DGSPhonesDataReader.h" @interface DGSPhonesDataReader () @property (nonatomic, strong, readonly) NSData *data; @property (nonatomic, assign) NSUInteger location; @property (nonatomic, assign, readwrite) unsigned long long int phone; @property (nonatomic, copy, readwrite, nullable) NSString *name; @end @implementation DGSPhonesDataReader - (instancetype)initWithFilePath:(NSString *)path { self = [super init]; if (self == nil) return nil; NSError *error = nil; _data = [NSData dataWithContentsOfFile:path options:NSDataReadingMappedIfSafe error:&error]; _location = 0; if (_data == nil) { NSLog(@"DGSPhonesDataReader data create error: %@", error); } return self; } - (BOOL)next { uint16_t blockLength; [self.data getBytes:&blockLength range:NSMakeRange(self.location, sizeof(blockLength))]; self.location += sizeof(blockLength); unsigned long long int phone; NSUInteger textLength = blockLength - sizeof(phone); [self.data getBytes:&phone range:NSMakeRange(self.location, sizeof(phone))]; self.phone = phone; self.location += sizeof(phone); uint8_t buffer[textLength]; [self.data getBytes:buffer range:NSMakeRange(self.location, textLength)]; self.name = [[NSString alloc] initWithBytes:buffer length:textLength encoding:NSUTF8StringEncoding]; self.location += textLength; return self.location < self.data.length; } @end

はい、理論的には、キャッシュを使用し、8 KBのブロックを読み込む必要があります。しかし、このようなアルゴリズムは、別のシステムプロセスで10秒間に2,000,000の数値のデータベースを実行し、メインアプリケーションに何らかの影響を与えることなく、さらにこれは更新ごとに1回発生するため、最適化を気にしないことにしました。

やった！これで、データベースの電話番号を安全に解析でき、静かに5 MBのメモリ制限内に収まります。しかし、時間が経ち、機能はまだ準備ができていません。

データ配信

次に、このデータを拡張機能に、つまり実際には別のアプリケーションで配信する方法を理解する必要がありました。ユーザーが新しい地域をダウンロードし、古い地域を削除し、すべてを更新したいので、そこに縫い付けることは機能しません。データは古く、新しい地域が追加されますが、私たちは正確さと関連性についての会社です。

すでにすべてが発明されていて、同じ開発者の2つのアプリケーション間でデータを手探りできるApp Groupsという素晴らしいものがありました。

パスに沿ってメインアプリケーションにファイルを配置できます。

  + (NSString *)extensionDataPath { return [[[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:[self extensionGroupName]].path stringByAppendingPathComponent:@"Dialer"]; }

そして、拡張でそれを手に入れます：

  NSString *databasePath = [[DGSCallKitExtensionModel extensionDataPath] stringByAppendingPathComponent:manifest.databaseName];

配送に問題はありませんでしたが、ありがとうございます。

次に、目的の形式でデータを準備しました。深くしすぎない場合は、500 MBの.tsvファイルを108の地域に分散させ、バイナリ形式でそれを追い越し、Jenkinsでジョブを作成して作成する必要があります。要するに、これにもかなりの時間を費やしました-開発全体の約90％。

このデータを電話に配信するタスクが発生しました（開発の2番目の90％）。

最初は「オンデマンドリソース」テクノロジーを使用すると同時に、xcodeの3番目の永遠に空のタブ（リソースタグ）が必要な理由を見つけることにしました。

これらの人はあなたにもっとよく言うでしょう：

要するに、私たちにとってのリソースタグは、天国からの単なるマナです（つまり、オンデマンドでのみダウンロード）。これにより、一部のアプリケーションリソースにタグをタグ付けし、そのタイプを示し、アプリケーションに入力するときにそれらをbinarに含めなくなります。次に、NSBundleResourceRequestを使用してダウンロードし、[NSBundle mainBundle]から取得できます。つまり、他のチームをキックする必要はまったくありません。他のチームを保管する方法や、ユーザーに提供する方法を考える必要はありません。そして、Apple自身がすべてのデータを保存し、それを取得するための非常に適切なAPIを提供します。ここでも迅速な統合を約束したもの。

しかし、すべてがそれほどバラ色になったわけではありません。最初のリリースでは、このテクノロジーは非常にひどいものであり、ユーザーの約20％が何もダウンロードできませんでした。 Appleのフォーラムを掘り下げてみると、このような問題だけではないことがわかりましたが、長い間修正されず、まったく反応しませんでした。

リソースタグは別の方法でカットして配信する必要がありました。その結果、データは都市更新データベースに入力されました。これで、都市の更新とともに、ユーザーは新しいベース番号を受け取ります。

すべて先に

少なくともダイヤラーはAppStoreに入り、ここでは4番目の「喜び」を待っていました。

インストールが正常に完了した後、データベースを削除しました。これは、携帯電話のメモリに既にあるものを保存する理由です。すべてがそれほど単純ではないことが判明しました。ユーザーが設定に入り、拡張機能をオフにしてからオンにすると、単にオンにするのではなく、拡張機能は完全な更新シナリオに従って動作します。残念なことに、私たちはこれを考慮に入れておらず、これを行ったすべての人は、それらを更新する可能性なしに基盤を失いました。次のバージョンでは、この問題をすばやく修正し、関連性のあるデータを電話に残します。

識別子が機能しないという苦情、または識別子を有効にする方法についての質問を常に受け取ります。これまでのところ、中間オプションとして、2GIS設定で行列式に関する個別の項目を作成しました。

iOS 10.3では、Appleはさらに多くの問題を投げかけました。このバージョンにアップグレードすると、ユーザーがアプリケーションを再インストールするか更新をロールするまで、設定で識別子が消えます。拡張機能は全体として不安定に動作します。定期的に（不明な理由や法律のため）、更新時に設定からオフになるか、完全に消えます。場合によっては、番号を更新する過程で、システムはエラーコードを使用して拡張機能をサイレントに釘付けにします。

→CXErrorCodeCallDirectoryManagerErrorLoadingInterrupted;

→CXErrorCodeCallDirectoryManagerErrorUnknown。

10月に、Appleで、ユーザーがアプリケーション自体からダイヤラーを有効にできるようにするためのペンと10.3のバグについて尋ねるレーダーを作成しました。 Appleは10月以降の最初のチケットを無視し、2番目のチケットは非常に長い列になります。

そのため、近い将来、ユーザーにとって製品を改善できる可能性は低くなります。

最終的にどのように機能するか：

ユーザーは都市をスイングします。
都市から、私たちの形式で数値のデータベースを取得します。
ユーザーにインストールされているすべてのデータベースを調べます（拡張機能とメインアプリケーション間の共通のUserDefaultsに保存します）。
各データベースにはハッシュがあります。少なくとも1つのハッシュが一致しない場合、または新しいハッシュが表示される場合、すべての新しいデータベースを共有ストレージに書き込み、インストールの準備ができているとマークします。これは、ユーザーが拡張機能をアクティブにしないが、アプリケーションを最小化し、後で有効にする場合に必要です。

拡張機能がアクティブな場合、次の方法で再起動します。

  [[CXCallDirectoryManager sharedInstance] reloadExtensionWithIdentifier:bundleID completionHandler:^(NSError * _Nullable error) {}];

拡張機能自体で、彼が受け取ったとき：

  - (void)beginRequestWithExtensionContext:(CXCallDirectoryExtensionContext *)context

インストールの準備ができているベースがあるかどうかを確認します。ある場合は、すべてを調べて、次の番号を追加します。

  [context addIdentificationEntryWithNextSequentialPhoneNumber:phone label:name];

ベースをインストール済みとしてマークします。
更新ごとにプロセスを繰り返します。

コードでは、次のようになります。

  - (RACSignal *)reloadExtensionsIfNeeded { @weakify(self); if (![DGSCallKitFetchModel isExtensionAvailable] || self.manifests.count == 0) return [RACSignal empty]; return [[[[[[[[[self fetchCanBeInstalledExtensionsRegionCodes] filter:^BOOL(NSSet *regionCodes) { return regionCodes.count > 0; }] deliverOn:[RACScheduler scheduler]] flattenMap:^RACStream *(NSSet *regionCodes) { @strongify(self); return [RACSignal combineLatest:@[ [self downloadDatabasesWithRegionCodesIfNeeded:regionCodes], [DGSCallKitFetchModel fetchExtensionEnabled] ]]; }] flattenMap:^RACStream *(RACTuple *t) { @strongify(self); RACTupleUnpack(NSSet *regionCodes, NSNumber *extensionEnabled) = t; //    ,     if (!extensionEnabled.boolValue) return [RACSignal empty]; //    ,     , //            , //       if ([self shouldInstallDatabasesWithRegionCodes:regionCodes]) { return [RACSignal return:regionCodes]; } else if ([self dialerEnabledWithRegionCodes:regionCodes]) { [self trackDialerInstalledEventWithRegionCodes:regionCodes]; } return [RACSignal empty]; }] flattenMap:^RACStream *(NSSet *regionCodes) { @strongify(self); return [self updateExtensionWithRegionCodes:regionCodes]; }] doNext:^(NSSet *regionCodes) { @strongify(self); ULogInfo(@"Dialer extension installed with region codes: %@", regionCodes); [self trackDialerInstalledEventWithRegionCodes:regionCodes]; }] doError:^(NSError *error) { @strongify(self); ULogError(@"Dialer extension error: %@", error); [self.analyticsSender trackEventWithCategory:kDGSCategoryDialer action:kDGSActionDialerFailed label:error.localizedDescription value:nil]; }] doCompleted:^{ ULogInfo(@"Dialer extension reload completed signal"); }]; } + (RACSignal *)fetchExtensionEnabled { NSString *bundleID = [DGSCallKitExtensionModel extensionBundleID]; return [RACSignal createSignal:^RACDisposable *(id<RACSubscriber> subscriber) { [[CXCallDirectoryManager sharedInstance] getEnabledStatusForExtensionWithIdentifier:bundleID completionHandler:^(CXCallDirectoryEnabledStatus enabledStatus, NSError * _Nullable error) { if (enabledStatus == CXCallDirectoryEnabledStatusEnabled) { [subscriber sendNext:@YES]; } else { [subscriber sendNext:@NO]; } [subscriber sendCompleted]; }]; return nil; }]; } - (RACSignal *)updateExtensionWithRegionCodes:(NSSet<NSString *> *)regionCodes { ULogInfo(@"Reload dialer extension with tag: %@", regionCodes); NSString *bundleID = [DGSCallKitExtensionModel extensionBundleID]; return [RACSignal createSignal:^RACDisposable *(id<RACSubscriber> subscriber) { [[CXCallDirectoryManager sharedInstance] reloadExtensionWithIdentifier:bundleID completionHandler:^(NSError * _Nullable error) { if (error) { [subscriber sendError:error]; } else { [subscriber sendNext:regionCodes]; [subscriber sendCompleted]; } }]; return nil; }]; }

この機能の実装に関する主な問題は、データの準備とアプリケーションへの配信でした。約100,000台の電話の内線で縫う場合、この機能は1時間で完了します（電話があれば）。

既製の形式のデータがなく、cな方法でデータを配信および更新する必要がある場合、この機能の統合には多くの時間がかかり、その組み込みの複雑さのために、ユーザーは残念ながら「ありがとう」とは言いません。ほとんどのレビューでは、「それは私には機能しません」、「アプリケーションをダウンロードしましたが、何も判断しません」などのようなものがあります。

結論の代わりに

現時点では、この機能は完成しています。近い将来、機能を完成させる計画はありません。それでも、最も定義された数字（約100,000の数字）に従って選択を行い、拡張機能ですぐに縫い付けて、ユーザーが地域をダウンロードせずに最小限の機能をすぐに利用できるようにします。また、Androidのダイヤラーユーザーから苦情が寄せられている収集機関、さまざまな世論調査、さまざまな金融ピラミッド、その他の望ましくない数字など、「有毒」な数字に関するデータもかなりあります。私たちも、それらを個別のパッケージですべての人に届けることができます。

一般的に、母自身でさえ有効にできるように、より安定した使いやすいものが必要でした。いずれにせよ、少なくとも20,000人のユーザーがこの拡張機能を有効にしましたが、これは本当の利点であり、すべてが無駄ではなかったと感じています。

CallKitのすべての「喜び」、またはiOS 10での発信者IDの処理方法

試作機

データベース

データ配信

すべて先に

結論の代わりに

More articles: