guys, I posted the below to the android-developer google group but it still hasn't turned up.
I would like to know what people here have to say as I know a couple of the Java Posse are involved in Android (looking at you Tor and Chet). Re-reading I can see that feature branching isn't unique to mobile, but it seems common amongst the mobile teams where I work. Hi all, I started a new Android development role a couple of weeks ago. Prior to that, I've been doing server-side Java for 10+ years. I have some questions and wanted to know whether it was just my team or the larger Android community who also do (or not do) things: 1. Low to zero unit testing. Is unit testing (let alone TDD) not worth it since it can't help with layout validation? Or is the mobile community in general not into unit testing? Its not true there's no logic at all and its all layout-centric, at least in the apps I work with. There's huge amounts of logic to communicate with external services that would benefit from unit testing. I've watched some Google IO and GTAC videos from last year where there quite a few talks about automated testing - does that mean it was a lower priority for the platform in the early days and now they are concentrating efforts in that area? I believe (in theory, not done it in practice yet) that I could keep Activities/Fragments thin, hopefully obviating the need for unit tests but have all the logic in POJOs with full unit tests. I can see how Activities and Fragments could be unit tested but that its not trivial. 2. Idiomatic Java variations a. null checking EVERYWHERE!! Its considered bad practice to throw nulls in regular Java but it seems rife to throw and check in Android. This is not helped when the platform itself is doing it - the onCreate() method on activity checks to see if the Bundle is not null before checking it for values for example. One of the most common reasons for bugs in our app reported by the QA team is crashes due to NPE. b. not throwing exceptions. Slightly related to point (a). If a set of conditions occurs where normal processing is not possible to continue, I would throw a Runtime exception. Of course I would write a catch block either in the caller because it was anticipated it could happen and I could recover or let it bubble to the top and catch it there in a more generic fashion. c. whats with the instance variable prefixed with 'm' e.g. mTextView? I remember back in the early days of Java that happening because so many new Java programmers were coming from C/C++ where that was a common convention to keep track of variable types. In modern Java programming its not so common so was surprised to see it in Android. It adds no value since most classes and methods should be small anyway (plus modern IDEs colour them differently). 3. Knowledge of Java best practices. Would the following books be considered required reading (like they are in regular Java-land): Refactoring by Martin Fowler Effective Java by Joshua Bloch Clean Code by Robert Martin et al. Or is Android Java different that they don't apply? 4. Poor support for DI built in. Without DI (dependency injection) its very difficult to write testable code. I was surprised to see that achieving DI on Android without the help of external libraries was not easy (in fact, its not easy WITH external libraries!). There's no mention of DI as a good thing to do in the docs either, leading devs to just wire everything up with 'new' and not bother unit testing. 5. Divide up the app into logical modules (library modules I think they are called?). My current app has 2 'logical' modules which seem right to me - they represent 2 external services we have written code to communicate with. However, we have another 2 library modules (ActionBarSherlock and DragSortListView) which made more sense to me as drop-in jar dependencies. Am I wrong? I want to push to have more 'logical' modules taken out of the main project because I believe that would make the app easier to work with and make merging easier. 6. Feature branching common. Ok, I know this is a contentious issue. In server side development, I have rarely come across feature branching. Its really poisonous to CI for one reason. Merging is non trivial for another. By this I don't mean bad tooling, I mean semantic overload leading to bugs. Refactoring is avoided because of the merge issues likely to come out of it. Any thoughts? I know I've raised a lot of points but any clarity would be useful, especially if it means doing things differently to what I'm used to (then I know when to pick my battles!). Regards -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/d/optout.
