Comments 12
только таймер у вас получился на 5 сек + лапоть!
А вот попробуйте сделать таймер пля бесконечной последовательности событий с периодом 5 сек.
Если использовать ваш таймер то скажем уже 10 событие будет назначено не на 5*10=50 сек от первого, а на 10 * 5 + 10 * (сумарное время ошибки определения периода таймера) = 50 + (десятикратный лапоть),
Помогут ваши конструкции решить задачу?
Дальше можно рассмотреть более сложную схему событий, например одна последовательность фреймов со спутника приходит раз в 450 милли-секунд, и есть фреймы которые приходят раз в 350 мс, надо симулировать сумарную последовательность.
Решается такая задача?
Код скриншотами IDE - это ужас. Поэтому код я не смотрел.
Вообще меня интересует, какую задачу решал автор и чем это отличается от тасков?
Согласен. Заменил на код. Задача - создать расширяемый каркас для асинхронного использование компонентов. Расширим наш код добавив 1 метод:
public static TAwaitable Instantiate<TAwaitable>(string path, params object[] parameters)
where TAwaitable:AwaitableBehaviour
{
_parameters = parameters;
var awaitable = Resources.Load<TAwaitable>(path);
return GameObject.Instantiate(awaitable);
}Допустим, мы показываем пользователю рекламу с несколькими кнопками, и хотим узнать на какую кнопку и спустя сколько времени он нажмет.
Благодаря такой записи мы получим аккуратный код:
var userPick = await AwaitableBehaviour.Instantiate<Advertising>(GO);Где Advertising - наш наследник-рут для рекламного попапа. Вся логика внутри попапа будет при этом инкапсулирована в компонент. В этой строчке мы добавляем попап в сцену, и дожидаемся окончания его работы в асинхронном виде. Мне кажется, это очень удобно.
Существующие библиотеки, мало того, что не поддаются нормальному расширению(попробуйте показать такую рекламу используя его ), так еще требуют изучения документации и знание тонкостей работы - а они есть, и представлены в товарном кол-ве. И это уже не говоря о том, что проекте появляется +1 огромная библиотека.
Вопрос о тасках не совсем корректный, так как мне ничего не мешает использовать самые обычные таски в этой записи. Awaitable тип не есть task-like тип.
А для чего именно вы используете такой компонентно-ориентированный подход? Имею в виду задачи в которых применяете. А то пример не очень показательный, так для задержки проще UniTask использовать
Например, наше приложение это набор UI окон с различными формами. Мы можем написать сами окна таким образом, унаследовав их от обобщенного типа и показывать пользователю дожидаясь результата(например, мы хотим получить то, что юзер ввел в инпут). Можно, например, показать аддитивно сцену, и дождаться пока она отработает. Можно дождаться пока персонаж вашей игры появиться, сделает все необходимое, и вернет результаты своей работы. Как правило, в Unity всегда есть компонент- агрегатор через который происходит взаимодействие с контейнером(gameObject-ом). Делая такой компонент ожидаемым, можно получить все что захочет наша фантазия)
Почему нельзя было код оформить нормально, а не скринить весь рабочий стол?
кто нибудь может мне пояснить где вызываются методы:
class ExampleWithResult. private void Update()
class Example. private void Update()они же приватные и кроме как изнутри класса их никто не может вызвать, как я понимаю. Но вызовов я не вижу! Зачем тогда они написаны???
Это я такой тупой (косой, слепой) или это, действительно, фигня какая то написана?
Это методы, которые движок Unity вызывает сам. Очень грубо говоря, при наличии такого метода в классе, отнаследованном от Monobehaviour, движок занесет его в свой список "исполнять каждый кадр", и каждый кадр будет вызывать этот метод. Unity предоставляет целый набор таких методов с разной функциональностью.
вон оно как, получается Unity это тестовый фреймворк, раз он имеет доступ к приватным членам?
Unity advanced или Awaitable компоненты-промисы