Введение

Свою статью я начну с признания: я немного завидую людям, чей родной язык — английский. В современном мире он стал языком интернационального общения, негласным стандартом. Практически любое популярное приложение поддерживает английский язык. Англоговорящие люди вряд ли когда-нибудь скачивали долгожданную игру из App Store и разочарованно понимали, что она не поддерживает их родной язык.

Игры и приложения приятнее и проще использовать на родном языке, а для некоторых людей он вообще единственно доступный. Именно поэтому компании, работающие на международном рынке, переводят свои приложения на распространённые языки.

Эта статья — для тех разработчиков, которые уже задумались о локализации своего приложения, сделали первые шаги в этом направлении и наступили на свои первые грабли. В сегодняшней статье я коротко опишу подходы к локализации приложений, остановлюсь подробнее на локализации на стороне клиента, расскажу о недостатках этого подхода и предложу способ их обойти. А в следующей части мои коллеги подробнее расскажут о деталях имплементации нашего подхода в мобильных ОС.

О локализации веб-приложений мы уже писали здесь.

Герои сериала «Шерлок»

Привет! Я Алексей Тимин, инженер из команды локализации Badoo. В этом посте я расскажу вам о том, как мы помогаем переводчикам в их нелёгком труде, и о новом Open Source-решении, позволяющем генерировать скриншоты дизайна, подготовленного в Sketch, для разных языков.

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

Отличного пятничного настроения, друзья!
Сегодня мы приготовили для вас полезный перевод поста основателя Ecler Studios Paweł Białecki, в котором он предлагает нашему вниманию 33 open source проекта для iOS разработчиков.
С помощью своего аккаунта в GitHub он открыл для себя множество перспективных инструментов и отобрал, по его мнению, лучшие из них для своих читателей.

— Здравствуйте. Скажите, сколько стоит сделать приложение типа Uber?

Менеджер по входящим заявкам нашей компании получает звонки с таким содержанием стабильно раз в неделю. Понимать его стоит, как правило, так: либо клиент хочет себе настолько же успешный аналог приложения для связи между пассажиром и водителем, либо Uber для ______ (вписать нужную отрасль).

В такие моменты мы отвечаем, что Uber — это технически очень сложный проект с миллионными инвестициями и сотнями тысяч человекочасов разработки, и что делать его клон не очень целесообразно.

Теперь у нас есть аргумент в защиту нашей позиции. Разработчики Uber опубликовали в блоге компании заметку про опыт переноса приложения с одной архитектуры на новую, собственную. Это очень масштабное мероприятие подтверждает, что Uber — далеко не элементарное приложение. Мы не могли пройти мимо этого материала и не перевести его.

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

В прошлой статье я рассказал о том, как создать простое реактивное приложение для iOS с помощью фреймворка RxSwift. В одном из комментариев прозвучала просьба рассказать про написание unit-тестов для реактивного кода. Я обещал написать об этом после пары других статей про RxSwift. Но меня опередили — то, о чём я собирался писать, прекрасно раскрыто в этой и этой статьях. Я лично хочу его поблагодарить автора за его титанический труд — эти две статьи прочно обосновались в моём избранном и помогают мне в работе.

Ну а мы приступим к написанию тестов!

Сетевое ядро как часть приложения

Для начала немного поясню, о чем пойдет речь в данной статье. Сейчас большинство мобильных приложений, на мой взгляд, являются клиент-серверными. Это означает, что они содержат в составе кода сетевое ядро, отвечающее за пересылку запросов и получение ответов от сервера. Причем речь вовсе не о сетевых библиотеках, которые берут на себя ответственность по «низкоуровневому» управлению запросами вроде пересылки REST-запросов, построения multipart-тела, работы с сокетами, веб-сокетами, и так далее. Речь идет о дополнительной обвязке, которая позволяет управлять запросами, ответами и данными состояния, характерными конкретно для вашего сервера. Именно в вариантах реализации этой обвязки и заключены основные проблемы сетевого уровня во многих мобильных проектах, с которыми мне приходилось работать.

Данная статья ставит целью привести один из вариантов архитектурного решения по построению сетевого ядра приложения, к которому я пришел после долгого времени работы с разными моделями и различными серверными API, и который на данный момент является наиболее оптимальным для задач, встречающихся мне в процессе работы над проектами. Надеюсь, этот вариант поможет вам разработать хорошо структурированное и легко расширяемое сетевое ядро, если вы начинаете новый проект или модифицируете существующий. Также буду рад услышать ваши советы и комментарии по улучшению кода и/или предложенной архитектуры. И да, статья из-за большого объема будет выпущена в двух частях.

Подробности под катом.

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

Статья о том как починить инкрементальную компиляцию в Xcode для Swift проектов и ускорить build phases для Cocoapods и Carthage, ничего не поломав.

Небольшой спойлер: на трех разных проектах получилось сократить время инкрементальной сборки в 9 раз!

Туториал несет сугубо практический характер с минимумом воды. Обязательно к прочтению для действующих iOS разработчиков.