Monthly Archives: June 2009

GenomeSearch v1 (Kind of…)

Today I successfully ran what I would call something like an alpha v1 of GenomeSearch. It works on a real Android phone, connects to the internet, loads genome data, performs the search, launches the web browser app when you click links, etc. I haven’t created a program package for it to run stand-alone yet (i.e. without being initially installed and launched by Eclipse on a PC that the Android is USB-connected to), but this is a possibility in the near future.

Two things that Daniel and I want to change with the current version of the app are the lack of a prompt above the box where a user is supposed to enter a genome (as this is very confusing to those who didn’t actually write the app), and the fact that the onscreen keyboard doesn’t minimize when the user performs a search (which blocks search results). At present, the user can hit the ‘back’ button to minimize the onscreen keyboard and free up more screen real-estate for results, but this is obviously not desirable. Clearly, the back button is calling some method to minimize the keyboard when the user presses it, and once we figure out what that method is, we can fix this UI clunkiness.

EEEBuntu wireless gotcha & connecting an Android by USB

A few misc. Ubuntu and Android notes today:

1) I said a couple days back that I’d write up some EEEbuntu gotchas that I had a whole barrel of laughs with over the weekend. This one had me reformatting my EEEPC, so I think it qualifies. In the USB stick install, there is a nice convenient wifi notification on the top/right portion of the screen. When you actually install the OS, however, this isn’t present. I’m not good enough at linux (apparently) to figure out how to launch that wifi app, so this left me without a way to connect wirelessly. I did some googling and it turns out that you need to Right-click the menu bar at the top, and navigate to ‘add a notification’ (I can’t recall the exact path and I couldn’t google up any guides). NOTE: At this point you MUST restart EEEbuntu. You won’t get any confirmation that you added your notification successfully, and it will not show up until you restart. This is all you have to do to fix the wifi. (I won’t tell the whole story, but the basic jist of my reformat is that I sat there and added about 8 notification areas without rebooting, and when I tried to delete them I blew up the whole top menu bar and couldn’t get it back…)

2) Preparing your Android development environment to include real-phone testing! (This one is pretty cool once you get it working)

Essentially, just follow this guide, however there are a few little tricks. First of all, if you’re doing it on Ubuntu, all of those steps may not make it ‘just work’. As for which of the two strings to put in your rules file, Dapper and Gusty/Hardy are older version of Ubuntu, but string that worked for me was: SUBSYSTEM==”usb_device”, SYSFS{idVendor}==”0bb4″, MODE=”0666″

Secondly, keep in mind you’re going to need to use the sudo command before just about every command related to this setup. (For those of you who, like me, aren’t well versed in linux, this gives you ‘root’ priveleges to do administrative stuff. If you don’t include it, the terminal will complain that you don’t have the rights to do things like save your rules file). My third tip is to restart your udev, which I found on the anddev.org forums. Use: sudo /etc/init.d/udev reload. Finally, use adb kill-server before you adb-devices if your device still doesn’t show up (but is connected). This was the magic trick that made it finally work for me (also from the same anddev.org forum post-that place is great).

GenomeSearch Update

So far today I’ve made the actual search function itself work, added hyperlinks to the search results, and added a scrollbar for results which take more room than is available. Additionally, the work for the search now happens in a second thread, so it doesn’t lag the User Interface and generate ANR (Application Not Responding) events. So instead of the UI seeming like it hangs when the user presses the search button, a progress dialog is displayed instead!

One notable performance issue with the application is that the AutoCompleteTextView currently available from google is a little slow, and tries to perform matching too early. I looked around the web and others have grumbled on blogs about this issue, but until Google improves this part of the API, I don’t think there is a fix.

GenomeSearch Update

So far today I’ve made the actual search feature itself work, added hyperlinks to theseed.org in the results display, and added a scrollbar to display results which take more room than the screen has available. In addition, the bulk of the search work now happens in a separate thread from the UI and a progress dialog is shown. I’m pretty happy with the performance of the app now, with one notable exception being that the Android AutoCompleteTextView code is a little on the slow side. This has been noted on a variety of Android blogs and such, but there doesn’t seem to be any way to improve it other than writing a new autoComplete class entirely.

Graphing data

Spent the morning graphing where the matches started on the HIV genome in a sliding graph format.  I’m meeting with Dr. Wolkovicz later to hopefully find out what it means.

Weekend update!

I spent some time this weekend working on GenomeSearch and doing things to my EEEPC, so I could round out my hours for the week (stupid jury duty…).

GenomeSearch update: I tweaked some methods a little bit, and coded the actual search behavior of the app. It isn’t working just right quite yet, but I’ve narrowed down where the problem is. It seems like after I build my hash of the results, I’m not pulling the data out of it correctly. This is likely what I’ll work on tomorrow.

As for the EEEPC, I like the look of the EEEbuntu that Nick gave me. I’m hoping it’ll run my development environment better, because the WinXP was really sluggish on the Android emulator. I managed to delete my taskbar on my last install, so I’m setting up a fresh install now. I’ll write another post sometime with some EEEPC/EEEbuntu gotchas, incase anybody else wants to do this install!

Summer Research Plans

Today I spent the first half of my day working on the GenomeSearch Android app, and the second half of the day tieing up loose ends with my old bbhFinder perl script.

I still need to verify the correctness of the last bit of bbhFinder at some point, but beyond that I’ve coded everything I set out to. I’m thinking of shifting my focus to the Android development for the summer, as I’ve been working on bbhFinder for over a full semester at this point. The Android development is also looking very promising at the moment, and satisfies the cell phone grant!

I thought I would make a few notes for either myself or anyone who works on bbhFinder (or related projects) in the future. Here are a few areas where I think the project could be improved:

As it stands, bbhFinder has several features, and a number of output files. These are currently all performed every time the script is run, which would likely lead to more work being done than a user cares about in a given sitting. This could be done better if bbhFinder asked the user which features they would like performed.

To achieve this, a simple GUI could be implemented which would have checkboxes for each feature, and a ‘Run’ button to perform all options checked. Further, the code could be broken up and organized a bit better, such that the main method is simply if(option1IsChecked){perform method 1} and so on. This would also increase readability of the code, which never hurts!

As for GenomeSearch, I finally got the spinner working today, and it shows every genome that the drop-down box in the opensocial app does!

Android Manifest & Permissions

Another in my series of ‘Android development gotchas’.

At Google I/O they made a very big deal over how programs need to request permission from the user in order to access most resources (user’s GPS location, the internet, files, etc). This is an easy one to forget during development however, and it slipped through the cracks on me twice. I actually corrected this problem early this week, but we had to remake our project from scratch due to other issues and I forgot to add the permissions again. Since it caused me a fair bit of headache I thought I’d write up a quick how-to on permissions in Android.

There is a file called the Android Manifest which holds various information about the program (this is generated for you when you make an Android project in Eclipse). Included here is a list of permissions that the program requires. Without these, attempts to do things like accessing the internet will fail. To add permissions, you basically:

Double click AndroidManifest.xml, Click the Permissions tab (at the bottom of the window it brings up), Click add, Click ‘Uses Permission’, Click the ‘name’ dropdown, Find the permission you need and click it. That’s all!

If my pure-text description is less than helpful, I used this link as a guide to figure this all out.

 

Debugging Android apps in Eclipse

This proved to be a little tricky for me. I ran into a problem where Eclipse wouldn’t show me my variables in my Android app.

Apparently, you can only inspect variables in a specific scope within an Android program. You can’t see class variables, etc. In order to see any variables at all, you need to set a breakpoint somewhere near the area you suspect is a problem.

I’m not sure if I needed to do this, but one other thing I did before I got the debugger to finally show me variables was adding the tools directory to my PATH. The explanation for this can be found in this guide. Note that those files are hidden, so you’ll have to learn how to view them on whatever OS you’re using!