Sorry for the lack of updates and posts to this web site. I have had a lot going on – and right now, we are in process of moving across the state. Eventually things will be settled down. I completed several interesting App Inventor projects but have lacked time to get them posted here. Hang in there – I intend to be back!
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.
I have redesigned the Learn2c.org web site to feature this clean and simple look, with less clutter than I had on the prior design. Do not be alarmed – its the same web site as before!
The following is a cross-post from my older web site on App Inventor:
This web site – appinventor.pevest.com – is no longer the primary web site for our App Inventor tutorials. However, that web site will remain there 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 is 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 been 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.
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.
If you have used Fusion Tables, you will need to update the code to use a new data base system. You might consider third-party App Inventor-based development systems such as Appy Builder.
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 🙂
A follow up to my earlier post asking about interest in other programming languages.
For now, this is just an idea. Looking for feedback!
If you have already learned App Inventor programming, what new things would you be interested in learning?
What App Inventor features or techniques would you like to learn about for App Inventor? I do not write custom apps here but instead try to identify generic features and methods that might be useful to know across many different types of apps.
Leave a comment with your thoughts. Thanks!
One of my hobbies is building and flying small quadcopter radio control (RC) aircraft. Most RC aircraft use a one way transmitter – the remote control is the transmitter and there is a receiver on the aircraft to process received commands for flying the aircraft. But the aircraft does not transmit anything back to the control unit – you have no way of knowing when the battery is about to reach empty!
Some RC aircraft use Wi-Fi or proprietary links sending data in both directions – those quads send an alert when the battery is low.
But for simple systems, there is no alert!
A crashed my small quad recently due to draining the battery. I was flying it back to land when its battery died. While only 2 meters off the ground, it came down hard and damaged a prop and motor. (I was flying at an AMA approved RC model airfield so this was all done safely over a grassy area.)
To solve this, I decided I needed a count down timer app that gives me an alert after 10-15 minutes of flying.
That’s where App Inventor comes in.
User Interface View
To set the countdown timer, move the slider control to select a number of minutes between 0 and 59. Or, select one of the “preset” buttons which set the time limit to 10, 12 or 15 minutes.
Press the Start Countdown button to activate. The count down timer shows the remaining time in minutes and seconds.
Once the timer reaches 3 minutes, the remaining time color changes to red and an audio alert “3 minutes” is played. At 2 minutes, there is a “2 minutes” alert and then a “1 minute” alert when there is 1 minute remaining.
The Stop button stops the timer and resets everything to zero. The Exit button closes the application.
Just wanted everyone to know that I am still alive!
I’ve had some other things occupying my mind for a long time as a result of having experienced in life not one – but six – traumatic brain injuries. Bleh. Traumatic brain injuries or TBI as they are known in health care, happen when you have head injuries that jostle your brain around. I do not recommend having head injuries! For me these head injuries included a skull fracture plus being knocked out four times in falls or bike crashes (which broke bike helmets and bones) and other bad whacks on the head… Amazingly, I’ve managed to space these head injuries out over my entire life too, for good measure, or something.
They tell me the effects of TBI are seen as cumulative – that is, a TBI + a TBI + a TBI is worse than having a single TBI.
The issues I was dealing with are now largely over and resolved and I am starting to get lots of things done again. Yay!
I’ve have a list of App Inventor projects I’d want to get to and will hopefully resume those projects near the end of this month.
Anyway, I’m okay, I’m fine, I’m still here!
Keep on programming!