Комбинируйте на помощь

Нам все еще нужны пароли. Надежные пароли.

А надежные пароли означают сложные проверки.

Банковская информация, семейные фотографии, электронные письма и т. Д. Несанкционированный доступ - серьезная проблема, когда конфиденциальные данные скрыты за стеной. По этой причине вам как никогда необходимо создавать надежные и сложные пароли, и их также необходимо проверять.

В этой статье вы узнаете, как создать отличную систему проверки с использованием SwiftUI и Combine, а также об основных принципах, лежащих в основе ее построения.

Что такое система валидации?

Система проверки позволяет приложению оценивать поток ввода пользователя и решать, действительны ли эти данные, на основе некоторых правил.

Face ID, Touch ID и т. Д. Это впечатляющие технологии, улучшившие способ защиты наших данных. Но даже при их использовании иногда наша бизнес-логика требует, чтобы пользователь вводил пароль вручную. И этот пароль должен быть надежным. А сильный обычно означает сложный.

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

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

Имея это в виду, давайте определим основные принципы, лежащие в основе нашей системы проверки.

Единый источник правды

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

Примечание. Хотя проверка является обязательной на стороне сервера, двойная проверка на стороне клиента также удобна, поскольку она может быть быстрее и быстрее реагировать на встроенную проверку.

Динамичный и масштабируемый

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

Непрерывная проверка ввода

Проверка должна реагировать на каждый ввод, введенный пользователем. Реактивность важна для того, чтобы пользователь мог понять, что правильно или неправильно во вводимом контенте.

Полезные выходы

Проверка без четкого результата бесполезна. Система должна предоставлять результат для отображения пользователю и должна быть адаптирована к пользовательскому интерфейсу для предоставления полезной информации. Вот некоторые примеры:

  • Общий прогресс: представление о ходе выполнения, которое позволяет пользователю узнать оставшийся объем работы для выполнения задачи.
  • Состояние проверки: Проверка прошла успешно? Форма действительна? Выходные данные состояния позволяют обновлять интерфейс соответствующим образом и обеспечивать четкую обратную связь с пользователем.
  • Подробная информация: при работе со сложными данными или конкретными бизнес-требованиями может быть интересно отобразить подробную промежуточную информацию, которая поможет пользователю в процессе.
  • Сообщения об ошибках или рекомендации: в случае ошибки пользователь должен знать, что делать дальше и как исправить проблемы.

Проверка пароля

Когда мы четко определим наши ценности, пора создать нашу систему проверки паролей.

Как указывалось ранее, связанный с проверкой код должен быть инкапсулирован во внешний пакет. Этот пакет будет вызываться из ViewModel, который обрабатывает бизнес-логику представления и строго отделен от представления.

ViewModel

В этом примере вы создаете модель представления, которая включает входное значение пароля. password служит входом, поступающим из представления. Он объявлен как @Published в ObservableObject, поэтому каждое изменение в этой переменной будет запускать поток проверки:

Правила валидации

В этом примере для создания действительного пароля строка должна удовлетворять следующим требованиям:

  • Пароль не должен быть пустым.
  • Пароль должен быть длиннее трех символов.
  • В пароле должен быть хотя бы один символ.
  • Пароль должен содержать хотя бы одну заглавную букву.

В вашем коде проверка проводится тремя взаимосвязанными структурами:

  • Field: поле для проверки. Требования могут быть разными в зависимости от оцениваемого поля.
  • ValidationState: Итоговое состояние проверки. Когда проверка обработана, она возвращает результат, указывающий, как она прошла.
  • ValidationType: Тип требования проверки, определяющий явные случаи.

Проверочные проверки

После определения требований следующим шагом будет реализация решения для проверки выполнения требований. В этом случае метод с именем fulfills(string) использует другое правило проверки для оценки входной строки (в зависимости от типа).

Примечание. Как вы можете видеть в методе init, state устанавливается с использованием результата метода fulfills. Таким образом, реализация скрыта снаружи структуры.

Для оценок hasSymbols и hasUppercasedLetters необходимы два String расширения регулярного выражения (RegEx):

Входной поток

Большая часть SwiftUI полагается на Combine. Как говорится в документации Apple:

«Платформа Combine предоставляет декларативный API Swift для обработки значений с течением времени. Эти значения могут представлять многие виды асинхронных событий ».

Для получения дополнительной информации о Combine, пожалуйста, следуйте официальному руководству по документации.

Combine позволяет получать непрерывные потоки ввода (вводимые пользователем), отображать этот поток и генерировать результат. В этом случае процесс, задействованный в ViewModel, следующий:

1. @Published var password получит непрерывный поток с вводом, введенным пользователем в представлении.

2. Этот вводимый пароль будет связан с passwordPublisher издателем. Этот издатель будет передавать контент для обработки.

3. В этом случае строка пароля будет использоваться для создания необходимого количества проверок. Эти проверки содержат всю информацию, необходимую для оценки данной строки.

4. Для этого конкретного случая мы предоставляем два разных выхода:

  • Необработанное значение validations будет использоваться для отображения промежуточной обратной связи о ходе выполнения. В этом случае отображается список проверок с их обновленным состоянием.
  • Логическое значение isValid: массив validations объединяется для создания логического значения, которое указывает, является ли значение допустимым или нет.

5. Это значение будет установлено на isValid, что приведет к обновлению представления.

Выходные данные валидации

Теперь, когда строка проверена, пришло время вернуть некоторый полезный вывод в представление.

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

Как часть ValidationType, message(fieldName: String) возвращает правильное сообщение об ошибке:

Пользовательский интерфейс и конечный результат

Как только система проверки будет завершена, мы сможем использовать ее в нашем представлении SwiftUI. Его можно использовать, обратившись к свойству userViewModel.

В этом случае мы отображаем представление, которое содержит три основных элемента:

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

Заключение

Combine и SwiftUI - отличные инструменты для простого создания сложных операций, подобных этим оценкам.

Следуя некоторым основным принципам структурирования системы и заботясь о предоставляемых входных и выходных данных, оценка сложных паролей становится простой!

Куда пойти отсюда

Вы создали базовую (но мощную) систему проверки. Великие улучшения могут включать:

  • Асинхронные оценки (т.е. отправка входных данных на сервер для проверки).
  • Проверки, предполагающие два или более ввода (например, запрос пароля дважды).