FireMonkey - анимация, шаг 2

Design-time

В предыдущем посте мы посмотрели на создание объекта "анимация" для произвольного компонента. Традиционно использовалась техника создания/настройки компонентов в design-time. Однако все мы знаем, что это очень эффективно для предопределенного времени жизни объектов, что характерно для статических интерфейсов.

Не надо придавать слову "статичный" негативный оттенок. Статичность - это хорошо. Даже отбросив чисто инженерную эстетику, можно сказать, что "статичность" интерфейса есть большой плюс с точки зрения эргономики. Стабильность (статичность) интерфейса - сильно повышает скорость обучения пользователя в начале и скорость выполнения заданных манипуляций с графическими элементами.  И только значительная перегруженность современного интерфейса требует динамически изменяющихся (к примеру) инструментальных панелей.

Кстати, проверка на возраст. Как раньше переводилось слово "toolbar"? Нет, "инструментальной панелью" или "панелью инструментов" она стала далеко не сразу. Было такое понятие "пиктографическое меню".

Теперь это уже в далёком прошлом, а FireMonkey - даёт практически неограниченные возможности создания новых метафор интерфейсов для бизнес-приложений будущего. Но бизнес-бизнесом, а  хочется попрограммировать именно всласть, создать что-нибудь лёгкое. Собственно, создал это:

Design

Конечно, рука не поднимется создать 16 раз компонентов TImage в design-time. Динамически создаем изображения, грузим растр, режем на 15 частей (16-я - "дырка"). Остается приделать анимацию.

Если интерфейс статичен, то создание анимационных объектов в design-time оправдано. Если всё динамично, а, кроме того, анимационных эффект вызывается не всегда и не всегда многократно, то лучше подойдёт другая техника, аналогичная этой:

    Image.AnimateFloat('Position.X', 100, 0.2);

    Image->AnimateFloat("Position.X", 100, 0.2);

Т.е. нужно просто однократно сделать анимацию. Сделать её легко, если, конечно, предварительно ознакомиться с механизмами настройки и использования соответствующего компонента в design-time. Мы кратко и выразительно изменяем свойство Position.X объекта Image от текущего значения к заданному без ожидания в означенный интервал времени 0.2.

Time

Что быстрее? Что лучше? Что эффективнее? Техника (инженерия, программирование) - это не наука. Здесь нет абсолютных истин. Для салюта в run-time создавалась связка  "компонент+анимация", для классических интерфейсов - полный design-time, для нечастой, незацикленной, нежёсткой анимации лучше использовать рассмотренную здесь технику.

Мы применяем критерий "удобочитаемости" кода. Но это - взгляд программиста. А для IT-бизнеса - "с точки зрения снижения затрат на сопровождение программных средств и их модификации".

Майка

В самом конце предыдущего поста я совсем не пошутил насчет микро-конкурса и стильной майки. Пока данная майка осталась неподаренной. Сначала хотел отдать её сам себе (ткань нравится, да и не выглядит "корповой"), но было бы нечестно. В пятницу программа была готова только на 90%.

Вдохновение

Черпать можно отовсюду. Игрушка, заставка, эмуляция какого-либо анимационного эффекта - лишь бы почувствовать азарт. Азарт творца, который и поднимает нас каждый день с кровати. Или не даёт вовремя лечь спать.

Ссылки по теме

• Все продукты компании Embarcadero