Comments 21
Кстати для мака неплохой клиент для SQLite — MesaSQLite
Еще советую посмотреть на Sqlite Studio в качестве редактора, довольно вменяемый функционал, open source and free.
Все таки вопрос «Зачем?» для меня остался открытым.
1) Локализация делается через Excel-xml файлы — тут тебе и редактор и проверка правописания, плюс отдавать на перевод один файл который откроется даже в Open Office.
2) Настройки сохранять/загружать из xml или банального ini файла.
То есть достаточно xml парсера для чтения и совсем ничего для записи.
Как по мне это Overengineering.
1) Локализация делается через Excel-xml файлы — тут тебе и редактор и проверка правописания, плюс отдавать на перевод один файл который откроется даже в Open Office.
2) Настройки сохранять/загружать из xml или банального ini файла.
То есть достаточно xml парсера для чтения и совсем ничего для записи.
Как по мне это Overengineering.
Лучше через гугл-доки — тогда всегда актуальная версия документа у всех. Каждому переводчику можно назначить область, где он может править, тока свой язык, и всё. Плюс скрипт, который выдаёт xml нужного формата — у нас так сделано, очень удобно, рекомендую.
Была такая идея — но отказались из за того что переводчики иногда просили вставлять картинки в документ Excel (для передачи сохраняли как xls) а у гугла с этим были проблемы
Если вы переводите всё внутри компании, зачем? Почему нельзя просто сказать работникам, кто что должен переводить, а уж они сами разберутся? Зачем устанавливать тоталитаризм внутри фирмы? У вас там тысячи китайцев с улицы работают?
Для синхронизации можно и Git использовать.
Для синхронизации можно и Git использовать.
Для локализации — это явно overengineering. Тем более учитывая, сколько уже готовых либ для Unity лежит в Asset Store.
А так, sqlite может использоваться как база данных внутри игрушки(если там сложная логика и нужно хранить кучу данных). Проверено, работает шустро.
А так, sqlite может использоваться как база данных внутри игрушки(если там сложная логика и нужно хранить кучу данных). Проверено, работает шустро.
SQLite для локализации рабочее решение. Такое применение вы можете встретить среди iOS разработчиков (и для ресурсов тоже). Имея несколько xml файлов локализации, sqlite даёт всегда один. Даже если вы объедините всю локализацию в один xml файл, поиск в БД всегда будет быстрее. Многим людям удобнее работать с SQL ORM чем с XPath. Ну и вербозность xml уже достала.
Возможно вам сейчас кажется имплементация SQLite большим оверхедом, но как только вы внедрите его в проект, вы поймёте насколько всё стало удобно, практично и быстро. Я конечно же не навязываю своё мнение, но SQLite в вашем приложении опрелённый плюс, пусть даже не для локализации, но всё же попробуете его.
Возможно вам сейчас кажется имплементация SQLite большим оверхедом, но как только вы внедрите его в проект, вы поймёте насколько всё стало удобно, практично и быстро. Я конечно же не навязываю своё мнение, но SQLite в вашем приложении опрелённый плюс, пусть даже не для локализации, но всё же попробуете его.
Зачем такие сложности?
На старте приложение вычитывает нужный язык (один раз пропарсить xml) и держится в Dictionary<key,text>
Время доступа почти мгновенное.
На старте приложение вычитывает нужный язык (один раз пропарсить xml) и держится в Dictionary<key,text>
Время доступа почти мгновенное.
среди ios разработчиков есть встроенные штуки для локализации в виде разных файликов <ключ=значение>, которое конвертируется в хэшмап. на юнити такое же сделать — дело одного дня максимум, даже с эдитором для непрограммистов. если лень, то можно купить за 20 баксов. Это будет работать быстрее и проще, чем грузить еще одну либу.
Хорошая статья! Только есть вопрос: в streaming assets файлы неизменяемые, то есть будет доступ только для чтения?
Да, совершенно верно, только для чтения.
Тогда незачем такие ухищрения, надо просто сериализацию хорошую сделать.
А еще можно держать шаблон вашей бд не в стриммингассетс, а в ресурсах. тогда при копировании в persistentDataPath не надо делать изврата c вычислением названия файла в зависимости от андроида, айфона.
А еще можно держать шаблон вашей бд не в стриммингассетс, а в ресурсах. тогда при копировании в persistentDataPath не надо делать изврата c вычислением названия файла в зависимости от андроида, айфона.
1. Что вы имеете ввиду под сериализацией? Работу с сервером? Для нас важно было не забивать канал излишними инициализационными данными, любые изменения приходят дифом и пишутся в базу.
2. Просветите меня тогда, пожалуйста, как из ресурсов использовать базу sqlite только для чтения без копирования в пользовательскую директорию? Я вот не знаю как.
2. Просветите меня тогда, пожалуйста, как из ресурсов использовать базу sqlite только для чтения без копирования в пользовательскую директорию? Я вот не знаю как.
1. Базу данных надо прикручивать когда много данных, данные постоянные обновляются или в приложении сложная логика (использование xml, json, <что там еще> причиняет большое неудобство). В конкретном случае локализации можно обойтись простым Dictionary, создаваемым из файла. Такое решение проще написать, работать это будет быстрее.
2. Без копирования никак. Но вычисление по имени файла в зависимости от платформы, обрезание по имени файла — это непонятно, если потом надо будет поддерживать новые платформы, то надо будет искать это место, добавлять еще ifdef-ов.
Более независимым решением является копирование с ресурсов:
2. Без копирования никак. Но вычисление по имени файла в зависимости от платформы, обрезание по имени файла — это непонятно, если потом надо будет поддерживать новые платформы, то надо будет искать это место, добавлять еще ifdef-ов.
Более независимым решением является копирование с ресурсов:
string fileName = Application.persistentDataPath + "/database.bytes";
if (!System.IO.File.Exists (fileName)) {
var asset = (TextAsset)Resources.Load ("database");
File.WriteAllBytes (fileName, asset.bytes);
}
1. В локализации много данных. Про преимущества над xml я уже рассказал. Взгляните на sqlite как на альтернативу, а не как на единственное правильное решение.
2. Нет, это не лучше. Потому что если рассматривать кейс только для чтения, вы будите удваивать данные, которые уже лежат в ресурсах. SteaningAssets позволяет избавиться от этого. Использования директив препроцессора для разработки кроссплатформенных приложений — это тоже нормально. И пользовательские директории приложения на разных платформах отличны, в статье я об этом упоминал.
2. Нет, это не лучше. Потому что если рассматривать кейс только для чтения, вы будите удваивать данные, которые уже лежат в ресурсах. SteaningAssets позволяет избавиться от этого. Использования директив препроцессора для разработки кроссплатформенных приложений — это тоже нормально. И пользовательские директории приложения на разных платформах отличны, в статье я об этом упоминал.
1. Можете использовать json, он не раздут. Можете сделать, как сделано в локализации ios: ключ=значение. Еще проще и правильнее(если вы компания, а не инди разработчик) взять плагин за 50 баксов. Любое из этих решение будет удобнее, работать будет быстрее. Не надо придумывать альтернативу, которая заведомо хуже «стандартного» решения.
2. Если для чтения, то да. Но таких кейсов, когда бд используется только для чтения и обязательно нужно использовать бд очень мало, поэтому я ими и пренебрег.
>пользовательские директории приложения на разных платформах отличны
вот именно поэтому и хочется писать код, которому будет все равно на запускаемую платформу. Я положил файл в ресурсы и забыл. Я не парюсь, что на blackberry у меня не работает, я не буду искать это место в коде, когда надо будет портировать под win8.
2. Если для чтения, то да. Но таких кейсов, когда бд используется только для чтения и обязательно нужно использовать бд очень мало, поэтому я ими и пренебрег.
>пользовательские директории приложения на разных платформах отличны
вот именно поэтому и хочется писать код, которому будет все равно на запускаемую платформу. Я положил файл в ресурсы и забыл. Я не парюсь, что на blackberry у меня не работает, я не буду искать это место в коде, когда надо будет портировать под win8.
я тоже как-то не понял в чем радость базы данных в режиме «только чтение». В любом случае за несколько часов можно написать тул который будет экспортировать информацию в любом виде (в тот же xml) и не придется тащить еще один бинарный плагин. Идея прямо писать ресурсы в БД без проверок как-то вовсе пугает. Если мои переводчики через раз умудряются испортить текстовый файл, я даж не представляю что они сделают с БД через редактор. Да и не пошлешь подрядчикам бинарник sqlite…
Sign up to leave a comment.
Unity3d + SQLite