The document discusses best practices for developing Android applications using an agile process. It covers topics like using extreme programming practices, testing Android apps, mocking dependencies, and challenges like the Dalvik runtime environment. Continuous integration is also mentioned as important for Android projects.

1. Android - A Practitioner's take on doing it The Agile Way Thiyagu, Krishna, Soundar, Ashwin

2. Can we run an Android Application Development Project the Agile Way?

3. As a practitioner, what are the effects of the Technical Stack on the process?

4. How can I follow the 'Extreme Programming' Practices?

5. As ThoughtWorks why can we expect Android Projects?

6. Enterprises are looking for a Mobile Presence

7. Mostly CRUD Applications though.

8. Then Why a native app over a Web App?

9. Native Applications are much more enabled than a web application

10. etc.....

11. But why Android?

12. Steep increase in the user base

13. Lots of new Vendors

14. So as ThoughtWorks, why have this capability?

15. We want to build something cool !

16. Disclaimer

17. Why is this not just a Java Project?

18. When you’re working with Android, it sure feels like you are writing regular old standard Java SE code

19. You are not!!

20. So what is the difference? Its the runtime!!!!

21. In the Android platform, we have the Dalvik Runtime which is specially designed for devices that are contrained in terms of memory, speed and battery power.

22. Dalvik is not even a Java Virtual Machine at all!

23. It does not understand byte code. Instead...

24. It understands Dex Code

25. Everything you need as a programmer is available in the Dalvik implementation of Java

26. Why do I mention all this?

27. Because you might want to use something like JMock to mock your dependencies when writing your unit tests

28. Its not a full Java SE implementation

30. Test Driven Development

31. The Application to be tested must/needs to run on a device instance

32. Any entity that aims to test the Android Application must be on the device instance as well

33. So the test in itself is Another Application!

34. Android Testing and Instrumentation

37. Does the service Locator Pattern Seem like a bad idea?

38. Ensure that your Mocking Framework is supported by the Dalvik VM

39. The problem with easy mock .... Mocking Concrete Classes

40. So can we clean up this mockery?

41. Split the code into 2 types: 1.Android Framework Dependent 2.Android Framework Independent

42. Over Engineering the code is Dangerous.

43. ActivityInstrumentationTestCase

44. Continuous Integration

45. Android Debugger Bridge adb install, -r, standup-timer-app.apk

46. The Testing Application and the Application under test are deployed on the same device instance

47. Android Maven Plugin &Ant Script Android SDK Path Platform Used Device Instance to use

48. <plugin> <groupId>com.jayway.maven.plugins.android.generation2</groupId> <artifactId>maven-android-plugin</artifactId> <version>2.5.1</version> <configuration> <sdk> <path>android_sdk</path> <platform>7</platform> </sdk> <emulator> <avd>my_avd</avd> </emulator> <deleteConflictingFiles> true </deleteConflictingFiles> <undeployBeforeDeploy>true</undeployBeforeDeploy> </configuration> <extensions>true</extensions> </plugin>

49. Independent parts of the build

50. // start tracing to &quot;/sdcard/calc.trace&quot; Debug.startMethodTracing(&quot;calc&quot;); // ... // stop tracing Debug.stopMethodTracing();

53. Time for Demo