Отрісовиваємих об’єкти в Android додатку

&nbsp

Отрісовиваємих обєкт (Drawablе) – це обєкт, що знає, як відобразити себе на полотні Canvas Оскільки під час відображення Drawablе піддається повному контролю, навіть самий складний процес відображення можна «Упакувати» так, що користуватися ним не складе ніяких труднощів

У прикладах 97 і 98 показані зміни, які необхідно зробити, щоб реалізувати приклад, показаний на рис 93, за допомогою Drawable Код, який малює червоний і зелений текст, шляхом рефакторинга був перетворений в клас Неї 1 oAndroidTextDrawablе, використовуваний методом onDraw при відображенні (цей метод відноситься до віджету)

Приклад 97 Використання TextDrawable

Для використання нової реалізації Drawable буде потрібно внести в метод onDraw з нашого прикладу всього кілька невеликих змін

Приклад 98 Використання віджета Drawable

Якоюсь мірою цей код вже дозволяє оцінити величезний потенціал Drawable Така реалізація TransformedViewWidget може перетворити будь Drawable незалежно від того, що саме передбачається малювати Код вже не має жорсткої привязки до обертання і масштабування нашого вихідного жорстко закодованого тексту Його можна використовувати багато разів для перетворення як тексту, взятого з попереднього прикладу, так і фотографії, знятої на фотоапарат (рис 94) Малюнок навіть можна перетворити в Drawablе-анімацію

Рис 94 Перетворені види з фотографіями

Drawable дозволяють втілити на практиці такі складні графічні техніки, як «девять прямокутників» або анімація До того ж оскільки Drawable повністю включають в себе процес рендеринга, отрісовиваємих обєкти можна вкладати один в одного, щоб розбивати складні графічні сутності на невеликі компоненти, придатні для багаторазового використання

Спробуємо уявити, як можна доповнити попередній приклад, щоб за хвилину кожне з шести зображень на якийсь час «вицвітало» і на його місці залишався просто білий квадрат Зрозуміло, потрібно просто змінити код з прикладу 98, додавши до нього ефект вицвітання Інший – набагато цікавіший – варіант реалізації повязаний з написанням одного нового Drawable

Конструктор цього нового отрісовиваємих обєкта (назвемо такий обєкт FaderDrawable) прийматиме як аргумент посилання на цільовий обєкт, той Drawable, який буде «вицвітати» до білого квадрата Крім того, цей обєкт повинен мати якесь уявлення про час, наприклад ціле число – назвемо його t, – прирощення якого відбувається у міру роботи таймера При кожному виклику методу draw, що відноситься до обєкта FaderDrawable, він спочатку викликає метод draw своєї мети Але потім він поступово замальовує ту ж цільову область білим кольором, використовуючи значення t для визначення прозорості малюнка, як це показано в прикладі 92 З часом t збільшується, білий колір стає все більш насиченим і цільовий обєкт Drawable повністю зникає з виду

Такий гіпотетичний обєкт FaderDrawable демонструє кілька важливих властивостей отрісовиваємих обєктів FaderDrawable за визначенням придатний для багаторазового використання Застосовуючи його, можна «розчинити» практично будь отрісовиваємих обєкт Крім того, оскільки FaderDrawable доповнює Drawable, FaderDrawable можна використовувати у всіх тих місцях, де ми б застосовували і його цільовий обєкт, тобто Drawable, «Вицвітають» до білого квадрата Будь-який код, який використовує Drawable в процесі відображення, може застосовувати і FaderDrawable без змін

Зрозуміло, і сам FaderDrawable може бути укладений в інший обєкт Насправді можна досягти ^ досить складних ефектів, просто побудувавши ланцюг оболонок Drawable У інструментарії Android надаються оболонки Drawable, що підтримують такий спосіб роботи, в тому числі CI ipDrawable, RotateDrawable і ScaleDrawable

Може бути, на даному етапі ви вже подумки переробили весь наш користувальницький інтерфейс у вигляді сукупності отрісовиваємих обєктів Але, хоча це і потужний інструмент, він не є панацеєю Є кілька проблем, про які не слід забувати, якщо ви збираєтеся користуватися Drawable

Ви, напевно, помітили, що отрісовиваємих обєкти мають чимало спільних функцій з класом View: розташування, розміри, видимість і т д Не завжди буває просто прийняти рішення про те, коли View повинен малювати прямо на Canvas, коли – делегувати це завдання своєму підвиду, а коли – одному або декільком отрісовиваємих обєктам Є навіть клас DrawableContai пег, що дозволяє групувати кілька дочірніх Drawable всередині батьківського елементу Можна будувати дерева Drawable, аналогічні деревам View, які ми використовували досі Працюючи з фреймворком користувача інтерфейсу Android, ми просто визнаємо, що є кілька способів зробити одне і те ж

Різниця між двома способами полягає в тому, що отрісовиваємих обєкти не реалізують властивий для View протокол виміру / компонування Як ви памятаєте, такий протокол дозволяє дочірнім видів, що знаходяться всередині контейнерного виду, «домовлятися» про компонування компонентів залежно від зміни розмірів виду Коли отображаемому обєкту потрібно додати, видалити або перегрупувати свої внутрішні компоненти – це серйозний аргумент на користь того, що в даному випадку слід використовувати повнофункціональний View, а не Drawable

Друга проблема, яку необхідно враховувати, полягає в тому, що, оскільки обєкти Drawable повністю містять в собі процес малювання, вони не малюються так, як обєкти Stri ng або Rect Наприклад, не існує жодних методів Canvas, які б відображали Drawable в конкретних координатах

Можливо, ви задумаєтеся, що краще зробити, щоб двічі відобразити одне і те ж зображення: застосувати метод ViewonDraw, який буде використовувати два різних незмінних Drawable, або двічі задіяти один і той же Drawable, перевстановити його координати після першого застосування

Але набагато важливіше, мабуть, проблема більш універсального характеру Причина, по якій втілюється сама ідея використання Drawable по ланцюжку, полягає в тому, що інтерфейс Drawable не містить ніякої інформації про внутрішню реалізації Drawable Коли Drawable передається коду, код жодним чином не може дізнатися, що саме йому доведеться відобразити – просте зображення або складну ланцюг ефектів – обертань, миганий, хитань Зрозуміло, така ситуація може бути як позитивною, так і негативною

Істотна частина процесу малювання відбувається із збереженням стану Ви налаштовуєте Paint, області відсікання, Canvas, а потім малюєте При спільній роботі по ланцюжку Drawable потрібно уважно стежити за тим, щоб після зміни станів Drawable між ними не виникало конфліктів Проблема полягає в тому, що при побудові ланцюжка Drawable неможливо явно і відразу визначити по типу обєкта, які конфлікти можуть виникнути (адже перед нами просто група отрісовиваємих обєктів) Саме незначне зміна може викликати небажані наслідки, які погано піддаються налагодженні

Щоб проілюструвати цю ситуацію, уявімо собі два класи-обгортки Drawable, один з яких повинен ужимать контент, а інший – повертати його на 90 ° Якщо кожна операція реалізується шляхом присвоєння матриці перетворень конкретного значення, то спільне використання цих класів може дати небажаний ефект Ще гірша ситуація, в якій А відмінно обертає В, а В зовсім не обертатися Л Тому важливо детально описувати в документації, як саме працює даний Drawable

Джерело: Android Програмування на Java для нового покоління мобільних пристроїв

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*