Mit App Inventor - Everyone can create a mobile application. App Inventor - Wednesday of Android Application Wednesday Download Education App Inventor in Russian

App Inventor - Wednesday of the visual development of Android applications, requiring the user minimal programming knowledge. Originally designed in Google Labs, after the closure of this laboratory was transferred to the Massachusetts Technological Institute. At the beginning march 2011. The Massachusetts Institute has launched a public beta version of the project available on the website app.Inventor.mit.edu.

It works this development environment directly from the browser. Download and install nothing. The result can be viewed on the Android device. Finished applications can be placed in Play Market.

August 2015 App Inventor 2 supports russian language.

In the online editor MIT App Inventor 2 applications are based on standard components that are the main element of the development of Android applications.

Blocks App Inventor. Important concepts and principles

The APP Inventor blocks are instruments for operating components and look like puzzles.

The blocks in this Android applications designer are divided into two large groups on the basis of which they affect and what are related to:

• relating directly to components
• applied to the application as a whole

Let's start by S. blocks that belong to components. They can be divided into three types that are easy to distinguish between:

1. Blocks describing the properties of the component. They are green and look like this:

this unit denotes the current component property. In this picture, the background color structure is shown for TextBox1 text component. It implies the receipt of the existing meaning.

and this sets the desired value of the component (assign TextBox1 background color ...). "SET" - set. This type of block-properties could be attributed to commanders (handlers), since it really gives the command to change any component property, including the fields of fields. However, the developers of the App Inventor decided so - yet it is also properties too.

2. Event blocks, that is, those blocks that track the occurrence of any event in the application, for example, pressing the button and then run the block command. They are painted in bronze color and look like this:

this unit, for example, performs an action by pressing the button (when on Button3 clicked to do ...)

3. Block-command, in the App Inventor This unit is often called the handler. This unit indicates that you need to do with the component to which the block belongs:

Specifically, this block causes data from the device timer.

Second group of blocks, related to all, Organized somewhat differently.

To begin with, here are their list subgroups:

• Logic Blocks. - logical blocks
• Math Blocks. - Mathematical blocks
• Text Blocks. - Text blocks
• Lists Blocks. - blocks to manage lists
• Colors Blocks. - Blocks for color management
• Variables Blocks. - blocks to manage variables
• Procedures Blocks. - Procedure blocks.

All of them, with the exception of Procedures Blocks, are embedded in other blocks. That is, they cannot serve as the original block, unlike the events belonging to components - all actions are made at any events with components.

Here it is worth telling about the types of "puzzles". So, you probably noticed that there are four species puzzles.

It is obvious from their shape that any chain in the mobile application begins first. This is an event and it is quite logical that it initiates all further actions. And this type does not differ from the applications adopted in this designer for Android.

And here is the following two types of blocks using the App Inventor typology refer to different types: properties and teams (handlers), respectively. But in the form of a puzzle and, in meaning, they could be attributed to teams, as they set the action. Let's say second Laid puzzle puzzle gives the command to assign a certain value to the component, but the third Puzzle - Call a component with a certain value. In addition, these puzzles are "intermediate", they can not be completed with a chain.

And here fourth The form represents the final value that exists or calculated and the chains end. For example, the fourth picture is the current value of the CLOCK component.

The company ITICHER announces a mobile application development contest for Android OS, created in the App Inventor Programming Language.

Terms of holding competition

• Reception and registration of competitive works: from January 1 to May 15, 2017.
• Consideration of the works of the competitive jury - from 15 to 30 May 2017.
• Announcement of the results of the competition on May 30 at the contest portal.

Under the operation, we will understand the sequence of actions, each of which may contain a different number of blocks.

Any operation can be placed either in the event processing unit or in the procedure unit. The location of the operation in the event processing unit is characterized by simple, but in the future this can lead to many problems, in contrast to using it in the procedure, which will get a flexible algorithm. Consider this on the example of a simple assignment operation of the global empty list variable consisting of two blocks (Fig. 1).

Fig. 1. Operation options.

When placing an operation in the processing unit of the component event (upper version), it is rigidly attached to it and becomes inaccessible to call from other blocks. If this operation must be called from another block, then it will have to be copied. Create copies of the operation is undesirable, because when it changes its algorithm, you will have to enter each of them. This increases the likelihood of different errors: you can forget to fix some kind of copy, make a mistake when copying blocks, insert them, etc. Placing the operation in the procedure unit will allow you to call it from other blocks and avoid the errors described above.

When working in the block editor, sometimes there is a need to call different versions of one operation or different operations. To do this, you can either create new components with new event handling units, or use one existing BTNexecute block by placing a call to this or that operation. As a result of the replacement, the disconnected operations will turn into "floating" blocks (Fig. 2), which do not belong to any group block.

Fig. 2. "Floating" blocks.

If there are many such floating blocks on the work field, it may not be easy to deal with them. If everything is clear with the bottom block - this is a block of calling a procedure, what makes the units of blocks at the top of the picture? Is this a separate operation or action that enters or was included in some other operation? But then where is the rest of this operation? Adding an operation to the procedure unit will allow you to get rid of incomprehensible "floating" blocks.

To execute the block, it is not necessary to place it in the event handler. You can right-click on it and in the context menu that appears, select the DO IT option.

Another disadvantage of the operation in the event handler is related to the fact that when accidentally deleting a component in the designer, not only all blocks that relate to this component, but also all blocks invested in them are deleted. Especially annoying will be in the event that the operation consisted of a large number of blocks (Fig. 3). If you delete the BTNTEST component, then the BTNTEST.Click block will be deleted with all its contents.

Fig. 3. Unwanted blocking of blocks in an event handler.

What operation perform blocks in this picture? It is difficult to answer right away. And when placing them in a separate procedure, everything will immediately become understandable from its name SETVARVALUE - sets the value of the variable (Fig. 4).

Fig. 4. Grouping of sides in the procedure.

Procedure blocks and local variables have a setup available when clicked on the gear icon. For the procedures blocks, it consists in adding input parameters to them, and for the blocks of local variables to the creation of additional inputs. This will allow four variables block to turn into one block with four variables (Fig. 4). Is such a conversion equivalent? Not. A block with multiple local variables has one scope that does not allow inside it to obtain the values \u200b\u200bof its variables. For example, the Value variable is impossible (Fig. 4) to assign the value of the KEY variable.

We list the disadvantages of the operation in the event processing unit:

• Hard binding to the event block of a certain type of selected component
• It is impossible to call the operation from other blocks (it means that it cannot become library)
• Removing the operation when removing the component
• The formation of incomprehensible "floating" block groups
• It's hard to quickly understand what the operation does

Get rid of all these drawbacks is very simple if all operations are placed in the procedure.

When creating algorithms for simplicity and speed, you want different operations to put in one procedure, which will lead to a rapid increase in the number of blocks and difficulties with understanding its work. To exclude this, a simple rule is widely used in programming:

One function (procedure) - one operation

This rule is taken from life practice. Imagine that you turn on the light in the room, and at the same time the TV is turned on, air conditioning and turning off the computer. Do you like it? No, because it will lead to confusion and unpleasant situations.
In fig. 4 At the beginning of the block, there is a challenge of four procedures - Getkey (get the key), GetNewVal (get a new value), GetKeys (get a key list) and GetIndex. Each of these procedures perform one operation. After them, the IF block is running, in which one SETVARVALUE1 procedure operation is executed.
Is it possible to use global in the procedures instead of local variables? You can, but do not do so. The use of global variables within the procedure, firstly, harshly binds it to them and, accordingly, to this application, and, secondly, with the help of global variables, external blocks from different applications can influence the internal mechanism of the procedure, which is quite undesirable. What can happen if the bus passengers have access to its mechanism?

Local variables are a kind of buffer. If the name of the global variable changes, this will not break the work of the procedure, because the names of local variables are used inside it, which have not changed. In the App Inventor when changing the name of the global variable, it will automatically change in all blocks using it. From here, an important conclusion that existing in the App Inventor automation to verify the correctness of variable types, renaming variables and otherwise, on the one hand, simplifies the development of applications, freeing the developer from thinking over these issues, and, on the other hand, promotes development Skill of negligent compilation of algorithms. Generally speaking, this skill can develop when programming in any language. How to avoid this? Use recommendations for creating a "clean code", which is written a lot of books. Mit App Inventor will be able to use only a small share of these recommendations, but following them will improve the algorithms and their readability with any way to create them - on a sheet of paper, board, when editing code or work with blocks.

The above rule should be used and in the case of using event processing units. In fig. 4 CLICK event handler produces only one operation - causes the procedure. And if you need to call several procedures from the event handler? Then you need to understand, this procedure group performs one or more operations? If one, then everything is in order. For example, under the initialization of the application, many procedures are called, but all of them are combined with one operation - initialization.

The more operations perform the procedure, the more closely its connection with this project is, and the more difficult it is to adapt it to work in another application. Ideally, the general purpose procedure is desirable to make an independent of this application so that it is possible to place it in its library for reuse in other applications.

As a repository of library procedures in the App Inventor, you can use the appropriate application screens. Libraries with a small number of procedures can be placed together on one screen, and large ones on individual. In the latter case, the movement of all library blocks in the backpack can be performed using one operation.

If the libraries have accumulated a lot, then you can arrange them as an application template in which the first screen is empty. We use this template when creating a new application, and after its readiness, create a copy from which all library screens are deleted.

To eliminate the renaming of global variables and violating the work of library procedures when copying them from a backpack to an application screen that can have global variables with the same names, the names of library blocks are needed in advance with prefixes indicating the library. If the library for working with a list of couples is called libpairs. Then you can variables, procedures and components in it so: libpairs_name, libpairs_setvalue, libpairs_btnexecute.

For more convenient operation with a large number of blocks and moving them through the working field, in addition to the scaling buttons on the viewport, it is useful to scale the browser's working area using the Ctrl-or Ctrl + key combination.

Today, in the labor market, we are seeing a real boom on specialists in the development of application applications for mobile devices. The profession of mobile application developer becomes one of the most sought-after. But is the education system ready to answer this challenge? After all, in order to diagnose the ability to programming and lay a solid foundation from knowledge and skills in time, you need to start from early school age.

Until recently, the problem of learning middle-class schoolchildren programming seemed intractable - primarily due to the lack of a tool, which, on the one hand, would be enough easy to learn, and on the other, it would allow to create really standing products. Attempts to train schoolchildren by Basica or Pascal, only led to the fact that the informatics object was only a very narrow circle of students - those who, due to intellectual features, family education or emergency luck with the teacher, managed to advance in the development of programming further than others . For most other schoolchildren, informatics remained something inaccessible.

The situation began to change in the early 2000s, with the emergence and development of visual programming languages, whose flagship is considered to be the SCRATCH language. This language made a real revolution in school teaching programming for desktop OS. Programming on scratch is as easy as folding children's mosaic-puzzle. Operators and language procedures are colored blocks. Dragging and connecting them, we create a program. It's simply impossible to make an error in the syntax of this language - if the blocks do not stand next to, the puzzle simply does not work out.

App Inventor

The natural development of this approach was the programming language of the App Inventor, developed by Professor Massachusetts Institute of Technology (MIT) Halome Abelson in 2010. It is based on the same principle of dragging the visual bricks and collecting the program from blocks.

The difference between the App Inventor from SCRATCH is that App Inventor is not oriented to desktop use, but is intended to create applications for a mobile device - a smartphone or tablet with Android OS. He knows how, for example, "understand" the data accelerometer data of the mobile gadget, control the built-in camera, sees how the phone is oriented in space and much more.

App Inventor is a completely cloudy application. To start programming on it, you only need the Internet and browser. The transition to the language page is carried out at this link. Interface in English and Russian.

Mit App Inventor Programming Language Interface consists of two main parts - designer and editor Blokov.

IN designer We construct our application from elements - screens, buttons, cells, images, sounds.

IN editor Blokov We program the behavior of these elements.

The App Inventor interface is simple and intuitive. If you want to try to teach programming on the App Inventor at school, we recommend the website app enterpriment.ru, which collected training materials for teachers.

Competition for schoolchildren

And schoolchildren who will be held on the programming programming on the App Inventor at school or inexpensively can take part in the competition for developing their own mobile applications on the App Inventor. The winner of the competition will receive a tablet computer from Samsung. The deadline for submission of work - until May 15, 2016.

Weather Station in Mit App Inventor 2 - Weather Station App for Android Phones Created using online service.

Announcement of the weather station is described in the article where we have made a review of the weather station, created the Skatch for Arduino and the device of the weather station. Well, today we will understand in more detail how to create an Android application and display all the data obtained from our weather station on the phone.

To create an application Weather station in Mit App Inventor 2, you will need:

1. The background image of the size of 540x960 pixels (the size of the background image depends on the size of the screen of your device)

2. Application icon for the main screen 128x128 pixels (in PNG32 format)

3. Buttons icons in the application in two colors, the size of 80x80 pixels

When we have prepared all the necessary images for the application, you can start working in Mit App Inventor 2. To begin with, we will require such components:

• ListPicker1 - To start the Bluetooth connection, select the available Bluetooth devices and the connection status display mode
• Label3 - Backup, to display additional information (temporarily does not work, you can not add)
• Label1 - To display the received data from Arduino
• Label2 - To display the inscription (temperature in the room, the temperature in the street, pressure, etc.)
• HorizontAlarRangement1 - Alignment mode of elements horizontally, in our cases of switching modes)
• Button1 - button for switching on the mode "Outdoor temperature"
• Button2 - Turning on the temperature in the room mode
• Button3 - button for switching on the mode "Pressure in mm.rt.st."
• Button4 - button inclusion mode "Humidity in%"
• Button5 - Disconnection Button (Invisible)
• Clock1 - Timer
• BluetoothClient1 - Component for working with Bluetooth (receiving and sending data)

Now let's go to block programming mode in Mit App Inventor 2 to start proposing functionality for Listpicker

then for timer

to receive data via Bluetooth

for buttons 1-4

for shutdown button

After all the stages of development passed, we test the application on the phone, and check the performance.

You can enlarge the built-in functionality of the App Inventor using Web technology and extensions. On the network you can find paid and free extensions (about 200 about Puravidaapps.com), but questions arise, and how difficult it is to create your own, what can they give and whether to spend time on this or better do something else?

All components and blocks available in the App Inventor belong to the built-in (internal), and expansion to external.

Built-in features provide interesting functionality for novice users, satisfactory for experienced and insufficient for programmers. At the same time, most users will prefer to load ready-made extensions, and not develop them. From this it follows a simple conclusion that the development of extensions may be interesting, mainly experienced users and enthusiasts. Beginners will fully arrange built-in capabilities and existing extensions, and programmers engage in extensions are not interested in the reason for the need to perform dual work. Why waste time on creating and debugging the expansion of limited functionality, and then using it to create a limited functionality application, if you can immediately write code on Java, using all the available features of Android Studio IDE and Android API?

Create extensions for AI is easy if there is some kind of programming experience and understanding the foundations of the OOP, but at the above reasons, units are seriously engaged. Create functional extensions is impractical, but writing simple additions to expand the built-in functionality or creating a new one may seem interesting and useful in terms of practice. But here you need to decide on the approach. You can either follow the concept of AI - visual programming, or to expand its text programming items.

If you say rudely, then App Inventor is similar to Iceberg, the top of which is visible to users in the form of built-in functionality, and in the water is also unavailable much most. This is done specifically in accordance with the purpose of this IDE, requiring users of minimal programming knowledge. The model of work in the App Inventor is not initially designed for greater functionality. Adding new properties will cause an increase in the number of blocks in geometric progression. For example, adding the transparency property will lead to the appearance of two blocks for each widget (to install and return the value). If such widgets 5, the number of blocks will increase by 10. Added 10 properties, 100 blocks received at the output. Additionally, new properties in the designer will appear to this. Under these conditions, the approach "simple IDE + expansion" looks reasonable, but not for those who prefer good functionality "of the box" without the need to search and install additions.

Individual setup properties of objects and task of the hard blocks of blocks at the application development phase, on the one hand, simplifies the development and avoids a large number of errors, but leads to static applications. If another block is attached to one block, then this is forever. Change property or select another object At the execution stage, it is possible only if this feature was initially laid at the development phase. To do this, use indirect access to objects. For example, you can create a list of pairs "object name - object" for all objects, and then use it in features to access different objects. In this case, the receiving unit will not be associated with a specific object, but with a list from which you need to get on its key-name.

If the above add complexity with the implementation of group operations, the lack of widgets, methods and other nuances of the built-in functionality is clear, the reason for the appearance of AppYBuilder, Thunkable, Makeroid, and others, in which the increase in functionality is implemented due to the number of components will be understood. More components - more blocks. But with the help of expansion, it is possible to increase the functionality in a qualitative way, for example, to use one block to access dozens of dozen properties of objects. This is already really interesting because it complements the visual programming of textual textual elements to compensate for a number of shortcomings of the built-in AI functionality.

Will the extensions be able to create extensions who are weakly familiar with programming? Yes, simple will be able to use the "Copy and Change" approach, but certain preparation is still required. Without it, it will be incomprehensible why the extension is not compiled and what is written on the screen. It should also be said that a part of the expansion working with Android objects is preferred to create and debug in Android Studio.

The development of extensions will suit those whom, in principle, suits the App Inventor, but I would like to supplement something, improve and simplify, and at the same time practicing Java. If this is your case, we'll start with the deployment of the development environment.

Vkontakte has a group Extensions for App Inventor where the video and text form gives a step-by-step guide to create and configure the working environment, as well as a simple example that returns the word TEST. Duplicate this material does not make sense, but the example of the example will consider as fast introduction to the topic.

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 \u003d YaVersion.NOTIFIER_COMPONENT_VERSION, category \u003d ComponentCategory.EXTENSION, description \u003d "This is a test extension", nonVisible \u003d true, iconName \u003d "images / notifier.png") @SimpleObject (external \u003d true) public final class TestExtension Extends AndroidNonvisibleComponent Implements ComponentContainer (Super (Super (Container. $ Form ());) @SimpleFunction (Description \u003d "This Function Returns The \\" Test \\ "String") Public String Test () (Return "Test ";))

The extension code includes a Java class and annotation code, starting with the @ symbol. Annotations are used to indicate that the code block under them must be processed by a simple compiler. A simple compiler scans annotations and integrates an extension on the Application Wednesday App Inventor - creates a block (function or properties) function, the edit field in the designer and performs another job.

@DesignerComponent indicates the general parameters of the component and what it refers to the category of extensions and is not univocal (currently you can create only non-invalid extension components)

@SimpleObject points to a component, and the External \u003d True field is that the component is external

@SimpleFunction indicates the compiler feature for which you need to create a block. If the function returns a value, the exhaust will appear in its left. If the function has parameters, the corresponding excavations will be on the right side.

The source codes of classes can be viewed in the directors corresponding to the package names:

cOM / Google / Appinventor / Components / Runtime - Building Classes.
COM / Google / Appinventor / Components / Annotations - Classes Annotations
Com / Google / AppInventor / Components / Common - General Use Classes
COM / Google / Appinventor / Components / Runtime / Util - Classes utilities

Currently, using the extension, you can create only an invisible component. If you need to create a visual component, dragging to the designer's working field, as well as the designed widgets, then it will take its own local copy of the App Inventor.

Try changing the inscription, compile, install and execute the block. If everything happens, the working environment is configured and you can go on to create more practical and interesting things.