Programmers, mind your rat holes!

I’ve spent good chunks of the last week ‘throwing time down the rat hole’ as we say around my house.  But it wasn’t till this morning that I got a clear picture of which rat hole(s) I was actually diving down and managed to plug two of three.

I don’t have an easy relationship with Eclipse.  I’ve spent years cursing the Visual Studio IDE, as it slowly matured, and can’t claim even now that VS is better that Eclipse, only that a) it HAS gotten much better and b) I know it well.  I can navigate its gotchas just the way I avoid the gravel and ruts on the shoulder of the highway along which I ride my bike two or three times a week.  They are there, but not particularly in my way.

OTOH, whenever anything goes wrong with my Android development environment, I find myself reflexively blaming Eclipse and trying to find a way to whack it upside the head so it will tell me what’s going wrong.  Eclipse CAN be the problem, as I was assured by this nice little (old) article on how to clean the cruft out of your Eclipse environment.  But this time, Mercurial/BitBucket, Java, Eclipse, and I all had some share of the blame for the insanity that descended upon me.  I think I’ve resolved everything BUT the Eclipse issues, but once more I could be blaming the victim for my own stupidity.

Ever since I pushed Sara’s changes to PasswordRN up to our BitBucket repository, I’ve been trying to reliably execute on the following simple ‘new developer’ exercise:

  • Clone the respository to a new, fresh location on my harddrive.
  • Run Eclipse and ‘import’ the project, which Sara pointed out is best done using File/New/Project/Android Project and telling Eclipse you are creating the new project from existing sources.
  • Build and run the results.

What was particularly frustrating was that I was sure I saw this work correctly at least once but could never recreate that success.  And Sara reported ‘it worked fine for her’ but when Hokan and I tried it again the other day, we wasted two precious hours hacking around trying to get the project to build and never succeeded.  And each step I took along the path of trying to diagnose what was wrong and how to fix it just seemed to make less and less sense.  But, enough with the emoting, here’s some useful detail for posterity.

1) Mind your empty folders.

1A) You push a working project to BitBucket, clone it to a new location, add the project to your Eclipse workspace, and try to run it.  Eclipse gives you a message box that says:  “Your project contains error(s), please fix them before running your application.”  In the Problems tab, you see an error message that says:  Project ‘PasswordRN’ is missing required source folder: ‘gen’. Ok.  Alright.  This is a known issue.  In fact it’s a perennial problem with source code control tools:  You don’t want to store your generated files in the repository.  But version control tools don’t like to store empty folders.  So when you clone, you get a folder structure that is missing folders under \gen and \bin Eclipse and Java expect to see ready for them.  This fix SHOULD be easy.  Add a ‘readme.txt’ or other small file to the bottom of each folder tree that you need to get back from source code control.  Check in that file and and keep ignoring the generated files.  Now, when you clone/pull, you’ll get the folder structure you need.  But, this time, watch out!

1B) The above worked great; I verified all the folders were in place after I cloned and before I imported the project into Eclipse.  But, then I imported the project into Eclipse and got the same message.  Huh?  After the looong detours represented by items 2 and 3 below, I finally figured this one out.  Either Eclipse or the Java compiler (doing a premature automatic build step, maybe?) ended up deleting some of the folders as I imported the project.  The fix is simple, just double clutch:  clone and get the full folder folder tree; import the project and the folder tree gets mangled; go out to DOS or Explorer and revert your file set to get the full folder tree back; refresh in Eclipse; and now everything builds just fine.  (I didn’t do telephone tech support for all those years without developing good hack-around skills, eh?)

2) Mind your classpaths. I know, I know; any Java developer worth her salt already knows this stuff.  But I’m just barely a Java developer.  (I can’t WAIT to see how much trouble I can make for myself tweaking the ObjectiveC/Xcode for my iThing version.  Sheesh.)  As it turns out, classpaths were NOT my problem at all, till I misunderstood the ‘buildpaths’ message above, did some dumb stuff, and made them into a problem.  OTOH, reading that article about them made me understand what a bad job I had done with constructing my original package name.  And, since it is often useful, while waiting for problem-solving enlightenment to strike,  to do something, anything, useful, I spent rather a lot of time today  cleaning up my package name and dealing with the source code, folder, and version control chaos that created.  So calming, sometimes, to deliberately break the code in a way that you think you understand and then bring it back to working again, step by step.  Gives you back that sense that you might actually know what you are doing.

3) Mind your Eclipse workspaces. Now we get to the embarrassing bit, the point at which I have to admit I have a problem I still don’t understand, don’t know how to understand, and have decided to just steer around for now.  It’s not as if I ever claimed to understand Eclipse workspaces; you can’t say I did.  But now I’m just plain confused and worn out. Ok, listen carefully.  If the empty folder problem is solved and I import the project into my original workspace, the one where I’ve already done Android development, using the double-clutch technique described above, the cloned project builds and runs fine.  Whether I delete my original project or not.  But, if I create a new Eclipse workspace and then do exactly the same thing, then every one of the classes in my project that implements an Android interface, as well as deriving from an Android base class, now has the error message:  “The method onClick(View) of type AddEntry must override a superclass method.”  At least now I know the difference between when importing works and when it doesn’t.

And I even think I know what the error message means — it means that the project isn’t handling its imports correctly. It’s as if I did NOT have the line:

import android.view.View.OnClickListener;

at the top of my source code file or as if the environment wasn’t set up to interpret it correctly.  But I do, of course.   And, weirdly, I can create a New little Hello World project, in the same workspace, and it implements OnClickListener and builds just fine.  So, you’d think, maybe, if NOW I delete my imported project, and re-import it, it would build.  I try that.  No joy; no build.

So I have a ‘healthy’ workspace and ‘unhealthy’ one.  And now I know which to use.  Duh.  But, what the heck is really going on here?

Time to get on with other stuff and wait for wisdom to filter in, from more experience, from someone telling me what is up, from ??  The rat holes have had their share of me this week.  Enough for coding and trying to do the fun technical stuff . . . time to write a business plan.