There is no problem with using App Inventor to write your own apps and share them with others. The problem is that App Inventor makes it easy to write any app – and malware authors have begun to use App Inventor to create apps that are malware and might do bad things.
“App Inventor doesn’t give malicious apps any special powers nor access to exotic exploits to attack your phone. But it does make the production of Trojanized apps enormously easy. With only a basic understanding of Android programming, an attacker can churn out tons of malicious apps. More apps means more confusion, and more opportunities for attack.”
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.
Yesterday, a WordPress plug in ran “amok” and used up all available system memory, causing this and all of my other web sites to become “unavailable” between about 2130 UTC and 0000 UTC. You would have seen a “503 Service Unavailable” error when accessing any of the web sites.
I had to remove plug ins one by one from each of my web sites until finding the errant plug in. Then I disabled WordPress until the process was suspended and then restarted WordPress.
At the recommendation of my ISP, I installed a WordPress Cache plug-in which temporarily stores accessed pages as HTML static web pages, which load very fast – versus being generated by the WordPress software and database each time the page is loaded. This, however, coupled with another small change, broke https security giving a “page is not secure” error, and display formatting errors in Firefox. I believe I have that fixed today.
NOTE: You can access this web site as https://appinventor.pevest.com or https://coldstreams.com/appinventor
If you access via appinventor.pevest.com , I have configured the web server to change the URL over to https://coldstreams.com/appinventor
For some reason, the appinventor.pevest.com/URL form is not working to correctly redirect to the sub URL part of the path. Since I did not see what is causing this problem, the simplest fix for now was to point to the coldstreams.com/appinventor folder, which is where the web site’s WordPress installation exists.
MIT has announced that the App Inventor for iOS (Apple iPhone and iPad) has entered beta testing. The Beta test program is currently limited, but is expected to expand in the summer, with a public release next summer.
This web site – appinventor.pevest.com – is no longer the primary web site for our App Inventor tutorials. However, this web site will remain here indefinitely as many people link to it, including search engines and my own e-books 🙂
The new, short and easy to remember URL is Learn2C.org as in “Learn 2 Code”
Unfortunately, for reasons I will not get into, it is not possible to integrate the two web sites together. So appinventor.pevest.com will remain “as is”, and Learn2C.org will become the primary focus point.
I am looking into having Learn2C automatically cross post to the appinventor.pevest.com web site but that has not yet implemented. But I’d like to do that for those that already follow the appinventor.pevest.com web site.
My apologies for not doing a lot of updates during 2018. I have already written some new code examples (Bluetooth LE anyone?) and am working on more in that area. These tutorials will appear once I have completed the entire series of example programs. There are also other items in the works that I cannot talk about yet.
Google created a cloud-based data base system called Fusion Tables. Later, support for Fusion Tables was added to App Inventor.
If you have used Fusion Tables, you will need to update the code to use a new data base system. You might also consider third-party App Inventor-based development systems such as Appy Builder.
Google has sent out an email advising Fusion Tables users that they will be discontinuing Fusion Tables – literally, the database service will go away on 3 December 2019.
Unfortunately, there is not yet a great alternative database for App Inventor apps other than to switch to Appy Builder.
Google Fusion Tables was launched almost nine years ago as a research project in Google Labs, later evolving into an experimental product. For a long time, it was one of the few free tools for easily visualizing large datasets, especially on a map. Since then, Google has developed several alternatives, providing deeper experiences in more specialized domains.
Here are some next steps to consider:
Learn about alternative tools
Several new Google tools have been developed over the years, and we encourage you to visit the Help Center to learn which ones fit your use-case.
Teams at Google have developed internal tools that can create powerful map visualizations. We are working to make some of these tools publicly available and will have more to share in the coming months—sign up to stay in touch.
Download your data
Filter by “type:table” to pull up a list of your tables in Google Drive. Download data from an individual table by following these instructions. If you have a lot of tables, we will make it easy to download all your data in one step via Google Takeout starting in March 2019.
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.
There are many surveys of programming language popularity. Many of the popular surveys have problems with the survey methodology such that they likely produce erroneous estimates of programming language popularity. For example, one survey looks at how many times each programming language is looked up on Internet search systems.
Python has become a standard for use by non-computer science students. Whether your college studies be in mechanical engineering or geology, there is a good chance you will learn Python for data analysis projects.
Java is now an old programming language, but still used especially for Android programming. It’s popularity for desktop applications is starting to diminish.
Ruby become popular about ten years ago. Ruby is based on a concept of “frameworks” that provide pre-made program skeletons which you adapt to make your own application. Ruby is very popular for quickly creating web-based applications.
PHP pre-dates Ruby – PHP is a script language that runs on the server side of a web application. PHP is very easy to learn and couples easily with MySQL databases, making the combination a great solution for web-based, database-backed applications.
Finally we get to the “C” derived languages including C, C++ and Microsoft’s cousin C# (a very powerful language with great development tools.). C dates back to about 1970 or so.
C++ was developed in the 1980s and added object oriented programming to C and has since expanded in many ways. C and C++ are commonly “compiled” into machine instructions for each CPU and are used for high performance applications, including operating systems, video games and media applications.
C# has features resembling Java and C++ – but in a more modern design. In some ways, C# is where some wish C++ had gone