1. CWC Grooming Session: Android

2. Outline
Problem Set for CWC
Judgment Criteria
Pragmatic Practices in Android Development
Some Dos and Don’ts
UX Design Fundamentals
Designing for Performance
Designing for Responsiveness
Supporting Multiple Screens
Location Based Services
UI Design Patterns
Testing

3. Problem Set
A courier service company wants to give its delivery employees ability to
perform deliveries easily and enable them to do on site reporting
quickly. In order to solve this problem, they want to have an Android
application which will be delivered to designated employees.
The key features of the app would be to
1. See the tasks assigned to an employee
2. See the delivery locations on Maps
3. View task details of a delivery item with associated location
information and recipient phone number.
4. After a successful delivery the details are emailed or synchronized
with server and task lists are auto updated based on that.
5. Ability to do any reporting from on site.
6. Tracking the performance of an application user through graphical
charts or aided system.

5. Problem Set
Required Features of Android (For your preparation)
1. Location Based Service
2. Consuming Web Services
3. Integrating Maps Library
4. Using SQLite Database
5. Unit Testing
6. Black-Box Testing

6. Battle: Round 1
1. A codebase and bare bone project along with
requirement specification will be provided to each
group over online repository on 20th January
2. You have to implement the unimplemented features
of the specification
3. You will also have to improve the given source code
4. During round 1 of the battle you’ll be given 3-4
assignments on your project
5. Your deliverables of round 1 of the battle will be
judged with the following criteria

7. Judgment Criteria
1. User Experience Design
2. Efficient handling of multiple screen sizes
3. Power efficient design
4. Database design
5. Unit Testing
6. Black-Box Testing
7. Quick integration with open source components
8. Application of Object oriented principles and design
patterns

8. Pragmatic Practices: Some Dos and Don’ts

9. Some DON’Ts (1)
SLOTH
Be Fast, Be Responsive
Golden Rules
Don't do work that you don't need to do
Don't allocate memory if you can avoid it

10. SLOTH
Some DON’Ts (1) Be Fast, Be Responsive
Performance Pointers
Optimize judiciously
Avoid creating objects
Use native methods
Prefer Virtual over Interface
Prefer Static over Virtual
Avoid internal setters and getters
Declare constants final
Avoid float and enums
Use package scope with inner classes
Source: http://developer.android.com/guide/practices/design/performance.html

11. SLOTH
Some DON’Ts (1) Be Fast, Be Responsive
Responsiveness
"Application Not Responding“-ANR
Respond to user input within 5 seconds
Broadcast Receiver must complete in 10 seconds
Users perceive a lag longer than 100 to 200ms
Use Threads and AsyncTasks within Services
Source: http://developer.android.com/guide/practices/design/responsiveness.html

12. SLOTH
Some DON’Ts (1) Be Fast, Be Responsive
Responsiveness

13. Some DON’Ts (2)
Don'ts
DON'T over use WakeLocks
DON'T update Widgets too
frequently
DON'T update your location
unnecessarily
DON'T over use Services GLUTTONY
Use System Resources Responsibly
DOs
DO use Receivers and Alarms not Services and Threads
DO let users manage updates

14. Some DON’Ts (2) GLUTTONY
Use System Resources Responsibly
What is a WakeLock?
Force the CPU to keep running
Force the screen to stay on (or stay bright)
Drains your battery quickly and efficiently

15. Some DON’Ts (2) GLUTTONY
Use System Resources Responsibly
Using WakeLock?
Do you really need to use one?
Use the minimum level possible
PARTIAL_WAKE_LOCK
SCREEN_DIM_WAKE_LOCK
SCREEN_BRIGHT_WAKE_LOCK
FULL_WAKE_LOCK
Release as soon as you can
Specify a timeout

16. Some DON’Ts (3)
HOSTILITY
Don’t Fight Your Users
User experience should be your top priority
Respect user expectations for navigating your app
Don't hijack the native experience
Respect user preferences

17. Some DON’Ts (3)
Respect User Expectations For Navigation Flow
HOSTILITY
Don’t Fight Your Users
The back button should always navigate back through
previously seen screens
Always support trackball navigation
Understand your navigation flow when entry point is a
notification or widget
Navigating between application elements should be
easy and intuitive

18. Some DON’Ts (3) HOSTILITY
Don’t Hijack The Native Experience Don’t Fight Your Users
Don't hide the status bar Back button should always
navigate through previous screens
Use native icons consistently
Don't override the menu button
Put menu options behind the
menu button

19. Some DON’Ts (4)
Don't use undocumented APIs.
Seriously. Don't use
undocumented APIs
Make your app behave
consistently with the system
Respect the application lifecycle ARROGANCE
model Don’t Fight The System
Support both landscape and
portrait modes
Don't disable rotation handling

20. Some DON’Ts (5)
Avoid Size Discrimination DISCRIMINATION
Design For Everyone
Don’t make assumptions about
screen size or resolutions
Use Relative Layouts and
Device Independent Pixels
Optimize assets for different
screen resolutions
Source: http://developer.android.com/guide/practices/screens_support.html

21. Some DON’Ts (5)
Ensure Future Hardware Happiness DISCRIMINATION
Design For Everyone
Specify uses-feature node for every API you use.
Mark essential features as required.
Mark optional features as not required.
Check for API existence in code.

22. Some DON’Ts (5)
Ensure Future Hardware Happiness DISCRIMINATION
Design For Everyone
Specify uses-feature node for every API you use.
Mark essential features as required.
Mark optional features as not required.
Check for API existence in code.

23. UX Design Fundamentals
UI Guidelines
Designing for Performance
Designing for Responsiveness
Supporting Multiple Screens

24. Location Based Services
Source: http://developer.android.com/guide/topics/location/obtaining-user-location.html

25. Location Based Services (Contd.)
How often do you need updates?
What happens if GPS or Wifi LBS is disabled?
How accurate do you need to be?
What is the impact on your battery life?
What happens if location 'jumps'?

26. Location Based Services (Contd.)
Restricting Updates
• Specify the minimum update frequency
• Specify the minimum update distance

27. Location Based Services (Contd.)
Use Criteria to Select a Location Provider

28. Location Based Services (Contd.)
Use Criteria to Select a Location Provider
Specify your requirements and preferences
Allowable power drain
Required accuracy
Need for altitude, bearing, and speed
Can a cost be incurred?
Find the best provider that meets your criteria
Relax criteria (in order) until a provider is found
Can limit to only active providers
Can use to find all matching providers

29. UI and UX Design (Some Tips)

30. UI and UX Design (Some Tips)

31. UI and UX Design
Some Resources:
1. http://developer.motorola.com/docstools/library/Best_Practices_for_Use
r_Interfaces/
2. http://www.androidpatterns.com/
3. http://pshyama.wordpress.com/2011/07/05/android-os-research/
4. http://www.slideshare.net/mswolfson/android-ui-patterns
5. http://www.youtube.com/watch?v=M1ZBjlCRfz0
6. http://speckyboy.com/2010/05/10/android-app-developers-gui-kits-
icons-fonts-and-tools/
7. http://coding.smashingmagazine.com/2011/06/30/designing-for-android/
8. http://www.androiduipatterns.com/2011/07/trending-android-ui-anti-
patterns.html

32. Black-Box Testing
 Testing of functionality of the application. The tester knows
what the software is supposed to do, but not how.
 Specific knowledge of the application's code/internal
structure not required.
 Test cases are built around specifications and requirements.
 The test designer selects valid and invalid inputs and
determines the correct output.
 Can be applied to all levels of software testing:
unit, integration, system and acceptance.
Input Output
Black-Box

33. Black-Box Testing in Android: Robotium
 A test framework created to make it easy to write powerful
and robust automatic black-box test cases for Android.
 Full support for Activities, Dialogs, Toasts, Menus and Context
Menus.
 Benefits
 Powerful test with minimal knowledge of app under test
 Handles multiple Android activities automatically
 Minimal time to write solid test cases
 Improved readability of test cases
 Resources
 Project Home: http://code.google.com/p/robotium/
 Wiki: http://code.google.com/p/robotium/wiki/Getting_Started
 Tutorials: http://code.google.com/p/robotium/wiki/RobotiumTutorials

34. Testing in Android
Sources:
http://developer.android.com/guide/topics/testing/testing_android.html

35. Questions???