Разработчики библиотеки MSLibrary for iOS продолжают серию очень компактных статей, посвященных тому как ПРОСТО реализовать ту или иную функцию. Никакой теории, только практика…

Итак, как правильно объявить глобальные переменные? Под глобальными мы понимаем переменные, объявленные на внешнем уровне (не static) и имеющие глобальное время жизни.

Если мы объявим переменную в одном из заголовочных файлов, например в файле MyClass.h таким, казалось бы логичным, образом:

NSString *myGlobalVariable;

а затем импортируем файл MyClass.h с помощью директивы #import в несколько файлов, например, MyClass1.h, MyClass2.h, MyClass3.h и MyClass4.h, то в результате с большой вероятностью получим примерно такое сообщение об ошибке:

duplicate symbol _myGlobalVariable in:
    /Users/L/Library/Developer/Xcode/DerivedData/…/MyClass.o
    /Users/L/Library/Developer/Xcode/DerivedData/…/MyClass1.o
duplicate symbol _myGlobalVariable in:
    /Users/L/Library/Developer/Xcode/DerivedData/…/MyClass.o
    /Users/L/Library/Developer/Xcode/DerivedData/…/MyClass2.o
duplicate symbol _myGlobalVariable in:
    /Users/L/Library/Developer/Xcode/DerivedData/…/MyClass.o
    /Users/L/Library/Developer/Xcode/DerivedData/…/MyClass3.o
duplicate symbol _myGlobalVariable in:
    /Users/L/Library/Developer/Xcode/DerivedData/…/MyClass.o
    /Users/L/Library/Developer/Xcode/DerivedData/…/MyClass4.o

ld: 4 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Произойдет это по тому, что в результате импорта переменная myGlobalVariable будет объявлена в каждом из подключенных файлов.

Очередная статья от команды разработчиков библиотеки MSLibrary for iOS посвящена довольно популярной теме создания и компиляции кроссплатформенных библиотек.

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

Мы постарались как можно подробнее и систематичнее осветить вопрос, рассмотрев создание библиотеки «с нуля» и упаковку в библиотеку части функционала уже готового проекта. Под кроссплатформенностью или универсальностью мы подразумевали совместимость библиотеки как с симуляторами, работающими на процессоре с архитектурой i386 или x86_64, так и с реальными девайсами, процессор которых, вероятнее всего, имеет архитектуру armv7 или armv64.

1. Создаем проект библиотеки

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

В дополнение к большим и подробным материалам, разработчики библиотеки MSLibrary for iOS решили начать серию очень компактных статей, посвященных тому как ПРОСТО реализовать ту или иную функцию. Никакой теории, только практика…

Итак, удаляем из строки ненужные символы, используя регулярные выражения, с помощью простой функции:

NSString *yourFuncionName(NSString *string) {
    NSString *regExString = @"yourRegularExpression";
    NSRegularExpression *_regEx = [NSRegularExpression regularExpressionWithPattern:regExString options:NSRegularExpressionCaseInsensitive error:nil];
    return [_regEx stringByReplacingMatchesInString:string options:0 range:NSMakeRange(0, [string length]) withTemplate:@""];
}

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

Несколько полезных регулярных выражений:

    \\s - удаляет все пробелы
    [-:_\\.] - удаляет все символы, находящиеся в квадратных скобках
    [:^digit:] - оставляет только цифры
    [:^alpha:] - оставляет только буквы
    [:^alnum:] - оставляет только буквы и цифры
    [:^word:] - оставляет только буквы, цифры и подчеркивания

Мы продолжаем публикацию материалов, от разработчиков библиотеки MSLibrary for iOS. Тема этой статьи не случайна, проблема выбора нескольких условий из заданного множества, не редко встречается в нашей работе. Простейший пример — выбор партнера для игры (свидания, путешествия и тд). Выбор надо осуществлять из нескольких групп, сформированных по уровню подготовленности (здесь могут быть и возрастные группы и все что угодно). Условие — дать пользователю возможность выбрать партнера из одной или нескольких групп одновременно. Другим примером могут служить константы NSRegularExpressionOptions проверки типа данных для класса NSRegularExpression. При подстановке этих констант в методы класса, мы можем записать:

	NSRegularExpressionCaseInsensitive | NSRegularExpressionDotMatchesLineSeparators 

Объединив константы знаком логического «ИЛИ» мы будем уверены, что проверим анализируемую строку на соответствие обоим из заданных условий.

Один из способов реализации подобной задачи — использование списка констант в виде перечисления enum, в котором элементы перечисления представляют собой двоичные числа с одним установленным битом. Сделать это не очень сложно, но сначала немного теории. Вспомним такие битовые операции, как «СДВИГ», «И», «ИЛИ».

В первой части статьи разработчики библиотеки MSLibrary for iOS рассказали об особенностях структуры телефонных номеров с точки зрения международных стандартов, опубликованных в документе RFC 3966 , рассмотрели Международную структуру телефонных номеров, корпоративные WEB стандарты набора телефонного номера, их взаимодействие между собой и то, как ведут себя пользователи.
Как уже было сказано, захват и верификация это — разные задачи, но решаются они схожими методами, различающимися в основном применяемыми в них регулярными выражениями. Во второй части статьи речь пойдет собственно о регулярных выражениях.

Верификация телефонных номеров

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

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

Рассмотрим оба варианта, но сначала общие соображения.

Валидация строки телефонного номера, чтобы он был адекватно обработан iOS, сводится к нескольким условиям:
1. общая структура номера должна соответствовать документу RFC 3966

telephone-uri = global-number-digits [extension]

_{рис. 1}

Поводом для появления серии статей, первая из которых представлена вашему вниманию, послужил большой аналитический и практический материал, накопившийся в процессе работы над библиотекой MSLibrary for iOS. Библиотека MSLibrary включает множество классов, и еще больше функций и макросов, призванных упростить рутинный труд разработчиков, существенно сократить сроки разработки и размер кода. Но, всему свое время, о библиотеке мы расскажем чуть позже.

Итак, захват и верификация телефонных номеров с помощью регулярных выражений. Казалось бы, о чем здесь говорить? Кто умеет, напишет сам, а кто не умеет скопирует одно из множества готовых решений, разбросанных на просторах Всемирной паутины. Вопрос только в том, что он напишет и что скопирует и насколько этот код будет соответствовать поставленным задачам, а также действующим международным, отраслевым и корпоративным стандартам? Любое решение, даже самое простое, хорошо лишь в том случае, если разработчик полностью осознает его работу и абсолютно в нем уверен.