Way back in my college days, we learned to program in everything from assembly language up through “high level” programming languages. Some of us even learned to enter boot strap code using front panel switches to enter machine code as bit patterns on a console!
Today, programming is simplified – tools like App Inventor illustrate this by using “drag and drop” programming methods, assembling programs from components, rather than typing in programing instructions.
Low Code does not necessarily divorce oneself from understanding programming concepts – but it enables the rapid construction of many functions – from user interfaces to underlying algorithms.
AI-based systems introduce a new level of automated code assembly. Go to Chat GPT, for example, and ask it to implement a sorting algorithm in Python – and sure enough, it will generates the source code in Python.
Two or three decades ago, the typical output of a software developer was likely to be a few hundred lines of code per day (at best, after integration, testing, and future modifications before final ship). New tools likely increase this by an order of magnitude or more!a
App Inventor is a “low code”, visual software development tool. Such “drag and drop” programming tools enable non-programmers (and programmers) to create many types of applications without the details of traditional programming code.
This leads to an important issue – will less trained/less experienced programmers inadvertently introduce security problems in their applications?
Gartner predicts that by the end of 2025, over 65% of development projects will use low-code builders. The field of low-code continues to expand. But what security implications does low-code introduce? Low-code refers to tools that enable application construction using visual programming models. Adopting drag-and-drop components instead of traditional code, no-code and low-code platforms enables non-technical folks to construct their own workflows without as much help from IT. Yet, handing power to citizen developers with less security training can be risky. Plus, low-code platforms may hold compromised propriety libraries or leverage APIs that may unknowingly expose sensitive data to the outside world. There’s also the possibility that low-code could increase shadow IT if not governed well.
A reader asked a question about how square roots can be calculated, referring to an example in my Volume 1 Introduction to App Inventor e-book. He was confused by the explanation of how it works – so I have written an expanded explanation of the method for calculating a square root of a number.
You could use the built in Math function to find the square root of a number – and generally that is what you should do. But if you would like to learn a method of calculating the square root of a number – then read on!
2,000 years ago, Greek mathematicians identified a method of finding approximate square roots. The method makes an initial guess of a square root (which is often not even close to the right value) and then repeats a sequence of dividing and averaging which gradually refines the initial guess into an accurate square root. To find the square root of some number n, we set our initial guess to n (which we know is not correct), and then calculate an average of our guess with n divided by our guess.
To find the square root of 30, we initially guess the square root is 30 (which we know is wrong). We then take 30 and divide it by our guess, which in this case is 30. This gives us a value of 1. The average of our original number 30 and our divided value is 15.5. We select 15.5 as our new guess.
This little spreadsheet may help understand how the square root concept works.
To find the square root of 30, we initially guess the square root is 30 (which we know is wrong). We then take 30 and divide it by our initial guess, which is 30. This gives a value of 1. The average of our original number 30 and 1 is 15.5. We select 15.5 as our new guess on the next row down in the Guess column.
Then we repeat this and take 30 divided by our new guess of 15.5. This gives us 1.93548. We average our 15.5 guess with our new value of 1.9458 giving us 8.717, which becomes our new guess on the next row down.
We repeat again using 8.717 as our new guess and divide 30 by 8.717, giving us 3.44. We average the 8.717 with 3.44 giving us 6.0795, use that as our next guess.
When do we stop this repeating cycle? We could repeat this a set number of times, say six, and then stop. But a better solution is to specify how many digits of accuracy we would like to have in our answer.
Let’s say that 5.4 is accurate enough for our purposes. We could stop as soon as our new guess is within 0.1 of our prior guess. In our spreadsheet above, our generated guesses are:
As you can see, the correct answer has converged to 5.477 rather quickly. If we wanted an accuracy of just 1 digit to the right of the decimal point, we can stop once the difference between the current and previous guess is 0.1
The first digits of the last two guesses are the same 5.4 so we could stop with an accuracy of .1. In this particular calculation, we see that we are accurate to the thousandth’s place 5.477 as these values are no longer changing.
We stop the cycle when the difference between guesses becomes very small.
With our definition of small to 0.1, we stop at 5.4. If we set our definition of small difference to 0.001, then we stop at 5.477.
Here is some sample App Inventor code that calculates the square root. It fetches the number for which we find the square root from a user interface Text Box named txtDataEntry. We set NewValue (our initial guess) to this value. Then the code uses a while test loop to repeatedly do the calculation while the difference between our new guess and our previous guess is greater than 0.1 (you can change this to smaller values for greater accuracy).
This square root calculation repeats as long as the difference between our NewValue and OldValue are large.
As long as the difference remains large, the while test condition is “true”, and the code inside the while block continues to execute. However, once the difference becomes small, the test condition evaluates to “false” and the the execution of the “do” section stops. We have found our approximate square root.
App Inventor programmers routinely store values, such as numbers or text strings (“Hello!”) in variables. For example,
stores the numeric value 6 in to the variable TOTALBUTTONS.
To illustrate by example, here is a global variable named SpecialButton. We can initialize it to anything we want at this point.
Next, inside our app, our blocks code assigns Button1 to the variable SpecialButton. SpecialButton now holds a reference to the actual user interface control Button1.
Since SpecialButton is a variable and not an actual button, we cannot directly use a SpecialButton.Click handler but we can use a feature of App Inventor to do the same thing in a different way. We will see how to do this in this a bit later.
You can store any App Inventor components – a Clock, a Bluetooth device – any component, in a variable.
Why would you want to do that? We will see in the example in this lesson.
This tutorial is in both written form and as an online video.
This tutorial shows how an App Inventor app can communicate with 2 (or more) Arduino boards and Bluetooth devices simultaneously. These instructions assume you are familiar with the code and hardware presented in Part 1 and Part 2 and “How to connect App Inventor apps to Arduino using Bluetooth“. This tutorial uses the same Arduino source code as in that tutorial.
A follow up tutorial will show how to simplify some of this code for supporting multiple Bluetooth devices.
Bluetooth is a short range, low power, limited speed wireless communications technology. The original Bluetooth technology provided a serial communications link between two paired devices (as compared to an individual data packet sent between up to n devices using the much newer Bluetooth LE – see here and here for information on Bluetooth LE).
Arduino is a microcontroller board for building hardware projects. You can write software for Arduino using a programming language similar to the C++ programming language.
The code used in these examples has been tested with some specific Bluetooth modules connected to Arduino. These include the JY-MCU (Amazon (Prime), Amazon (non-Prime) and also some HC-05 and HC-06 based Bluetooth modules.
Build two Arduino boards each with an appropriate Bluetooth module as described in the prior tutorial.
Compile and load the Arduino software in to each of the Arduino boards.
Test and confirm that your basic LED lights flash for the original, single Bluetooth connection case.
Then, with two working boards, continue to this tutorial.
User Interface View
The original app supported just one device, so there was just a single “Connect” and “Disconnect” button. This version demonstrates how to connect more than one Bluetooth device so we need separate buttons for each device. Similarly, we must add a second status and data sending item to the screen:
Before running this app, be sure to use Android | Settings | Bluetooth to “pair” your Bluetooth devices with Android.
Then, run the app and select Connect to Device 1. This displays a list of available Bluetooth devices in the vicinity. Select your specific Bluetooth device for the connection. Do this for both Bluetooth devices.
Once connected, you can send some simple commands to the Arduino board. Commands are very simple – a single number – to tell the Arduino to do something (this confirms that the Bluetooth link is working). If we enter a single digit 1 and then press Send Numeric 1, the Arduino board will send back 2 bytes of data which will then be displayed on the app screen. If we enter a single digit 4 and then press Send Numeric 1, a value of 4 is transmitted over Bluetooth to the Arduino board, which responds by flashing the externally connected LED.
Because the text box for data entry has its property set to NumbersOnly, a pop up numeric keypad displays when entering data, rather than the usual Android text keyboard.
Video Demonstration this App
I created a short video showing this app in operation. There are two versions of the video – one is standard 2D format and the other is in VR 3D format for viewing on Google Cardboard-like viewers used with smart phones to watch VR videos.
Our prior post showed how to use user interface button components to simulate a column chart.
We can apply the same trick to create a bar chart. In a bar chart, the data is represented as horizontal bars, whereas in the column chart, the data appears in vertical columns.
Implementing the bar chart requires just a few minimal changes to the original column chart app.
This screen shows the basic output, with the data represented as horizontal bars in the chart. To simplify, the slider control and column #6 that appeared in the original column chart version, have been removed.
A new feature has been added, as an example illustration. Since each bar in the chart is actually a button, you can press on the bar. For fun, a Click event handler has been added to bar #1 in the chart. Pressing bar #1 causes the bar to change to a randomly selected color. This feature has been implemented only for bar #1, but if you wish, you can add Click event handlers for the other buttons.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.