Unity iOS localization scripts

Unity iOS localization scripts

Исходники на Github

Мобильные Unity разработчики меня сейчас должны понять: когда делаешь билд под iOS, то локализацию «из коробки» настроить не получится. Конечно, есть разные ассеты и даже! официальный пакет для локализации. С которым уже можно работать, кстати. Но как обычно, самое интересное в деталях...

Если ваша игра поддерживает несколько языков, к примеру: русский, английский, немецкий, испанский, то для каждого языка неплохо бы сделать локализуемое название игры. Кроме того, если игра/приложение использует камеру или галерею, то нужно показывать диалог запроса прав доступа, тоже локализованный, иначе апрув скорее всего не пройти. Для этого, обычно используется файл InfoPlist.strings и содержимое его выглядит как-то так:
 

"CFBundleDisplayName" = "Локализованное название";
"NSCameraUsageDescription" = "Тут описание зачем приложению доступ к камере";
"NSPhotoLibraryUsageDescription" = "Тут описание зачем доступ к галерее";
"NSPhotoLibraryAddUsageDescription" = "Тут описание зачем доступ к галерее";
"NSUserTrackingUsageDescription" = "Тут описание зачем доступ к IDFA";
 

В общем-то всё это уже можно сделать официальным пакетом локализации, кроме NSUserTrackingUsageDescription по-моему. Но так как я всё равно использую пост-билд скрипт для добавления файлов, фреймворков и установки различных параметров через ProjectCapabilityManager, то использовать ещё один пакет не хотелось бы. Тем более, пакет для локализации сам использует приватные методы пространства имен UnityEditor.iOS.Xcode. Вот тут-то и нашлось решение. С помощью рефлексии вытянуть нужные методы и сделать расширение для PBXProject.

В итоге, получился всего один файл с расширением, который позволяет:

• очистить неиспользуемые локали
• добавить используемые языки в приложении, из списка
• добавить <код_языка>.lproj папки в проект с файлами InfoPlist.strings

В старых проектах я использовал UnityiOSLocalization, он работал, но его «проблема» в большом количестве файлов, которые когда-то были доступны на Bitbucket’е, потом это всё стало приватным — т. е. это то что сейчас получилось вытянуть через рефлексию.

Скорее всего когда допилят официальный пакет, всё это станет не актуальным, ну а пока можно пользоваться.

Unity plugins system on JSON

Unity plugins system on JSON

Наконец-то дописал статью про создание плагинов. В процессе «дописания» нашёл и пофиксил баг под iOS, так что — не зря :)

И тут сразу возникает вопрос: почему не использовать пакеты и UPM? Это удобно, да и весь механизм уже встроен в Unity?

Но как оказалось, не всегда удаётся выделить какую-то часть приложения в отдельный пакет, чтобы у него было минимум зависимостей и он представлял из себя какую-то самостоятельную единицу. Проекты бывают разные, с различной архитектурой и набором дополнительных ассетов и прочего. А выделить какую-то общую часть (ядро) хочется, чтобы использовать её в других проектах... В общем, если по какой-то причине пакеты вам не подходят — попробуйте Git Submodules.

В чём отличие при работе с сабмодулями гита?
Unity использует скрипты и ассеты которые расположены в папке Assets. Если вы попробуйте подключить сабмодуль и указать путь, например Assets/Core, то ничего не получится, потому что папка Assets уже существует. Поэтому надо провернуть такой финт:

1. Подключаете сабмодуль к проекту (как это сделать, тут описывать не буду, потому что есть разные клиенты SourceTree, Fork, GitKraken, просто консоль)
2. В качестве директории можно указать Modules/your_module
3. Переходите в папку Assets
4. Устанавливаете симлинк (symlink) на новый сабмодуль. Всё! Он у вас в проекте, можно пользоваться.

cd Assets
ln -s ../Modules/Core Core

Выглядеть это будет примерно так:

Unity Git submodules

Unity Git submodules

Теперь если в подключаемых сабмодулях, что-то меняется, надо просто спуллить обновления. В общем, кто привык работать с Git, то всё достаточно привычно и понятно.

MoDI. Lightweight IoC container for Unity.

MoDI. Lightweight IoC container for Unity.

MoDI — простой контейнер для внедрения зависимостей в Unity.

Когда я хочу в чём-то разобраться, я почти сразу перехожу к практической части. Если со старта не получается, тогда начинаю читать мануалы :) После этого, снова повторяю шаг №1 и так по кругу. Иногда это надоедает и я или ищу другие пути решения, или говорю себе, что это «не моё», мне это не надо — сдаюсь короче.

Решил я однажды разобраться как работать с Zenject и Ninject в Unity. Сделал несколько тестовых проектов — вроде работает. Начал копать дальше, понял принцип и решил, что хочу своё такое же, но попроще :) И чтобы было достаточно для всех моих разработческих потребностей. Так появился MoDI.

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

Это можно сказать и про ECS, да Leopotam? :)

MoDI можно подключить к проекту с помощью пакетного менеджера, через него же можно импортировать сцену с примерами. Ну или просто скачать архив и добавить в проект.

Простейший пример выглядит так:

using MoDI;
using UnityEngine;

public class QuickStart : MonoBehaviour {

    public void Start() {
        DI.Get().Bind<Hello>().WithArguments("Hi, I'm MoDI!");
        Hello hello = DI.Get().Resolve<Hello>();
    }
    
}

public class Hello {

    public Hello(string data) {
        Debug.Log(data);
    }

}

После запуска данного скрипта в консоли появится сообщение: «Hi, I’m MoDI!».

В документации можно найти ещё примеры и описание API.

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