I remember in one of the articles on App Inventor I wrote that there was an attempt to Russify it, but I didn’t really like it. I don’t even remember why. Meanwhile, Russification from App Inventor2 has disappeared.
But the world does not stand still and here again we have App Inventor in Russian. This happened thanks to the efforts of enthusiasts from "Learning with Google" community. Next I’ll try to figure out what happened, but now, first of all, applause for the enthusiasts! Well, simply because it turned out quite well, in my opinion, and the work was necessary in every way.
But, from enthusiasm to action.
You can switch to Russian in the language selection drop-down menu at the top right. 
Now what I liked:
Competent and pleasant translation into Russian of various menus on the “Designer” and “Blocks” desktops
This will immediately allow a person far from programming and the English language not to get lost. I myself am far from the first, and only a little closer to the second, so I like it, damn it! Although I’m already used to the English interface.
We click the question next to it in the “Palette” menu and what do we see?
Bah! Yes, this is a small hint, also translated into ours, the great and mighty. Great too! If I figured out a thing like a button without resorting to a dictionary, then, for example, to figure out sprites, I had to scratch my head. And here everything is on a silver platter.
Let's go further and look at the blocks. And here there is complete splendor and Russification. 
I admit honestly that I seem to have figured out the AI (well, okay, only part of it), but some blocks make me strain because, again, my English, alas, is lame. So App Inventor in Russian is here to help.
There is also an error index in App Inventor. And his guys didn’t ignore him.
In general, I repeat, I liked the Russification.
There are, of course, small mistakes: for example, some words are missing in the “Properties” of the components. 
But, by God, this is such a small thing!
Yes, here, the tooltips for the blocks are still in English. But their correct understanding is often lacking.
Now about whether I personally will switch to the Russified version. Most likely not, and here's why: the vast majority of programming languages use English. Hence the conclusion - anyone who wants to advance further in learning programming must work with the original language. And I want.
And the next argument: in the process of dealing with AI, I raised my level of English. And this is also very useful.
But! I will still turn to the Russian-language App Inventor, since not everything is always clear. And what’s more, you don’t always have the time and desire to learn a foreign language if you need to write yourself, say, an alarm clock application with your own features. And here App Inventor in Russian will help. What if you want to teach how to create mobile applications for kids who have just started learning English? Yes, with English-speaking AI you will only confuse their heads. After all, remember that this thing was created for training.
So, the work done deserves all the attention and respect. And, without a doubt, use.
It would also be nice for the guys to create a complete Russian textbook... Stop! Stop! What will I do then?
By operation we mean a sequence of actions, each of which can contain a different number of blocks.
Any operation can be placed either in an event processing block or in a procedure block. The location of the operation in the event processing block is simple, but in the future this can lead to many problems, in contrast to using it in a procedure, which will allow you to obtain a flexible algorithm. Let's consider this using the example of a simple assignment operation to a global variable of an empty list, consisting of two blocks (Fig. 1).
Rice. 1. Options for the location of the operation.
When an operation is placed in a component's event processing block (top option), it is tightly bound to it and becomes inaccessible for calling from other blocks. If this operation needs to be called from another block, it will have to be copied. It is not advisable to create copies of the operation, because if its algorithm changes, you will have to make changes to each of them. This increases the likelihood of various errors appearing: you can forget to correct some copy, make a mistake when copying blocks, pasting them, etc. Placing an operation in a procedure block will allow you to call it from other blocks and avoid the errors described above.
When working in the block editor, sometimes you need to call different versions of the same operation or different operations. To do this, you can either create new components with new event processing blocks, or use one existing btnExecute block, placing a call to a particular operation in it. As a result of the replacement, detached operations will turn into “floating” blocks (Fig. 2), which do not belong to any group block.
Rice. 2. "Floating" blocks.
If there are a lot of such floating blocks on the work field, then dealing with them may not be easy. If everything is clear with the bottom block - this is a procedure call block, then what does the concatenation of blocks do in the upper part of the picture? Is this a separate operation or an action that is or was included in some other operation? But then where is the rest of this operation? Adding an operation to a procedure block will allow you to get rid of strange “floating” blocks.
To execute a block, it is not necessary to place it in an event handler. You can right-click on it and select the Do it option in the context menu that appears.
Another disadvantage of placing an operation in an event handler is that if you accidentally delete a component in the designer, not only all blocks that belong to this component will be deleted, but also all blocks nested in them. It will be especially annoying if the operation consisted of a large number of blocks (Fig. 3). If you delete the btnTest component, the btnTest.Click block with all its contents will be deleted.
Rice. 3. Undesirable grouping of blocks in the event handler.
What operation do the blocks in this picture perform? It's difficult to answer right away. And when placing them in a separate procedure, everything will immediately become clear from its name setVarValue - sets the value of the variable (Fig. 4).
Rice. 4. Grouping the sides in the procedure.
Procedure and local variable blocks have settings available by clicking on the gear icon. For procedure blocks, it consists of adding input parameters to them, and for blocks of local variables, creating additional inputs. This will turn four blocks of variables into one block with four variables (Fig. 4). Is this conversion equivalent? No. A block with several local variables has a single scope, which prevents the values of its variables from being retrieved inside it. For example, it is impossible to assign the value variable (Fig. 4) to the key variable.
We list the shortcomings that we discovered in placing the operation in the event processing block:
- Rigid binding to an event block of a certain type of the selected component
- It is impossible to call an operation from other blocks (which means it cannot become a library operation)
- Delete operation when deleting a component
- Formation of strange “floating” groups of blocks
- It is difficult to quickly understand what the operation does
It is very easy to get rid of all these shortcomings if all operations are placed in procedures.
When creating algorithms for simplicity and speed, you want to put different operations into one procedure, which will lead to a rapid increase in the number of blocks and difficulties in understanding its operation. To eliminate this in programming, a simple rule is widely used:
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 and air conditioner turn on and the computer turns off. Will you like it? No, because it will lead to confusion and unpleasant situations.
In Fig. 4, at the beginning of the block, four procedures are called - getKey (get a key), getNewVal (get a new value), getKeys (get a list of keys) and getIndex (get an index). Each of these procedures performs one operation. After them comes an if block, in which one operation of the setVarValue1 procedure is executed.
Is it possible to use global variables instead of local variables in procedures? It's possible, but you shouldn't do it. The use of global variables inside a procedure, firstly, strictly binds it to them and, accordingly, to a given application, and, secondly, with the help of global variables, external blocks from different places in the application can influence the internal mechanism of the procedure, which is very undesirable. What might happen if bus passengers have access to its mechanism?
Local variables are a kind of buffer. If the name of a global variable changes, this will not disrupt the operation of the procedure, because the names of local variables that have not changed are used inside it. In App Inventor, when you change the name of a global variable, it will automatically change in all blocks that use it. This leads to an important conclusion that the automation existing in App Inventor for checking the correctness of variable types, renaming variables, etc., on the one hand, simplifies application development, freeing the developer from thinking about these issues, and, on the other hand, contributes to the development skill of careless compilation of algorithms. Generally speaking, this skill can be developed by programming in any language. How to avoid this? Use recommendations for creating “clean code”, about which many books have been written. MIT App Inventor will use only a small portion of these recommendations, but following them will improve the algorithms and their readability in any way they are created - on a piece of paper, on a whiteboard, when editing code, or working with blocks.
The above rule should also be used when using event processing blocks. In Fig. 4, the Click event handler performs only one operation - it calls a procedure. What if you need to call several procedures from an event handler? Then you need to understand whether this group of procedures performs one or more operations? If there is only one, then everything is fine. For example, when an application is initialized, many procedures are called, but they are all united by one operation - initialization.
The more operations a procedure performs, the closer its connection to a given project, and the more difficult it is to adapt it to work in another application. Ideally, it is advisable to make a general-purpose procedure independent of a given application so that you can put it in your library for reuse in other applications.
You can use unused application screens as storage for library procedures in App Inventor. Libraries with a small number of procedures can be placed together on one screen, and large ones - on separate ones. In the latter case, moving all the library blocks into the backpack can be done using a single operation.
If you have accumulated a lot of libraries, you can arrange them in the form of an application template, in which the first screen is left blank. We use this template when creating a new application, and after it is ready, we create a copy from which all library screens are deleted.
To avoid renaming global variables and disrupting the operation of library procedures when copying them from the backpack to the application screen, which may have global variables with the same names, it is necessary to compose the names of library blocks in advance with prefixes pointing to the library. If the library for working with a list of pairs is called libPairs. Then you can name the variables, procedures and components in it like this: libPairs_name, libPairs_setValue, libPairs_btnExecute.
For more convenient work with a large number of blocks and moving them around the workspace, in addition to the zoom buttons on the viewing area, it is also useful to zoom the browser’s workspace using the Ctrl- or Ctrl+ key combination.
Installing the Windows software for App Inventor Setup has two parts:
- Installing the App Inventor Setup software package. This step is the same for all Android devices, and the same for Windows XP, Vista, Windows 7, 8.1, and 10.
- If you choose to use the USB cable to connect to a device, then you"ll need to install Windows drivers for your Android phone.
NOTE: App Inventor 2 does not work with Internet Explorer. For Windows users, we recommend using either Chrome or Firefox as your browser for use with App Inventor.
Installing the App Inventor Setup software package
You must perform the installation from an account that has administrator privileges. Installing via a non-administrator account is currently not supported.
If you have installed a previous version of the App Inventor 2 setup tools, you will need to uninstall them before installing the latest version. Follow the instructions at How to Update the App Inventor Setup Software.
Locating the Setup software
In most cases, App Inventor should be able to locate the Setup software on its own. But if it asks for the location of the software, the path to enter is C:\Program Files\Appinventor\commands-for-Appinventor. If you are using a 64-bit machine ((How to tell if you"re on 64-bit Windows) , you should type Program Files (x86) rather than Program Files. Also, if you did not install the software as an administrator , it was installed in your local directory rather than in C:\Program Files. You"ll need to search for it to find the correct pathname.
Today in the labor market we are seeing a real boom for specialists in the field of application development for mobile devices. The profession of mobile application developer is becoming one of the most in demand. But is the education system ready to respond to this challenge? After all, in order to diagnose programming abilities and lay a solid foundation of knowledge and skills in time, you need to start from early school age.
Until recently, the problem of teaching programming to middle school students seemed insoluble - primarily due to the lack of a tool that, on the one hand, would be fairly easy to learn, and on the other, would allow one to create truly worthwhile products. Attempts to universally teach schoolchildren BASIC or Pascal only led to the fact that the subject “computer science” was tough for only a very narrow circle of students - those who, due to intellectual characteristics, family upbringing, or extreme luck with a teacher, managed to advance further in mastering programming than others . For most other schoolchildren, computer science remained something inaccessible.
The situation began to change in the early 2000s, with the emergence and development of visual programming languages, the flagship of which is the Scratch language. This language has made a real revolution in school teaching of programming for desktop operating systems. Programming in Scratch is as easy as putting together a children's puzzle. The language's statements and procedures are represented by colored blocks. By dragging and connecting them, we create programs. It is simply impossible to make a mistake in the syntax of this language - if the blocks do not fit side by side, the puzzle simply will not come together.
App Inventor
A natural extension of this approach was the App Inventor programming language, developed by Massachusetts Institute of Technology (MIT) professor Hal Abelson in 2010. It is based on the same principle of dragging visual bricks and assembling a program from blocks.
The difference between App Inventor and Scratch is that App Inventor is not focused on desktop use, but is intended for creating applications for a mobile device - a smartphone or tablet running Android OS. He can, for example, “understand” the accelerometer data of a mobile gadget, control the built-in camera, see how the phone is oriented in space, and much more.
App Inventor is a completely cloud-based application. To start programming on it, you only need the Internet and a browser. You can go to the language page using this link. Interface in English and Russian.
The MIT App Inventor programming language interface consists of two main parts - designer And block editor.
IN designer We construct our application from elements - screens, buttons, cells, images, sounds.
IN block editor we program the behavior of these elements.
The App Inventor interface is simple and intuitive. If you want to try teaching programming using App Inventor at school, we recommend the website appinvent.ru, which contains training materials for teachers.
Competition for schoolchildren
And schoolchildren who have been trained in programming using App Inventor at school or on their own can take part in a competition to develop their own mobile applications using App Inventor. The winner of the competition will receive a tablet computer from Samsung. The deadline for submitting works is May 15, 2016.
Loading...
