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 🙂