с помощью поставщиков Zendesk Swift API
Zendesk - отличный инструмент, позволяющий предоставить нашим пользователям систему продажи билетов, а также статьи из базы знаний, также известные как. FAQs. Судя по моему опыту реализации его в iOS, Zendesk предоставляет компоненты пользовательского интерфейса, которые позволяют нам быстро включать справочный центр в наши проекты. Однако, когда мы хотим, чтобы пользовательский интерфейс выглядел по-другому, это становится немного сложнее, поскольку изменение стилей или просто другое настраиваемое поведение не просто и не масштабируемо. В этой статье я покажу, как использовать Zendesk поставщиков услуг для создания верхнего уровня, а также разделю проблемы системы поддержки.
Конечно, преимущества создания нового уровня очевидны: можно настроить пользовательский интерфейс и получить большую гибкость в поведении нашей системы поддержки пользователей. С другой стороны, это требует времени и усилий для реализации. Но это то, для чего я здесь, я показываю вам Zendesk Service Provider API, которые, возможно, вам понадобятся вместе с этой реализацией функции.
Небольшой отказ от ответственности, прежде чем мы перейдем к учебнику. Я никак не связан с Zendesk. Вся информация и код, которые я получил, взяты с их общедоступного сайта разработчиков. В этой статье приводится пример из реального проекта, который может помочь другим разработчикам быстро достичь той же цели.
Давайте сначала упакуем протоколы
Идея, лежащая в основе использования протоколов на ранней стадии процесса, состоит в том, чтобы иметь больше возможностей для тестирования и легко менять поставщиков. Представьте, что завтра мы решим больше не использовать Zendesk, изменения, необходимые для внедрения нового поставщика, окажут минимальное влияние на проект.
Провайдер поддержки
Этот протокол предоставляет способ инициализации библиотеки, который может показаться бесполезным, но становится удобным для целей тестирования.
Служба поддержки Поставщик справочного центра
Этот протокол предоставит логику часто задаваемых вопросов, чтобы перечислить все статьи, выполнить поиск и проголосовать против или проголосовать за статью. Естественно, можно добавить еще много функций, но это основной подход.
Поставщик запросов на поддержку
Этот протокол управляет всей логикой, связанной с пользовательскими запросами, такой как создание запросов, получение запросов, список комментариев к запросу и чтение комментария к запросу. Термин UserRequest также известен как UserTicket, но для этой статьи и для того, чтобы он был близок к тому, что предлагает Zendesk, я тоже назвал его Request.
Конкретные реализации
Хорошо! Имея наши протоколы, пора добавить наши конкретные реализации Zendesk, в которых мы будем использовать то, что предлагает библиотека. Поскольку мы использовали протоколы, чтобы определять, как будет вести себя эта функция, вся логика, связанная с Zendesk или любой другой системой продажи билетов, останется изолированной, а также ее будет легко отслеживать, тестировать, отлаживать и заменять при необходимости.
Инициализировать Zendesk
Вот как мы настраиваем библиотеку Zendesk, как вы можете видеть в следующем фрагменте, этот код будет использоваться из AppDelegate или любого объекта внедрения зависимостей, который вы используете.
Обратите внимание, я рассматриваю объект supportProvider как тип SupportProvider, хотя я создаю его как объект ZendeskSupportProvider, это касается протокола, а не конкретной реализации.
Поставщик справочного центра Zendesk Support
Поставщик запросов на поддержку Zendesk
Собираем все вместе
В этом репозитории GitHub вы можете найти весь проект, включая модели, которые мы не рассматривали в этой статье. Если вы хотите глубже погрузиться в документацию, посетите официальный сайт разработчика Zendesk.
Спасибо за внимание. Надеюсь, вам понравился этот небольшой урок, и если он был вам полезен, не стесняйтесь 👏 в этой статье. Увидимся в следующий раз.
