Writing Mobile Code and Architecting Mobile Solutions

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
Data Gathering Analysis
Line of Business Productivity
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
Mobile Web Browser
.NET CompactFramework
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
Details
User input2 Hands. Touch screen basic
navigation buttons, sometimes keypad
User input1 Hand. Phone keypad joystick(no
touch screen)
17
2 basic kinds of application screens
Typical navigationscreen
Typical applicationscreen (with menu showing)
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

• Dont 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 machinesKeep 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
29
State machines allow you to easily iterate on
your user-interfaces layout
Layout A
Layout B
Layout C
30
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
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 trees 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
• gt95 of these pixels are wasted!
• Compressed formats dont 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
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
• Users 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?