Главное Свежее Вакансии Образование
Выбор редакции:
75 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Клиент ↔ сервер. Давайте не ссориться

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

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

Среди неурядиц первого рода наиболее распространены проблемы, связанные с парсингом объектов, отсутствием необходимой информации в ответе сервера и обработкой push нотификаций.

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

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

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

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

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

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

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.