Ну вообще вы правы. Можно вообще все данные отображения свести до одного класса и реализовать классический RESTful. И насчет использования CBV это тоже холивар не для хабра) Просто в данной статье хотелось подчеркнуть особенности использования, показания лучшие стороны в ООП подобных отображений. То есть, что можно отнаследоваться от базового ListView и сделать свой класс с пагинацией, затем уже отнаследоваться от него и возвращать уже пагинованные списки объектов. Если делать все «по-человечески», то это можно реализовать в том числе «примесями (mixens)». ООП предлагает множество путей решения проблемы.
И да, везде использовать это не стоит, но иногда оправдано. Например, недавно решил переписать проект полностью на CBV, в итоге на логику отображений ушло намного меньше кода.
Я лишь за :) В моих планах описать работу с CBV со всех сторон, причем на личном опыте. Уже готов пример статье работы с FormView (и будет опубликован в ближайшие дни).
Хотелось бы рассказать про основные SOAP модули (post/get/put/delete), и про остальные методы CBV. Тема достаточно интересная.
Мне кажется просто не стоит дожидаться, пока «проснется» работодатель, а собраться с коллегами или самостоятельно и сдать кровь. Я сам уже около 3 лет регулярно сдаю кровь в ближайшем донорском пункте и всегда вижу не меньше 20 желающих, особенно среди молодежи. И насчет плюшек — они есть, пусть и небольшие. Например, донор получает 2 выходных дня, которые можно сложить с основным отпуском. А учитывая что за год разрешается сдавать цельную кровь до 5 раз, можно увеличить свой отпуск в среднем на неделю. Разумеется в данном случае уже потребуется понимающее начальство. Да и я сам, на собственном примере, убедился в полезности данного мероприятия, в том числе и для самого донора. Сопротивляемость организма существенно повышается.
Вообще проблем с донорской кровью особенных нет, со слов сотрудников донорского пункта, экстренно может потребоваться лишь кровь экзотической группы.
Неплохая идея, кстати. Думаю сегодня добавлю дополнительный пример. В таком случае и проблемы с фризами быть не должно, как при ручном перемещении солнца.
Я конечно могу ошибаться, но мне кажется, что у Вас при импорте задействуется дефолтный боксовый коллайдер. То есть после импорта модели Вам следует повесить на нее коллайдер с той же геометрией, что и сама модель. То есть навесить в качестве коллайдера эту же модель. Немного субурно, конечно, но думаю смысл ясен :)
Думаю тут зависит от условия, при котором необходимо создавать объект. Функции, подобные Update, выполняются слишком часто, и совершенно не подходят для такой задачи, потому что большую часть времени код будет выполняться впустую (даже если сделать проверку на какое-либо условие). Если нужно создать объект единожды, при инициализации, то возможно подойдут функции Awake или Start.
Насколько мне известно, то вынесение части логики из Update в LateUpdate не ускорит отрисовку кадра. Если смотреть описание в Script Reference, то там рекомендовано использовать эту функцию для перемещения камер, следящих за объектами, которые могли быть перемещены в пределах функции Update. Что в принципе логично, так как до выполнения функции Update мы не можем узнать новую позицию объекта.
Лично передо мной на данный момент не стояло подобных задач, поэтому я, честное слово, в замешательстве. :) Есть некоторые идеи по данному поводу, в ближайшие дни попробую поэкспериментировать, и если опыты приведут к положительному результату, то я добавлю об этом в статью. Но возможно кто-то, более опытный, возьмется написать про это. Я бы и сам с удовльствием почитал.
Тема оптимизации вообще заслуживает отдельной статьи. В данной замечательной статье рассматриваются некоторые вопросы оптимизации, в одноименной главе. В частности, цитирую:
2. Без необходимости лучше не использовать Find\GetComponent и похожие методы — по мере возможности лучше сохранить ссылку на компонент один раз при запуске скрипта.
Просто на JavaScript пишу несколько дольше, да и изначально писать под Unity3d начал на нем. Конечно переучиваться никогда не поздно, но на данный момент меня все устраивает.
Я руководствовался оффициальной документацией, в частности этим описанием. В принципе на практике я никогда не испытывал проблем с указанием больших значений, однако раз это указано в Script Reference, я решил упомянуть об этом и в статье.
Лично мое мнение — полезной информации никогда не бывает много. Поэтому писать статью Вам определенно стоит.
Возможно описано сухо, но я постарался аггрегировать наиболее употребляемые мной лично методы в работе, надеюсь кому-то пригодится как справочник. Изначально была идея сделать «живые» примеры использования для большинства описанных методов, но статья выходила слишком объемный. Решил оставить в таком виде, как вводной экскурс. Если получится, то в ближайшее время планировал сделать более подробные статьи по каждому разделу с примерами и описанием.
Спасибо. Статья в первую очередь позиционируется как справочник, а не самоучитель. Просто хотел, чтобы человек, впервые взявшийся за данный движок, знал о подобных возможностях. Если у Вас есть предложения, то я всегда готов к конструктивной критике.
И да, везде использовать это не стоит, но иногда оправдано. Например, недавно решил переписать проект полностью на CBV, в итоге на логику отображений ушло намного меньше кода.
Хотелось бы рассказать про основные SOAP модули (post/get/put/delete), и про остальные методы CBV. Тема достаточно интересная.
Вообще проблем с донорской кровью особенных нет, со слов сотрудников донорского пункта, экстренно может потребоваться лишь кровь экзотической группы.
Раздал плюсы всем, кому был смысл и на кого хватило заряда. Немного, конечно, но чем богаты. Еще раз всем удачи! :)
Возможно описано сухо, но я постарался аггрегировать наиболее употребляемые мной лично методы в работе, надеюсь кому-то пригодится как справочник. Изначально была идея сделать «живые» примеры использования для большинства описанных методов, но статья выходила слишком объемный. Решил оставить в таком виде, как вводной экскурс. Если получится, то в ближайшее время планировал сделать более подробные статьи по каждому разделу с примерами и описанием.