MIT App Inventor - кожен може створити мобільний додаток. MIT App Inventor - кожен може створити мобільний додаток Блоки App Inventor. Важливі поняття та принципи

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

Донедавна проблема навчання школярів середніх класів програмуванню здавалася нерозв'язною - передусім через відсутність інструменту, який, з одного боку, був би досить простий у освоєнні, а з іншого - дозволяв би створювати справді продукти, що стоять. Спроби поголовно навчати школярів Бейсику чи Паскалю призводили лише до того, що предмет «інформатика» виявлявся по зубах лише дуже вузькому колу учнів - тим, кому з інтелектуальних особливостей, сімейного виховання чи надзвичайного везіння з учителем вдавалося просунутися в освоєнні програмування далі, ніж іншим . Більшість інших школярів інформатика і залишалася чимось недоступним.

Ситуація почала змінюватися на початку 2000-х років, з виникненням та розвитком візуальних мов програмування, флагманом яких по праву вважається мова Scratch. Ця мова здійснила справжню революцію у шкільному викладанні програмування під десктопні ОС. Програмувати на Scratch так само легко, як складати дитячу мозаїку-пазл. Оператори та процедури мови є кольоровими блоками. Перетягуючи та з'єднуючи їх, ми створюємо програми. Помилка в синтаксисі цієї мови зробити просто неможливо - якщо блоки не стануть поруч, пазл просто не складеться.

App Inventor

Природним розвитком цього підходу стала мова програмування App Inventor, розроблена професором Массачусетського технологічного інституту (MIT) Халом Абелсоном у 2010 році. В основі його - той же принцип перетягування візуальної цегли та збирання програми з блоків.

Відмінність App Inventor від Scratch полягає в тому, що App Inventor орієнтований не на десктопне використання, а призначений для створення програм під мобільний пристрій – смартфон або планшет з ОС Android. Він вміє, наприклад, «розуміти» дані акселерометра мобільного гаджета, керувати вбудованою камерою, бачить, як орієнтований телефон у просторі та багато іншого.

App Inventor - це повністю хмарна програма. Щоб почати програмувати на ньому, потрібний лише інтернет та браузер. Перехід на сторінку мови здійснюється за цим посиланням. Інтерфейс англійською та російською мовами.

Інтерфейс мови програмування MIT App Inventor складається із двох основних частин - дизайнераі редактора блоків.

У дизайнерами конструюємо нашу програму з елементів - екранів, кнопок, осередків, зображень, звуків.

У редактор блоківми програмуємо поведінку цих елементів.

Інтерфейс App Inventor простий та інтуїтивно зрозумілий. Якщо ви захочете спробувати викладати програмування на App Inventor у школі, рекомендуємо сайт appinvent.ru, на якому зібрані навчальні матеріали для вчителів.

Конкурс для школярів

А школярі, які пройдуть навчання з програмування на App Inventor у школі або самотойно, можуть взяти участь у конкурсі на розробку власних мобільних додатків на App Inventor. Переможець конкурсу отримає планшетний комп'ютер від компанії Samsung. Термін подання робіт – до 15 травня 2016 року.

App Inventor- середовище візуальної розробки android-додатків, що вимагає від користувача мінімальних знань програмування. Спочатку розроблено в Google Labs, після закриття цієї лабораторії було передано Массачусетському технологічному інституту. На початку березня 2011Массачусетський інститут запустив публічну бета-версію проекту, доступну на сайті appinventor.mit.edu.

Працює це середовище розробки безпосередньо з браузера. Завантажувати та встановлювати нічого не потрібно. Отриманий результат можна переглядати на Android-пристрої. Готові програми можна розміщувати у Play Market.

З серпня 2015 року App Inventor 2 підтримує російська мова.

В онлайн редакторі MIT App Inventor 2 додатки будуються на базі стандартних компонентів, які є основним елементом розробки додатків Android.

Блоки App Inventor. Важливі поняття та принципи

Блоки App Inventor є інструментами для оперування компонентами і виглядають як пазли.

Блоки в цьому конструкторі програм для Android розбиті на дві великі групи за ознакою – на що впливають і до чого ставляться:

що стосуються безпосередньо компонентів
що відносяться до додатку в цілому

Почнемо з блоків, що належать до компонентів.Їх можна розділити на три типи, які легко розрізнити за кольором:

1. блоки, що описують властивості компонента. Вони зеленого кольору і виглядають так:

цей блок означає поточну властивість компонента. На цій картинці наведено блок кольору тла для текстового компонента TextBox1. Він має на увазі отримання вже існуючого значення.

а цей задає потрібне значення компоненту (привласнити TextBox1 фоновий колір …). "set" - задати. Цей тип блоку-властивості можна було б віднести до команд (обробників), оскільки він дійсно дає команду змінити будь-яку властивість компонента, в тому числі, і значення полів. Однак розробники App Inventor вирішили так - все ж таки це і властивості теж.

2. блоки-події, тобто ті блоки, які відслідковують настання якоїсь події в додатку, наприклад, натискання кнопки і далі запускають блок-команду. Вони пофарбовані в бронзовий колір і виглядають так:

цей блок, наприклад, виконує дію після натискання кнопки (коли по Button3 клікнули зробити …)

3. блок-команда, в App Inventor цей блок часто називають обробником. Цей блок показує, що необхідно зробити з компонентом, до якого належить блок:

Саме цей блок викликає дані з таймера пристрою.

Друга група блоків, що відносяться до всього додатку, організована дещо інакше.

Для початку ось їх список підгруп:

Logic blocks– логічні блоки
Math blocks– математичні блоки
Text blocks- Текстові блоки
Lists blocks– блоки для керування списками
Colors blocks– блоки для керування кольором
Variables blocks– блоки для керування змінними
Procedures blocks- Блоки процедур.

Всі вони, крім Procedures blocks, вбудовуються в інші блоки. Тобто, вони не можуть служити початковим блоком, на відміну від блоків-подій, що належать компонентам – всі дії здійснюються за будь-яких подій з компонентами.

Ось тут варто розповісти ще про типи «пазлів». Отже, ви напевно помітили, що є пазли чотирьох видів.

З їхньої форми цілком очевидно, що першим видом починається будь-який ланцюжок у мобільному додатку. Це – подія і цілком логічно, що вона ініціює усі подальші дії. І цей тип не відрізняється від прийнятого в цьому конструкторі програм для Android.

А ось наступні два види блоку за типологією App Inventor відносяться до різних типів: властивостей та команд (обробників), відповідно. Але за формою пазла та за змістом їх можна було б віднести до команд, оскільки вони задають дію. Скажімо, другийнаведений на зображенні пазл дає команду присвоїти компоненту певне значення, а третійпазл - викликати компонент із певним значенням. Крім того, ці пазли є «проміжними», ними не можна закінчити ланцюжок.

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

Компанія Айтічер оголошує конкурс розробки мобільних додатків для ОС Андроїд, створених мовою програмування App Inventor.

Термін проведення Конкурсу

Прийом та реєстрація конкурсних робіт: з 1 січня до 15 травня 2017 року.
Розгляд робіт конкурсним Журі – з 15 до 30 травня 2017 року.
Оголошення результатів конкурсу 30 травня на порталі конкурсу.

Збільшити вбудовану функціональність App Inventor можна за допомогою веб-технологій та розширень. У мережі можна знайти платні та безкоштовні розширення (близько 200 на puravidaapps.com), але виникають питання, а наскільки складно створювати свої, що вони можуть дати і чи варто витрачати час на це чи краще зайнятися чимось іншим?

Всі компоненти та блоки, доступні в App Inventor, відносяться до вбудованих (внутрішніх), а розширення – до зовнішніх.

Вбудовані можливості надають цікаву функціональність для користувачів-початківців, задовільну для досвідчених і недостатню для програмістів. При цьому більшість користувачів воліють завантажувати готові розширення, а не розробляти їх. З цього випливає простий висновок у тому, що розробка розширень може бути цікава, переважно, досвідченим користувачам та ентузіастам. Початківців цілком влаштують вбудовані можливості і розширення, а програмістам займатися розширеннями не цікаво через необхідність виконання подвійної роботи. Навіщо витрачати час на створення та налагодження розширення обмеженої функціональності, а потім за допомогою нього створювати програму обмеженої функціональності, якщо можна відразу писати код на Java, користуючись усіма доступними можливостями Android Studio IDE та Android API?

Створювати розширення для AI нескладно, якщо є якийсь досвід програмування та розуміння основ ОВП, але з вищевказаних причин цим серйозно займаються одиниці. Створювати функціональні розширення непрактично, а ось написання простих доповнень для розширення вбудованої функціональності або створення нової може здатися цікавим та корисним у плані практики заняттям. Але тут слід визначитися з підходом. Можна або наслідувати концепцію AI - візуальне програмування, або розширити її елементами текстового програмування.

Якщо сказати грубо, то App Inventor схожий на айсберг, верхівка якого видно користувачам у вигляді вбудованої функціональності, а під водою знаходиться і недоступна значно більша частина. Це зроблено спеціально відповідно до призначення цієї IDE, що вимагає від користувачів мінімальних знань програмування. Закладена в App Inventor модель роботи не розрахована на велику функціональність. Додавання нових властивостей викликає зростання кількості блоків у геометричній прогресії. Наприклад, додавання властивості прозорості призведе до появи двох блоків для кожного віджету (для встановлення та повернення значення). Якщо таких віджетів 5, число блоків збільшиться на 10. Додали 10 властивостей, на виході отримали 100 блоків. Додатково до цього з'являться нові поля властивостей дизайнера. У цих умовах підхід "проста IDE + розширення" виглядає обґрунтованим, але не для тих, хто надає перевагу хорошій функціональності "з коробки" без необхідності пошуку та встановлення доповнень.

Індивідуальне налаштування властивостей об'єктів та завдання жорсткого зв'язку блоків на етапі розробки програми, з одного боку, спрощує розробку та дозволяє уникнути великої кількості помилок, але призводить до виникнення статичних додатків. Якщо до одного блоку приєднано інший блок, це назавжди. Змінити властивість або вибрати інший об'єкт на етапі виконання програми можна тільки в тому випадку, якщо ця можливість була закладена на етапі розробки. Для цього необхідно використовувати опосередкований доступ до об'єктів. Наприклад, можна створити список пар назва об'єкта для всіх об'єктів, а потім використовувати його в функціях для доступу до різних об'єктів. В цьому випадку приймаючий блок буде пов'язаний не з конкретним об'єктом, а зі списком, з якого потрібний можна отримати за його ключем-ім'ям.

Якщо до сказаного вище додати складнощі з реалізацією групових операцій, відсутністю віджетів, методів та інших нюансів вбудованої функціональності, то стане зрозумілою причина появи AppyBuilder, Thunkable, Makeroid та ін., в яких збільшення функціональності реалізовано за рахунок кількості компонентів. Більше компонентів – більше блоків. А ось за допомогою розширення можна збільшити функціональність якісно, наприклад, використовувати один блок для доступу до десятків властивостей десятка об'єктів. Ось це вже дійсно цікаво, оскільки доповнює візуальне програмування текстовими елементами для компенсації ряду недоліків вбудованої функціональності AI.

Чи зможуть створювати розширення ті, хто слабо знайомий із програмуванням? Так, прості зможуть, скориставшись підходом "скопіюй і зміни", але певна підготовка все ж таки потрібна. Без неї буде незрозуміло, чому розширення не компілюється і що при цьому пишеться на екрані. Також слід сказати про те, що частина розширення, що працює з об'єктами Android, зручніше створювати та налагоджувати в Android Studio.

Розробка розширень підійде тим, кого, в принципі, влаштовує App Inventor, але хотілося б щось доповнити, покращити та спростити, а заразом і попрактикуватися в Java. Якщо це ваш випадок, то почнемо з розгортання середовища розробки.

ВКонтакті є група Розширення для App Inventor, де на відео та в текстовому вигляді дано покрокове керівництво зі створення та налаштування робочого середовища, а також простий приклад, що повертає слово Test. Дублювати цей матеріал не має сенсу, а ось сам приклад розглянемо як швидке введення в тему.

package vlad; import com.google.appinventor.components.runtime.*; import com.google.appinventor.components.annotations.DesignerComponent; import com.google.appinventor.components.annotations.DesignerProperty; import com.google.appinventor.components.annotations.PropertyCategory; import com.google.appinventor.components.annotations.SimpleEvent; import com.google.appinventor.components.annotations.SimpleFunction; import com.google.appinventor.components.annotations.SimpleObject; import com.google.appinventor.components.annotations.SimpleProperty; import com.google.appinventor.components.common.ComponentCategory; import com.google.appinventor.components.common.PropertyTypeConstants; import com.google.appinventor.components.common.YaVersion; import com.google.appinventor.components.runtime.util.SdkLevel; @DesignerComponent(version = YaVersion.NOTIFIER_COMPONENT_VERSION, категорія = ComponentCategory.EXTENSION, description = "Це є тест extension", noVisible = true, iconName = "images/notifier.png") @SimpleObject(external=true) public final class extends AndroidNonvisibleComponent implements Component ( public TestExtension(ComponentContainer container) ( super(container.$form()); ) @SimpleFunction(description = "This function returns the \"Test\" string") public String Test() ";))

Код розширення включає java-код класу і анотації, що починаються з символу @. Анотації використовуються для вказівки, що блок коду під ними повинен бути оброблений простим компілятором. Простий компілятор переглядає анотації та здійснює інтеграцію розширення в середу розробки App Inventor – створює для зазначеної функції блок (функції або властивості), поле редагування в дизайнері та виконує іншу роботу.

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

@SimpleObject вказує на компонент, а поле external=true на те, що компонент є зовнішнім

@SimpleFunction вказує компілятор функцію, для якої потрібно створити блок. Якщо функція повертає значення, виїмка з'явиться в його лівій стороні. Якщо функція має параметри, відповідні їм виїмки будуть у правій стороні.

Вихідні коди класів можна переглянути в директоріях, які відповідають назвам пакетів:

com/google/appinventor/components/runtime – класи вбудованих об'єктів.
com/google/appinventor/components/annotations - класи інструкції
com/google/appinventor/components/common - класи загального використання
com/google/appinventor/components/runtime/util - класи утиліт

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

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

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

Будь-яку операцію можна помістити або блок обробки події, або блок процедури. Розташування операції у блоці обробки події характеризується простий, але у майбутньому це може призвести до багатьох проблем, на відміну використання їх у процедурі, що дозволить отримати гнучкий алгоритм. Розглянемо це з прикладу простий операції присвоєння глобальної змінної порожнього списку, що з двох блоків (рис. 1).

Мал. 1. Варіанти розташування операції.

При розміщенні операції в блоці обробки події компонента (верхній варіант) вона жорстко прив'язується до нього і стає недоступною для виклику з інших блоків. Якщо цю операцію потрібно викликати з іншого блоку, її доведеться скопіювати. Створювати копії операції небажано, тому що при зміні її алгоритму доведеться вносити редагування в кожну з них. Це підвищує можливість появи різних помилок: можна забути виправити якусь копію, помилитися при копіюванні блоків, вставці їх і т.п. Розміщення операції в блоці процедури дозволить викликати її з інших блоків та уникнути описаних вище помилок.

При роботі в редакторі блоків іноді виникає потреба викликати різні версії однієї операції або різних операцій. Для цього можна створити нові компоненти з новими блоками обробки подій, або використовувати один існуючий блок btnExecute, поміщаючи в нього виклик тієї чи іншої операції. В результаті заміни від'єднані операції перетворяться на “плаваючі” блоки (рис. 2), які не належать жодному груповому блоку.

Мал. 2. "Плаваючі" блоки.

Якщо на робочому полі таких плаваючих блоків багато, то з ними розібратися буде непросто. Якщо з нижнім блоком все зрозуміло - це блок виклику процедури, що робить зчіпка блоків у верхній частині малюнка? Це окрема операція чи дія, яка входить чи входила до якоїсь іншої операції? Але тоді де решта цієї операції? Додавання операції в блок процедури дозволить позбутися незрозумілих "плаваючих" блоків.

Для виконання блоку не обов'язково поміщати його в обробник події. Можна натиснути правою кнопкою миші на ньому і в контекстному меню вибрати опцію Do it.

Ще один недолік розміщення операції в обробнику події пов'язаний з тим, що при випадковому видаленні компонента в дизайнері відбудеться видалення не тільки всіх блоків, які відносяться до цього компонента, але всіх вкладених в них блоків. Особливо прикро буде в тому випадку, якщо операція складалася з великої кількості блоків (рис. 3). Якщо видалити компонент btnTest, то буде видалено блок btnTest.Click з усім його вмістом.

Мал. 3. Небажане угрупування блоків у обробнику події.

Яку операцію виконують блоки цьому малюнку? Відразу важко відповісти. А при поміщенні їх в окрему процедуру все відразу стане зрозуміло з її назви setVarValue - задає значення змінної (рис. 4).

Мал. 4. Угруповання боків у процедурі.

Блоки процедур і локальних змінних мають налаштування, доступне при натисканні на піктограмі шестерні. Для блоків процедур вона полягає у додаванні їм вхідних параметрів, а для блоків локальних змінних до створення додаткових входів. Це дозволить чотири блоки змінних перетворити на один блок із чотирма змінними (рис. 4). Чи є таке перетворення еквівалентним? Ні. Блок із декількома локальними змінними має одну область видимості, що не дозволяє всередині нього отримувати значення його змінних. Наприклад, неможливо змінній value (рис. 4) присвоїти значення змінної key.

Перерахуємо виявлені нами недоліки розміщення операції у блоці обробки події:

Жорстка прив'язка до блоку події певного типу обраного компонента
Неможливо викликати операції з інших блоків (означає, вона не може стати бібліотечною)
Видалення операції при видаленні компонента
Утворення незрозумілих "плаваючих" груп блоків
Важко швидко зрозуміти те, що робить операція

Позбутися всіх цих недоліків дуже просто, якщо всі операції поміщати в процедури.

При створенні алгоритмів для простоти та швидкості хочеться різні операції помістити в одну процедуру, що призведе до швидкого збільшення кількості блоків та складнощів з розумінням її роботи. Для виключення цього у програмуванні широко використовується просте правило:

Одна функція (процедура) – одна операція

Це правило взято із життєвої практики. Уявіть, що ви вмикаєте світло в кімнаті, а при цьому вмикається телевізор, кондиціонер і вимкнення комп'ютера. Чи вам це сподобається? Ні, тому що це призведе до плутанини та неприємних ситуацій.
На рис. 4 на початку блоку відбувається виклик чотирьох процедур - getKey (отримати ключ), getNewVal (отримати нове значення), getKeys (отримати список ключів) та getIndex (отримати індекс). Кожна з цих процедур виконує одну операцію. Після них йде блок if, у якому відбувається виконання однієї операції процедури setVarValue1.
Чи можна замість локальних змінних у процедурах використовувати глобальні? Можна, але так не слід робити. Використання глобальних змінних всередині процедури, по-перше, жорстко прив'язує її до них і, відповідно, до цього додатку, а, по-друге, за допомогою глобальних змінних зовнішні блоки з різних місць застосування можуть впливати на внутрішній механізм роботи процедури, що дуже небажано. Що може статися, якщо пасажири автобуса матимуть доступ до його механізму?

Локальні змінні є свого роду буфером. Якщо зміниться ім'я глобальної змінної, це не порушить роботу процедури, оскільки всередині неї використовуються імена локальних змінних, які змінювалися. У App Inventor при зміні імені глобальної змінної воно автоматично зміниться у всіх блоках, що його використовують. Звідси випливає важливий висновок про те, що існуюча в App Inventor автоматизація з перевірки коректності типів змінних, перейменування змінних та ін., з одного боку, спрощує розробку додатків, звільняючи розробника від роздумів над цими питаннями, а, з іншого боку, сприяє розвитку навички недбалого складання алгоритмів. Взагалі кажучи, ця навичка може розвинутися при програмуванні будь-якою мовою. Як цього уникнути? Використовувати рекомендації щодо створення "чистого коду", про що написано чимало книг. У MIT App Inventor вдасться використовувати лише малу частку цих рекомендацій, але дотримання їм дозволить поліпшити алгоритми та їх читаність за будь-якого способу їх створення - на аркуші паперу, дошці, при редагуванні коду або роботі з блоками.

Зазначене вище правило слід використовувати у разі використання блоків обробки подій. На рис. 4 обробник події Click робить лише одну операцію - викликає процедуру. А якщо з оброблювача подій потрібно викликати кілька процедур? Тоді потрібно зрозуміти, чи ця група процедур виконує одну або кілька операцій? Якщо одну, то все гаразд. Наприклад, при ініціалізації програми викликається багато процедур, але вони об'єднані однією операцією - ініціалізації.

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

Як сховище бібліотечних процедур App Inventor можна використовувати незадіяні екрани програми. Бібліотеки з невеликою кількістю процедур можна розташовувати спільно на одному екрані, а великі - на окремих. В останньому випадку переміщення всіх блоків бібліотеки до рюкзака можна буде виконати за допомогою однієї операції.

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

Для виключення перейменування глобальних змінних та порушення роботи бібліотечних процедур при копіюванні їх з рюкзака на екран програми, який може мати глобальні змінні з такими самими іменами, необхідно імена бібліотечних блоків заздалегідь складати з префіксами, що вказують на бібліотеку. Якщо бібліотека для роботи зі списком пар має назву libPairs. Тоді можна змінні, процедури та компоненти в ній назвати так: libPairs_name, libPairs_setValue, libPairs_btnExecute.

Для зручнішої роботи з великою кількістю блоків і переміщення їх по робочому полю, крім кнопок масштабування на області перегляду нагоді і масштабування робочої області браузера за допомогою комбінації клавіш Ctrl- або Ctrl+.

Погодна станція в MIT App Inventor 2 – програма погодної станції для android телефонів створена за допомогою онлайн сервісу.

Дана погодна станція описана у статті, де ми робили огляд роботи погодної станції, створювали скетч для arduino та пристрій погодної станції. Ну а сьогодні ми розберемося докладніше як створити програму для android і відобразити всі отримані дані з нашої погодної станції на телефоні.

Для створення програми погодна станція в MIT App Inventor 2 не знадобиться:

1. Фонове зображення розміром 540х960 пікселів (розмір фонового зображення залежить від розміру екрана пристрою)

2. Іконка програми для головного екрану 128х128 пікселів (у форматі PNG32)

3. Іконки кнопок у додатку у двох кольорах, розміром 80х80 пікселів

Коли ми підготували всі необхідні зображення для програми, можна розпочинати роботу в MIT App Inventor 2. Для початку нам знадобляться такі компоненти:

ListPicker1 – для запуску Bluetooth підключення, вибору доступних Bluetooth пристроїв та режиму відображення стану підключення
Label3 – резервна для відображення додаткової інформації (тимчасово не працює, можна не додавати)
Label1 – для відображення отриманих даних з arduino
Label2 – для відображення напису (температура в кімнаті, температура на вулиці, тиск і т.д.)
HorizontalArrangement1 – режим вирівнювання елементів по горизонталі, у нашому випадку кнопок перемикання режимів)
Button1 – кнопка ввімкнення режиму “температура на вулиці”
Button2 – кнопка ввімкнення режиму “температура в кімнаті”
Button3 – кнопка включення режиму “тиск у мм.рт.ст.”
Button4 – кнопка включення режиму “вологість у %”
Button5 – кнопка відключення (невидима)
Clock1 – таймер
BluetoothClient1 – компонент для роботи з Bluetooth (отримання та надсилання даних)