Several years ago, whilst I was contributing to the Microcontroller Central forum (now defunct), I wrote a series of blogs on a project that involved interfacing an Android tablet to an embedded system via Bluetooth communication. The only remaining part the description on the Internet is that of the final product described in “Trace Signals From Behind Closed Doors”. As you can see half the project was an app on a tablet that reproduced an oscilloscope style interface.
The official Android development environment for an app consists of fairly complex layers of software proceeding from Java, through Dalvik (Google’s Virtual Process Machine), to Linux all running in an Eclipse environment. There are other ways to develop for Android, but since this is Google’s way I thought it would be the prudent option. Boy was I wrong! There is NO SUPPORT, anywhere. Sure there are books, but the only way to get anything resembling support is to trawl the Internet or post questions on one of several forums and hope that someone with enough knowledge will deign to give you an answer which may or may not be pertinent to what you are doing.
As our own Max Maxfield described in “What's the best C/C++ course for someone like me?”, I come from a hardware background and I often get thrown into learning a software language at the deep end. My initiation to the Android was difficult to say the least. I suffered tremendous anguish as there were bugs in the examples, poorly commented examples, bugs in parts of the development environment, Eclipse moments, there was no one of whom to ask questions and all made worse because I was trying to learn Java at the same time. I tried finding developers to code the project, but there were remarkably few and they were only involved in commercial software and wanted to develop simultaneously for Android, iOS and Windows. Imagine trying to write a spec of the operation of an oscilloscope for someone who has no idea how it performs and what it is its purpose! I actually abandoned the project twice. I was so disillusioned that I nearly quit the profession. But pride forced me back and I managed to find solutions. I hope you get the gist of my displeasure since I have digressed enough.
I swore that if I ever was to write an Android app again, I would use something else. There are several alternatives and someone I know recommended a product called Basic for Android (B4A). I had seen it mentioned in several of the hobbyist magazines and Fred Eady did two series on the Design News Continuing Education Center- “Design Your Own Android App” (June 2013) and “Develop Apps for Embedded Android Networking”(Jan 2014) Both available here. All the examples that I had seen were, by comparison to what I wanted, trivial and I wanted to get a feel if B4A was up to the task. This is my assessment.
I must apologise in advance for some confusion — in writing this is it was sometimes difficult to draw the distinction between the Android operating system (which is common to everything that I am writing about in the blog) and Google’s Android development environment. I coined the acronym GADE (for Google’s Android Development Environment) in an attempt to clarify the situation and to reduce the word count.
B4A appears to be brainchild of Erel Uziel, who is still dominant in its maintenance and support. At the outset I found the documentation for B4A far more limited than GADE. The online documentation is dated and the only book “B4A: Rapid Android App Development using BASIC” by Wyken Seagrave is a reference book and really short on examples. There are so-called tutorials on the website, but these in fact are very simple sample programs posted on the B4A forum. The biggest problem I found is that the only overview of the program intention is the title. Sure almost every line is commented, so they are very good at telling you what they are doing. They just aren’t very good at telling you why. Sometimes help can be gleaned from the conversation on the forum thread.
Like GADE, the only support for B4A is to search the forum. There is good and bad in this — there is only one forum so all your efforts are concentrated on this space, but if the information is not there you have to pose your question and hope that Erel or someone else answers. From what I have seen someone normally does, but you have to take the response you get, even if it is not the answer to what you asked. Just like GADE.
BUT, this development is in Basic and it is way more friendly, less verbose and easier to understand than Java. And there is no Eclipse — happy dance, to borrow an expression from Max. I have tackled a few Visual Basic projects (even wrote about them if you followed some of my Circuit Cellar articles) over the years, and given that some of my experience in GADE must have embedded itself in my sub-consciousness; I found that it was very simple to get into B4A programming. In GADE the first “Hello World” program comes up very quickly, since it is embedded in the setup. The second step is huge, but with B4A this is not the case. It is very simple to go from one program to the next. I just wish there was a good guide in how to do this, like a book that develops a larger project in stages.
B4A’s development environment is clean and easy to use. You can see from Figure 1 that the development environment is pretty conventional. The project demands appear much less than GADE which needs many support files for all the resources, messages being one example, colours another.
click for larger image
Figure 1: The programming environment
Perhaps I am jumping the gun if I start to cover download and emulation now, but I feel it will ease our discussion. GADE provides an emulator that allows you to see the results of your programming output on a simulated Android device on your PC screen. B4A can also access it. Aside from the fact that certain functions like GPS obviously won’t work, it is excruciatingly slow. Realistically, the only way is to develop with a real Android tablet or phone. For simple programs you could compile and download the app, make astute observations of what is happening and deduce where the problem, just like micro development without an emulator. This is impractical in my opinion.
You can connect to an Android device in two ways using B4A. Like GADE it will allow a USB connection and this certainly is the most versatile. But B4A also allows you to connect via Bluetooth for cordless debugging. Debugging in either approach is quite normal with breakpoints, stepping, logging messages etc. Inevitably there are also a few irritations — for instance there is no “pause” button during emulation, you have to get to the function through the menus.
click for larger image
Figure 2: B4A’s Visual designer
The user interface of any Android app is via the touch screen. In GADE you can get an idea of the visual screen just as you can in B4A’s “Abstract Designer” (see Figure 2). But B4A has a great feature that if you are connected to the actual device you can see the layout on the actual screen as well.
Android’s apps, like the weather forecast etc. are called “widgets”. Confusingly in GADE, the component parts of the user interface (like buttons) are also called “widgets”. B4A calls them “Views”. It seems to me that there are fewer “views” than there are “widgets”. I know for sure that the widget that appears like an LED (on or off condition) is not in B4A. (On the other hand, I couldn’t get it to work in GADE.) Certainly the API for the “Views” appears more consistent than in GADE.
With Android target systems it is likely you are developing for many different screen types and B4A allows you upload your configuration to the cloud and get a visualization of the screen returned to you. Also in development you can also get a screenshot of the Android device from the PC.
The system API has at least one feature that I deeply appreciate. With GADE, the prime cause of my issues (that I ranted about above) was the loss of data in a long burst over Bluetooth to the tablet. With a tablet all you can check is that the data is being sent to the Bluetooth transmitter, and what is being captured when you set a breakpoint in the code. Long story short, the data loss was because the received message was passed from the operating system as and when it was ready to do so and the calling program (all Google sample code) would miss some bytes. B4A solves this (or at least I hope so) by adding a call that includes the number bytes in the transmission (the first word of the transmission includes the count). Sweet!
There are some things that I am not quite sure of yet. Part of GADE’s complexity is that it allows you to develop multiple resources by adding them in a separate file. But on the up side, if you wanted to change languages, for instance — you would access message 4 and depending on what language was set you would get it in the correct language. Also I have yet to find out if B4A can detect 2 or more finger actions, like zoom for instance.
I will be continuing to use B4A as it does seem to be capable of reaching the complexity that I need. I should mention that there is a version for Apple’s iOS (B4i) and for Java with the result running on Windows, Mac, Linux and ARM boards (such as Raspberry Pi). I imagine there must be quite a bit of work to run the same app on all three. In answering one of Max’s queries on Visual Studio, I noticed that Microsoft provides support for Android in the Visual Studio environment. I must look into that. Watch this space for the next update.