Всем доброго времени суток! Меня зовут Николай, я iOS-Lead в компании Touch Instinct. В процессе разработки часто приходится иметь дело с проектами, которые должны работать на нескольких языках. Расскажу, к какому подходу мы пришли при работе с локализацией.

Минусы базовых подходов

Есть несколько основных подходов для локализации iOS-приложения. Сперва стоит определиться, разрабатывается приложение с использованием storyboards или нет.

С использованием storyboards

Можно локализовывать строки напрямую в storyboard. Однако, при таком подходе есть ряд минусов:

• в случае наличия большого количества storyboards, локализованные строки разбросаны по проекту;
• невозможность использования атрибутных строк, а также строк, которые состоят из нескольких составных частей;
• вам всё равно придется часть строк локализовывать в коде. Это ведет к еще большему разбросу в приложении;
• фактически отсутствует возможность что-то проверить другому разработчику при проведении code review.

Без storyboards

В этом случае локализуем всё в коде. Однако и тут есть ряд минусов. Дело в том, что файлы со строками локализации localizable.strings — магические. При изменении таких файлов очень велика вероятность возникновения ошибки из-за человеческого фактора. Изменения нельзя отследить, пока ошибка не будет найдена в процессе тестирования.

Таким образом, хотя для локализации уже есть готовые механизмы в iOS SDK, они имеют существенные минусы. Более подробно смотрите здесь.

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

На Mac, пользователи видит песочные часы или вращающийся радужный курсор, пока снова не возобновится взаимодействие с пользовательским интерфейсом. Многие пользователи ошибочно предполагают, что приложения сразу же заработает при прикосновению к экрану. Такие приложение дают ощущение низкой производительности и кажутся медленными, и, как правило, получает плохие отзывы в AppStore.

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

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

Одним из методов для одновременного выполнения операций в iOS являются использование классов NSOperation и NSOperationQueue. В этой статье вы узнаете, как их использовать! Вы будете работать с приложением, которое совсем не использует многопоточность, таким образом, оно будет очень медленным, и будет «тормозить». Когда вы измените приложение, чтобы можно было добавлять параллельные операций и — надеюсь – это обеспечит более отзывчивый интерфейс для пользователя!

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

Пожалуй, для многих новость о выходе новой системы Unity UI (далее просто UI) не показалась чем-то значимым. Как минимум — по причине её сырости, как максимум — из-за существования NGUI. Я поначалу не стал исключением, но открытие исходного кода UI системы (1) под либеральной лицензией MIT/X11, а так же энтузиазм разработчиков Unity Technologies заставили меня изменить мнение.

На мой взгляд, новый UI принесет нам довольно много плюсов:

• Вполне достойный инструмент из коробки;
• Возможность более глубоко понимать работу UI благодаря наличию исходников;
• Общепринятый механизм внесения изменений в исходный код UI — fork/pull request;
• Здоровая конкуренция между разными системами UI в конечном итоге принесет свои плоды в виде более качественных и удобных инструментов для Unity, а возможно и демпинг цен;
• Тесное взаимодействие команды разработки UI и ядра Unity уже сейчас приносят плоды в виде оптимизаций производительности, да и в будущем надеюсь они будут идти нога в ногу.

Всем привет.

Когда Вы начинаете использовать CoreData для сохранения данных в Ваших приложениях, Вы начинаете работать с единственным управляемым объективным контекстом / managed object context (MOC). Это — то, что используется в шаблоне при создание проекта в xCode, если Вы при создание проекта ставите галочку рядом с «Use Core Data».

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

По крайней мере, таков план.

Но как же именно вам, как разработчику игры, отрендерить такой эффект?