Comments 17
Посмотрим что за обновлённый GUI будет в текущей ветки 4.* юнити, если я не ошибаюсь его разработкой занимается как раз автор NGUI.
Думается, что новый гуи будет хотя бы частично совместим с NGUI
Автор писал, что процесс миграции будет существовать и переделывать заново не придётся.
Только вчера просматривал ваш проект на гринлайте, кстати, поговаривают, что гринлайт прикроют, что думаете по этому поводу?
Не думаю что прикроют в ближайшие 3-4 месяца, да и надеюсь, что будут поблажки тем, кто на момент закрытия гринлайта уже собрал / уже собирает голоса.
Его не прикрывают, а просто меняют форму. Другими словами идет развитие.
Ну изменяет ему название, и что? Суть-то останется.
«Вообще я очень удивлен, почему так мало разработчиков пользуются возможностью записи различных данных в одну строку, а потом декодировать эту строку. Это же так просто и удобно!»

Быть может потому, что строки Immutable, и такие вот операции конкатенации очень дороги. Если их будет много (как например при конкатенации в каком-нибудь событии дрэга, ресайза и прочего), то GC убьет всю производительность, а память забьется фрагментами и будет дырявой как шапка почтальона печкина.
Добавлю, что раз уж так хочется производить подобные операции именно со строками, то лучше юзать класс StringBuilder.
Вот тут с вами не согласятся: habrahabr.ru/post/220921/
Если количество соединяемых строк заранее неизвестно (в цикле, например), то StringBuilder будет хорошим выбором.
Если известно заранее, но больше 4 — то нужно уже смотреть, что быстрее будет.
У StringBuilder есть конструктор, принимающий в качестве аргумента изначальный размер внутреннего буфера. Если выделить ровно столько памяти, сколько нужно — едва ли будет какая-то разница между этими вариантами.
Но тут-то и возникает одна из главных «проблем» (из-за которой я изначально и отказался от NGUI) — приходится выводить отдельные функции для обработки событий, таких как нажатие на кнопку и ей подобные.

Ну переход к подпискам начал происходить только с 3.х и еще в процессе. В линейке 2.х (да и сейчас можно, ничего не удалено) есть компонент UIButtonMessage, который форвардит клики в указанный GameObject (ГО) путем вызова метода, указанного строковым параметром. Т.е. в сцене делается центральный ГО с компонентом, в котором есть методы-колбеки для всего локального гуя, например:
class GuiCallbacks : MonoBehaviour {
void OnButton1Click()
{
}

void OnInventoryItemClick(GameObject itemGO)
{
}
}


Сам контрол генерится любыми способами и на него довешивается UIButtonMessage в коде или в инспекторе, в taget вешается ГО с указанным выше компонентом, в method пишется строка «OnButton1Click». Все, метод на главном ГО с UI-логикой будет вызван при клике по кнопке. Поддерживаются 2 варианта — без параметра и с параметром ГО, на котором висел компонент UIButtonMessage. Так же есть готовый компонент по форвардингу любых ссобщений нгуя. Вся работа ведется через стандартный SendMessage. Кто-то скажет, что это медленно и не модно, но все зависит от задачи. Если кнопка не должна кликаться 100 раз в секунду, то отсылка через сообщение будет вполне вариантом. Плюсом данного метода становится независимость от подписки и правильной отписки для корректной сборки объекта через GC. Можно делать прототипы с вызовами определенных методов, а сами методы реализовывать сразу или потом — все свяжется автоматом и без проблем.
Да, функция для подписке на события не имеет аргументов, но собственно какие аргументы должна передавать кнопка?
Ну и принцип динамических кнопок я использую такой. У нас всё равно есть список, допусти итемов в инвентаре из которых генерируешь кнопки. Так же кнопки складываешь в список/словарь, в итоге находишь нажатую кнопку — получаешь доступ к итему.
А подписка на события теперь (т.к. UIButtonMessage теперь legacy) делается из кода так:
EventDelegate.Set(NGUITools.AddMissingComponent<UIEventTrigger>(prevButton.gameObject).onClick, PrevButtonClick);
Only those users with full accounts are able to leave comments. Log in, please.