Ladies and Gentlemen, we have concurrency! By that, I mean that my test application for MM with Käppler’s interface seems to be working 100% as expected. All that I need to do now is patch the concepts from my proof-of-concept into real MM. I’m going to do my best to get that done between today and tomorrow, and hopefully have a video made by mid-next week.
Things are going to be a little crazy once the semester starts, I’d imagine, but I’m going to try to keep up with MM. I’d like to be able to keep improving on it through the semester, potentially adding things like the Notifications that Daniel found for me. Rob and I have also talked about working up some cool ideas for the hierarchy views, which is particularly exciting!
Stay tuned for a new MM video which should be dropping by the end of next week!
If I were clever, I’d say that it is “you don’t talk about programming”. Since I’m not clever, I submit that the first rule of programming is “check to see if somebody else already figured it out”. The answer is yes at least 85% of the time, and usually that person did a better job than you would if you’re rushing towards a bigger and better goal. On that note, I found this cool thing today.
I’ve been thinking over approaches for dealing with the issue of MM getting onPause()’d, and have tried my hand at a few snippets of code so far. I still rather like my approach of the downloads happening in a service while the background thread deals with sorting results. I believe that Käppler‘s approach will save me a lot of time on coding my onResume()/onPause() and generally laying out the structure. I haven’t studied his code intesively enough yet, but it already looks much more promising than what I frantically hacked up last week on the subject.
So, next time you’re about to scratch-code something difficult, talk to Uncle Google and see if some helpful person already solved the problem for you! 🙂 …and that is all from me for the week, as I’m going on vacation. Enjoy the silence!
Today we continue our lesson on Activities and Intents. In Part One of our discussion, I explained how to switch Activities within a single application. This time, we’ll discuss how to launch an Activity belonging to another application. I will use as an example some code from my work with the OpenIntents FileBrowser. Check out the Read More!
Triple M?! You betcha! Up until about five minutes ago, I was under the impression that when somebody navigated away from Mobile Metagenomics, I had to drop everything. I envisioned stopping my download thread, saving current results, saving iteration values, saving a mode variable, and whatever else was necessary to later restart whatever MM was doing. I even wrote pseudocode for it yesterday, and spent the first half of today implementing it.
I’m glad I decided to take a short break and read about Android stuff, because as it turns out I was flat out wrong about onStop(). Apparently, I can actually let my worker thread busily download new chunks of data into MM while a user is checking their email, making phone calls, IMing their friends about how cool Edwardslab is… And if the phone needs additional memory and has to kill the MM process, I believe I can actually store & create aforementioned variables at that point. Which is cool not only because we get to save our progress, but also because I don’t have to crumple up two pages of pseudocode
I was starting to feel like MM might be getting close to finished (unless Rob and I do some kind of cool file browser-esque navigation of results, in which case I’ll probably have to spend a week just learning the Biology), but now I have a new thing for my brain to chew on for a bit. I feel like doing the annotation downloads as a background process adds quite a bit of value to MM as an application. The user may choose to view the results as they happen (which is the original intent of Real-Time Metagenomics to begin with), but they will no longer be locked into MM. Even as a developer I hate the notion of “okay I started MM, now lets have it sit there for 3 minutes”, so I can only imagine how much users would’ve disliked that.
As far as progress since my last post about what I’m actually working on, I’ve got a fair amount of error detection/recovery implemented in both Genome Search and Mobile Metagenomics. I’m not going to say that I can detect and recover from everything (because I’m sure we’ll find some obscure way to break the app), but it is looking pretty solid from my tests. Through normal use, it shouldn’t do anything weird anymore. Note that ‘normal use’ still confines us to being locked inside of MM unless we want to lose all progress. That is, until I get this next part figured out!
Today we’re going to do some fun Activities together! Perhaps it would be more fair to say that we’re going to have fun learning aboutActivities. In Android! In this article, I will explain the Activity model, how to use it, and tell you why I like it. Interested? Check behind the Read More!
This episode of Nuts and Bolts puts us back on course with what I had originally planned as N&B 3 – “Threads, or, How to Not Blow Up Your New User Interface”. We’ve already discussed how to make a UI, and we’ve talked about how to make it work. The next logical step is to learn how to make our application do something meaningful. For simple applications this may not mean using threads, but any time your app needs to A. sit around and wait for something, or B. do intensive computations, you will need Threads. Become an Android sewing master by clicking the “Read More“!
One of the tasks that I’ve been meaning to work on for some time is doing some actual error recovery for MM. I realized however, that not only is this a pretty big problem to get a hold of, I also never did it for GenomeSearch. Since we want to put both on the market someday anyhow, I figured I may as well start with the more simple app and get some practice.
I took Daniel’s network status checking snippet, stripped out the textview stuff specific to his test app, and turned it into a small boolean method for GS to query. Now, when the app launches, it checks for network availability before it tries to fill up the list of Genomes. If it should fail, I have an alert dialog method which either recurses on itself until the network is available, or closes the program. The user is able to click ‘Retry’ or ‘Quit’ to achieve either option. In the future I may want to add an arbitrary delay between re-tries, or we may choose to just leave it with no delay.
I also put into place a little bit of code to let the user know if something goes wrong anywhere along the GenomeSearch process. This part isn’t quite done yet; I had most of the code in place last week, but due to some complexities I didn’t anticipate I had to not use any of the cool Toast error pop-ups. (Specifically, the methods I put the Toasts into are called from both the UI thread and a worker thread. The worker thread isn’t allowed to perform the toast pop-ups, and I had forgotten that we were using a worker thread in GS, so I have to work around this a bit.)
I have the solution to the Toast issue about 75% in-place, but I need to do a couple more things and then test it before I call it good to go and move on to MM. I had honestly been dreading the error recovery stuff, but once I traced through GS, it was actually very easy. Not only that, but I made some passing improvements to the code as I went along! MM is a bit more work to trace, but I already did a preliminary run-through, so I should be able to tackle this in the coming week 🙂
Before I show you cool things, you’re probably wondering “what the heck is OpenIntents, Josh?” Well, OpenIntents is a pile of awesome pieces of code that work independently as useful software, but are also a great resource to tap for other projects. In my case, Mobile Metagenomics has been sitting around with a broken “Browse” button since the first day I made the layout. I knew that there were a handful of open source file browsers out there that I could use, but none of them seemed to work for me.
Today I tried pulling down the OpenIntents source directly from their svn repository, and it fixed all of my issues! The final result? When you click browse, this happens:
Android: Nuts and Bolts IV could easily be titled “The Right Way To Do Android: Nuts and Bolts III”. Since writing my last entry discussing Relative versus Linear Layout, I have made an important discovery! Table Layout actually solves the problem much better than my previous hokey tinkering did. (In fact, just bookmark that page, or print it out and frame it or something, it’ll save you a lot of time.) I also learned some really cool stuff about phone orientation changes, alternate layouts, and alternate resources in general.
For a more detailed description of TableLayout and other neat stuff I’ve learned since N&B III, check behind the Read More cut.
I recently tested the code for the share options on my Ion and I’m proud to say they work perfectly! Well, with the exception of the browse button not working yet… (that is next on my list!). Now, users are able to press the share button, and choose an output format: .mmr for sending results to other phones, or .txt for sending results to computers. The text version has been tested in Windows, Linux, and Mac environments and is viewable in all three. One application that has problems with the output is Notepad in Windows; the WordPad application works fine, and is an acceptable alternative.
Another thing I’m happy to have done is the registration for the Android Market. In the future I’ll be able to upload our lab applications to the market where they will be available as free downloads to anyone with an Android phone. It was a pretty simple process to go through, and would’ve been really quick, but I decided it was probably a good idea to actually read the license agreement… Either way, I am now set up to upload our apps! Big thanks to Rob for paying my Market fees! (I’ll be sure to remember you when I make my imaginary millions on MtgHelper…)
I’ll have to talk it over with Rob, but I think there are only a few adjustments I’d like to make before releasing initial versions of GenomeSearch and Mobile Metagenomics. Both applications currently have no provision for warning the user of poor/no internet connection – this results in application failure and is unnacceptable for Market-deployed apps. The other issue is that MM needs to have the browse button coded, which requires me to either code a file browser by hand or somehow incorporate one which has been written by others. Once I complete these features, we can consider deploying the apps on the Market.