Introduction

 
 
 

I am a very late arrival to the smartphone arena (I didn't get one until the end of 2012) but I had seem some intriguing possibilities in these devices and once I had one it seemed a natural area to delve in to. I favored the Android OS because it has several different ways to program it, most/all of them freely available and it is much easier to distribute an app to a phone without needing to go through an app store or get permission from some other organization. I have tried three different systems for programming Android (all free) and I've found that each of these different systems has different levels of functionality and ease of use that make them suited for different projects. Because I am just starting out in this area, there are a lot of potential projects for new apps, and I am always happy to find improvements to what I'm already doing, so if you have an interest in app programming, that could be another area for a research project. It is clear that with the increasing availability and power of smartphones, app development is going to be an important tool for research scientists and it's an area that any budding scientist would do well to investigate.

 
 
 
 
 

App Developmpent in RFO Basic!

 
 
 

I first tried a programming system called RFO Basic! which allows you to write programs directly on the device and gives access to just about anything the phone can do. You can write simple apps very quickly with a function that seems a lot like a command line interface from DOS (where the user is given a prompt and then enters their response). This was ok back in the day, but it's not really a good user interface for a modern computer, let alone a smart phone. I did some work with the software and learned how to make HTML forms that you can use to allow the user to enter information before submitting it to the program for calculation. This shows a quick program I wrote to calculate the Nernst potential for a given ion (something that comes up when discussing the nervous system in physiology classes):


When the user enters the numbers and hits submit, one of two things happens. If you forgot to enter a value or if you entered an inappropriate value, you'll get some kind of error message. If you did it right, you'll see something like this:


At this point you have your answer, but you can't see the numbers you entered to check them for errors. And if you want to go back and do it again, perhaps changing one number, you need to re-start the app and put them all in again. Now I know it's possible to make a better user interface than this, and there are a number of example apps that come with the software that show you can do that, but I didn't find a lot of really clear tutorials to explain how to go about making a good user interface. I am learning more about this system, because it definitely has a lot of promise, and can do some pretty powerful things as shown by the example programs provided with it, but there is going to be a learning curve...

 
 
 

App Development in App Inventor

 
 
 

Around the same time I started using RFO Basic, I began to use something called App Inventor. This was originally a project developed by Google, but they eventually set it free and it was picked up by the MIT Center for Mobile Learning. This is a web-based programming environment and it is designed to be used by someone with limited programming experience. I first heard about this at a science fair in early 2012 when one of the projects I was judging was based on using App Inventor to develop a computer game. The system looked interesting, but it seemed to be set up for very simple game programming, so between that and the fact that I didn't have a phone to program, I didn't really follow up on it. At the end of 2012, I found out a colleague at CSU was using App Inventor for research apps, so I went to the site to learn more about it. The system is pretty straightforward: you move around "blocks" that correspond to variables and the commands that you want the phone to carry out. The user interface and block programming are all drag-and-drop so it's easy to learn and get it working pretty quickly. The blocks shown below are used to take information from the GPS and update the display of latitude, longitude, and GPS accuracy on the screen. This would take a lot more programming in the other systems I've used to program Android, so this demonstrates that you can do some pretty impressive stuff in App Inventor with a minimal amount of effort.

Another huge benefit of App Inventor is the excellent series of tutorials that are available through their website, which walk you through a lot of the complexities of programming very clearly. There are some items that are not covered, but overall you can get up and running in a short amount of time. One of the first apps I developed determines if a particular population is in Hardy-Weinberg equilibrium based on the genotypes of the population. This is a pretty common type of test to use in my intro biology for majors and evolution classes, so it was nice to have a quick way to check some numbers without having to worry about making a math error or opening up my computer to plug the numbers into a spreadsheet. 

I've already developed several apps using this system for use in my research. The first app allows me to store a location along with it's GPS coordinates and some notes describing the location. This is an important tool for field research in general, but it's especially useful with working with nocturnal animals, since you can visit the same location in the day time and have no idea that you're in the same place!  This app can also take your current location and calculate the distance and bearing to a particular site, search for the closest stored site based on your current location and even point the way with an arrow on the screen so I know which way to travel and how far I have to go. This is very helpful when you are in the general vicinity but aren't 100% sure of exactly where that research site is located. This app has a number of ways to store the data, including on the phone, to a web data base, to a Google Fusion Table (a type of document available through Google Drive, which can map the locations on Google Maps in addition to other capabilities), or to a text file on the SD card for use by other programs. This last option requires a second program that was written in Eclipse, which I describe in more detail below.

A second app stores a record of the path you travel, by storing your GPS coordinates every time you move a certain distance. This allows you to document the path you followed and the distance you traveled. This is useful for research involving transects, where the researcher has to travel a certain path which can sometimes be quite long. This app can save the data in a variety of ways, but I found one major problem with saving data to Google's Fusion Tables. The app defaults to saving a data point every 20 meters but even if that is increased, on a long trip, you can generate several hundred points. When I tried to upload the data to the Fusion Table, it would manage to upload some of it, but eventually fail and give an error of some sort. For the previous app this hadn't been a problem, but I had never saved more than a handful of points at a time. I eventually gave up on saving directly to the Fusion Table, and instead save the data to a text file on the SD card in a format that can be imported into the Fusion Table. The app also allows you to re-trace your path displaying an arrow directing you along the path, towards the nearest stored point, etc. This image shows a small number of points saved on a stroll on campus. The app can add a note to the points so that they are displayed differently. These points were uploaded to the Fusion Table and displayed through its default mapping capability with green ones indicating that a note was added while the red ones indicate that no note was added. No extra programming was required to make this display beyond the programming of the app itself.

A third app I recently completed is one to estimate the height of objects. This is useful because when studying flying animals, it can be helpful to have some idea of how high the bats are. Bat echolocation calls fade rapidly with distance, so the height of the bats can affect the type and quality of the sounds that you can record. Instead of trying to estimate the heights myself (which I suspect is very inaccurate) it uses basic trigonometry to determine the height. You start directly underneath the height you need to measure (e.g., where the bats are flying) and then walk some distance away. The app calculates how far you have walked based on the GPS unit in the phone as well as making an estimate using the accelerometer of the phone to count the number of steps you've taken from the starting point (this works like a pedometer, which requires you to have an estimate of your stride length). You can also enter the distance directly into the app in case you already know how far you are from the location. You then point the phone to the height you are trying to estimate and click the calculator button. At this point, the app calculates the height based on the angle of the phone and the distance you have walked. The theory is pretty simple (and it's been in use for as long as trigonometry has existed) but it's nice to have the phone do all the calculations so that I can just record the data! One thing you'll note is that the GPS and accelerometer measurement of distance are different, which means the height calculations are different as well. This could be for a variety of reasons, but one of the major ones is the accuracy of the GPS, which can vary a lot depending on your situation. For that reason, the app displays the accuracy of the GPS (the number is listed after the GPS coordinates) so that you can take that into consideration as that can sometimes make significant difference in the height that the app calculates. The app also takes into account any changes in altitude as you walk and the user's own height to give a more accurate value. Even with the variability that you can find, this estimate is one I have more confidence in than my own guess as to how high something is, so the data should be taken with a grain of salt, but they do provide a good starting point and it spares me having to measure out my walking distance and getting an inclinometer to measure the angle for me, so it's faster and simpler to use and it's accurate enough for my needs.

 
 
 

App Development in Eclipse

 
 
 

At the same time as I was experimenting with Basic and App Inventor, I began testing the use of the official Android development system (using a program called Eclipse) which gives you full access to everything Android can do and then some. This system has a fairly easy way to set up the user interface of your apps, but it does require a lot of non-intuitive programming to access it, and it requires a good background in Java programming. I have some experience there, but I'm definitely still going through the steep part of the learning curve. While I was able to set up simple apps in Basic and App Inventor in a few hours, it took me much longer to really understand what I was doing with Eclipse. At this point, I've worked my way through several different tutorials and I'm getting to the point where I almost feel like I know what I've doing. I've developed several simple apps that match the ones I wrote in the other systems. Below is a modified Nernst calculator written in Eclipse. It has the advantage of being more flexible, as it displays the results on the same screen and allows the user to adjust numbers and calculate new values, which isn't possible with the version I wrote in Basic.


I also wrote a new version of the Hardy-Weinberg app that I had developed in App Inventor. The layout and function are basically identical to the App Inventor version.


One interesting thing to note when comparing these apps is that there are small differences in the numbers that are calculated which seem to be based on the precision that different programming languages use. For the purposes of the apps I'm currently writing, those small differences do not matter (and are going to be a factor of rounding error even if I do the math by hand or in a spreadsheet) but it's definitely something to keep an eye on if you have a math-intensive app.

A significant benefit of a smartphone to a field biologist is the ability to access a variety of different types of information very easily. As I conduct my research, I want to collect as much environmental data as possible so that I can use that to understand the behavior of the animals I'm studying. However, collecting these data can require a lot of cumbersome equipment that has no replacement on a smartphone directly. One such variable is wind speed, which can't be measured by a phone app (at least not by any phone I'm aware of) thus requiring a device called an anemometer. These devices have a couple of serious limitations. One, they can only measure the wind speed of the wind blowing through them, which means I can't tell anything about wind at any height unless I can get the device up there, and two, they are hard to use in the dark since the ones I have do not have a lighted display. Fortunately, there is an internationally recognized system for classifying wind speeds that is quite reliable called the Beaufort scale. The scale goes from 0-12 and I was worried that I or my research students might remember the categories incorrectly, so I decided to write a quick app that would let me look up the different values and see how they correspond to the current situation. This allows me to estimate wind speeds reliably and allows me to get away with one less thing to carry in the field. I even found some graphics online that gave a visual representation of the different levels to make it a little easier to classify the current conditions. This app could have been written in any of the different Android programming languages, but the nice thing about doing it in Eclipse was that it gave me access to the control where the user can just use his/her finger to swipe the numbers up or down to adjust the levels. As the number changes, the text and graphic are automatically updated so it makes for a much more intuitive user interface than I could have produced with RFO Basic or App Inventer due to the more limited set of tools these languages provide.

Another major limitations of App Inventor is its inability to save files to the SD card in a way that other programs can access. Luckily, some searching on line found this link, which gives you the code you need to compile an app that you can use with App Inventor. The App Inventor app sends the information you want to save as text formatted as comma-separated values (CSV) a common format used by spreadsheets, so you can save the data to the phone's SD card and then use it in other apps, download to your computer for further analysis, etc. The eclipse app prompts you for a filename to save the data under. It's not perfect since you're limited to the type of information you can provide (only information that can be encoded as text can be used, but luckily this includes all the data I tend to work with) but it's definitely a useful tool to have.


While the functionality of the apps I have written in Eclipse is still pretty limited, it's clear that this is the way to go if you want to have complete control over your app's functionality. There is a strong advantage for someone who can program using this system as the level of functionality you can produce is limited more by your imagination than any other factor...

 
 
 

Pros/Cons of Each System

 
 
 

As I have increased my familiarity with these systems, I have found some advantages and disadvantages for each

RFO Basic!

Pros

  • Free
  • Programming language is fairly easy to understand
  • Can access most/all(?) of the smartphone's functions
  • Size of the app corresponds to the complexity of the app
  • Permissions match what the app requires
  • Apps can be set up to look very professional

Cons:

  • Limited number of tutorials available to help new users learn the system
  • Programming the user interface takes more work than the other systems
  • Producing APK files for installation on phones is complicated (but not required as long as the Basic App is installed on the phone)

App Inventor

Pros

  • Free
  • Block programming interface is very easy to understand and start using
  • Simple to set up the user interface for your apps
  • Excellent online tutorials make it easy to learn how to use the system
  • Can access many of the smartphone's functions
  • Producing APK files for installation on phones is very easy

Cons

  • System is web-based, so can only be used when you have internet access (it is possible to install on a computer, but it does not appear to be a trivial task)
  • Currently not possible to re-use code from one app in another app - if you write a complex function in one app, you have to rebuild it from scratch if you want to use it in another app
  • Size of files is much larger than other systems even for apps with the same functions.
  • Requires an extensive list of permissions (e.g., identify the phone and open network sockets) even if the app does not use them
  • Inability to directly access/store files to the phone's SD card - this makes it more difficult than it should be to share data between different apps
  • No way to search through the program blocks - which means it can be difficult to keep track of your code when dealing with a complicated program
  • Documenting your programs is difficult - you can add comments to particular blocks, but without a search function it is difficult to find a particular comment in the future
  • Block programming method becomes awkward to use for programs that involve a lot of calculations
  • The text displayed by the apps is a little "jagged" which makes it a little hard to read if the fonts are small

Eclipse

Pros

  • Free
  • Fairly easy to set up the user interface
  • Wide variety of online and printed resources that are available to help learn how to use it
  • Access to everything the smartphone can do
  • APK building is straightforward
  • Size of app corresponds to its complexity
  • Permissions are only added if the programmer requests that permission in the code

Cons

  • Much more complicated programming language than other systems leading to a longer learning period

In the end, each system is worthwhile and the choice of which to use would be based on what you need your app to do and the time you have to develop it.

 
 
 
 
 
 
 
 
 
 
This website requires Internet Explorer 8 and higher.
Please update to the newest version.