Wednesday, May 11, 2011

The Android Market is FULL of Viruses!

I first heard those words from a gadget loving iPhone fan-boy whom also happens to be a very good friend of mine.  We don't often discuss the pluses or minuses of the 2 platforms because he's not a geek.  He is, by all accounts, in love with anything Apple is willing to put on the shelves for us to consume.

He does ask how my application development is going and is at least interested in that I'm interested.  He asked me one day about all the viruses in the Android App Store and when refuted by me had the evening news on his side.  He did concede that they weren't necessarily viruses in the traditional sense, but rather poorly written applications that cause performance problems, consume more data than they should, etc.  I exclaimed that if that were the classification for a virus then Apple's own machines are the preferred platform for the world's leading virus ... Photoshop.  :)

His comment and the opinion of the main stream media stuck with me.  I can't do anything about it, but it did get me wondering about the complete lack of an approval process for Android developers' submissions.  Apple has one.  Windows Phone 7's is unbelievably thorough.  I have had 2nd hand experiences with both.  Android has none.  That helps keep a low cost to entry, but it does open the door for some poor code to end up on users' phones.

Thank goodness there are a few good developers out there writing quality code; like me!  But wait, I wrote a "virus."  It's true.  I downloaded the Android SDK, the Eclipse ADT plugin, Eclipse and even the Subclipse SVN plugin.  I have source repositories setup to store my code change by change and I maintain this blog to discuss the application, coding in general, etc.  I can Google anything and figure out how to make something work.  That doesn't mean that's how it should or needs to work.  Therein lies the problem.  I can write some fancy code, but you don't know what you don't know!

So, why was my app a virus?  Several versions ago I switched the UI to a tabbed view.  There was major refactoring involved in doing so.  Shortly thereafter I was experimenting with JSON string parsing and how that might benefit my app.  I was debugging something in the JSON app I was building and had left the DDMS perspective in Eclipse open while I was researching.  I kept noticing screen updates in my peripheral vision but it wasn't until I stopped what I was doing to investigate that I realized I had a coding mistake.  My other app had been opened to do some other work and it was the culprit.  It was requesting a new ad from AdMob even though the application was not in the foreground.  It should have been paused and had no activity going on.  In all the refactoring I had lost my onPause() method.  After getting that back into my code things were normal again.  Thank goodness it was for something as small as an ad!

That spurred me to start doing some reading on the Application Life Cycle.  There's fabulous documentation on it provided by Google.

So is the Android Market really full of viruses?  I can tell you that I've seen some really crappy code over the years.  I can also tell you that I take special care (certainly more than most!) to understand my code and do extensive testing.  There are no formal checks and balances and even with the best of intentions my code was consuming more data and thusly more battery power than it should have been.  Whether it's full of viruses or not I know that it has 1 less as of several weeks ago and I will be much more conscience of how my phone performs after I install something new.

Tuesday, May 3, 2011

What Goes Into Source Control, Android?

From the very beginning of my Android App development I knew I would be releasing it into the market.  As such I wanted to keep it in source control.  I'll explain my reasons for that in another post, but here I want to talk about what exactly goes into source control, what to do if you inherit a project that needs cleaned up and finally, how to coerce Eclipse into helping you long term.

I had never created a project outside of Eclipse's new Android Project Wizard so what was part of it's overhead versus what was needed for someone else to build this project on a difference machine?  I asked a few guys around the office and Stack Overflow.  As is always the case I got, "whatever isn't required to build the project doesn't go into source control."  Thanks geniuses.  At least one of them actually pointed me to the official documentation from which I could start to cherry pick the fluff out of my project.  Here's the official documentation on what is required for your project:

My development environment is Eclipse with the Subclipse SVN plugin and I'm using online repositories from both BeanStalk and Assembla.  A quick scan of my repository and I was a little bummed to find several things in there that did not need to be:

  • bin/
  • gen/
  • .classpath
  • .project
  • proguard.cfg
A friend and longtime developer asked me why I wouldn't want .classpath included?  Our office has a mix of both Windows and Linux development platforms so I've tried to mimic that as often as possible when doing personal development so I'm familiar with the challenges faced by my colleagues.  Everytime I would sync my local machine after the alternate environment had updated the repo I had .classpath issues.  Some of this could be my own inexperience so if you know the way around this please share ;)

Back to the point ... I did some research and found that I needed a local SVN client in order to accomplish what I wanted to do.  The command is:

svn rm --keep-local {filename/folder}

Execute that for each of the files or folders you wish to get out of source control, but keep your local copy.  I had read on SO that you needed the trailing / after folder names, but I've found that to be inaccurate.  Simply listing the folder "bin" works and actually adding the trailing / does not.

After running the svn command to remove (rm) each of the items I wanted out of source control I executed a commit:

svn commit -q -m "Removing unwated files/folders from source control" .

The next thing I did was set the filesystem level properties to keep them from accidentally ending up in Source Control in the future, but it is leading somewhere.  You can execute the following command from your project folder to add the items to the ignore list:

svn pe svn:ignore .

Just add each item, 1 per line, as above again excluding the trailing / on folder names.

I had tried to do all these things in the SVN perspective from within Eclipse but it would not let me set file/folder properties.  That's what lead me through the exercise outline above.  My next goal was to start with a fresh project and get things into source in the easiest way possible.  As I dug through the entire process I found that I can actually add the ignore property from within the Team Sync perspective!  That's huge as it keeps me (and you) from dinking around at the command line unnecessarily.  After you've "shared" your project go into the Team Sync perspective, right click the project and choose synchronize.  In the left pane you will be presented with a list of files that will be placed under source control.  You can right click them and choose to ignore them.  From here I can control exactly what is and is not going to get into my repo.  That was a big win and almost perfect, but curiosity had me wondering if I could go further.

Eclipse can help by default!  If you look at the Team section in Eclipse Preferences you can add the items to the "Ignored Resources."  I added each item and again created a new project.  This time after sharing it and going to the Team Sync perspective I had only the items listed that were identified in the Android documentation.  Obviously you can start by just doing this and save yourself all the hoop jumping that I went through.