Согласен. Заменил на код. Задача - создать расширяемый каркас для асинхронного использование компонентов. Расширим наш код добавив 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 тип.
Например, наше приложение это набор UI окон с различными формами. Мы можем написать сами окна таким образом, унаследовав их от обобщенного типа и показывать пользователю дожидаясь результата(например, мы хотим получить то, что юзер ввел в инпут). Можно, например, показать аддитивно сцену, и дождаться пока она отработает. Можно дождаться пока персонаж вашей игры появиться, сделает все необходимое, и вернет результаты своей работы. Как правило, в Unity всегда есть компонент- агрегатор через который происходит взаимодействие с контейнером(gameObject-ом). Делая такой компонент ожидаемым, можно получить все что захочет наша фантазия)
Этот таймер написан в качестве примера использования. Он ведь даже не останавливается в 0 (там отрицательное значение будет на момент остановки). Честно говоря, я не понял описываемую вами задачу, но добавлять и убирать таймеры на компонентах когда речь идет о миллисекундах точно не стоит =)
Виновен, исправился
Согласен. Заменил на код. Задача - создать расширяемый каркас для асинхронного использование компонентов. Расширим наш код добавив 1 метод:
Допустим, мы показываем пользователю рекламу с несколькими кнопками, и хотим узнать на какую кнопку и спустя сколько времени он нажмет.
Благодаря такой записи мы получим аккуратный код:
Где Advertising - наш наследник-рут для рекламного попапа. Вся логика внутри попапа будет при этом инкапсулирована в компонент. В этой строчке мы добавляем попап в сцену, и дожидаемся окончания его работы в асинхронном виде. Мне кажется, это очень удобно.
Существующие библиотеки, мало того, что не поддаются нормальному расширению(попробуйте показать такую рекламу используя его ), так еще требуют изучения документации и знание тонкостей работы - а они есть, и представлены в товарном кол-ве. И это уже не говоря о том, что проекте появляется +1 огромная библиотека.
Вопрос о тасках не совсем корректный, так как мне ничего не мешает использовать самые обычные таски в этой записи. Awaitable тип не есть task-like тип.
Хабр 3000 знаков только дает, пришлось больше половины выкинуть, а код скринить (
Например, наше приложение это набор UI окон с различными формами. Мы можем написать сами окна таким образом, унаследовав их от обобщенного типа и показывать пользователю дожидаясь результата(например, мы хотим получить то, что юзер ввел в инпут). Можно, например, показать аддитивно сцену, и дождаться пока она отработает. Можно дождаться пока персонаж вашей игры появиться, сделает все необходимое, и вернет результаты своей работы. Как правило, в Unity всегда есть компонент- агрегатор через который происходит взаимодействие с контейнером(gameObject-ом). Делая такой компонент ожидаемым, можно получить все что захочет наша фантазия)
Этот таймер написан в качестве примера использования. Он ведь даже не останавливается в 0 (там отрицательное значение будет на момент остановки). Честно говоря, я не понял описываемую вами задачу, но добавлять и убирать таймеры на компонентах когда речь идет о миллисекундах точно не стоит =)