StartPad Countdown 5 - Google Geo: Mobile Mapping
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

StartPad Countdown 5 - Google Geo: Mobile Mapping

on

  • 3,066 views

Mapping technologies and mobile technologies have often been at odds with each other. Mobile technologies require compact, high performance applications, and maps require massive amounts of data and ...

Mapping technologies and mobile technologies have often been at odds with each other. Mobile technologies require compact, high performance applications, and maps require massive amounts of data and special interfaces. Recently, mapping technologies have been optimized for the increased power of modern mobile devices. This talk will give an overview of what Google offers to mobile developers, including Android MapView and iPhone MapKit, and will demonstrate how to get started with the new Google Maps API version 3, which has been optimized for mobile devices.

Statistics

Views

Total Views
3,066
Views on SlideShare
2,957
Embed Views
109

Actions

Likes
0
Downloads
19
Comments
0

4 Embeds 109

http://startpad.org 86
http://www.slideshare.net 20
http://www.slideee.com 2
http://www.health.medicbd.com 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • We're going to talk about the options for various devices.  Though we're all excited about the iPhone and Android and the other devices coming to the market with fully-featured browsers, I'll mention solutions for non-JS enabled devices. The static maps API, which I'll go into greater detail about, provides a solution for the lowest common denominator: it requires no JS and so can render in any phone browser.  Users cannot interact with it, but it at least gives the ability to show locations on a map. Native APIs provide for a slick user interface and take full advantage of the phone's hardware. And then there's the JavaScript API that is officially supported on iPhone, works pretty well on Android, and has the potential to work on other high-end browsers.
  • Since the browser has so many issues with both startup and interaction  performance, why not just create an application using client APIs?  The  experience of using the native API on the iPhone is bound to be smoother.  At Google, we've found the web browser to be incredibly powerful.  Downloads introduce a steep barrier to entry.  And how many times have Mac users asked when their favorite Windows application will be available for them?
  • Since the browser has so many issues with both startup and interaction  performance, why not just create an application using client APIs?  The  experience of using the native API on the iPhone is bound to be smoother.  At Google, we've found the web browser to be incredibly powerful.  Downloads introduce a steep barrier to entry.  And how many times have Mac users asked when their favorite Windows application will be available for them?
  • Has streetview, polylines, and much more
  • There are a number of issues that make developing in a mobile browser tricky. User interface: The iPhone and Android-based devices have changed the way we are able to interact with maps.  We are working to make the browser based maps experience as smooth as a native application.  We introduced touch and multi-touch functionality in v2.  Mention touch events, desktop components, clickability, webkit
  •    A. server side      1. our servers are fast - serving the files takes negligible time compared to other causes of latency.      2. Distance is a factor. Consider finding local caches for your data if you have users in distant lands (like Australia).    B. download time is limited by bandwidth. Detecting low bandwidth users and serving them appropriately downgraded data (particularly images) can have profound impact. Bandwidth on high speed mobile devices (3g) is good - download time is a fairly constant but small factor in latency (numbers for 10kB, 50kB, 200kB file)    C. parsing/execution time. On both iphone and android devices, parsing time is severely slower than on desktop machines. This is cpu bound. As devices have more processing power, this may improve, but we're designing for today's devices. (Numbers for 10kB, 50kB, 200kB file)
  • A. Compiling/obfuscating: Because parsing time on the iphone and android are so slow, obfuscate/compile your code to significantly reduce code size.   (Mention publicly available js compilers?)    B. Download as few scripts/images as you need.  Keep in mind that there is overhead in each download, so the balance between breaking the JS apart and making fewer requests is important.
  • A. Compiling/obfuscating: Because parsing time on the iphone and android are so slow, obfuscate/compile your code to significantly reduce code size.   (Mention publicly available js compilers?)    B. Download as few scripts/images as you need.  Keep in mind that there is overhead in each download, so the balance between breaking the JS apart and making fewer requests is important.
  •   
  •    A. takes Xs to load on the iphone over wireless, Ys over 3G    B. design: uses an MVC (model-view-controller) design to download only the state storing models initially. When objects like Map or Marker are instantiated, the modules required to render their views are downloaded asynchronously    C. first requests a static map to reduce user perceived latency. Then makes that map draggable even before tiles have necessarily loaded    D. expected increase to initial download per feature (how much did marker and infowindow add?)      1. untangling of modules: map knows nothing about marker or infowindow or marker about infowindow. You can have as many infowindows as you want and they can be associated with any object that inherits from our generic MVC object known as MVCObject.    E. basic development should be as simple as v2 (although interface has changed so it may seem awkward at first!). We've exposed the basic object that all of our models and views inherit from. This allows you to create rich applications fairly simply. We've become big fans of MVC while developing the new API. See how simple it is to create the OverlayMapControl. In v2 that took X lines of complicated state tracking.
  • One of the most obvious differences between desktops and mobile devices that has not changed even with the introduction of full-featured browsers is the size.  Designing a mobile applications remains a different and challenging task.  Whereas on a desktop, you may be able to expose a map and content on one page, you may prefer for your map to fill the page and expose extended content on user action.  We have worked to enhance the mobile maps experience in the v3 API by detecting the map size and ensuring appropriately sized controls are used by default and that info windows are bound by the map size.
  •    A. takes Xs to load on the iphone over wireless, Ys over 3G    B. design: uses an MVC (model-view-controller) design to download only the state storing models initially. When objects like Map or Marker are instantiated, the modules required to render their views are downloaded asynchronously    C. first requests a static map to reduce user perceived latency. Then makes that map draggable even before tiles have necessarily loaded    D. expected increase to initial download per feature (how much did marker and infowindow add?)      1. untangling of modules: map knows nothing about marker or infowindow or marker about infowindow. You can have as many infowindows as you want and they can be associated with any object that inherits from our generic MVC object known as MVCObject.    E. basic development should be as simple as v2 (although interface has changed so it may seem awkward at first!). We've exposed the basic object that all of our models and views inherit from. This allows you to create rich applications fairly simply. We've become big fans of MVC while developing the new API. See how simple it is to create the OverlayMapControl. In v2 that took X lines of complicated state tracking.
  • One of the most obvious differences between desktops and mobile devices that has not changed even with the introduction of full-featured browsers is the size.  Designing a mobile applications remains a different and challenging task.  Whereas on a desktop, you may be able to expose a map and content on one page, you may prefer for your map to fill the page and expose extended content on user action.  We have worked to enhance the mobile maps experience in the v3 API by detecting the map size and ensuring appropriately sized controls are used by default and that info windows are bound by the map size.
  • One of the most obvious differences between desktops and mobile devices that has not changed even with the introduction of full-featured browsers is the size.  Designing a mobile applications remains a different and challenging task.  Whereas on a desktop, you may be able to expose a map and content on one page, you may prefer for your map to fill the page and expose extended content on user action.  We have worked to enhance the mobile maps experience in the v3 API by detecting the map size and ensuring appropriately sized controls are used by default and that info windows are bound by the map size.

StartPad Countdown 5 - Google Geo: Mobile Mapping Presentation Transcript

  • 1. Mobile Mapping Mano Marks Geo Developer Advocate Startpad September 1 st , 2009
  • 2. What are (were) the API options? Lowest common denominator: Static Maps Android, iPhone: Native APIs iPhone, Android, Nokia, Palm, etc: JavaScript API
  • 3.
      • Browser Win:
      • Many different platforms
      • Let us solve the cross-device issues
      • Mashups available on desktop as well as mobile
      • No download
      • We can release features (and bug fixes) faster
      • AppStore approvale
      • Native API win:
      • Native UI
      • One language to learn
      • Easier integration with your app
        • No loading browser into app
    Browser vs Native APIs
  • 4.
      • Returns a static image
      • Just upgraded to v2 with lots of new features
      • Doesn’t use JS
      • No slippy-ness
      • Wide compatibility
    Static Maps API
  • 5.
      • iPhone 3.0 SDK
      • Apple API (not Google, exactly)
      • Objective C
      • Less Powerful than JS API
    iPhone Development with MapKit
  • 6.
      • OK, MapView is just one class in com.google.android.maps
      • Java Development
      • More powerful than iPhone
      • Iteration still requires new Android release
    Android Development with MapView
  • 7. What makes mobile browsers tricky?
      • Screen size
      • User interface and interaction
      • Speed
      • Use cases
  • 8. Causes of Latency
      • Serving data
      • Download time
        • Bandwidth vs latency
          • 3G networks have reasonably high bandwidth but low latency
          • Loading small and big files take a surprisingly similar amount of time
      • JavaScript parsing time (iPhone Safari)
  • 9. What is latency?
      • Page load: the time until all components of the page are loaded, visible, and usable
      • User perceived: the time until the page appears to have loaded
  • 10. Attempts to reduce JS page load latency
      • Reduce size of JavaScript
        • Compile/obfuscate code
        • Delay load code until required
      • Combine image fetches using sprites
  • 11. Attempts to reduce JS perceived latency
      • Load Static map first, and then JS
    JS -> Static
  • 12. So, how well does Google Maps API v2 work on mobile browsers?
      • Not very
      • Initial download: 60kB in 2006; 190kB now
      • Time to load tiles
      • Synchronous access to state limits ability to delay-load code
      • Code base not designed with mobile in mind
  • 13. Maps API Version 3
  • 14.  
  • 15. Speed Comparison v3 v2 35KB 190KB
  • 16. How does v3 accomplish this improvement?
      • Start with static map
      • MVC Architecture
      • Remove unneeded code, Untangle code
  • 17. What does v3 look like? var map = new google.maps.Map(    document.getElementById("map_canvas"),    { center: new google.maps.LatLng(37.442, -122.142),      zoom: 13,      mapTypeId: google.maps.MapTypeId.ROADMAP    }); var marker = new google.maps.Marker(    {      position: map.get_center(),      map: map    }); Simple Map
  • 18. What can you do with v3? Markers, Controls, InfoWindows Geocoding  (Forward/Reverse) Custom Overlays
  • 19. Screen-Size Dependent Default UI
  • 20. No Keys Required! http://maps.google.com/maps/api/js?sensor=false
  • 21. Learn more at http://code.google.com/apis/maps/