Monthly Archives: June 2009

Multiple Background Threads in Android

One of the main things that came out of my Android tinkering today was knowledge of multi-threading. The threading technique used in GenomeSearch had ‘multiple’ threads as well (2), but the implementation was a bit lacking. Without going into too much detail, GenomeSearch has one (main) thread which manages the User Interface, and one background thread that blocks on network I/O. Unfortuantely, the implementation is such that if we had ever needed a third thread, we wouldn’t have been able to add it.

So, with a little help from this conversation on Android Beginners, I wrote up a little snippet to test running multiple background threads in addition to the main UI thread. You can find the code behind the cut (note that you will need to set up all of the other project files for this to work (layout, manifest, etc).

Continue reading →

Ion Successfully Tethered!

After a couple more hours troubleshooting stuff with the hacked su permissions, I’ve succeeded!

I am currently posting this from my netbook, which is tethered to my Ion’s 3G connection Laughing So if anybody needs this set up, or is stuck somewhere in the process of doing it themself, let me know. Once you find the right system image to install, it actually works very quickly and easily.

Ion Successfully Rooted

I spent most of the day Friday scared half to death that I was about to brick my Ion, but the end result was a success! I got a shiny green # prompt in my terminal and I can now proceed to do fun things like download multitouch enabled apps and try out tethering 😀

I had some issues getting my phone linked back up to the T-mobile network after I installed the hacked OS, but the awesome folks at the XDA Forums helped me out. If anyone in the lab (or friends of the lab) would like their Ion rooted for them and tethering enabled, I can set it up for you. The rooting should take less than 30 minutes or so if all goes well on it. I haven’t done the tethering yet but I’m going to work through it for a few hours today.

Edit: But I’m not responsible if anything terrible happens to your phone! Surprised

Edit #2: After ~4 hours of working away at it, I hosted wifi from my Ion to my eeePC!!! Unfortunately, I can’t pick up 3G at my house, and the connection is terrible in general 🙁 So I can’t be 100% sure that everything is working perfectly until I’m somewhere with a better connection. Things look good though, and the tethering app I’m using is very cool as well; you can host wifi or bluetooth connections to the Ion’s 3G!

Apache errorlog

In case anybody will look for the Apache error log on a machine (e.g. edwards), this may save you the half-hour I spent to re-find it:

/var/log/httpd/error_log

Introducing Mobile Metagenomics!

Mobile Metagenomics is the name of my latest project. What I am trying to achieve with this Android application is a mobile implementation of Rob’s Real Time Metagenomics webpage. I envision several development phases for this application, but the first stage will likely play out as follows:

1. Create a suitable UI (striking some type of balance between preserving look&feel from the website, and Android-ifying things)

2. Generate a request that the CGI online will recognize

3. Receive the results and organize them in some manner

These three tasks represent a bare-bones version of the application, but there are quite a few things that should also be added. I would eventually like to add: A file browser feature, connection type detection & large file warning, poor connection detection & retry popup, efficient results display, perhaps display of results as they are downloaded to take full advantage of the ‘real-time’ aspect of Rob’s website.

How to annotate a metagenome

First, you’ll need a fasta file. There is one here called 51.hits.fa that I like because pretty much every sequence will hit, and its reasonably small. And yes, it fits on the sd card 🙂 (it’s 1.2 M).

Go to this website:

http://bioseed.mcs.anl.gov/~redwards/FIG/RTMg_cellphone.cgi

There is a really vanilla upload form. It takes the following options:

a. ‘uploadedfile’ – this is the file name in a file input field.

b. ‘stringency’ – an integer between 1 and 4

c. ‘level’ – an integer between 0 and 5.

  • 0 : function
  • 1 : Subsystems
  • 2 : One level hierarchy
  • 3 : Two level hierarchy
  • 4 : Three level hierarchy
  • 5 : OTUs

At the moment only levels 0 and 5 work – the other levels return the same results as level 0. I’ll fix that soon.

Of course, if you know how to make a call with a file in a POST method, you don’t need to use this form!!

This will return a JSON formatted string like this:

{"max":"3","url":"http://bioseed.mcs.anl.gov/~redwards/FIG/RTMg_cellphone.cgi?annotate=1&stringency=2&file=18601&level=5&number="}

There are two values, a URL and a max. In this case the max is 3. You need to call the URL with 1, 2, and 3 appended to the string to get the data for each fraction of the input file (ie. from 1 to max times).

Calling the URL will return another JSON formatted object that is basically a hash where the keys are the functions, subsystems, or OTUs, and the values are the number of occurrences. Each time you call it, sum up the numbers and display them somehow.

 

 

File Upload A Success (on a real phone!)

I finally got the upload proof-of-concept application to work on my Ion! As it turns out, the problem was actually the registration page for the university wireless network…

There is a redirect page the first time a new device is connected to the network, which requests some simple information like a name and email address. This page was apparently being loaded behind the scenes in my application, and giving me some strange errors (file IO errors for the website) in the ddms log. I likely would never have discovered that this was the problem, had I not opened up the actual web browser application, as was suggested by this post on Google’s Android Beginners.

Basically, the suggestion found there is to try to access your file upload page in the normal browser (even though that application disables file uploads!) to confirm that you can actually access the page from the phone. I know it saved me a ton of time, so I definitely recommend using this technique Smile

Android Debugging Protip & Mini Upload Update

I’ll start off with a very useful tip if you’re doing any Android development: use ddms and logcat!!! I heard this several times at Google I/O and even attended a talk about it, however, my work computer’s Eclipse doesn’t seem to want to let me use the DDMS perspective. Daniel’s works fine, and I found a work-around (close eclipse w/ emulator running, run ddms from terminal).

The DDMS tool allows you to view the phone’s (or emulator’s) file system, browse logs, and many other things. I find the logging aspect particularly useful though; not only can you browse for any messages where the OS thinks something is happening, you can actually insert your own debugging statements. You start to miss System.out.println pretty early on in Android development, because variable visibility in Eclipse’s debug mode is a little hokey (for some pretty complex reasons which are beyond me). However, the solution is of the form: Log.e(“MediaPlayer”,”Hey! I’m writing a statement out to Logcat at this point in the code!”);

I’m pretty sure MediaPlayer can be whatever you want too, but the snippet I found had that in it, and I haven’t tried to change it. (All it does is categorize the log messages)

As for my mini-update with the Upload code, it works again!!! The issue was with the file system, as I suspected. I’ve fixed the stupid things I did to it, and all is well. I can upload from emulator to octopussy flawlessly, but real phone to octopussy is still a no-go. I think it may have to do with internet permissions on the phone, but I’m still testing. I hope to blog some success on that front either later today or Monday!

Uploading Files from Android (progress update 2)

Right before I left the lab yesterday, I uploaded from the Android Emulator to Octopussy successfully. Daniel was here, he’s my witness.

Today, it doesn’t work, which is super awesome. It isn’t a matter of computer goblins or anything like that though, the Android Emulator was running a pseudo-SD card which I had manually pushed my test file onto. That is the only thing that changed from yesterday to today, so something has gone wrong with the file system. I’ve been making some attempts to get away from using the SD cards for my testing, because it is a bit unpredictable.

I wrote some code to generate files based on user input, but I’m getting the same crashes from that as I do from the SDcard version. I have a feeling it has something to do with file permissions, because when I browse the emulator’s file system with DDMS, the permissions on files I’ve pushed are all weird and different from other ones on the phone. I started having some issues yesterday with command line sdcard management, and I switched to direct code/DDMS options, which is probably why it is acting all weird.

Once again I’m really hoping I can get it up and running soon! It was really exciting to see it run successfully yesterday, and pretty disappointing to have it crash today 🙁

Uploading Files from Android a success! (locally)

Shortly after my last post I actually had a pretty major breakthrough with the upload proof of concept. I managed to get my Android application (running on the emulator) to upload a file to a server on my local machine. The PHP approach to the problem ended up being the way to go. I added a post to this thread which had been confusing me for about a week. Tons of people posted saying “it worked” or “this is the client side code that worked”, but nobody simultaneously posted the PHP and Client-side snippets which worked for them.

I found the XAMPP server application very helpful as I worked on doing the initial proof of concept. It creates a server on the localhost of your machine, so you can test web code without actually deploying it on a server (which is a whole other set of headaches-the ones I currently have!). One little gotcha that Carny helped me fix is that the permissions on the directory you want to upload to – they need to be such that your ‘server user’ has permissions to write to that directory (or just chmod 777 but be aware that this is NOT the good/secure way to do it – it works if you just need to test it and set it back afterwards though).

Another interesting thing I learned today was how to add a faux-SDCard to your android emulator. Just run the commands on that site in a terminal (from your tools directory). In order for the file upload to work, you need to manually push the file to your Android’s SD Card!

Also, please note (and I’ve forgotten it twice already since learning it in that tutorial…) that the directory path given in that link is NOT what you want to put as your own eclipse path. It looks deceptively like some super-secret google pathname, a G: drive, Android, SDK_Root, etc. However, this is just the path that the creator of the tutorial happened to have on his PC. You need to insert the path to the sdcard you create!

My next task will be to get the file upload working from a real Android phone to an actual server. I’ve been working on getting the uploader.php to run on Octopussy, but so far I’m getting errors. The PHP that I set up seems to be working fine though, which is nice to see. Hopefully by tomorrow I’ll have it all up and running!