Pull to refresh

Comments 17

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

Быть может потому, что строки 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);
Sign up to leave a comment.

Articles