Збільшити вбудовану функціональність 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.
Спробуйте змінити напис, скомпілювати, встановити та виконати блок. Якщо все вийшло, то робоче середовище налаштоване і можна йти далі для створення більш практичних та цікавих речей.
MIT App Inventor 2- середовище візуальної розробки, що дозволяє легко створити програму для Android пристроївнавіть не володіючи знаннями в галузі програмування.
Працює це середовище розробки безпосередньо з браузера. Завантажувати та встановлювати нічого не потрібно. Отриманий результат можна переглядати на Android-пристрої. Готові програми можна розміщувати в Play Market. App Inventor 2 підтримує російську мову.
Відразу, при старті, з'являється можливість створити свій унікальний додаток, наприклад, додаток який може керувати іншими bluetooth-пристроями (Проста Bluetooth машинка на Arduino), ну або гру на смартфон.
У онлайн редакторі MIT App Inventor 2 додатки будуються на базі стандартних компонентів, які є основним елементом розробки додатків Android. В інтернеті наведено багато прикладів, як використовувати комбінацію блоків, компонентів, щоб вийти той додаток, який ми хочемо зробити.
Вікно конструктора
У цьому вікні налаштовується як виглядатиме програма (які елементи відображатимуться на екрані тощо). Подивившись на вікно конструктора, ви побачите, що воно складається з декількох областей:
- palette (палітра) - область, де показані доступні компоненти. Палітра поділено на секції.
- viewer (перегляд) - область, куди додаються компоненти і де ви працюєте з ними. У цій області можна подивитися, як ваш додаток буде виглядати на вашому смартфоні.
- components (компоненти) - область, де показуються використовувані компоненти. Компоненти в цій галузі можна перейменовувати або видаляти, також зручна для їх редагування за допомогою Properties.
- media (медіа) -область куди завантажуються використовувані картинки та аудіо.
- properties (властивості) - область де редагуються властивості компонентів: колір, розмір тексту, шрифт та інше.
Вікно редактора блоків
У цьому вікні ми налаштовуємо поведінку нашого смартфона при дії на нього будь-яких зовнішніх факторів. Наприклад, при натисканні на клавішу на екрані смартфона подається сигнал вітання або при зміні стану датчиків (акселерометра, датчика наближення тощо) згасає екран смартфона для економії енергії акумуляторної батареї.
Під операцією ми розумітимемо послідовність дій, кожна з яких може містити різну кількість блоків.
Будь-яку операцію можна помістити або блок обробки події, або блок процедури. Розташування операції у блоці обробки події характеризується простий, але у майбутньому це може призвести до багатьох проблем, на відміну використання їх у процедурі, що дозволить отримати гнучкий алгоритм. Розглянемо це з прикладу простий операції присвоєння глобальної змінної порожнього списку, що з двох блоків (рис. 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+.
Сьогодні на ринку праці ми спостерігаємо справжній бум на фахівців у галузі розробки програм для мобільних пристроїв. Професія розробника мобільних додатків стає однією з найбільш популярних. Але чи готова система освіти відповісти на цей виклик? Адже щоб діагностувати здібності до програмування та вчасно закласти міцний фундамент із знань та навичок, починати потрібно вже з раннього шкільного віку.
Донедавна проблема навчання школярів середніх класів програмуванню здавалася нерозв'язною - передусім через відсутність інструменту, який, з одного боку, був би досить простий у освоєнні, а з іншого - дозволяв би створювати справді продукти, що стоять. Спроби поголовно навчати школярів Бейсику чи Паскалю призводили лише до того, що предмет «інформатика» виявлявся по зубах лише дуже вузькому колу учнів - тим, кому з інтелектуальних особливостей, сімейного виховання чи надзвичайного везіння з учителем вдавалося просунутися в освоєнні програмування далі, ніж іншим . Більшість інших школярів інформатика і залишалася чимось недоступним.
Ситуація почала змінюватись на початку 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 року.
Почати хочеться з того, що на habrahabr і geektimes є кілька статей про попередньої версії App Inventor. Ось вони:
MIT відкрив Google App Inventor у бета-версії
App Inventor - створення Android-додатків для кожного: Урок 1
Читання файлу XML за допомогою App Inventor
Ця версія App Inventor (beta) пропрацювала з 2011 до 2015 року, але зараз її підтримка припинена. З 2014 року працює версія App Inventor 2, яка несумісна з попередньою. До 2011 року існувала версія Google App Inventor у рамках Google Labs
Отже, App Inventor – середовище візуальної розробки android-додатків, що вимагає від користувача мінімальних знань програмування. Виглядає вона так: 
Працює це середовище розробки безпосередньо з браузера. Завантажувати та встановлювати нічого не потрібно. Створювати програми можна хоч з android-планшета, хоч із Ipad. Основна вимога до «заліза» це гарний дозвілекран. Для прикладу наведу скріншот з екрана роздільної здатності FullHD. Можна порівняти його з попереднім, зробленим з HD екрану. 
Готові програми можна розміщувати в Play Market, наприклад наведу обліковий запис розробника , в якому всі програми зроблені в App inventor.
Детально описувати MIT App inventor 2 не буду, оскільки від попередньої версії він відрізняється переважно безліччю дрібних удосконалень, які виходять в середньому раз на кілька тижнів. Прочитавши статті, вказані вище, можна легко освоїти поточну версію.
У вконтакті є досить живе спільнота, де учасники діляться один з одним досвідом використання App Inventor.
Частина 2. App Inventor+Arduino проекти.
Останнім часом бурхливо розвивається тема «інтернету речей». У багатьох проектах на цю тему використовується Ардуїно. Іноді в таких проектах потрібно створити android-додаток, тут може знадобитися App Inventor 2. На habrahabr і geektimes є кілька статей на цю тему.
1. App Inventor+Arduino проекти з використанням блютуз-з'єднання. (Блютуз модуль HC-05\06\07)
Робот-пилосос на ардуїно
Проста Bluetooth машинка на Arduino
Bluetooth пульт для телевізора на arduino
2. App Inventor+Arduino проект із використанням wi-fi з'єднання.(wi-fi модуль ESP8266)
Інтернет Речів (IoT) та водопровід
3.App Inventor+Arduino проект з використанням проводового з'єднання (Ethernet модуль Enc28j60)
Управління гучністю багатозонного підсилювача за допомогою програми для Android та Arduino
4.App Inventor+Arduino проект з використанням GPRS/GSM з'єднання (GPRS/GSM шилд SIM900)
Управління опаленням у заміському будинку
Ну і закінчити хотілося б позитивною новиною, що з серпня 2015 App Inventor 2 підтримує російську мову. Якщо у когось є свої цікаві програми, зроблені в цьому середовищі розробки, можна скидати в коментарі, думаю багатьом буде цікаво подивитися які ще можна робити програми, використовуючи App Inventor.
P.S. Збірник з понад 100 навчальних матеріалів по ардуїно для початківців та профі
P.P.S. Онлайн курспо ардуїно на гіктаймс