Introduction

All of these things are important elements of a project I want to put together - namely a way to carry digital topographic maps into the field. I need to have all the maps in the device because I go to remote places where cell networks (never mind WiFi) do not and likely will not ever reach. I want an all solid state device that will resist being bounced around in a vehicle being driven over rough roads. I want something on the order of an 8 hour battery life, along with a large display (the 2.5 inch displays on portable GPS receivers do not meet the requirements for this project).

I have let over a year go by without doing anything about this project, but now have a trip planned where having this done would be ideal. The trip is 5 weeks away (April 15, 2013) - a reasonable timeframe if I can focus on getting it done. These pages are intended to be a "blog" of sorts - a chronological logbook of my progress as I work through this project.

• Follow this link to the latest entry.
• Follow this link to Phase 2 (3-10-2013).
• Follow this link to Phase 3 (3-12-2013).
• Follow this link to Phase 4 (3-16-2013).
• Follow this link to Finish (3-22-2013).
• Follow this link to the next stage (4-4-2013).

Phase 1 checklist for the Android gtopo project

• Get Android SDK installed and tested.
• Build hello world application.
• Run hello world on simulator.
• Run hello world on Xoom.
• Investigate command line Android development.
• Write simple app to access GPS coordinates.
• Write simple app to access files.
• Write simple app to display a JPEG image from a file.
• Write simple app to access SD card slot files.

Monday 3-4-2013

I followed the advice on the Google Android Developer site, and downloaded the file adt-bundle-linux-x86_64.zip. This is about 419 megabytes of stuff.

• Downloading the Android SDK

The claim is that it will give me:

• Eclipse + ADT plugin
• Android SDK Tools
• Android Platform-tools
• The latest Android platform
• The latest Android system image for the emulator

I unzip it to /u1/adt-bundle-linux-x86_64 on my system, and make a symbolic link to it I call /u1/adt-bundle. Within it are two directories, "sdk" and "eclipse".

The advice is to "open the directory /u1/adt-bundle/eclipse and then run the eclipse executable in that directory. I am not sure what they mean by "open the directory". (I guess they are trying to give platform independent instructions here, which leads to ambiguity). I tell it I want my workspace to be /home/tom/Android -- then I get the error "Could not find SDK folder /opt/androidSDK". Now on my system, the file /opt/androidSDK is an old (and broken) link to /u1/android/android-sdk-linux from a prior attempt to set up android development. I delete this link and still get the same error. I then follow the dialog, open the preference gadget, and tell it that the SDK location is /u1/adt-bundle/sdk and things seem cool now.

I will be honest that I am somewhat concerned about using the android bundle on my system. I already have an eclipse executable in /usr/bin/eclipse (which is on my path) that I installed as a Fedora package. Hopefully the eclipse in the android bundle can keep itself in its own world.

It doesn't seem to matter whether I do "cd /u1/adt-bundle/eclipse; ./eclipse" or if I give the full path "/u1/adt-bundle/eclipse/eclipse". I am putting a short script "adt" in my /home/tom/bin directory which does the second of these (and it seems to work).

Just for the record, the java I am running seems to be:

 javac -version
 javac 1.7.0_09

Also for the record, I note that the bundle is set up for Android 4.2 (Jelly Bean).

Hello World

There seems to be nothing more beyond unzipping the bundle to get it installed (that and setting up a shortcut to launch eclipse), so the next step is to give it a try. I am going to follow the Android developer training plan set up by Google, which starts with the traditional "hello world" application:

• Android developer "getting started"

I launch eclipse, and from the menu bar:

File->New->Android Application

Apparently selecting "My First App" selects a sample demo that already is typing "Hello World", so I don't have to do anything really. I certainly have not entered any java or xml code. I am heartened to see that it is possible to set up the Android application scaffolding using command line tools and bypass Eclipse if I want to, and I will take some time later to look into this (they key tools are "ant" and "adb").

Tuesday 3-5-2013

My Android device is a Motorola Xoom (non-cellular) MZ604. It requires a micro USB cable (to connect to my development machine. I have a USB 2.0 A-male to Micro-B Cable 6 feet long that I bought via Amazon some time ago (I bought two while I was at it), otherwise I would be wasting time running off to buy a cable. When I plug it in and watch /var/log/messages, I see:

 usb 1-6: new high-speed USB device number 3 using ehci_hcd
 usb 1-6: New USB device found, idVendor=22b8, idProduct=70a8
 usb 1-6: New USB device strings: Mfr=2, Product=3, SerialNumber=4
 usb 1-6: Product: MZ604
 usb 1-6: Manufacturer: Motorola
 usb 1-6: SerialNumber: 0380624640e04217

I am told I need to enable USB debugging on my device. I click on the lower right corner of the screen, then click again to get a bigger menu that includes "Settings" at the bottom. Near the bottom of the settings I see "Developer options", but within that everything except "take bug report" is greyed out. At this point, this is a show stopper.

It only took two hours (but all that searching and hair pulling allowed me to learn a bunch of stuff), but now I have the answer. In the uppermost right corner of the screen is a pair of buttons on/off -- click "on" and all the settings get activated and I can click the box to enable USB debugging.

Just for the record, my Xoom is running Android 4.1.2, Linux kernel 2.6.39.4 built on September 10, 2012 - Build number JZ054K.

And for the record, my screen measures 5.5 by 8.5 inches. They call this a 10.1 inch display (measuring on the diagonal). It has a native resolution of 1280 by 800 pixels.

And a short history of my Xoom. I bought it as a recertified unit in December of 2011. It shipped with Android 3.2 (Honeycomb), but as soon as I plugged it in almost it upgraded itself (over the wifi connection) to something newer. It has upgraded itself several times since then (I have never initiated an upgrade myself). It ran a 4.0 version (Ice Cream Sandwich) for a while, and is now (March, 2013) running Android 4.1.2 (Jelly Bean). Note that 4.1 is Jelly Bean, API level 16. Current Android development is at 4.2 which is Jelly Bean, API level 17. The next version (Key Lime Pie) is expected by summer of 2013. The word for the Xoom is that (as of November, 2012) it has officially been removed from Android 4.2 AOSP (Android Open Source Project), which means that there will be no official over the air update.

Back to running the hello world application on my Xoom. I have it hooked up with the USB cable and now have USB debugging enabled. I open up Eclipse ADT and on the left side select my project (an important step that I was missing at first). Then on the menu bar I select Run --> Run as --> Android Application and I get a dialog that allows me to select my Xoom as a target option (wow, this is promising!). And voila, the hello world application is running on my tablet. No icon - the application does not seem to get installed on the tablet by doing this.

Running on a virtual Android device

The next trick is to set up a virtual device to test with. I fire up the AVD manager, and click the "New" button. I create "MyXoom" as a 10.1 inch 1280 by 800 device with an SD card. It is targetting Android 4.2 (it remains to be seen if this is a problem). I select this target device, start, and launch it, this gives me an emulated tablet screen on my desktop display.

This is miserably slow (I was warned about this). In fact it takes several minutes, maybe as many as 10 to get the emulator fully up and running. I was totally confused by trying to get the emulator to respond to mouse clicks while it was still in the process of getting its act together. The tutorial says to unlock the screen before trying to download the application. This is a big clue -- if there is nothing to unlock, then the emulator is still not ready.

As you might expect there is lots of discussion online about how slow this is and all kinds of suggestions about how to speed it up. One key piece of advice I have seen is to never close the emulator once it starts up, but rather to keep reusing a started emulator. Start times on the order of 15 minutes are mentioned, but some people get this down to under 5 minutes! The emulator start time seems to be the worst of it. Once it gets up and running (give it at least 10 minutes on my system), applications can be loaded into it in a reasonable time, but real hardware is far far better.

Onward with the hello world application

The tutorial now has us editing XML files that specify the application layout (not writing a line of Java yet!!). We edit res/layout/activity_main.xml and res/values/strings.xml to install a text entry field

All this is fine, but feels a lot like the ruby on rails tutorials I have worked through; lots of jumping around between directories and editing files that I do not fully understand. But it works, and I am getting a taste of the flavor of the whole thing, which is sufficient for now. Also, I am pleased to find that I can just use the vi editor alongside of eclipse to work on files without problems.

Finally the tutorial has us writing some java. We modify the already generated template code in src/org/mmto/myfirstapp/MainActivity.java and then use eclipse to generate a new class in src/org/mmto/myfirstapp/DisplayMessageActivity.java which we then modify. This actually is working out OK. I can use vi outside of eclipse, but use eclipse to show me errors (which works out nicely), as well as to download to the Xoom.

At this point, I am done for the day and have finished the "Building my first App" on the Google getting started web page tutorial.

Another highly recommended tutorial is:

• Android game development tutorial (xda-developers).

• Professional Android 4 Development

Wednesday 3-6-2013

As I have noted, I have had no problems using the vi editor right alongside of eclipse. This is not the handiest thing though, and in particular eclipse promises to afford a much handier way of navigating around the android directory structure. It is possible to configure eclipse so that its built in editor acts a lot like "vi". The way to do this is to use an eclipse plugin, and there are several to choose from. Two recommended commercial ones are "viable" and "viplugin". A plugin called Vrapper is recommended by many. It is open source and has a toggle switch that activates vi key bindings, which is a feature some people really like. This explains how to install it and get started.

I decided to go through the game tutorial on the XDA-developers site. "XDA" by the way is the name of some phone that ran a microsoft based operating system. The "XDA" site has expanded far beyond that origin and seems to be a major center for android related information. The game tutorial is covering a lot of basic Java programming (as well as just basic programming all around), so I have been able to go through the first "11 day" unit in a morning. Nothing Android specific yet. The big benefit, apart from a Java warm up, is getting better acquainted with Eclipse.
Some useful tidbits learned:

• Control-Shift-F will fix indentation.
• Control-Shift-O will (sometimes) supply needed import statements.
• Control-Space will give a menu of selection to complete something partial.

Now using Eclipse with "vi" style keystrokes available, I am quite liking it. And the Control-Space thing works quite nicely. When you double click on the thing you like in the menu it fills it in for you, and will generate a lot of extra code (even a set of stub methods when you extend an interface for example). Also, the eclipse editor (with vi enhanced) will obey the mouse, which is very nice. One thing to watch out for is that when you do an insert and paste something - the paste happens at the mouse location. Typing Escape and u to undo saves the day though. So far I have not found any vi command that has not been there. Some people complain that the Vrapper plugin does not support regular expressions, but I use these so rarely in vi that I have yet to miss them.

On with the second unit of the tutorial. I was concerned that the tutorial instructs me to set up a java applet, but it turns out this is no liability as the run button in Eclipse launches it with no extra effort on my part.

And a random note about units in the Android world:

• px = pixel (honest hardware screen resolution pixels).
• dp = "dip" density independent pixels based on a virtual 160 dpi screen.
• sp = scale independent pixels (use these to specify font sizes).
  These are like dp, but also scaled by a users font size preferences.

Note also that the (0,0) point of the Android screen is the upper left.

Another amazing Eclipse trick. Click on white space outside of the editor window. Select "Source", then "Generate Setters and Getters" and it adds a flock of accessor methods to your class for all private variables. It offers you a dialog so you can choose to set all of them or select which you like.

I had a lot of trouble getting the images that the tutorial instructs you to place into src/data to appear. It turns out that when Eclipse does the build, it copies these into bin/data (it also is placing compiled java into bin/kiloboltgame). Apparently everything under src is going to get mapped to bin by some set of rules. I sometimes had to select the data folder and do a File --> Refresh. I also changed the call to getDocumentBase(); to getCodeBase(); in the source (which seems like the right thing to do).

Maybe you are wondering whether it is worth all the trouble going through a game writing tutorial. As I am doing it, I realize that a lot of what I do with my topo map software is like what is being done in the games. I plaster images on the screen with the appropriate calls, and respond to various events to move these images and to change sizes. So the nature of the programming is quite appropriate. Also one of the greatest benefits is just getting road time with eclipse.

I have made it through Unit 1 and am about half way through Unit 2. What I may do is to skip to Unit 4 (which gets into porting the game to the Android) otherwise I could spend days honing my Java game writing skills.

Thursday 3-7-2013

Some things I am learning:

• Android has the SQLite database built in.
• Android now includes an NDK allowing extensions to be written in C/C++.

A thought that is coming into focus as I have been following the Java game writing tutorial is that I can do a lot of Java development and debugging in the native Java environment (which is quite efficient and responsive), before investing the effort to port the code to the Android.

Now, let's get the Android development system set up on my machine at work, and this time not using the adt-bundle.

Java

 javac -version
 javac 1.7.0_09

 ls -l /etc/alternatives/javac
 javac -> /usr/lib/jvm/java-1.7.0-openjdk.x86_64/bin/javac

This is openJDK, not the "official" sun/oracle java. I will leave this be and see if any problems arise.

Android SDK

Eclipse and the ADT plugin

This is always terribly slow. While it is grinding away, I will just reiterate my complaint that every significant piece of Java based software (Eclipse, the Arduino IDE, the Android virtual device) are horrible dog slow turkeys. OK, it is finally up and running now. I see the "Welcome to Android Development" telling me I am on the right track behind a pop up that says it doesn't know where to find the Android SDK.

I select "Use existing SDKs" and enter /u1/android-sdk-linux. Now it tells me the SDK Platform Tools component is missing and I should use the SDK Manager to install it (this is expected). It offers to launch this for me (and I let it), but should I ever want to launch it by hand, I can run "/u1/android-sdk-linux/tools/android sdk".

I select all tools, the latest Android (4.2.2), Android 4.1.2 (since the Xoom runs that), and all the extras. It wants to install 25 packages and delete one. I click the button that tells me this, accept a license, and away it goes. It goes quite fast, but I am on a very fast connection at the University. It finishes telling me it has installed 21 package. I have to install the 4 extra packages next in a separate step. And now 2 more MIPS packages in another step (a different license apparently). And lastly it wants to delete one package (the SDK tools, revision 21.1), I do this, but am not sure it was such a good idea (see below) as it deletes the "android" executable that I need to run the SDK manager.

Where did my tools go??

Install 32 bit libraries

• Click on Window --> Customize perspective
• Click on the Command Groups Availability tab
• Check the "Android SDK and AVD Manager" option
• hit the OK button.

/u1/android-sdk-linux//tools/emulator:
error while loading shared libraries:
libstdc++.so.6: wrong ELF class: ELFCLASS64

yum install libstdc++.i686

[2013-03-07 14:21:11 - MyFirstApp] /u1/android-sdk-linux/platform-tools/aapt:
error while loading shared libraries:
libz.so.1: wrong ELF class: ELFCLASS64

yum -y install zlib.i686
yum -y install libXrender.i686
yum -y install libXext.i686
yum -y install fontconfig.i686

yum -y install --skip-broken glibc.i686 arts.i686 audiofile.i686 bzip2-libs.i686 cairo.i686 cyrus-sasl-lib.i686 dbus-libs.i686 directfb.i686 esound-libs.i686 fltk.i686 freeglut.i686 gtk2.i686 hal-libs.i686 imlib.i686 lcms-libs.i686 lesstif.i686 libacl.i686 libao.i686 libattr.i686 libcap.i686 libdrm.i686 libexif.i686 libgnomecanvas.i686 libICE.i686 libieee1284.i686 libsigc++20.i686 libSM.i686 libtool-ltdl.i686 libusb.i686 libwmf.i686 libwmf-lite.i686 libX11.i686 libXau.i686 libXaw.i686 libXcomposite.i686 libXdamage.i686 libXdmcp.i686 libXext.i686 libXfixes.i686 libxkbfile.i686 libxml2.i686 libXmu.i686 libXp.i686 libXpm.i686 libXScrnSaver.i686 libxslt.i686 libXt.i686 libXtst.i686 libXv.i686 libXxf86vm.i686 lzo.i686 mesa-libGL.i686 mesa-libGLU.i686 nas-libs.i686 nss_ldap.i686 cdk.i686 openldap.i686 pam.i686 popt.i686 pulseaudio-libs.i686 sane-backends-libs-gphoto2.i686 sane-backends-libs.i686 SDL.i686 svgalib.i686 unixODBC.i686 zlib.i686 compat-expat1.i686 compat-libstdc++-33.i686 openal-soft.i686 alsa-oss-libs.i686 redhat-lsb.i686 alsa-plugins-pulseaudio.i686 alsa-plugins-oss.i686 alsa-lib.i686 nspluginwrapper.i686 libXv.i686 libXScrnSaver.i686 qt.i686 qt-x11.i686 pulseaudio-libs.i686 pulseaudio-libs-glib2.i686 alsa-plugins-pulseaudio.i686

Try the My First App demo

I was getting supposed syntax errors, missing methods and java variables. All this resolved itself when I installed the missing 32 bit libraries, much to my surprise. I was beginning to think that the ADT-bundle was special in some way.

When I clicked the "Run" button to load my application into the AVD and run it, I kept getting the following error:

The selection did not contain any resources that can run on a server

By the way DDMS stands for Dalvik Debug Monitoring Service, which is part of the ADT setup. Also, "SMS" stands for "Short Messaging Service", which is just good old text messages. ADB is Android Debug Bridge (not the old assembly debugger I knew and loved).

Also, to learn more about Eclipse, you can restore the Welcome page by clicking on Help --> Welcome.

Repeat the exercise on my home machine

Continue the Game Tutorial

The first two lessons in Unit 4 deal with setting up the development system. The method recommended to check the java version is to start eclipse and click Window --> Preferences --> Java --> Compiler (which shows a compliance level of 1.7 -- which is fine). The tutorial recommends using the ADT bundle, which is a sensible approach.

I am missing the DDMS button he talks about in the upper right. It turns out this is just a shortcut to the DDMS perspective, which you can get via Window --> Open Perspective --> Other --> DDMS (which causes the shortcut button to appear).

A trivia item. Android releases are named after desserts, but in alphabetical order.

I really should create another AVD with a smaller screen size (he recommends a Galaxy Nexus with a 720x1280 screen and 1024K of RAM). He also enables snapshot as it lets the device start up the "same as last time", which speeds things up.

Note that when I click on the AndroidManifext.xml file, it presents me with a nice GUI with entry fields to allow me to screw with this file. This is nice. I wonder if Eclipse will do this for all the xml files that pop up?

The Game Tutorial guy (James Cho) says that he got much of what he is teaching from the following book, which he recommends. Reviewers say that the Android 4 claim in the title is baloney and that it is the same old Android 2.2 book with a new title and some misprints inside.

• Beginning Android 4 Games Development

Friday 3-8-2013

Back to the game tutorial -- I dutifully follow his building of the framework interface.

A key object in the Android world is the "Activity". Each visible "screen" in android is an activity. The following diagram illustrates the activity life-cycle with key methods.

Just for the record, a vital link:

• Android Reference documentation

Up to the final day of the final unit has all been setup for:

• Porting your game.

• Assets
• SplashLoadingScreen
• LoadingScreen
• MainMenuScreen
• GameScreen
• SampleGame

To port the plain java code to Android:

• Java Image gets replaced by the Image class in the framework.
• Java Rectangle gets replaced by the Android Rect class.

• Animation
• Background
• Enemy
• Heliboy
• Robot
• Projectile
• Tile

After all of this, there are 4 java warnings, so it looks ready to go. He provides a game icon image (icon.png 150x150 pixel), which goes into the res/drawable-hdpi directory. Again I do File->Refresh in eclipse after copying it there.

He warns that I may get an error with R.raw.map1, I may need to change the line: import android.R; to import com.trebisky.robotgame.R; .

I do get this error in SampleGame.java. I don't have either line, but when I add this line the import line itself gives me an error. Using Control-Shift-O suggests the following fix (which works):

import com.trebisky.androidgame.R;

Also in GameScreen.java, the following line gives me an error:

TouchEvent event = touchEvents.get(i);

TouchEvent event = (TouchEvent) touchEvents.get(i);

Now we edit the AndroidManifest.xml file. We add three "uses-permission tags. And we specify the one and only activity in the game, ".SampleGame", but I copy and paste the entire application tag (which includes the activity tag, which in turn includes and intent-filter).

At this point I can load the game into the Xoom, but I immediately get a popup telling me that the game has stopped. On a hunch, I use File --> Refactor on the com.trebisky.robotgame package, changing it to com.trebisky.androidgame -- and now it runs!! The clue on this was the need for this change on the import line above. And I had the project named AndroidGame, but the package named RobotGame.

Packaging the project

Here is the game.apk.

After putting the game on my own website (at the link above), I encounter two obstacles when trying to install it on my Xoom. First I need to go into settings and enable the installation of applications from "unknown sources", i.e. other than Google Play. Next, when I go to install it, I find it is in conflict with some previous application called "RobotGame" with a different signature, and the Xoom refuses to install it.

The deal is that when I ran the application via eclipse to test it, it actually did get installed on the Xoom. It is this previous install (with some key generated by eclipse) that I am in conflict with. This brings up the subject of some Xoom basics:

• To see all apps, touch the group of six squares (this is supposed to be the "apps" icon) in the upper right corner of the home screen. Now you will see all the apps, including those installed via eclipse.
• To make a shortcut to one of these apps on the home screen, just do a press and hold on the app.
• To remove a shortcut from the home screen, do a long hold, then drag the app to the top center where a "remove" messages has appeared. This does not remove the app from the tablet.
• To remove an app from the tablet, do the same remove exercise on the app screen.

Now I am reading chapter 3 in the OReilly "Android Programming" book. This is a very good book, unlike other computer book publishers, OReilly seems to have a good editing staff that cleans up a lot of rough spots that show up in other books that seem published raw from the author. Chapter 2 (Java for Android) is superb.

This book strenuously recommends NOT doing what I have done, namely using the eclipse that ships with Fedora. I am hoping that this won't be an issue in my one user system. Android likes to set up layouts using XML. This is a way of separating code from layout (but you can ignore this and generate your layout from code, not that it is a good idea). ADT provides both layout editors and manifest editors, so you do not have to hack on XML directly (though you can).

Some Java tips:

• Java initializes all fields (guaranteed) to 0, false, null, ...
• Java does not initialize local variables.
• There are 11 modifier keywords that can be applied to a declaration in Java.
  (more than I thought!)
• Avoid the legacy collection classes: Vector, Hashtable, Enumeration, and Dictionary.
• The <T> notation where T is a type is a java "generic".
• Java threads are best done via a class implementing "Runnable" with a run() method.

Some Android tips:

• Sqlite3 is a component of android and available to android applications.
• An Activity is both a unit of execution and a unit of user interaction.
• An Intent is a way for one activity to communicate with another.
• res/layout holds xml layout files.
• Context.getResources() and the R class are used to access resources.
• The directory "gen" contains generated java, in particular the R.java class.

msgToServer.post(new Runnable() {
    public void run() {
	msgToServer.setText("your text here");
    }
}

// set up fields in main Activity:
Handler h = new Handler ();
// later, in some other thread:
h.post(new Runnable() {
    public void run() {
    	do_something();
    }
)};

• Google Handler class documentation

• post(Runnable)
• postAtTime(Runnable, long)
• postDelayed(Runnable, long)
• sendEmptyMessage(int)
• sendMessage(Message)
• sendMessageAtTime(Message, long)
• sendMessageDelayed(Message, long)

The following is a very good description of different ways to implement listeners (such as methods to respond to button clicks):

• Implementing Listeners

Saturday 3-9-2013

• Use a post rather than a message to update the display on a timer.
• Use something even more clever than a second thread to generate timer activations.
• Use a bigger font for the number display
• Do not hog the entire screen with the application.
• The application locks up after a sleep, fix this.

// Set these up a fields in the main Activity
Handler h = new Handler ();
Runnable r = new Runnable() {
   @Override
   public void run() {
	 do_something ();
	 // tail recursion
	 h.postDelayed(this, 500);
   }
}
// Then do this in the onCreate() method
h.postDelayed(run, 0);

// Set up fields in the main Activity
final Handler h = new Handler(new Callback() {
        @Override
        public boolean handleMessage(Message msg) {
	    do_something ();
	    return false;
        }
});
// a class within the main Activity
class tickTask extends TimerTask {
        @Override
        public void run() {
            h.sendEmptyMessage(0);
        }
};
// in the onCreate method
timer = new Timer();
timer.schedule(new tickTask(), 0,500);

// a class within the main Activity
class uiTask extends TimerTask {
        @Override
        public void run() {
            main.this.runOnUiThread( new Runnable() {
                @Override
                public void run() {
		   do_some_ui_update();
		   // something like the following
		   // tt.setText("yada yada");
                }
            });
        }
};
// in the onCreate method
timer = new Timer();
timer.schedule(new uiTask(), 0,500);

• Android Background Processing

A bigger font size seems to be an easy thing. It can be changed in the XML layout with android:textSize = "50sp", or at run time via: tt.setTextSize(size).

I can get rid of the title by putting this in the onCreate() method:

requestWindowFeature(Window.FEATURE_NO_TITLE);

android:theme="@android:style/Theme.NoTitleBar.Fullscreen" 

Access and display values from the GPS

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

Access files on my SD card

I have a little micro SD to USB holder that I put the card in and plug it into my linux development computer. I copy three small files onto the card (keeping whatever filesystem the SD card shipped with). The files are named "cat, dog, and rat". Then I turn off the Xoom and carefully insert the card into the SD slot. I have been warned that if a person is clumsy and inattentive doing this that the card can just slip into the bowels of the Xoom. I avoid this.

The word is that FAT32 is the way to go on the SD card. The card I have (as shipped) mounts as:

/dev/sdb1 on /run/media/tom/3162-6436 type vfat

Format /fs:FAT32 driveletter:

• SD card formatter

su
umount /dev/sdb1
mkdosfs -F 32 -I /dev/sdb1

I download the android app "File Manager HD" and click on "Storage" and I am immediately looking at the contents of my external SD card with my 3 files front and center! Apparently ES File Manager is just clueless about the SD slot. The lower right corner of the screen shows "/storage/sdcard1" --- I will bet you that the internal card is /storage/sdcard0. Now we are getting somewhere.

Folks say that with a USB cable, they can plug the Xoom into a PC running windows and transfer files to the SD card slot. This does not work with my linux machine. At least I cannot just plug it in and see it pop up like a USB memory stick would. Some people say that the following will accomplish this under linux:

yum install mtpfs
mkdir /mnt/xoom
mtpfs -o allow_other /mnt/xoom

• MTP on linux

Indeed mtpfs works on my Fedora 18 system. With no arguments it detects the Xoom, but then tells me to specify a mount point. Once I give it a mount point I can do:

mtpfs -o allow_other /mnt/xoom
Listing raw device(s)
Device 0 (VID=22b8 and PID=70a9) is a Motorola Xoom (MTP+ADB).
   Found 1 device(s):
   Motorola: Xoom (MTP+ADB) (22b8:70a9) @ bus 1, dev 12
Attempting to connect device
Android device detected, assigning default bug flags
Listing File Information on Device with name: (NULL)

 ls -l /mnt/xoom
 total 0
 drwxrwxrwx 2 tom tom 0 Dec 31  1969 Internal storage
 drwxrwxrwx 2 tom tom 0 Dec 31  1969 Playlists
 drwxrwxrwx 2 tom tom 0 Dec 31  1969 SD card

 ls -l /mnt/xoom/SD\ card/
 total 2
 -rwxrwxrwx 1 tom tom 4 Mar  9 15:21 cat
 -rwxrwxrwx 1 tom tom 4 Mar  9 15:21 dog
 drwxrwxrwx 2 tom tom 0 Dec 31  1969 LOST.DIR
 -rwxrwxrwx 1 tom tom 4 Mar  9 15:21 rat

mtpfs on /mnt/xoom type fuse.mtpfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)

su
umount /mnt/xoom

Find these files from my own android app

• Google data storage documentation

String sd_base = Environment.getExternalStorageDirectory().getAbsolutePath();

This returns "/storage/sdcard0", which is almost right. The double talk from Google on this is: "don't be confused by the word 'external' here. This directory can better be thought as media/shared storage... In devices with multiple 'external' storage directories... , this directory represents the 'primary' external storage that the user will interact with."

All this is well and good (sorta), except there is no standard Environment setting to interrogate to get the honest and for real external storage, so I just have to hard-wire it as /storage/sdcard0. This works, but is hardly ideal. The reason for this subterfuge would seem to be that for a long time there was no support for the external SD slot, so they set things up so that applications that were trying to access external storage would find something (the built in flash card). Now that support for the external card has been implemented, they just don't want to change this, or something.

To scan the directory on the SD card, this works:

File sd_file = new File ( "/storage/sdcard1" );
File [] file_list = sd_file.listFiles();
int n = file_list.length;
String fname = file_list[0].getName();

And by 7PM, we are at somewhat of a milestone, having accomplished several things today:

• We have read and displayed GPS data.
• We have put files on the SD card and read them in our own app.
• My demo now endures sleeps OK.
• The timer handling is cleaned up nicely

Let's display an image

The file "sabino.jpg" makes it there, but the attempt to copy the tpq files just silently fails. Weird. Nothing to be done besides prying the SD card out and seeing if we can get the map files into the Xoom that way. (Planning ahead for some anticipated testing in Phase 2). That certainly works (removing the SD cards, placing it into a USB adapter, copying the files, then replacing it in the Xoom).

Sunday 3-10-2013

I am finding that doing Android graphics is entirely its own game, and none of the material in my Java books (which deal mostly with "AWT", and maybe also with "Swing") are of any help. A great article is the 2-D Graphics guide from Google:

• Google Canvas and Drawables guide

Also worth noting is that Android supports access to OpenGL for games, animation, and high performance graphics.

When I did the game tutorial, it was easy to display a graphic file (in that case a PNG). The tutorial was (before porting to android) a Java applet. An applet has a collection of methods:

• init/destroy
• start/stop
• update
• paint ( Graphics g)

Image img = getImage ( getCodeBase(), "dingus.png" );
Image img = getImage("http://www.myschool.edu/anImage.gif");

g.drawImage ( myimage, x, y, this );

Toolkit = Toolkit.getDefaultToolkit();
Image img = Toolkit.getDefaultToolkit().getImage(URL or file path);

File imgFile = new  File("/sdcard/Images/test_image.jpg");
if ( imgFile.exists() ) {
    Bitmap myBitmap = BitmapFactory.decodeFile(imgFile.getAbsolutePath());
    ImageView myImage = (ImageView) findViewById(R.id.imageviewTest);
    myImage.setImageBitmap(myBitmap);
}

File imgFile = new  File("/sdcard/Images/test_image.jpg");
if(imgFile.exists()) {
    ImageView myImage = new ImageView(this);
    myImage.setImageURI(Uri.fromFile(imgFile));
}

Canvas canvas = new Canvas();
canvas.drawBitmap(bitmap, yPos, xPos, null);

public class myView extends View {

    public myView(Context context, AttributeSet attrs, int defStyle) { 
        super(context, attrs, defStyle);

    }
    public myView(Context context) { this(context,null,0); }
    public myView(Context context, AttributeSet attrs) { this(context, attrs,0); }

    @Override 
    public void onDraw(Canvas canvas)
    {
        super.onDraw(canvas);
	// do your drawing code in here 
    }
}

Here is some other code:

setContentView(R.layout.main);
Bitmap bitmap = BitmapFactory.decodeFile("/sdcard/sample-1.jpg");
ImageView jpgView = (ImageView)findViewById(R.id.imageView);
jpgView.setImageBitmap(bitmap);

• Android Drawables
• Google Canvas and Drawables guide

Drawable d = Drawable.createFromPath(imagePath)

Fix dangerous eclipse keybindings

This delete binding is an eclipse thing. It can be changed. Window --> Preferences --> General --> Keys Then I click on the "Bindings" column to get it to sort, scroll down to "Delete Line" and click the "Unbind Command". While I am there I also unbind Control-F and Control-U and Control-B. Control-B could have been a nice shortcut (for build project), but it says "In Windows", so I guess I am not giving up anything. I hit "apply" and "OK" and now I can safely scroll up and down using Control-D and Control-U.

Get an image to display

• The map image I chose to display
• MainActivity.java
• MyView.java

String im_file = "/storage/sdcard1/sabino.jpg";
File imgFile = new File ( impath );
Bitmap myBitmap = BitmapFactory.decodeFile(imgFile.getAbsolutePath());
canvas.drawBitmap(myBitmap, 0, 0, null);

One thing I was curious about was how a 7.5 minute quadrangle was going to look displayed with one to one pixel mapping on the Xoom screen. The short answer is that it looks fine (I was fearful it might look too dense). The Xoom screen is 160 dpi with 1280 by 800 pixels (on a 10.5 inch diagonal). In comparison, my desktop screen is a 21 inch diagonal with 1680 by 1050 resolution. When I display the same image on my desktop screen, it is 14 inches wide (measured with a tape measure), as compared to 8.5 inches on the Xoom. Although they quote the Xoom as 160 dpi, I calculate 1280/8.5 = 150.6 dpi. By comparison my desktop display gives 1280/14 = 91 dpi.

Phase 2 Checklist

Window --> Show View --> Other --> Android --> Devices

android:debuggable="true"

• LogCat tutorial

• Log.w("myApp", "warning: no network")
• Log.e("myApp", "error: no network")

Window - Show View - Debug - Display

Monday 3-11-2013

I had ideas about using the seek method in RandomAccessFile to maneuver around the file, reading the header and index (this worked fine). I then tried handing the FileDescriptor to BitmapFactory.decodeFileDescriptor, but it kept returning null. Then we read the JPEG image bytes into a byte array, and passed this to BitmapFactory.decodeByteArray. This worked.

Just for the record, once the bitmap is displayed, it would seem to be a good idea to make the following call:

bitmap.recycle();

bitmap.getWidth();
bitmap.getHeight();

Now some mundane screen issues are coming to the foreground:

• Detecting when the tablet gets rotated.
• Finding out what the size of the canvas is.
• Disabling response to tablet rotations.

Orientation Changes

     @Override
     public void onConfigurationChanged(Configuration newConfig)
     {
	 if (getResources().getConfiguration().orientation == Configuration.ORIENTATION_LANDSCAPE) {
	    //do your task
	 } else if (getResources().getConfiguration().orientation == Configuration.ORIENTATION_PORTRAIT) {
	    //do your task
	 }
	 super.onConfigurationChanged(newConfig);
     }

• OrientationEventListener class

Canvas size (and changes)

canvas.centerX();
canvas.centerY()

canvas.getWidth();
canvas.getHeight();

this.getWidth();
this.getHeight();

    @Override
    protected void onSizeChanged(int w, int h, int oldw, int oldh) {
        this.w = w;
        this.h = h;
        super.onSizeChanged(w, h, oldw, oldh);
    }

• Canvas size

After Alan left, the program was displaying a single tile from one map file. I got to work on the code to read the header and index from the TPQ file, and soon had it cycling through tiles displaying one after the other with a 2 second delay. And I modified the onDraw routine to ask for the canvas size and center the tile -- just doing this allow things to work properly when the tablet is rotated from portrait to landscape. Not need to catch the SizeChanged() event.

As a last step I added code that entered the longitude and latitude for Tucson and fetched the proper tile from the US map, centering the tile (leaving centering on an exact coordinate as an easy task for the future). This was fairly easy and adds code that uses information from the image header and knows how the use the index to find a tile of interest.

One thing I am punting on now, but will need to be solved is how to read a double (64-bit) floating point value from the TPQ file (in back-assward byte order) and get its bytes flipped around and acting like a proper float for Java. This is a fairly easy thing to solve in C, but Javas strict typing fights me tooth and nail.

Tuesday 3-12-2013

I do see in the LogCat window that every 2 seconds now Java is doing garbage collection. I don't know if this is symptomatic of my beginning to push memory limits. I hope not.

"Best Practices" and other nonsense

But I can blame the author (Reto Meier) for the following outrage, namely the hitting me over the head with the "best practices" stick. Any groundless appeal to some nameless authority (in lieu of a discussion of why doing something or other is a good thing) is reminiscent of "you are really gonna get a whoopin' when your daddy gets home" and such like. When I hear "best practices", I am immediately eager to jump up and demonstrate how I can do a better job while flying in the face of such admonishments. I don't like people telling me what to do either.
Anyway, enough said.

Full screen display from a TPQ map

And since this is a significant milestone, it is appropriate to put the code up here:

• MainActivity.java
• MyView.java

TPQ file details

		 1  2  3  4  5
		 6  7  8  9 10
		11 12 13 14 15
		16 17 18 19 10
		21 22 23 24 25
		26 27 28 29 30
		31 32 33 34 35
		36 37 38 39 40
		41 42 43 44 45
		46 47 48 49 50

Android interface events

• User Interface Events

The size (in pixels) of maplets within a TPQ file seem to be constant, but different TPQ files at the same level may be different. For example the O'Neill Hills quadrangle (q32113a3.tpq) has all 436 by 256 pixel files. This quadrangle is in extreme southwest Arizona at latitude 32 north. For the North Palisade quadrangle (q37118a5.tpq) in central Calfornia at latitude 37 north, these are all 410 by 256 pixel files. Note that the height in pixels remains constant, but the width shrinks as you head north and longitude lins converge.

Adding motion via finger touches

• Set up a cache of tile objects that hold tile bitmaps. (No sense loading these over and over when doing tiny motions).
• When motion processing, get the event list and process the last item only.

It is also worth noting that I have only written 663 lines of java code to do all this (and there is a lot of debug stuff and cruft that could be preened out of that).

Phase 3 Checklist

• Android 24M memory limit
• Android memory limit

The following note from Google definitely looks worth reading:

• Efficient use of bitmaps

Log.w ( TAG, "memory limit: " + Runtime.getRuntime().maxMemory() );

Another tip is to add this to the Android Manifest and see what happens:

android:largeHeap="true"

• Google documentation of application element

One tip is to do as much as possible using OpenGL Textures, as they work outside of the application memory limit. Either than or go with native code (the NDK). I also wonder about setting up some kind of android helper process to cache maps for me (if it could run as a separate 256M limited process). If I was to rig something like this up it would be good to design it so several of these could be running -- in case I wanted to use this scheme on devices with less than a 256M limit.

• Android NDK documentation.
• Android NDK - getting started tutorial

Last but not least, a quick look at the second link above (getting started with the NDK) makes it clear that using the NDK to include C code in a project is really pretty straightforward and simple.

I found the following tidbit (from the second link above) quite instructive:

So how does the NDK work on the emulator? The emulator is running a true virtual machine, including full processor emulation. And yes, that means when running Java within the emulator you are running a VM inside a VM.

Wednesday 3-13-2013

What about new android tablets

Nexus 10

The huge wart on this otherwise superb tablet is the lack of an SD card slot. This is apparently an "attitude thing" on the part of Google. Here are some quotes:

Google wants to avoid "techy nonsense left over from the paleolithic era of computing". ... "Everybody likes the idea of having an SD card, but in reality it's just confusing for users"

I for one, am not at all confused. This kind of stupid "we know best" attitude, coupled with an unwillingness to listen to users (they know everbody likes the idea of an SD card) will and should spell trouble for them. It is a total showstopper for what I want to do. I might be interested if they offered 64G of internal storage like the Asus TF700, but they don't. 2G of ram is a nice touch though.

Asus TF700

This is "what the Asus Prime should have been", althouugh the battery life is not as good as the Asus Transformer Prime TF201. Asus claims an 8.5 hour battery life, and testers seem to agree (this would be fine by me). A proprietary USB connector is an irritation.

Thursday 3-14-2013

It is time to put all the maps on the sdcard and make a final decision on a file layout. I have decided to make things as simple as possible for the android application. This is in contrast to my philosophy for gtopo, where I put images of the original CD's verbatim on my hard drive and made the application deal with their directory structure and file names. In the new scheme of things:

• I make a directory "topo" on the flash card and put everything in there.
• The two top levels are represented by a single tpq file and the two files just sit in the top directory.
• The three lower levels are collections of files in the directories l3, l4, and l5.
• So, at the root of this tree there are two files and three directories.
• Filenames are all lowercase.
• Within a level, filenames all have the same first letter.
  • For level 3, letters are all "g" ("f" files are ignored).
  • For level 4, letters are all "c" (k gets mapped to c).
  • For level 5, letters are all "n" (q gets mapped to n).

• Just under 20G of disk space consumed by the files.
• 0.2G in 1249 files in level 3 (500K series)
• 2.1G in 414 files in level 4 (100K series)
• 17.7G in 12023 files in level 5 (24K series)

cmp /u1/topo/co_d04/d39105/g39105a1.tpq /u1/topo/SI_D01/US_NW/B35105/D39105/G39105A1.tpq

Work got interrupted when I discovered that my computer at my office was down with serious hardware problems. As it turned out this old AMD socket 939 motherboard, which has been in service for 8 years died today. Its demise was because a plastic rivet holding a heat sink on the motherboard chipset popped loose, the heatsink slipped out of position, and the chip incinerated itself. A stupid way for a computer to die (and the guys in the computer shop say that this is well known and common on AMD motherboards of that era). Of course it is tricky to buy a replacement motherboard (well, actually there are lots on Ebay), so it was time for an upgrade. So now my office computer (which hosts this website) has an Intel i7-3770 (which gives it 8 cores at 3.5 Ghz) and 32G of ram, a significant upgrade.

As for the files on the SD card, the more I think about it, the more I like the simple and clean file setup. I am relying on the filesystem to find files for me quickly from within a directory of 12,000 files - so I hope whoever wrote the filesystem code thought of that and did things right. Doing it this way will certainly make my code much simpler and cleaner than all the crazy things I dealt with in the gtopo program.

On that vein, I am thinking seriously of reorganizing the way gtopo handles files to use the same setup. What I would like to do is to use my "walk" script to load one CD of files at a time into the new simple directory structure. So a gtopo user would have to load his CD's one at a time, running "walk" (maybe renamed to something like "topo_loader") on each CD. This scheme (which would require little or no changes to the script), would easily allow a new state to be purchased and added to a setup. And it would not be hard to write additional scripts to select files from an existing collection (probably by specifying a rectangle bounded by latitude and longitude.

Friday 3-15-2013

Endian issues

It is easy enough to to fix 2-byte (short) and 4-byte (int) integers, but 8-byte doubles so far are perplexing me. This is easy enough to do in C, and actually rearranging a byte array or 8-byte (long) java integer is no real challenge. The trick is convincing the java strong typing that the value is now actually a double. It looks like there is help in the class Double, which offers the following method:

long lval;
double dval = Double.longBitstoDouble ( lval );

• Byte Swapper class

Eclipse has lost the Android ADT

A look at /var/log/yum.log shows (from the wee hours this morning):

Mar 15 03:42:27 Updated: 1:eclipse-platform-4.2.2-4.fc18.x86_64

As an aside, while researching this, I came across the following link, which is a summary of what I have already worked my way through to get to this point. If you have made it to here, you are probably well beyond needing this information also:

• http://fedoraproject.org/wiki/HOWTO_Setup_Android_Development

We really mean it about installing Eclipse in your home folder. .... Do not use your system's package manager. .... Eclipse plug-ins and updates are managed separately from other software in your system.

Instead, what I do is to check the copy of eclipse that I got as part of the ADT bundle, and indeed it is alive and well and talking to my Xoom. What it is missing is the Vi wrapper plugin.

To install the Vrapper plugin into the ADT bundle copy of eclipse, I need to do:

• Help --> Install New Software
• Paste in: http://vrapper.sourceforge.net/update-site/stable
• Click Add and Select All
• Click "Next"

I install the PyDev package, and then go back and install all of the Vrapper packages. What I probably should have done is to just uncheck the Python vi extension and avoid the whole PyDev thing.

Whatever the case, Vrapper acts like it installs OK, but I do not get the familiar "V" icon on the toolbar, and vi mode is definitely not working in the edit window. Who knows what this is all about, but I definitely cannot use eclipse without the Vrapper plugin.

So, it is back to the newly installed Fedora eclipse. I was going to create my own "eclipse" script that would hide the fedora eclipse and warn me that I probably want to run the adt version. I may do things the other way around (which would boil down to nuking my "adt" shortcut).

Installing the ADT plugin in the Fedora eclipse is almost effortless and takes maybe 2 minutes. (It is downloading the SDK that takes a lot of time). Yep, this is/was the thing to do -- if I had only know it, it would have taken 5 minutes to download the ADT plugin and get on with things, not the frustrating two hours. Maybe the moral of the story is to never exit eclipse.

Show a map at a given coordinate

Set up a GIT repository.

cd /u1/repo (on my remote server)
mkdir atopo.git (I will call the project "atopo"
cd atopo.git
git --bare init

New --> Project --> Android Application Project
call it "atopo"  (com.trebisky.atopo)
I make the icon text "Topo" and create an empty new project.
I delete the default layout (don't need it).
cd /home/tom/Android/atopo
git init
create .gitignore with "bin" the only line
git add .
git commit -m "initial project"
git remote add origin cholla.mmto.org:/u1/Repo/atopo.git
git push origin master

Edit the files
git add .
git commit
git push origin master

I notice that the changes I make in eclipse are not always reflected in the files on disk. A key thing about this is that eclipse tells me if a file has not been written to disk by putting a little "*" in the file tab. I can force a write using the vi command ":w", and there may be other ways.

Also, eclipse needs to be manhandled a bit before it recognizes that I have added files behind its back. File --> Refresh along with collapsing and expanding the file tree eventually seems to do the trick.

Saturday 3-16-2013

public static int[] something(){
    int number1 = 1;
    int number2 = 2;
    return new int[] {number1, number2};
}

// Main class code
public static void main(String[] args) {
  int[] ret = something();
  System.out.println(ret[0] + ret[1]);
}

Provider gps requires ACCESS_FINE_LOCATION permission

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"></uses-permission>

Window --> Show View --> Other --> Android --> LogCat

Window --> Preferences --> Java --> Editor --> Content Assist
Window --> Preferences --> Java --> Editor --> Typing

Window > Preferences > Web > HTML Files > Editor > Content Assist

• Pinch zoom

Ultimately, I rolled my own "gesture detection" logic, which actually is not too hard. The first tutorial gave a key piece of advice, a strategy I have employed many time, namely to write a routine to log motion events, then study the log and discover just how things work.

Tuesday 3-19-2013

AndroidRuntime  java.lang.OutOfMemoryError

Wednesday 3-20-2013

Today I spent several hours doing code cleanup (and regression testing at key points in the reorganization). I did away with the internal "Level_info" class and reworked the Level class to allow external access only through class methods. Internally it has an array of Level class instances that it hides and uses. This is much nicer and cleaner than the previous arrangement. I also eliminated the MyLocation class entirely, absorbing it into the Level class and adding a handful of class methods. The Location class was shrinking and was a singleton anyway, supporting only the lat/long coordinates of the center and ways to change the position. Things became simpler and cleaner when these just became global (static) fields in the Level class.

Doing this now was essential. The ideas would fade from my thinking, and a tangle of code would remain forever.

Thursday 3-21-2013