Mobile Code: Developing for Mobile Devices

1. Writing Mobile Codeand Architecting MobileSolutions Ivo Salmre Microsoft EMIC Aachen, Germany

2. Agenda • Why “Mobile code?” • Comparing desktop / mobile devices • Comparing desktop / mobile applications • Design and development strategy • The future

3. Why mobile code? • Instant access to information and services • “Fits in pocket” (remarkably important) • “Instant on” / “Instant off” • Work done in “5-20 second spurts” • Connected and disconnected usage • Rich data synchronization options • On demand (GPRS / Wi-Fi / etc) • Periodic (Work Wi-Fi, Cradle / etc) Education & Entertainment Line of Business & Productivity Data Gathering & Analysis Location Services Communication

4. Other mobile software options • Mobile Device Browser Good for many scenarios, but… “What could you do with a mobile web-browser in 0-20 seconds?” • Limited to “on line” scenarios • High latency request/response • Data transfer can be expensive • Mobile Laptop Huge storage, processing power, rich i/o, but… “What could you do with a laptop in 5-20 seconds?” • Boot up times are long • Battery life limited • Physical access to the laptop takes time

5. Application Models for Devices Visual Studio.NET eC++ .NET Framework code code web pages Clientapps Webapps Native code .NET CompactFramework Mobile Web Browser

6. Great uses for smart mobile device software • Scenarios • Converting paper-based processes • Upgrading (expensive/inflexible!) custom devices • “Real-time data” applications • Intermittently connected applications • Field automation • Benefits of a “smart mobile” approach • New personal/organizational capabilities • Increased efficiency • Fewer errors (no data transcription) • Increased agility • Shortened cycle business transactions • Shortened cycle data acquisition

7. Agenda • Why “Mobile code?” • Comparing desktop / mobile devices • Comparing desktop / mobile applications • Design and development strategy • The future

8. Characteristics of mobile devices • Physically/logically smaller screen • Lower bandwidth text input • Stylus/keypad vs. full keyboard • Smaller RAM /No memory paging file • You must have an explicit memory/resource model • Battery power is key constraint • RAM, Screen, standby mode

9. Characteristics of mobile devices • Fits in pocket • Instant on / always on • Built in communications • Mobile networks (GPRS, UMTS, etc) • Wi-Fi • High bandwidth information output • Low bandwidth information input • Easy navigation of small sets of options • Input of small amounts of text

10. Agenda • Why “Mobile code?” • Comparing desktop / mobile devices • Comparing desktop / mobile applications • Design and development strategy • The future

11. Writing mobile code is the same… • Same programming languages • Managed: VB, C# • Native: C++ • Similar programming libraries • Similar UI tools (Form Designer) • Similar data tools (SQL/SQL-CE) • Similar base classes • These similarities are useful, comforting, but can be deceptive!

12. Writing mobile code is different… • Mobile applications are used differently • 20 second usage sessions • Targeted focus vs. exploratory • User responsiveness much more important • Much higher user expectations • User navigation must be much simpler • Fewer navigation paths • Memory, Storage and Communication strategies differ • No memory paging file (difference between hard-disks and FlashRAM) • Frequently disconnected or interrupted communication

13. Mobile development demo…

14. “Write once, run anywhere” will not work for rich mobile applications • Technically possible, but not useful • Displays & input models radically different • Storage and communications • Device usage patterns • Focus on source code reuse (not binary) • Design code for adaptability • Different binaries for different device-classes • Leverage target form-factor fully • No compromises for “portability”! • Best possible Pocket PC experience • Best possible Smartphone experience

15. Similar OS, 2 Different form factors Note: Keep in mind the that Flash-RAM and RAM are very different!

16. Main UI:Room to express a “full paragraph’s worth of information” and options Main UI:Room to express a “1-3 sentences worth of information” Navigation:Application dataand navigationsimultaneous Navigation: Show appdata or navigation Details User input:2 Hands. Touch screen + basic navigation buttons, sometimes keypad User input:1 Hand. Phone keypad + joystick(no touch screen)

17. 2 basic kinds of application screens Typical applicationscreen (with menu showing) Typical navigationscreen 1 2 Smartphone user interface • 1 main idea per screen • Screens with data-fields • Screens with lists • Screens with charts/photos/etc. • 2 menu buttons • Show lists • Act as “buttons” • Consistent use very important!

18. Agenda • Why “Mobile code?” • Comparing desktop / mobile devices • Comparing desktop / mobile applications • Design and development strategy • The future

19. How to be successful in Mobile Development • Be guided by performance/responsiveness • Plan to iterate! • Iterate on performance • Iterate on user interface design and layout • Iterate on communications strategy • Iterate on performance/responsiveness!

20. What is “performance” for mobile devices? • Performance = user responsiveness • Instant acknowledgement of user requests! • Fast startup time • Few “wait states” • Asynchronous communication • Pre-cached information

21. Follow a performance driven development methodology at every stage of development. If performance goals are not being met stop coding and revisit the design of the preceding levels! Your great idea! Step 0: Define application scope Performance driven redesign as needed! Step 1: Commit to a performance based methodology Performance driven redesign as needed! Step 2: Design the right user interface Performance driven redesign as needed! Step 3: Get the data/memory model right Performance driven redesign as needed! Step 4: Get the communications model right Performance driven redesign as needed! Code the rest of your application logic Great mobile application and user experience

22. A thought experiment: Mobile applications, done wrong… What would happen if you took desktop applications and ran them on a mobile device?

23. What went wrong? Too much data to display at once Too many simultaneous navigation options

24. What went wrong? (part 2) This might almost work!(There is only one main task, reading.) My personal favorite…(this explains why software development is hard! – It is free-form and exploratory)

25. Scope of your application • Don’t “down port” desktop applications • Features, uses, navigation different • Performance environment different • UI and algorithms will be different • The results will not be satisfactory • Instead • Write down “20 second” scenarios • Build from ground up, optimize experience

26. State machines:Keep it simple and flexible • Good for user interface management • Good for managing expensive resources • Memory • Graphics resources • Connections • Allow you to easily tune your application • UI layout responsibility concentrated, not distributed • Different modes of application well defined • Allow you to easily port your application • Application logic and UI cleanly separated

27. A simple example: 4 UI states UI State = Start UI State = Ask Question UI State = Show Answers State machines help you manage your screen resources well. Hiding, resizing and moving sets of controls in different states is easy. UI State = Show Result

28. Another view of the 4 UI states UI State =“GameUIState.startScreen” UI State = “GameUIState.waitForUserToStateKnowledge” UI State = “GameUIState.waitForUserToAnswerMultipleChoice” User interface drawn above playfield. (code: “#define PLAYFIELD_ON_BOTTOM”) UI State = “GameUIState.waitForNextQuestion

29. State machines allow you to easily iterate on your user-interface’s layout Layout “A” Layout “B” Layout “C”

30. State of user interface Called to change user interface state Different states the user interface can be in State machine driven user interface Notes: 1. This code allows very easy iteration on the user interface layout 2. This source code is highly portable between different device classes.

31. Responsiveness is your most important feature • Always provide instant acknowledgement • User discomfort worse than on desktop • Small size = expectation of “gadget feel” • Wait cursor fine for short delays • 0.5 – 3 seconds • Longer delays • Design UI for async work execution • Give user non-invasive updates • Allow cancel of long operations

32. Performance & memory management • Unused data does not get paged out! • Unlike your desktop paging file • Valuable memory wasted in two ways • Unneeded application state in memory • Wasteful object allocation and destruction • Both will cause frequent garbage collection! • Have an explicit memory/state model • Defer loading of data/resources • Cache frequently used data/resources • Free data/resources when exiting states

33. 3. Efficient algorithms / Wasteful state GC GC GC GC GC GC GC GC GC GC GC GC GC GC memory limit Memory Usage Application state (wasteful) Intermediate Case!Relatively frequent garbage collection Application (time) 2. Wasteful algorithms / Efficient state 4. Efficient algorithms / Efficient state memory limit memory limit GC GC GC GC GC GC GC GC GC Best Case!Infrequent garbage collection Memory Usage Memory Usage Application state (good) Application state (good) Intermediate Case! Application (time) Application (time) 1. Wasteful algorithms / Wasteful state memory limit Memory Usage Application state (wasteful) Worst Case!Continual garbage collection Application (time)

34. Performance and multi-threading • One main user-interface thread! • Why would you possibly need more? • Background thread for • Communication • Long calculations • Loads/saves of large amounts of data

35. Performance and user interface • Defer population of UI elements • Fill long-lists “as needed” • Fill deep tree’s “as needed” • Trace control “event firings” • Use flags to turn of unwanted event handling • Sounds obvious, but… • Do not forget to use most efficient mechanisms for filling/clearing controls!

36. UI demo…

37. Performance and graphics • Do graphics work ahead of time! • Design time better than run-time • Once at run-time, better than repeats • “Dispose()” of expensive resources • Particularly big Bitmaps • Smart caching of resources • Cache colors, bitmaps, pens, graphics, fonts, etc. • Make estimates • How big are the cached bitmaps/resources? • How often would they be created if not cached?

38. Graphics Performance - Images • Choose correct image dimensions • 2 megapixel photo = 2 Meg device memory • >95% of these pixels are wasted! • Compressed formats don’t change in-memory footprint (only storage size) • Instead • Pre-shrink images before download • Use best storage format (*.PNG/ *.JPG) • Dispose() bitmaps aggressively

39. Graphics demo…

40. XML Performance • XmlReader / XmlWriter favored • Stateless • Good for large documents • Writing = trivial, Reading = more work • Use XmlDocument for • Trivially small documents • Whole document modifications • This will get even easier in the future! • XML Serialization improvements in v2!

41. Data access • Local SQL-CE database is very useful • Stand alone, or synchronized? • Do you really need the ADO.NET Dataset? • Yes: Complex cross-table relationships/frequent updates • No: Simple queries • Datasets are overkill for simple tasks • Consider going right to SQL-CE datastore • SQL-CE Connections/Commands are easy and low-overhead • In the future… “SQL-Mobile” (richer, more ubiquitous)

42. Communications / Synchronization • Put the user in control of synchronization • How often? How much data? Which data? • Make all communications async from UI • Admit you can not control latency/bandwidth Mobile communications will fail – plan on it! • Try/Catch blocks around all communications • Test by injecting failures • Make sure application responds robustly • Make sure subsequent requests work • Check failure cleanup code

43. Structured list of failures we would like to inject. See if we should inject a failure at runtime Fail only once Inject the failure Injecting failures to test communications code

44. Communications Design • How much connectivity is required? • Minute-by-minute? Hourly? Daily? • Communications mechanism • Desktop sync? • Storage card? • Wi-Fi? • GPRS? • There is no on-stop solution

45. Characteristics of good mobile applications • Instant end user gratification • Useful in short (20 second) bursts • Instant response to user input • Simple navigation • Tuned for usage scenarios • Tuned for target mobile device • Tuned for users needs • Simplest navigation possible • Robust communications model for • Intermittent connectedness / Frequent breaks • Communications asynchronous to user interface

46. The future… • More context awareness • Location • User’s activity • Users health and surrounding environment • More communications options • Wide area (GPRS, UMTS, 4G…) • Local area (Wi-Fi 802.11xxxx) • Body area (Bluetooth, ZigBee) • (but communications will remain intermittent) • More dynamic applications • Productivity, Quality of life, Entertainment

47. Finally, a shameless promotion… The book: • Theory and practice • Hands on examples • C# and VB • Great with coffee…(Addison-Wesley Press) Many thanks! Questions?