Warning:
This wiki has been archived and is now read-only.
Main Page
From Network-Friendly App and WebApp Best Bractices Community Group
Comparison W3C and GSMA Best Practices
Goal
- Check overlap/differences
- Identify candidate W3C BPs that could be included by GSMA
(draft)
W3C BPs that don't appear in GSMA but maybe should
- Aggregate static images into a single composite resource (sprite)
- Cache resources by fingerprinting resource references
- Minimize perceived latency - keep user informed of activity - use spinners
- Inform user about automatic network access (icon, help pages)
- Provide sufficient means to control automatic network access
GSMA/W3C Comparison tables
GSMA High Level Recommendations | W3C Best Practices | Comment |
---|---|---|
Asynchrony | ||
Pipelining | ||
Efficient network connection usage | Optimize Network Requests, Minimize Application and Data Size | W3C: Batch requests, Throttle low priority requests, Back off during user inactivity, Change behavior based on WiFi or not ("Device Context") |
Deactivate background processes when not required | ||
Design polling applications to aggregate their network activities | ||
Handle connection loss | Use Appropriate Client-Side Storage Technologies for Local Data | |
Applications should be resilient to changing network connections and errors | ||
Use HTTP compression | Use transfer compression | W3C: points out battery cost of decompression, no compression benefit for very small files (<1K) |
Use push services in preference to polling | Consider Mobile Specific Technologies for Initiating Web Applications | W3C means: use "push" |
GSMA Network Friendliness | W3C Best Practices | Comment |
---|---|---|
Non-blocking user interface | ||
Offline mode | ||
Bandwidth Awareness | ||
Efficient network connection usage |
GSMA Ideal mobile application | W3C Best Practices | Comment |
---|---|---|
Connection loss and error handling | GSMA: identify type of connection (WiFi), switch to offline when not connected, identify(?) secondary requests, make primary requests cancellable, use "retry" error for information to be delivered rapidly, automatically reestablish connection for longer transactions (music download), if failure, suspend (don't cancel) and manual option to resume later, don't loose downloaded data, use resume | |
Support resuming large downloads | ||
Use Caching | Cache Ajax data, Cache resources by fingerprinting resource references | Add fingerprinting W3C BP to GSMA? |
Define caching strategy based on content type | GSMA: type of content: cacheable, cachable but needs validation, don't cache | |
Privacy: some cacheable content should not be kept | ||
Authenticate access to private data | GSMA: device ids (serial number, telephone number, IMEI) should never be used - obscured ok, or use automatically provisioned unique identifiers - use third party authentication providers (Google ID, FB ID, Microsoft passport) - authenticate every time app establishes new session - use secure authentication protocols @@ more | |
Use input validation | ||
Use APIs rather than HTML ("screenscaping") for "Cloud-based transformations" | ||
Don't upload big images taken by phone camera to sites that will downsize it anyway | ||
Don't download original file size image on mobile if not needed (e.g. thumbnail) | ||
HD videos taken by phone might need transcoding before upload to lower filesize | ||
@@ video playback best practices | ||
Don't use unnecessary network resources when app is in background mode, prevent app from interacting with network in most cases | ||
Batch transactions of several apps in background mode | ||
Use push rather than poll | ||
Use keep-alive connection to replicate push rather than poll | ||
@@ rules on exploiting application life cycle | ||
Don't concentrate network activity at specific (clock?) times (time of day?) | ||
Use randomnisation to spread network synching and connnectivity load |