It is out of date. Enums are fine these days and developers were already using Guice these past years, despite the heavy runtime penalty (a problem Dagger doesn't have, so you should use it instead these days).
-- Cédric On Tue, Mar 25, 2014 at 8:09 AM, rakesh mailgroups < rakesh.mailgro...@gmail.com> wrote: > Hi, > > I made a mistake with (4) Dependency Injection. There is something in the > docs - > > "Avoid dependency injection frameworks" > > http://developer.android.com/training/articles/memory.html > > Its also says not to use Enums! > > This has got to be out of date, or at least it needs qualifiers for > devices seriously constrained by space, which is becoming rarer over time. > > Rakesh > > > On Wed, Mar 19, 2014 at 11:07 AM, rakesh mailgroups < > rakesh.mailgro...@gmail.com> wrote: > >> 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 javaposse+unsubscr...@googlegroups.com. > To post to this group, send email to javaposse@googlegroups.com. > Visit this group at http://groups.google.com/group/javaposse. > For more options, visit https://groups.google.com/d/optout. > -- 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 javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/d/optout.
