зачем нужна папка assets
Assets (Активы)
По умолчанию проект в студии не содержит данную папку. Чтобы её создать, выберите меню File | New | Folder | Assets Folder.
Чтение файлов
Для доступа к файлам используется класс AssetManager. Пример для чтения текстового файла.
Для доступа к графическому файлу из актива можно использовать следующий код:
Вы также можете загрузить изображение в Bitmap, используя BitmapFactory.decodeStream(), вместо Drawable.
Функция-расширение для Kotlin, которая вернёт Bitmap.
Используем собственные шрифты
Напишем практический пример создания приложения, в котором будут использоваться собственные шрифты, не входящие в стандартную библиотеку шрифтов Android. Для этого мы упакуем нужные шрифты вместе с приложением. Поместим в каталог assets/fonts файлы шрифтов (можно скачать бесплатные шрифты с сайтов 1001 Free Fonts или Urban Fonts ).
В файл разметки добавим пару текстовых полей с заготовленным текстом для вывода этого текста с нашим шрифтом.
В классе активности загрузим объект EditText из ресурсов, а затем создадим объект Typeface, используя вызов статического метода Typeface.createFromAsset(). Метод createFromAsset() принимает два параметра:
Например, загрузить шрифт для текстового поля EditText можно следующим способом:
Запустив проект, мы увидим в текстовых полях надписи Happy New Year! и Meow!, выводимые нашими собственными шрифтами.
Пример для фрагмента.
Загрузка локальных файлов из активов в WebView
Если нужно загрузить локальные страницы и изображения из активов в WebView, то можно использовать префикс file://android_asset. Подробнее смотрите в статье про WebView.
Получаем список файлов в папке assets
Можно получить список файлов, которые находятся в папке assets. Для быстрой проверки кода я вручную скопировал в папку два файла:
Кроме ваших файлов, также возвращаются странные папки /images, /sounds, /webkit. Учитывайте это в своих проектах. Так как в папке можно создавать собственные подпапки, то можно воспользоваться вспомогательным методом:
Ограничение на размер файлов
По сети гуляет информация, что существует ограничение в 1 Мб на размер файлов в папке assets. При превышении размера у вас может появиться ошибка:
Я не сталкивался, поэтому рецепт решения проблемы не предлагаю.
Webpack 5 — Asset Modules
Доброго времени суток. Этим постом хочу начать серию статей про новые возможности грядущего webpack 5. Почему я хочу рассказывать про webpack? Как минимум потому, что я принимаю активное участие в его разработке и постоянно копаюсь в его внутренностях. В данном посте хочу рассказать про Asset Modules — экспериментальную фичу webpack 5, которая позволяет избавиться от нескольких привычных лоадеров, сохранив при этом их пользу.
Представим, что нам нужно собрать страницу с картинками и стилями.
Решение на webpack 4
Конфигурация webpack 4 под эту задачу может выглядеть следующим образом:
webpack.config.js
src/index.js
src/styles.css
Вывод:
При таком подходе все svg-файлы будут обработаны при помощи svgo и при помощи file-loader помещены в директорию с собранным бандлом, а css, при помощи css-loader, превратится в нечто подобное:
В какой-то момент нам может понадобиться оптимизировать нашу страничку и мы можем захотеть инлайнить изображения прямо в css. Для этого заменим file-loader на url-loader:
Вывод:
Собранный css изменится следующим образом:
Далее мы можем захотеть инлайнить только небольшие по размеру svg (например, до 8кб), а все остальные оставлять в виде отдельно лежащих файлов. Для этого, у url-loader есть специальная настройка limit:
Задача решена, но с использованием webpack 5 и фичи Asset Modules, она решается проще, позволяя избавиться от url-loader и file-loader (его url-loader неявно использует для файлов, размером больше, чем указано в опции limit ).
Решение на webpack 5
Для начала, необходимо явно указать, что мы хотим использовать Asset Modules. Для этого добавим в конфигурацию следующее:
На данный момент это экспериментальная фича и мы ждем от пользователей обратную связь по ее использованию.
После этого, достаточно просто пометить svg-файлы как asset и всё то, что было описано выше касаемо file-loader и url-loader — заработает само, из коробки, без каких-либо лоадеров:
Вот и всё, для файлов, которые попадают под правило с type: ‘asset’ будет применяться следующая логика: Если файл меньше 8кб (по умолчанию), то встроить его в собранный бандл, в ином случае поместить его в директорию с собранным бандлом.
Свойство use так же учитывается.
Помимо asset есть и другие встроенные типы модулей.
asset/inline
В результате получим такой css:
Таким образом можно совмещать использование лоадеров и кастомное поведение для генерирования data-url.
asset/resource
Это аналог file-loader. Файлы, которые будут подпадать под правило с type: ‘asset/resource’ будут складываться в директорию с бандлом:
Указываем путь
По умолчанию, модули с типом asset/resource складываются в директорию, которую вы указываете в output.path (по умолчанию dist ), но при помощи output.assetModuleFilename можно переопределить это поведение:
Вывод:
А заменив [name] на [hash] мы получим прекрасный вариант для long term caching:
Вывод:
Вывод:
asset/source
Это аналог raw-loader. Файлы, которые будут подпадать под правило с type: ‘asset/source’ будут всегда инлайниться в бандл в неизменном виде:
file.txt
webpack.config.js
index.js
Вывод:
asset
Лимит для применения asset/inline можно установить:
Подводя итог: Asset Modules в webpack 5 позволяют отказаться от некоторых привычных лоадеров за счет поддержки их функциональности «из коробки».
Полноценный пример можно посмотреть здесь.
Когда выйдет webpack 5?
Я и дальше планирую рассказывать о новых возможностях webpack 5 и о самом webpack. Некоторые из статей будут побольше, некоторые поменьше, а совсем мелкие заметки (не только про webpack) можно будет наблюдать в моем телеграмм-канале.
Файлы js и css, а также прочие asset’ы – тонкости и нюансы работы с ними в Альто
Я не знаю, как коротко и однозначно перевести с английского слово «assets». Но те, кто работают со всякого рода фреймворками или занимаются версткой, как правило, сталкиваются с этим термином. Он обычно (в данном контексте) означает наборы файлов, которые используются на HTML-странице – это файлы стилей (css), скрипты (javascript), различные изображения и шрифты. Нередко термином assets называют только наборы css- и js-файлов.
Разумеется, эти «наборы» активно и в Альто используются. И в этой статье я расскажу о некоторых особенностях их обработки, которые присущи именно нашему движку. И это чрезвычайно будет полезно знать и тем, кто занимается версткой, и тем, кто будет писать плагины под движок, да и вообще всем, кто делает или собирается делать сайты на Alto
Если вы собираетесь создавать сайт и выбираете для этой цели CMS (или «движок», как еще говорят), то наверняка у вас возникает вопрос: «А чем же Alto лучше других CMS? И годится ли для моих задач?»
Общий подход при работе с css- и js-файлами
Основной подход – все css- и js-файлы собираются в папке /_run/assets/, там они (если это задано в настройках сайта), объединяются, и уже оттуда они подключаются в HTML-код.
При объединении файлов может использоваться сжатие (минификация) – удаление лишних пробелов, переводов строк, комментариев и т.д.
Например, задано подключение файлов:
Т.е. в общем случае принцип такой: css-, js- и прочие включаемые в HTML-код файлы не дергаются из сотни разных мест движка (шаблоны, плагины, библиотеки и т.д.), а должны быть аккуратно сложены в одну папочку /_run/assets/ и подключаться оттуда.
Важный нюанс: если у подключаемого файла указан не путь на диске, а веб-URL, то этот файл будет подключен в HTML-код без всякой обработки. Например, эти файлы будут подключены как есть:
Объединение и сжатие
В настройках сайта задать опции для объединения и сжатия файлов. Это можно сделать либо в админке (Настройки сайта / CSS и javascript), либо добавив в конфиг-файл /app/config/config.local.php
Надо отметить, что сжатие js иногда приводит к появлению ошибок при исполнении js-кода, поэтому пользоваться этой опцией надо осторожно.
При подключении файлов могут задаваться и дополнительные опции.
Параметр name, как сказано, используется во избежании двойного подключения. Если встречается несколько файлов пусть и с разными путями, но с одинаковым значением name, то подключен будет только первый из них. Но если у повторного файла с тем же параметром name указать еще и параметр ‘replace’ => true, то он заменит в наборе предыдущий файл с таким именем.
И у этого параметра (name) есть еще одно назначение — можно по нему получить URL к нужному файлу из javascipt’а на странице. Например:
Из хаоса в порядок, или «создаем структуру проекта в Unity и не только. »
При создании нового проекта он такой чистый, понятный, нет лишнего хлама… он пуст. Чем дольше идет разработка, тем больше в нем появляется лишнего мусора, непонятных папок, файлов, иногда туда могут попасть префабы для других проектов и вся организация летит в Тартар.
Выясняется что организации никогда не было, проекту три года, порядок наводить уже поздно, работать не удобно и вообще…
Добро пожаловать в хаос, вы оказались именно тут потому что:
Зачем нужна структура? — время. Мы экономим кучу времени на отладке, добавлению новых фич, файлов, чистке при условии что наша организация нам понятна и удобна, при условии что она есть. Правильные названия файлов, порядок, таги прочие маленькие хитрости позволяют экономить время.
В сети достаточно подобных материалов с примерами, но не очень много объяснений «почему это так». Опишу решения которые использую сам и чем они удобны конкретно мне. Не думаю что внесу что-то новое, но правильная организация — это начало начал любого проекта.
«Как это сделано»
Взять к примеру коллайдеры для окружения. Какие объекты и плоскости у нас есть?
Поэтому мы сделаем отдельный game object для коллайдеров пола, стен, потолка и препятствий.
Как пример уровень из игры
Если у нас больше 10 дочерних объектов то рекомендую писать таг, это упрощает поиск. Опять же коллайдеры, если мы говорим о 2D то используется edge,polygon,box,circle и каждый может быть коллайдером плоскости или препятствия. Можно именовать в виде «coll_edge_N» или «coll_e_N» т.к коллайдеры стен имеют материнский обьект Wall(который в свою очередь имеет материнский обьект Colliders) встает вопрос писать ли таг плоскости «coll_wall_edge_N», стоит для упрощенного поиска, когда количество объектов большое вы сэкономите очень много времени.
Мы получаем нечто подобное.
Организация папок в Unity
Внутри проекта тоже есть достаточно понятные правила.
Можно сделать нечто более организованное с понятной структурой.
А теперь давайте разберем что нужно, что нет.
Очень удобно делить проект на internal assets и external assets, это плюс.
В external assets у нас лежат все сторонние асеты и ничего больше.
Есть отдельная папка Scene в которой лежат все сцены.
Папка scripts тоже отдельно, это удобнее.
Самая интересная папка для нас internal assets
Все что касается видимой части нашей игры лежит именно там.
Какие папки там нужны?
Для анимации юнита нам нужно сделать animator controller и animation clip, анимационных клипов бывает несколько, поэтому их удобнее уложить в папку. Плюс нужна папка для самого юнита.
Выглядеть это будет так.
В папке с vfx нужна папка textures, materials и по желанию prefabs. VFX артисту удобнее работать в своих папках и не наводить бардак во всем проекте, а следить за порядком в своем огороде. Текстуры для эффектов, это всегда текстуры. Материалы для эффектов имеют разные настройки от additive до alpha blend и иногда одна текстура идет на несколько материалов, если папка текстур рядом то поиск проще. Если вы пишете шейдеры, то тянуть текстуры из папки VFX удобнее, точно так же удобнее и логичнее материалы готового шейдера положить в VFX.
Часто нужно что-то удалить, не факт что вы сможете сделать это и все пройдет гладко, часто нечто теряется и если вы не лид программист на проекте, то можете накосячить. Также бывает потребность протестировать фичу/идею и не факт что она приживется и вообще нужна. Именно для этого нужна папка trash, все тесты, все что нужно удалить или все что вы не хотите отправлять с текущим коммитом лучше положить сюда и прописать игнор для гита.
Организация иерархии в Unity
Чуть выше был пример про коллайдеры. Именно этому правилу подчиняется все. В нашем проекте мы применили такое решение.
Организация на примере Spine
Когда мы говорим о 2Д или 3Д анимации то важность организации и имен выходит на иной уровень. Можно прибегнуть к мокап анимации и не переживать за организацию, а просто сделать нужные движения в студии и сделать финал тут же на месте, к сожалению не всегда так получается. Есть множество вещей которые необходимо дорабатывать вручную даже при захвате движения, но мы не об этом. Как править все движения, определить нужную точку, кость, когда их более 20? Простой человечек с 5 костями не будет сложным в организации и понимании связей, а теперь добавьте ему 10 пальцев, сложнее, не так ли?
Правила те же, но в анимации есть зависимости и дочерние кости, которые упрощают организацию. Так же для визуального восприятия используется изменение цвета костей. Всегда есть ключевая кость к которой крепятся другие кости, к этим костям еще кости и так до самого конца. Часто мы именуем ее просто Root, от нее дальше идут бедра или торс, от торса левая или правая рука и так далее. С названиями нам проще понять что и откуда.
А вот пример выделения цветом, помогает в работе (на примере Dragon Bones)
Главные правила
Вывод
Я не найму вам клининговую кампанию, я дал вам в руки метлу, используйте.
Комментарии
«ExternalAssets» — это путь в никуда, если нужно не только подкладывать ассеты, но и обновлять их. Самое правильное и простое решение — это изолировать локальные ассеты проекта (в статье это «InternalAssets»), а внешние ассеты хранить так как их подготовили авторы — в идеале, отдельными папками на уровне папки «InternalAssets». В этом случае обновление становится легким и простым, не нужно сортировать по кастомным папкам то, что может приехать в обновлении и чего не было ранее. К тому же есть специальные папки, которые нельзя двигать и которые могут быть только в корне (Gizmos, Plugins/Android, Plugins/iOS и т.п.).
Зачем нужна папка assets
Разбор структуры компонента, зачем нужны assets, core и _build
При установке они могут совершать различные действия: создавать таблицы, менять системные настройки, копировать файлы и т.п.
Писать транспортный пакет с нуля очень долго, муторно и чревато ошибками. Гораздо лучше использовать проверенную заготовку modExtra — именно с её помощью написаны почти все мои дополнения.
Поэтому, сегодня нам нужно скачать modExtra из репозитория и разобрать структуру будущего компонента: зачем там так много файлов и директорий?
Конечно, мы разберемся и со сборщиком пакета — как он работает и конфигурируется.
Загружаем modExtra
Должно получиться вот так: 
test.php можно смело удалить.
Структура компонента
Директория core
Самая важная директория компонента — здесь хранится вся логика его работы.
Эта директория должна копироваться на рабочий сайт, поэтому выглядит так:
То есть, структура директорий такова, чтобы скопироваться в нужное место /core сайта.
Это — файлы ядра, и в MODX директорию core можно вынести вообще за пределы сайта, или даже использовать одну core для нескольких установок.
Если вам нужно что-то открывать из браузера — для этого есть assets.
Директория assets
Директория, доступная из браузера для запросов. Здесь хранятся файлы *.js, *.css и php-коннекторы для запросов их админки.
По умолчанию коннектор всего один, именно к нему будут обращаться страницы админки для выполнения каки-то задач.
Особо рассказывать здесь нечего, все и так понятно.
Директория _build
Наверное, самая интересная часть modExtra. В отличии от стандартных скриптов сборки MODX, в modExtra все очень гибко настраивается.
Конфигурация
Поэтому транспортный пакет, по сути, это другой специальный объект — modTransportVehicle и у него есть свойства, описывающие как установить все чанки, сниппеты и шаблоны пакета.
Устанавливаемые объекты
Собственно, это и есть наши чанки, сниппеты и т.д.
Файлы с объектами у меня состоят из массива и цикла, который разбирает этот массив и возвращает уже готовые объекты.
Логика тут простая: в массиве уникальные значения объекта, а в цикле добавляются значения по умолчанию + настройки статичности элементов из конфига.
Таким образом, вот стандартный массив с одним чанков для modExtra:
Схожим образом добавляются и другие объекты.
Если вы хоть немного знакомы с php — вопросов не будет, просто поглядите исходники.
У всех элементов MODX можно прописывать параметры — они будут видны на соответствующей вкладке при просмотре элемента. 
Правило хорошего тона: всегда прописывать параметры сниппетам, для остальных они не особо нужны.
Скрипт сборки ищет параметры для сниппетов в директории _build/properties/. Файлы там устроены по тому же принципу — массив с уникльными значениями, и цикл со значениями по умолчанию.
Вспомогательные скрипты (ресолверы)
Это такие специальные файлики, которые выполняются при различных действиях с пакетом: установке, обновлении и удалении.
Файлы-ресолверы лежат в _build/resolvers/ и выглядят примерно так:
Заключение
Возможно, что-то будет непонятно по работе сборщика, но мы еще с ним поразбираемся, когда будем упаковывать готовый код.
Главное помните, что есть универсальный набор скриптов, который соберет нам в транспортный пакет всё, что захотим.
На следующем уроке мы выгрузим modExtra на сервер, переименуем в Sendex, немного изменим, соберем в пакет и установим.