JS Ext

Thursday, August 7, 2014

Blindly Following Documentation

I have been working on a project that has multiple development teams working together.  One of the teams has a habbit of blindly following documentation without understanding what is actually going on.  This caused us problems before.  This project was to build a proof of concent Google Glass app for my company.  On this project, we needed to store some data that would be globally available to every activity.  I had learned my lesson already and chose to store the data insize of a custom Application class.  Every activity that needed the data was able to access it without the fear of the data being nulled out during a GC cycle.  The other team tore me apart.

They said I should use a static class with a public static variable that would store the data.  They citced the official Google documentation for the Application class.  In the documentation, you will see a paragraph that says to do the exact opposite of what I implemented.
There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.


I tried to explain the GC issue with static classes, but they didn't really care too much.  They complained about needing a reference to the Context to be able to access that information.  I explained that everything should already have access to the Context.  That is when things got ugly.  I was accused a promoting the worst possible style of Android development.  Apparently, I was advocating a Worst Practice.  Passing the Context around is evil.  Android developers should do as much as possible to prevent having access to the Context (some blog post was quoted where people were keeping static references to Activities, keeping the entire view in memory).  In their mind, when documentation says "In most situation(s)", that means NEVER.

Through more discussions, it turns out the other team didn't really understand the GC issue.  After fully explaining it, the lead on that team suggested that we should store the data in SharedPreferences instead.  Now, every time an activity starts up, we read from the internal SD card on the UI thread.  That is way better!  On top of that, SharedPreferences requires access to a Context, so we are still passing the (evil) Context in.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.