(5) Client-Side Constraints

• Limitations of the Mobile Platform
  • general limitations of the mobile platform (HTML5 has no camera API)
  • specific limitations of one implementation of that platform (Firefox has no SQL support)
• Limitations of the runtime environment
  • memory is a problem on all mobile platforms (no support for virtual memory)
  • limited processing power is a problem on all mobile platforms
  • smartphones are increasingly used as general-purpose computers
• Layering does have some problems on mobile devices
  • layering creates inefficiencies (JavaScript on iPhone 100 times slower)
  • layering takes away possibilities for optimization (UI and execution)
  • some platforms oppose/prevent layering out of general principle

(6) Client Devices

• iPhone hardware comes in two different memory configurations
  • first generation iPhones have 128MB of RAM
  • 3G and 3GS iPhones have 256MB of RAM
• Android hardware is less predictable and varies more widely
  • the Droid [Hardware/Platform Opinions] has 256MB of RAM
  • for many devices getting hardware specs is almost impossible
• Bundling data might not always be a good idea
  • Android applications can only be installed in the onboard memory (Droid: 512MB)
  • applications requiring a lot of local data should store it separately

(7) Network Constraints

• Network connectivity is potentially slow and unreliable
  • applications should be designed to work well with a slow network
  • applications should be designed to behave reasonably with no network
• Offline behavior largely depends on the application scenario
  • considering offline behavior in use cases should always be included
• Enabling any Web-app for offline use may be a good idea
  • not all browsers support offline applications
  • browsers may start removing cached applications more aggressively
  • HTML5 AppCache [Offline-Capable Applications; Caching Application Code (1)] is only a caching hint for a browser

(8) Native vs. Offline Web

• Native applications are under control of the user
  • users decide what to install, update, and uninstall
  • the only networking part is how to get the installation package
• Web-based applications are under control of the server
  • services decide to provide a manifest and become off-line capable
  • browsers implement some strategy for caching those applications
  • updates have to be initiated and implemented by the service
• Challenges for offline Web-based applications
  • giving users better control over what to cache
  • caching data probably should be handled different from caching code
  • allowing applications to expose widget-like behavior

(10) In-App Analytics

• Analytics are useful for a variety of purposes
  • they allow to track user behavior and identify possible improvements
  • they allow to track application behavior and identify possible problems
  • they are important for all kinds of business-oriented analyses
• Google Analytics is the most popular service for Web-based analytics
  • Web pages embed code hosted by Google Analytics
  • scripting collects information which is collected by Google Analytics
  • Web masters can access Web-based tools for accessing the collected data

(11) Google Analytics

(12) Pinch Media

(13) Browser-Based Analysis

• Web-based applications run in standardized implementations
  • users use the same resources regardless of the implementation
  • using browser-based debugging yields cross-platform results
• Client-side analysis can generate many interesting analyses
  • is the scripting code distributed across many JavaScript files?
  • would it be possible to minify the JavaScript code?
  • is the CSS code distributed across many CSS files?
  • would it be possible to minify the CSS code?
  • can the images be compressed more effectively?
  • are components served with useful HTTP metadata?
  • are components served in a compressed format?
  • does the site use cookies?

(14) Browser Tools

(15) Server-Side Analysis

• Less intrusive but more limited than In-App Analytics [In-App Analytics (1)]
  • all requests go to the server-side (unless there is a CDN)
  • server-side analysis is able to capture client requests
• Server logs are the simplest way of gathering usage data
  • in the simplest scenario log files are written by the server
  • one entry per request with a configurable set of fields in the entry
• More sophisticated scenarios write log data to a database
  • can be very convenient for immediate analysis and query support
  • can be very risky because database writing tends to be slow
• Most scenarios use simple writing and delayed analysis
  • entries are added to simple text-based files
  • log files are rotated on a regular basis
  • completed log files are processed for traffic analysis