Задача слишком простая и от этого вариантов много :) К примеру можно использовать MVVM из UI фреймов, таких как MAUI к примеру. Суть его в том, что есть View - то что видит пользователь, Model - то, что управляет VIew т.е. непосредственно контентом, и ViewModel - данные, с которыми работает Model:
Вот реализация MVVM в крайне грубом варианте :) (Правда называть это MVVM - неправильно, т.к. это View-Model или View-ViewModel) View здесь это - Console.
И как писал funca выше - это хорошая (хоть и нечестная) задача заставляющая изучить тему, и вы как учитель сильно подстегнули аудиторию :)
Решение - смерть для читаемости кода. Если мы не работаем с высоконагруженными система, то основная наша задача - читаемость кода, чтобы если после тебя кому-то придется это исправлять ему не приходилось решать "третью" часть задачи.
Как по мне - хорошим решением будет следующее: Раз появилась задача на изменение поведения, то можно предположить, что в будущем придет другое изменение, поэтому, чтобы поддерживать разные варианты и сохранить читаемость - можно использовать паттерны. Ввести тип, который генерирует задачу и проверяет ответ и передавать его во вью, в нашем случае - тип, работающий с консолью.
Это позволит не только добавить деление и умножение, а так же и другие вычисления, без необходимости по 10 раз переписывать то, что уже работает :)
Добавлю ваши замечания, но с небольшими корректировками:
Корутины не являются асинхронными, они выполняются в основном потоке приложения, в том же, что и отрисовка кадров, инстансирование объектов и т.д., если заблокировать поток в корутине, то остановится все приложение, корутины с асинхронностью использовали бы "IAsyncEnumerator", который Unity не поддерживает. Но вы правы, что корутина позволяет растянуть выполнение на несколько кадров, что бы не нагружать 1 кадр большими вычислениями. Unity предоставляет тип UnityWebRequest для Http запросов, которые можно выполнять "асинхронно" в несколько кадров, что может показаться "асинхронностью", на самом деле же это обертка над нативным асинхронным HttpClient, которая предоставляет некоторую информацию синхронно, по типу поля isDone, которое отображает - закончился ли запрос или еще ожидается ответ, но сам запрос идет асинхронно.
Поэтому Unity корутины, в рамках программирования, не реализуют асинхронность.
async\await существует с C# 5, которая, согласно гуглу, вышла в 2012 году, вряд ли за 10 лет команда Unity не обновила бы свой движек, учитывая, что появление async\await было самым главным событием для языка, поэтому смысл корутин в другом, а именно - разделить выполнение на несколько кадров в основном потоке, что написано в документации.
Применение для асинхронных корутин мне сложно придумать, если есть Async\Await.
Здравствуйте, это хорошее замечание, для поддержки разных соотношений можно использовать подобный скрипт, дублировать интерфейс нецелесообразно, т.к. это удваивает работу, если только, конечно, речь не идет о кардинально другом лэйауте, в этом случае сама задача подразумевает "дублирование" работы. Но если такой задачи не стоит, то правильная верстка и этот скрипт будет достаточным решением, пример можно увидеть в приложении, которое стало основой статьи, оно поддерживает как планшеты, так и мобильные устройства, без дополнительных скриптов, кроме представленного, с небольшой доработкой на смену анимации. Ссылка на приложение есть в начале статьи и в конце этого ответа.
Насчет анимаций: в большинстве случае анимации перемещения интерфейса длятся <1 сек, а при смене ориентации проигрывается анимация поворота длиной 0.5 сек, за это время можно сменить набор анимаций и перевести элемент в конечную точку запущенной анимации, пример можно увидеть в приложении.
Насчет перемещения: если задача подразумевает перемещение без анимаций, то необходимо доработать скрипт, согласно вашему случаю, универсальное решение тут сложно придумать.
Здравствуйте, если я правильно вас понял, что вы посмотрели код типа SavedRect, то инкапсулировать поля будет лишним, т.к. их изменение не сломает логику, и позволяет дизайнеру править данные без необходимости менять ориентацию в редакторе, и к тому же делает данные открытыми и следовательно простыми для проверки. Если вас неустраивает большой контроллер с кучей значений, то Unity предоставляет возможность свернуть эти поля типа SavedRect.
Задача слишком простая и от этого вариантов много :)
К примеру можно использовать MVVM из UI фреймов, таких как MAUI к примеру. Суть его в том, что есть View - то что видит пользователь, Model - то, что управляет VIew т.е. непосредственно контентом, и ViewModel - данные, с которыми работает Model:
Вот реализация MVVM в крайне грубом варианте :) (Правда называть это MVVM - неправильно, т.к. это View-Model или View-ViewModel) View здесь это - Console.
И как писал funca выше - это хорошая (хоть и нечестная) задача заставляющая изучить тему, и вы как учитель сильно подстегнули аудиторию :)
Решение - смерть для читаемости кода. Если мы не работаем с высоконагруженными система, то основная наша задача - читаемость кода, чтобы если после тебя кому-то придется это исправлять ему не приходилось решать "третью" часть задачи.
Как по мне - хорошим решением будет следующее:
Раз появилась задача на изменение поведения, то можно предположить, что в будущем придет другое изменение, поэтому, чтобы поддерживать разные варианты и сохранить читаемость - можно использовать паттерны. Ввести тип, который генерирует задачу и проверяет ответ и передавать его во вью, в нашем случае - тип, работающий с консолью.
Это позволит не только добавить деление и умножение, а так же и другие вычисления, без необходимости по 10 раз переписывать то, что уже работает :)
Можно через CancellationToken. https://docs.microsoft.com/ru-ru/dotnet/api/system.threading.cancellationtoken?view=net-6.0
А так корутины и асинхронность хороша под разные задачи, нельзя сказать, что что-то лучше всегда.
I am glad that the article was useful, I'll correct the article.
Спасибо за дополнение, но статья не про Async в Unity.
Искренне рад, что вам понравилась статья!
Добавлю ваши замечания, но с небольшими корректировками:
Корутины не являются асинхронными, они выполняются в основном потоке приложения, в том же, что и отрисовка кадров, инстансирование объектов и т.д., если заблокировать поток в корутине, то остановится все приложение, корутины с асинхронностью использовали бы "IAsyncEnumerator", который Unity не поддерживает. Но вы правы, что корутина позволяет растянуть выполнение на несколько кадров, что бы не нагружать 1 кадр большими вычислениями. Unity предоставляет тип UnityWebRequest для Http запросов, которые можно выполнять "асинхронно" в несколько кадров, что может показаться "асинхронностью", на самом деле же это обертка над нативным асинхронным HttpClient, которая предоставляет некоторую информацию синхронно, по типу поля isDone, которое отображает - закончился ли запрос или еще ожидается ответ, но сам запрос идет асинхронно.
Поэтому Unity корутины, в рамках программирования, не реализуют асинхронность.
async\await существует с C# 5, которая, согласно гуглу, вышла в 2012 году, вряд ли за 10 лет команда Unity не обновила бы свой движек, учитывая, что появление async\await было самым главным событием для языка, поэтому смысл корутин в другом, а именно - разделить выполнение на несколько кадров в основном потоке, что написано в документации.
Применение для асинхронных корутин мне сложно придумать, если есть Async\Await.
Да, Вы правы, но видимой проблемы или преимущества это изменение не дает.
Здравствуйте, это хорошее замечание, для поддержки разных соотношений можно использовать подобный скрипт, дублировать интерфейс нецелесообразно, т.к. это удваивает работу, если только, конечно, речь не идет о кардинально другом лэйауте, в этом случае сама задача подразумевает "дублирование" работы. Но если такой задачи не стоит, то правильная верстка и этот скрипт будет достаточным решением, пример можно увидеть в приложении, которое стало основой статьи, оно поддерживает как планшеты, так и мобильные устройства, без дополнительных скриптов, кроме представленного, с небольшой доработкой на смену анимации. Ссылка на приложение есть в начале статьи и в конце этого ответа.
Насчет анимаций: в большинстве случае анимации перемещения интерфейса длятся <1 сек, а при смене ориентации проигрывается анимация поворота длиной 0.5 сек, за это время можно сменить набор анимаций и перевести элемент в конечную точку запущенной анимации, пример можно увидеть в приложении.
Насчет перемещения: если задача подразумевает перемещение без анимаций, то необходимо доработать скрипт, согласно вашему случаю, универсальное решение тут сложно придумать.
Ссылки на приложение:
https://apps.apple.com/de/app/россети-центр-книга-достижений/id1498965479
https://play.google.com/store/apps/details?id=com.NexusStudio.mrskglorybook&hl=af&gl=US
Здравствуйте, если я правильно вас понял, что вы посмотрели код типа SavedRect, то инкапсулировать поля будет лишним, т.к. их изменение не сломает логику, и позволяет дизайнеру править данные без необходимости менять ориентацию в редакторе, и к тому же делает данные открытыми и следовательно простыми для проверки. Если вас неустраивает большой контроллер с кучей значений, то Unity предоставляет возможность свернуть эти поля типа SavedRect.