Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Grooming Session Android CWC


Published on

Published in: Technology
  • Be the first to like this

Grooming Session Android CWC

  1. 1. CWC Grooming Session: Android
  2. 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. 3. Problem SetA courier service company wants to give its delivery employees ability toperform deliveries easily and enable them to do on site reportingquickly. In order to solve this problem, they want to have an Androidapplication which will be delivered to designated employees.The key features of the app would be to1. See the tasks assigned to an employee2. See the delivery locations on Maps3. 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.
  4. 4. Problem SetRequired 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
  5. 5. Battle: Round 11. A codebase and bare bone project along with requirement specification will be provided to each group over online repository on 20th January2. You have to implement the unimplemented features of the specification3. You will also have to improve the given source code4. During round 1 of the battle you’ll be given 3-4 assignments on your project5. Your deliverables of round 1 of the battle will be judged with the following criteria
  6. 6. Judgment Criteria1. User Experience Design2. Efficient handling of multiple screen sizes3. Power efficient design4. Database design5. Unit Testing6. Black-Box Testing7. Quick integration with open source components8. Application of Object oriented principles and design patterns
  7. 7. Pragmatic Practices: Some Dos and Don’ts
  8. 8. Some DON’Ts (1) SLOTH Be Fast, Be Responsive Golden Rules Dont do work that you dont need to do Dont allocate memory if you can avoid it
  9. 9. SLOTHSome 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:
  10. 10. SLOTHSome DON’Ts (1) Be Fast, Be ResponsiveResponsiveness"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 ServicesSource:
  11. 11. SLOTHSome DON’Ts (1) Be Fast, Be ResponsiveResponsiveness
  12. 12. Some DON’Ts (2)DontsDONT over use WakeLocksDONT update Widgets too frequentlyDONT update your location unnecessarilyDONT over use Services GLUTTONY Use System Resources Responsibly DOs DO use Receivers and Alarms not Services and Threads DO let users manage updates
  13. 13. Some DON’Ts (2) GLUTTONY Use System Resources ResponsiblyWhat is a WakeLock?Force the CPU to keep runningForce the screen to stay on (or stay bright)Drains your battery quickly and efficiently
  14. 14. Some DON’Ts (2) GLUTTONY Use System Resources ResponsiblyUsing 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
  15. 15. Some DON’Ts (3) HOSTILITY Don’t Fight Your Users User experience should be your top priority Respect user expectations for navigating your app Dont hijack the native experience Respect user preferences
  16. 16. 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
  17. 17. Some DON’Ts (3) HOSTILITYDon’t Hijack The Native Experience Don’t Fight Your Users Dont hide the status bar Back button should always navigate through previous screens Use native icons consistently Dont override the menu button Put menu options behind the menu button
  18. 18. Some DON’Ts (4)Dont use undocumented APIs. Seriously. Dont 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Dont disable rotation handling
  19. 19. 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 resolutionsSource:
  20. 20. 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.
  21. 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. 22. UX Design Fundamentals UI Guidelines Designing for Performance Designing for Responsiveness Supporting Multiple Screens
  23. 23. Location Based ServicesSource:
  24. 24. 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?
  25. 25. Location Based Services (Contd.) Restricting Updates • Specify the minimum update frequency • Specify the minimum update distance
  26. 26. Location Based Services (Contd.)Use Criteria to Select a Location Provider
  27. 27. 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
  28. 28. UI and UX Design (Some Tips)
  29. 29. UI and UX Design (Some Tips)
  30. 30. UI and UX DesignSome Resources:1. r_Interfaces/2. icons-fonts-and-tools/7. patterns.html
  31. 31. 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 applications 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
  32. 32. 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:  Wiki:  Tutorials:
  33. 33. Testing in Android Sources:
  34. 34. Questions???