On Wednesday, March 19, 2014 6:07:07 AM UTC-5, rakesh mailgroups wrote: > > 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? >
I'll probably end up saying this a couple times in here, but the Android SDK is beset by a number of issues. Crippling unit tests was the single biggest mistake, IMO. This is due to the stubbed-out android jar they supply in the SDK instead of a functional one. The SDK effectively forces developers to run their tests on device. It's is a valid kind of test, but should have been a secondary goal, since these tests are bigger and more complex than *unit* tests. Isolate your code from as many android classes as possible when you can. Use Robolectric when you can't. I wrote a huge bit about the whole testing and testability thing over at https://github.com/pforhan/sandroid . Though I've never fully used that pattern, we're using Mortar and Flow which feel pretty good and carry some of the same princia > 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 many joys of the android SDK. And don't forget about the heavy reliance on inheritance instead of composition. 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). Different teams have different practices. On such a large codebase, I'd be willing to bet this is not consistent. I dislike such prefixes, although m for member is far better than class prefixes, like iMyInteger or sMyString etc. 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? Those would all be pretty fantastic to read for your own codebase. Send 30 (300?) copies to the Android team, too. ;-) I'd say Effective Java's going to get the most bang for your buck, it's great for any java, and for software development in general. 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. True, I've seen several open source projects end up that way. Dagger is quite nice, and Guice functions well. I'd assume spring would function, too, though it's got a very large library. 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. A fair thing to do (small, focussed modules) but be aware that the tooling will get harder. You will definitely want to move away from the (old) Ant-based builds, to either the new Gradle support in the SDK or to Maven. 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. At Square we do feature branches everywhere. Is your version control hurting you here? We use Git and feature branches work out just great. Pat. -- 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.
