ВИЗНАЧЕННЯ ДОДАТКИ ANDROID: Фото МАНІФЕСТУ

Додаток Android може складатися з великої кількості різних компонентів

Активності – компоненти представлення користувача інтерфейсу і взаємодії з ним

Сервіси – процеси, що працюють у фоновому режимі і не мають видимого інтерфейсу Наприклад, сервіс може відповідати за отримання поштовим сервером нових листів

Постачальники вмісту – роблять частини вашого застосування доступними для інших додатків

Наміри – це повідомлення, створювані системою або самими додатками Вони можуть оповіщати нас про системні події (наприклад, витяг карти памяті або підключення USB-кабелю), а також використовуються системою для запуску компонентів нашого застосування (наприклад, активностей) Ми також можемо викликати власні наміри, щоб попросити інші додатки виконати необхідні нам дії (наприклад, відкрити фотогалерею або зробити фотографію за допомогою стандартного додатка Камери)

Приймачі мовлення – реагують на особливі наміри і можуть виконувати дії: запустити певну активність або згенерувати інший намір для операційної системи

Додаток Android не має однієї точки входу, до чого ми звикли при розробці для настільних систем (наприклад, у вигляді методу mai п у випадку з Java) Замість цього компоненти програми Android запускаються або виконують певні дії при отриманні відповідних намірів

Набір компонентів і намірів, на які ці компоненти реагують, визначається у файлі маніфесту додатки Система Android використовує цей файл маніфесту, щоб знати, з чого складається додаток, а також про те, яка активність запускається при його старті

ПРИМІТКА

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

Файл маніфесту виконує набагато більше завдань, ніж просто визначення компонентів програми Наступний список показує відповідні частини файлу маніфесту в контексті розробки ігор: версія програми, відображається і використовувана на Android Market Про версії Android, на яких наш додаток може працювати Про профілі обладнання, необхідні додатком (наприклад, наявність мультитач, певні дозволи дисплея, підтримка OpenGL ES 20) дозволу на використання певних компонентів (запис на SD-карту, доступ до мережі і т д)

У наступних підрозділах ми створимо шаблонний маніфест, який зможемо повторно використовувати у всіх проектах, які розробимо в процесі вивчення та Для цього пройдемося по відповідних XML-тегам, необхідним для визначення програми

Елемент

Тег є кореневим елементом файлу Androi dMani f est xml Ось простий приклад:

Якщо раніше ви вже мали справу з XML-файлами, то вам повинно бути все зрозуміло про першу сходинку Тег визначає простір імен android, використовуване у всьому файлі маніфесту Атрибут package задає кореневої пакет нашого застосування Пізніше ми співвіднесемо певні класи нашого застосування з цим імям пакета

Атрибути versionCode і versionName визначають версію нашого застосування в двох формах, versi onCode – ціле число, яке необхідно збільшувати кожен раз, коли ми публікуємо нову версію програми Воно використовується в Android Market для відстеження нашій версії програми versionName показується користувачам Android Market при відвідуванні сторінки програми Тут ми можемо застосовувати будь строкове значення

Атрибут install Location доступний нам, тільки якщо ми в Eclipse опеределить в якості мети нашого застосування версію Android 22 і вище Він визначає, де має бути встановлено додаток Рядок preferExternal повідомляє систему, що додаток повинен встановлюватися на карту памяті Таке можливо тільки з версії Android 22, для більш старих прошивок параметр буде ігноруватися Починаючи з Android 22 додаток завжди буде встановлюватися у внутрішнє сховище, якщо існує така можливість

Всі атрибути XML-елементів у файлі маніфесту мають префікс, що означає приналежність до простору імен android Для стислості надалі я буду опускати цей префікс, кажучи про певний атрибуті

Усередині елемента ми визначаємо компоненти програми, дозволи, профілі обладнання та підтримувані версії Android

Елемент

Як і у випадку з елементом , обговоримо елемент на прикладі:

Дещо тут виглядає дивно Що означають рядки @ drawable / icon і @ string / appname При розробці стандартного додатка Android ми зазвичай створюємо багато XML-файлів, кожен з яких визначає деяку частина нашого застосування Щоб мати можливість точно ідентифікувати ці частини, нам потрібна можливість звертатися до ресурсів, не визначених у файлах XML (наприклад, до зображень або інтернаціоналізованим строками) Ці ресурси розташовуються в підпапках каталогу / res

Для звернення до цих ресурсів ми використовуємо зазначену вище нотацію Знак @ вказує, що нам необхідний зовнішній по відношенню до маніфесту ресурс Рядок після @ визначає тип ресурсу, з яким ми звязуємося, що безпосередньо повязує його з одним з каталогів або файлів у папці / res Остання частина визначає імя ресурсу – в прикладі вище це зображення з назвою i con і рядок appjiame У випадку з зображенням імя ресурсу – це назва файлу, розташованого в каталозі res / drawable / Зверніть увагу – імя файлу вказано без розширення (PNG або JPG) Android додасть його автоматично, просканувавши папку res / drawabl в / Рядок appjiame визначена у файлі res / val ues / stri ngs xml, що містить рядки, використовувані додатком Імя рядки визначено в цьому файлі

ПРИМІТКА

Обробка ресурсів в Android дуже гнучка, але одночасно складна У даній е я вирішив майже повністю пропустити цю тему з двох причин: відсутність необхідності в цьому для написання ігор і бажання мати повний контроль над нашими ресурсами У Android є звичка змінювати ресурси, розміщені в каталозі res / (особливо зображення в drawables) Як розробникам ігор нам це зовсім не потрібно Єдина річ, яку я б запропонував, – використовувати систему управління ресурсами Android для інтернаціоналізованих рядків У нашій е це не знадобиться замість цього ми будемо застосовувати більш відповідний для ігрових додатків інструмент – дружню папку assets /, в якій наші ресурси ніхто не буде чіпати і яка дозволить нам створювати всередині власну ієрархію

Тепер значення атрибутів елемента має стати більш зрозумілим Атрибут icon визначає зображення з папки res / drawable /, використовуване як значка нашого застосування Цей значок буде показуватися на Android Market, а також на пристрої Крім того, цей значок застосовується за умовчанням для всіх активностей, визначених всередині елемента

Атрибут 1abel задає рядок, яка буде показуватися для нашого застосування в програмі для запуску додатків У прикладі це рядок у файлі res / val ues / stri ng xml, відповідна тому, що ми визначили при створенні проекту в Eclipse Ми можемо встановити йому будь-яке значення, наприклад My Super Awesome Game Ця мітка також є міткою за замовчуванням для всіх активностей, визначених всередині елемента , вона буде показуватися в рядку заголовка нашого застосування

Атрибут debuggabl е визначає, чи може наш додаток піддаватися налагодженні У процесі розробки краще встановити йому значення true (інакше налагодження в Eclipse буде неможлива), але при розміщенні готової програми на Android Market бажано задати значення false

Ми обговорили дуже маленьку частину атрибутів, які ви може встановити для елемента <Арр1е i cati оп> Однак для наших цілей цього цілком достатньо Якщо ви хочете дізнатися побільше, то зможете знайти повну документацію на сайті Android Developers

Елемент містить визначення всіх компонентів додатка, включаючи активності та сервіси, а також будь-які використовуються додаткові бібліотеки

Елемент

Чим далі, тим цікавіше Ось гіпотетичний приклад для нашої гри Містер Ном:

Для початку поглянемо на атрибути тега

name – визначає імя класу активності, яке повязане з атрибутом package, встановленим нами в елементі Ви також можете ввести тут повне імя класу

label – такий же атрибут ми вже визначили раніше в тезі Цей рядок відображається у рядку заголовка активності (якщо вона присутня) Крім того, дана мітка використовується як тексту, що показується в програмі для запуску додатків, якщо дана активність є точкою хвхожденія для програми Якщо не визначити даний атрибут, використовуватиметься відповідний атрибут елемента Зауважте, що в даному випадку я застосував саму рядок, а не посилання на неї у файлі stri ngs xml

screenOrientation – визначає орієнтацію екрану, використовувану даної активністю Для нашого Містера Нома я визначив портретну орієнтацію (тільки в ній вона і буде використовуватися) При бажанні можна визначити і ландшафтну орієнтацію Обидва варіанти змусять активність використовувати певну орієнтацію протягом усього її життєвого циклу незалежно від того, як насправді орієнтоване пристрій Якщо цей атрибут НЕ буде визначений, активність буде застосовувати поточну орієнтацію дисплея, грунтуючись на даних акселерометра Це також означає, що при будь-якій зміні орієнтації активність знищується і створюється заново – у випадку з іграми це не дуже бажано Тому режим орієнтації зазвичай фіксується в одному з варіантів (портретному або ландшафтному)

configChanges – переорієнтація пристрою або зсув клавіатурного блоку розглядаються як зміна конфігурації У разі подібних змін Android знищує і перезавантажує наш додаток для застосування змін У випадку з іграми це не кращий варіант поведінки Атрибут conf i gChanges елемента допомагає впоратися з цією проблемою Він дає можливість визначити, які зміни конфігурації ми хочемо обробляти самі, без пересозданія активності Множинні зміни конфігурації можуть бути задані з використанням символу для склеювання декількох варіантів У прикладі вище ми самі обробляємо клавіатуру, keyboardHi dden і зміна орієнтації

Як і у випадку з елементом , насправді атрибутів для елементу , звичайно, набагато більше Але для розробки ігор ми обмежимося описаними вище

Ви, мабуть, помітили, що елемент не порожня – він містить у собі інший елемент, а той, у свою чергу, містить два Для чого вони потрібні

Як я зазначав раніше, не існує єдиної точки входу в додаток Android Замість цього у нас є кілька таких точок у вигляді активностей і сервісів, що запускаються при отриманні намірів від системи або сторонніх додатків Нам якимось чином необхідно повідомити Android, які активності та сервіси (і як саме) будуть реагувати на певні наміри Саме для цього потрібен атрибут

У розглянутому прикладі ми визначили два типи фільтрів намірів: h Елемент повідомляє систему, що наша активність є головною точкою входу в програму Елемент вказує, що ми хочемо, щоб активність була додана в програму для запуску додатків Обидва елементи разом дозволяють Android зробити висновок, що при натисканні значка додатка в програмі для запуску додатків повинна запускатися саме ця активність Значення елементів і – Імя, що визначає намір, на яке слід реагіроватьandroidintentactionMAIN – Спеціальний намір, яке система Android використовує для запуску головної активності додатки Намір android, intent Category LAUNCHER використовується для оповіщення операційної системи про те, чи повинна дана активність мати можливість запуску через програму для запуску додатків (application launcher)

У нашому прикладі є тільки одна активність з двома цими фільтрами Однак стандартний додаток Android майже завжди має кілька активностей, і всі вони також повинні бути визначені у файлі mani fest xml Ось приклад визначення подібної субактівності:

Як бачите, тут не визначені фільтри намірів – тільки чотири атрибута, які ми розглянули раніше При подібному визначенні активності вона стає доступна тільки нашому додатком Запускається така активність спеціальним видом наміру (наприклад, при натисканні відповідної кнопки в інший активності) Трохи пізніше в цьому розділі ми розглянемо питання програмного запуску активності

Підводячи підсумок, можна сказати, що у нас є одна активність, у якій визначені два фільтра намірів (що робить її головною точкою входження для нашого застосування) Для всіх інших активностей ми опускаємо визначення фільтрів намірів, тому вони є внутрішніми для нашого застосування і тому запускаються програмно

ПРИМІТКА

Як було сказано раніше, в наших іграх буде тільки одна активність Вона буде володіти тим же визначенням фільтрів намірів, що і в даному прикладі Причина, по якій я описав визначення множинних активностей, в тому, що у нас в планах значиться створення спеціального тестового додатку з множинними активностями Не хвилюйтеся, це буде зовсім нескладно

Елемент

Тепер залишимо елемент і повернемося до елементів, певним нами в якості дочірніх для елемента Один з них –

Android володіє ретельно пророблений моделлю забезпечення безпеки Кожна програма працює в рамках власного процесу і віртуальної машини, під власним користувачем Linux і групою і не може впливати на інші програми Крім того, система обмежує застосування своїх ресурсів (мережевий доступ, карта памяті, диктофон і т д) Якщо нашому додатку необхідно їх використовувати, ми повинні запросити на це дозвіл за допомогою елемента

Дозвіл завжди запитується в наступній формі (рядок визначає назву необхідного нам дозволу):

Ось кілька назв дозволів, які нам можуть знадобитися: Про androi d permi ssi on REC0RD AUDI0 – отримання доступу до обладнання для запису звуку android, permi ssi on INTERNET – отримання доступу до всіх мережних API, що дозволяє, наприклад, отримати зображення з Інтернету або завантажити кращі результати androi d permi ssi on WRITE EXTERNAL STORAGE – дає можливість читати і записувати файли на зовнішній носій (зазвичай на SD-карту) androi d permi ssi on WAKEJ0CK – дозволяє здійснювати так звану захист від блокування З її допомогою ми можемо перешкоджати переходу пристрої в сплячий режим при відсутності натиснень екрану протягом деякого часу Таке може статися, наприклад, при управлінні грою за допомогою акселерометра

Для отримання доступу до мережевих API ми визначаємо наступний елемент як дочірнього для :

Для всіх додаткових дозволів ми просто додаємо ще елементи

Ви можете визначити набагато більше дозволів – я знову адресую вас до документації Android Нам зараз потрібні тільки ті, які ми тільки що розглянули

Якщо ви забудете додати на щось дозвіл (наприклад, на доступ до карти SD), повідомлення про це зявиться в LogCat, але його там не завжди легко виявити Подумайте добре про дозволи, необхідних вашому додатком, і визначте їх при первісному створенні проекту

Ще одна річ, про яку необхідно сказати, – коли користувач інсталює додаток, його першим справою попросять переглянути всі дозволи, необхідні програмою Багато хто просто пропускають цей текст і довіряють автору Однак деякі більш відповідально ставляться до своїх рішень і уважно вивчають дозволу Якщо ви просите щось підозріле (наприклад, можливість відсилати платні CMC або отримувати координати користувача), то можете отримати несхвальну реакцію від них в розділі Коментарі на Android Market Якщо вам потрібна одна з таких проблемних дозволів, повідомте користувачеві, навіщо саме воно вам потрібно, в описі програми Але найкраще взагалі уникати подібних дозволів

Елемент

Якщо ви самі – користувач Android і володієте пристроєм зі старою версією ОС (наприклад, 15), то, мабуть, помітили, що деякі відмінні додатки не показуються вам на Android Market Причина цього – Використання елемента у файлі маніфесту додатки

Android Market фільтрує всі наявні програми, виходячи з вашого профілю обладнання За допомогою елемента додаток може визначити, які апаратні можливості йому необхідні (Наприклад, мультитач або підтримка OpenGL ES 20) Будь-який пристрій, що не володіє зазначеними можливостями, не бачитиме додаток

Елемент володіє наступними атрибутами:

Атрибут name визначає саму можливість (функцію) Атрибут requi red повідомляє фільтру, чи необхідна нам ця можливість для роботи програми або просто було б добре її мати Останній атрибут опціональний і використовується тільки в разі, якщо для роботи обовязково потрібна певна версія OpenGL ES

Для розробників ігор найбільш важливими є такі вимоги: android hardware touchscreen multi touch – вимагає від пристрою наявності мультитач-екрана, який підтримує деякі поширені можливості Такі типи дисплеїв можуть мати проблеми з відстеженням незалежних торкань, тому вам потрібно подумати, чи достатньо цих можливостей для вашої гри androidhardwaretouchscreenmultitouchdistinct – Старший брат попередньої можливості Він запитує повний набір мультитач-здібностей, що дозволяють реалізувати всі доступні функції

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

Інша корисна річ для розробників ігор – визначення необхідної версії OpenGL ES У нашій е ми маємо справу з OpenGL ESIOhIIB цьому випадку нам немає необхідності задавати відповідний елемент , оскільки дві вищезгадані версії не надто один від одного відрізняються Однак будь-який пристрій, що володіє підтримкою OpenGL ES 20, набагато випереджає за своїми графічним можливостям попередників Якщо наша гра візуально складна і вимагає багато обчислювальної потужності, ми можемо зажадати версію OpenGL ES 20, щоб додаток було видно тільки апаратам, що підтримує цю бібліотеку Зауважте, що ми не використовуємо OpenGL ES 20, а просто фільтруємо пристрої таким чином, щоб наш код на OpenGL ES 1x отримав достатньо обчислювальної потужності Зробити це можна так:

Тепер наша гра буде видно тільки пристроям з підтримкою OpenGL ES 20, що гарантує нам використання потужного графічного процесора

ПРИМІТКА

Ця можливість на деяких пристроях обробляється некоректно, що робить додаток невидимим для цілком відповідних пристроїв Використовуйте дану можливість з обережністю

Врахуйте – кожна нова вимога до апаратної складової потенційно зменшує кількість пристроїв, яким буде видно ваш додаток на Android Market (а це безпосередньо впливає на його продажу) Подумайте двічі, перш ніж додавати їх Наприклад, якщо стандартний режим гри вимагає мультитач, але ви хочете розглянути можливість грати в неї і на звичайних дисплеях, вам може знадобитися розділити код на окремі гілки, щоб охопити більший сегмент ринку

Елемент

Останній елемент, який ми помістимо в наш файл маніфесту, – , дочірній для Ми неявно вже задавали його при створенні проекту Hel1о World коли визначали мінімальну версію SDK в діалоговому вікні New Android Project (Новий проект Android) Отже, для чого потрібен цей елемент Розглянемо приклад:

Як обговорювалося, кожна версія Android має якийсь цілочисельний параметр, також відомий як версія SDK Елемент визначає мінімальну версію SDK, яку підтримуватиме наш додаток, тобто його цільову версію

Цей елемент дозволяє розгортати додаток, що використовує API з новіших версій, на пристроях з більш старою версією SDK Показовий приклад – API для мультитач, підтримувані починаючи з 5-й версії SDK (Android 20) При створенні проекту в Eclipse ми використовуємо мета збірки, підтримуючу цей API, наприклад SDK 5 або новіше (я зазвичай задіюю новітню версію, 9 на момент написання) Якщо ми хочемо, щоб наша гра запускалася також на пристроях з версією SDK 3, необхідно визначити значення атрибута mi nSdkVersi on у файлі маніфесту Звичайно, нам потрібно буде подбати про те, щоб не використовувати API, недоступні в старіших версіях SDK (принаймні на пристроях з версією 15) На апаратах з більш новою версією нові функції з нових API залишаться доступними

Описана вище конфігурація звичайно цілком підходить для більшості ігор (тільки якщо ви не хочете розділити гілки програмного коду для різних версій API – в цьому випадку буде правильним встановити значення атрибута mi nSdkVersi on рівним мінімальній версії SDK, яку ви підтримуєте)

Налаштування проекту гри на Android за 10 простих кроків

Тепер скомбініруем всю отриману до цього моменту інформацію і розробимо простий покроковий метод створення нового ігрового проекту для Android в середовищі Eclipse Ось що нам потрібно від цього проекту

Він повинен бути здатний використовувати можливості останньої версії SDK, зберігаючи при цьому сумісність з більш старими версіями, які до цих пір застосовують багато пристроїв Це означає, що нам необхідна підтримка Android 15 і вище

Він повинен інсталюватися на карту памяті (при наявності такої можливості), щоб не заповнювати внутрішню память пристрою

Він повинен бути доступний для налагодження

Він повинен мати одну головну активність, обробну всі зміни конфігурації самостійно, щоб не пересоздавать при зсуві клавіатури або зміну орієнтації пристрою

Активність повинна бути зафіксована в портретному або ландшафтному режимі

Проект повинен мати доступ до SD-карті

Він повинен бути здатний реалізовувати захист від блокування

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

1 Створіть новий проект Android в Eclipse, відкривши діалог New Android Project (Новий проект Android)

2 У діалоговому вікні New Android Project (Новий проект Android) визначте назву проекту і встановіть мета збірки рівний останній версії SDK

3 У тому ж вікні введіть назву вашої гри, пакету (в якому зберігатимуться всі ваші класи), а також назва головної активності Далі встановіть мінімальну версію SDK рівний 3 Натисніть Finish (Готово) для створення проекту

4 Відкрийте файл AndroidMani fest xml

5 Щоб встановлювати гру на карту памяті завжди, коли це можливо, додайте атрибут nstal Locati on в елемент і встановіть його значення рівним preferExternal

6 Щоб зробити доступною налагодження гри, додайте атрибут debuggabl е в елемент і встановіть його значення рівним true

7 Для фіксації орієнтації активності додайте атрибут screenOrientation в елемент і визначте його значення (portrait або landscape)

8 Щоб повідомити Android про те, що ми хочемо обробляти зміни конфігурації, викликані подіями клавіатури, keyboardHidden і зміною орієнтації дисплея, встановіть атрибуту conf i gChanges елемента значення keyboardkeyboa rdHi ddenori entati on

9 Додайте два елементи в елемент і визначте атрибути name androi dpermi ssionWRITE EXTERNALSTORAGE і androi d permi ssionWAKE LOCK

10 Додайте атрибут targetSdkVersion в елемент і визначте вашу цільову версію SDK Вона повинна бути тією ж, що ви задали для цільової збірки в кроці 2

Ось і все Десять простих кроків – і в результаті ми маємо додаток, що встановлюється на SD-карту (у випадку з Android 22 і вище), здатне до налагодження, що володіє фіксованою орієнтацією екрана і не перезавантажуємо при зміні конфігурації Воно має доступ до карти памяті, перешкоджає автоматичному блокуванні і працює на всіх версіях Android починаючи з 15 Ось підсумковий файл Androi dMani fest xml, що вийшов після здійснення всіх кроків:

Як бачите, я позбувся @ stnng / app name в атрибутах мітки елементів і Це необовязково, але мені подобається, коли всі визначення додатки зібрані в одному місці Тепер прийшов час коду Або ..

Призначення значка для вашої гри

Коли ви розгорнете вашу гру на пристрої і відкриєте вашу програму для запуску додатків, то побачите, що їй призначено красивий, але аж ніяк не унікальний значок Android Він же буде показуватися для вашого додатки і на Android Market Як змінити його на наш значок

Ще раз поглянемо на елемент Тут ми визначили атрибут icon, повязаний із зображенням, розташованим в каталозі res / drawable і мають назву icon Тепер наші дії повинні стати очевидними – нам необхідно замінити файл icon в каталозі drawable нашим власним

Якщо ви вивчите каталог res /, то побачите не одну, а кілька папок, що починаються з drawable (рис 41)

Отже, у нас знову класична проблема курки і яйця

Це сталося через те, що ми визначили як мету збірки версію SDK 3, яка підтримує тільки один розмір екрану Починаючи з версії 16 (SDK версії 4) становище змінилося

Виявляється, існує продуманий механізм, що дозволяє вам визначати ваші графічні ресурси для набору так званих густин Щільність екрану – це комбінація фізичного розміру екрану та кількості пікселів на ньому Ми вивчимо це питання докладніше пізніше, поки ж досить знати, що Android визначає три щільності: 1dpi для екранів з низькою щільністю, mdpi для стандартної щільності і hdpi для дисплеїв високої щільності Для екранів з малою щільністю ми зазвичай використовуємо зображення меншого розміру, для більш щільних – ресурси високого дозволу

Рис 41 Що сталося з каталогом res / folder

Отже, у випадку з нашим значком нам необхідно запропонувати три його версією, по одній для кожної щільності Але який повинен бути розмір цих версій На щастя, у нас вже є значки за замовчуванням в кожній папці res / drawabl е, з яких ми можемо визначити необхідні розміри для наших власних значків Файл icon в res / drawable-ldpi має розмір 36 х 36 пікселів аналогічний файл в res / drawabl e-mdpi – 48×48 пікселів і, нарешті, icon в res / drawabl е – hdpi – 72 х 72 пікселя Все, що нам потрібно, – створити версії нашого значка з відповідними розмірами і замінити файли iconpng в кожному каталозі на наші власні з тим же імям Зверніть увагу – посилання на файли в маніфесті чутливі до регістру Щоб уникнути потенційних проблем, завжди використовуйте нижній регістр

Щоб домогтися справжньої сумісності з Android 15, нам необхідно додати в проект каталог res / drawablе / і скопіювати в нього файл iconpng з res / drawabl e-mdpi / Android 15 нічого не знає про інших каталогах drawable, тому може не знайти потрібний нам файл

І ось тепер вже точно ми можемо зайнятися написанням коду під Android

Джерело: Mario Zechner / Маріо Цехнер, «Програмування ігор під Android», пров Єгор Сидорович, Євген зазноби, Видавництво «Пітер»

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


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

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

Ваш отзыв

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

*

*