Friday, 10 December 2010

api's

What i have mentioned before about putting a map on each page showing the location of the event, i am know going to reseacrh into how to do it.

Google apis is what i hope to use to create these maps i searched in in google and here is a website that allows you to create the api for desktop but for also mobile devices all using javascript. I never had thought of creating a mobile device app either but seeing as this has intreged me about it i might just have a look into it.



Welcome to the newly updated and official Google Maps Javascript API V3! This JavaScript API now officially replaces version 2 of the Google Maps Javascript API. The versions look similar, though much has changed under the hood: Version 3 (called V3 within this document) has been designed to load fast, especially on mobile browsers such as Android-based devices and the iPhone™.
We welcome your feedback and comments on this version of the Google Maps API within the Google Maps API V3 discussion group.

Welcome to Version 3

Welcome to the release of version 3 of the Google Maps API. This JavaScript API will look similar to the existing version 2 of the Google Maps API. However, much has changed under the hood: Version 3 (called V3 within this document) has been designed to load fast, especially on mobile browsers such as Android-based devices and the iPhone™. The initial launch has a smaller feature set than that available in the V2 API. We will migrate additional features from V2 while working to keep the size of the JavaScript code small and maintain our optimized loading speeds. We welcome your feedback and comments on this version of the Google Maps API within the Google Maps API V3 discussion group.
We've implemented this latest version of the Google Maps API using a modified MVC framework. Any state changes of an MVC object (such as a map) for example, are handled through setters and getters of a particular format. As well, all state of the MVC objects are stored as properties of that object, and all observation of state changes through event handlers is of a particular format as well.
Special emphasis on enabling reliable and fast maps on mobile browsers has been integrated into this API. We encourage you to test out this API on mobile devices and post issues with specific devices to the group noted above.
Note: This version of the Google Maps JavaScript API no longer needs API keys!

Audience

This documentation is designed for people familiar with JavaScript programming and object-oriented programming concepts. You should also be familiar with Google Maps from a user's point of view. There are many JavaScript tutorials available on the Web.
This conceptual documentation is designed to let you quickly start exploring and developing cool applications with the Google Maps API. We also publish the Google Maps API Reference.
The conceptual documentation is divided up into the following areas:
Feedback on this version of the API and its documentation is welcome. Make sure to post feedback to the Google Maps JavaScript API V3 group.

Geolocation

Geolocation refers to the identification of the geographic location of a user or computing device via a variety of data collecton mechanisms. Typically, most geolocation services use network routing addresses or internal GPS devices to determine this location. Note that geolocation is a device-specific API; some browser/devices support it, while others do not (or cannot), so you cannot assume that geolocation is always possible for a web application.

Detecting the User's Location

Currently, several ways exist to detect the user's location within a browser. None of these methods are part of the Google Maps API; instead, they are common industry standards.
  • Newer browsers are starting to support the W3C Geolocation standard. This standard is part of HTML5 and will likely become the de-facto standard going forward. All applications that wish to perform geolocation should support this standard.
  • Some browsers with Google Gears can use Google Gears Geolocation API. Since widespread support for the W3C standard is still forthcoming, checking for Gears is a good fallback mechanism.
  • Some browsers use IP addresses to detect a user's location, though this provides only a very rough estimate.
As a user's IP address can only provide a rough estimate of a user's location, we don't recommend using this approach for geolocation. The W3C approach is the easiest and most fully-supported so it should be prioritized over other methods. If you do decide to use Google Gears, you should first check for whether the browser supports the W3C standard. (Note that using Google Gears will require you to load the Gears initialization Javascript).
The following example attempts to determine the user's location through the W3C navigator.geolocation property first, attempts a Google Gears approach second, and bails out if neither approach works.
// Note that using Google Gears requires loading the Javascript
// at http://code.google.com/apis/gears/gears_init.js
var initialLocation;
var siberia = new google.maps.LatLng(60, 105);
var newyork = new google.maps.LatLng(40.69847032728747, -73.9514422416687);
var browserSupportFlag =  new Boolean();
function initialize() {
  var myOptions = {
    zoom: 6,
    mapTypeId: google.maps.MapTypeId.ROADMAP
  };
  var map = new google.maps.Map(document.getElementById("map_canvas"), myOptions);
  
  // Try W3C Geolocation (Preferred)
  if(navigator.geolocation) {
    browserSupportFlag = true;
    navigator.geolocation.getCurrentPosition(function(position) {
      initialLocation = new google.maps.LatLng(position.coords.latitude,position.coords.longitude);
      map.setCenter(initialLocation);
    }, function() {
      handleNoGeolocation(browserSupportFlag);
    });
  // Try Google Gears Geolocation
  } else if (google.gears) {
    browserSupportFlag = true;
    var geo = google.gears.factory.create('beta.geolocation');
    geo.getCurrentPosition(function(position) {
      initialLocation = new google.maps.LatLng(position.latitude,position.longitude);
      map.setCenter(initialLocation);
    }, function() {
      handleNoGeoLocation(browserSupportFlag);
    });
  // Browser doesn't support Geolocation
  } else {
    browserSupportFlag = false;
    handleNoGeolocation(browserSupportFlag);
  }
  
  function handleNoGeolocation(errorFlag) {
    if (errorFlag == true) {
      alert("Geolocation service failed.");
      initialLocation = newyork;
    } else {
      alert("Your browser doesn't support geolocation. We've placed you in Siberia.");
      initialLocation = siberia;
    }
    map.setCenter(initialLocation);
  }
}

Specifying the Sensor Parameter

Use of the Google Maps API requires that you indicate whether your application is using a sensor (such as a GPS locator) to determine the user's location. This is especially important for mobile devices. Applications must pass a required sensor parameter to the <script> tag when including the Maps API javascript code, indicating whether or not your application is using a sensor device.
Applications that determine the user's location via a sensor must pass sensor=true when loading the Maps API JavaScript.
#
# Example using sensor when loading the Maps JavaScript API
#<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=true"></script>
Note that even if your device does not use a sensing device, you must still pass this parameter, setting its value to false.

Developing for Mobile Devices (iPhone and Android device)

The Google Maps API V3 has been designed to load fast and work well on mobile devices. In particular, we have focused on development for advanced mobile devices such as the iPhone and handsets running the Android operating system. Mobile devices have smaller screen sizes than typical browsers on the desktop. As well, they often have particular behavior specific to those devices (such as "pinch-to-zoom" on the iPhone). If you wish to have your application work well on mobile devices, we recommend the following:
  • Set the <div> containing your map to have width and height attributes of 100%. Be aware that some older desktop browsers don't display well with these values, however.
  • You can detect iPhone and Android devices by inspecting the navigator.userAgent property within the DOM:
    function detectBrowser() {
      var useragent = navigator.userAgent;
      var mapdiv = document.getElementById("map_canvas");
        
      if (useragent.indexOf('iPhone') != -1 || useragent.indexOf('Android') != -1 ) {
        mapdiv.style.width = '100%';
        mapdiv.style.height = '100%';
      } else {
        mapdiv.style.width = '600px';
        mapdiv.style.height = '800px';
      }
    }
    This allows you to alter layout for particular devices, as we've done here to change the screen real estate for each device.
  • The iPhone device respects the following <meta> tag:
    <meta name="viewport" content="initial-scale=1.0, user-scalable=no" />
    This setting specifies that this map should be displayed full-screen and should not be resizable by the user. Android devices running software version 1.5 (Cupcake) also support these parameters. Note that the iPhone's Safari browser requires this <meta> tag be included within the page's <head> element.
For more information on development for the iPhone, consult Apple's Developer documentation. For more information on development of Android devices, consult theAndroid documentation.

Localization in the V3 Maps API

You may localize your Maps API application both by altering default language settings and by setting the application's region code, which alters how it behaves based on a given country or territory.

Language Localization

The Google Maps API uses the browser's preferred language setting when displaying textual information such as the names for controls, copyright notices, driving directions and labels on maps. In most cases, this is preferable; you usually do not wish to override the user's preferred language setting. However, if you wish to change the Maps API to ignore the browser's language setting and force it to display information in a particular language, you can add an optional languageparameter to the <script> tag when including the Maps API javascript code, specifying the language to use.
For example, to display a Maps API application in Japanese, add &language=ja to the <script> tag as shown below:
<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false&language=ja">
Note: loading the API in the manner shown above will use the Japanese language for all users regardless of user preferences. Be sure you wish this behavior before setting this option.
The Maps Javascript API also supports Bi-directional (Bidi) text containing characters in both Left-to-Right (LTR) and Right-to-Left (RTL) languages natively. Examples of RTL languages include Arabic, Hebrew and Farsi. Generally, you should specify RTL language pages to render properly by adding dir='rtl' to the page's<html> element. The following example renders a map of Cairo, Egypt using Arabic controls:
See also the supported list of languages. Note that we often update supported languages so this list may not be exhaustive.

Region Localization

The Maps API serves map tiles and biases application behavior, by default, using the country of the host domain from which the API is loaded (which is the USA formaps.google.com). If you wish to alter your application to serve different map tiles or bias the application (such as biasing geocoding results towards the region), you can override this default behavior by adding a region parameter to the <script> tag when including the Maps API javascript code.
The region parameter accepts Unicode region subtag identifiers which (generally) have a one-to-one mapping to country code Top-Level Domains (ccTLDs). Most Unicode region identifiers are identical to ISO 3166-1 codes, with some notable exceptions. For example, Great Britain's ccTLD is "uk" (corresponding to the domain.co.uk) while its region identifier is "GB."
For example, to use a Maps API application localized to the United Kingdom, add &region=GB to the <script> tag as shown below:
<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false&region=GB">
The following examples show two maps, one which geocodes "Toledo" based on the default region (US) to "Toledo, Ohio" and one which biases results based on aregion set to ES (Spain) to "Toledo, Spain."

Libraries in the V3 Maps API

The JavaScript code for the Maps API is loaded via a bootstrap URL of the form http://maps.google.com/maps/api/js. This bootstrap request loads all of the main Javascript objects and symbols for use in the Maps API. Some Maps API features are also available in self-contained libraries which are not loaded unless you specifically request them. Breaking up supplemental components into libraries allows the main API to load (and parse) quickly; you only incur the additional overhead of loading and parsing libraries if you need them.
You specify additional libraries to load within the bootstrap request by specifying a libraries parameter, passing that parameter the name of the library or libraries. Multiple libraries may be specified as a comma-separated list. Once loaded, libraries are accessed via the google.maps.libraryName namespace.
The following libraries are currently available:
  • geometry includes utility functions for calculating scalar geometric values (such as distance and area) on the the surface of the earth. Consult the Geometry library documentation for more information.
We will add more libraries in the future as we release additional opt-in features.
The following bootstrap request illustrates how to request the google.maps.geometry library of the Maps Javascript API:
<script type="text/javascript" src="http://maps.google.com/maps/api/js?libraries=geometry&sensor=true_or_false"></script>

Asynchronously Loading the Javascript API

Generally, you load the Javascript Maps API as soon as you load your page by including the API with a <script> tag and executing your application Javascript code after that script has loaded. However, while this Javascript is being parsed, your browser may not render additional content on the page. In most cases, this delay is not noticable, but you may wish to load the Maps API Javascript code after your page has finished loading. You may also wish to load the Maps API Javascript on demand
It is simple enough to load the Maps Javascript API after a page loads by injecting your own <script> tag in response to a window.onload event, but you need to additionally instruct the Maps Javascript API bootstrap to delay execution of your application code until the Maps Javascript API code is fully loaded. You may do so using the callback parameter. This parameter takes as an argument the function to execute upon completing loading the API.
The following code instructs the application to load the Maps API after the page has fully loaded (using window.onload) and write the Maps Javascript API into a<script> tag within the page. Additionally, we instruct the API to only execute the initialize() function after the API has fully loaded by passingcallback=initialize to the Maps API bootstrap:
function initialize() {
  var myLatlng = new google.maps.LatLng(-34.397, 150.644);
  var myOptions = {
    zoom: 8,
    center: myLatlng,
    mapTypeId: google.maps.MapTypeId.ROADMAP
  }
  var map = new google.maps.Map(document.getElementById("map_canvas"), myOptions);
}
  function loadScript() {
  var script = document.createElement("script");
  script.type = "text/javascript";
  script.src = "http://maps.google.com/maps/api/js?sensor=false&callback=initialize";
  document.body.appendChild(script);
}
  
window.onload = loadScript;

Versioning

The Google Maps API team will regularly update this Javascript API with new features, bug fixes, and performance improvements. All API changes will be backwards-compatible, ensuring that if you launch an application using the currently documented interfaces, that application will continue to work without modification as the API is updated. (Note: experimental features are not covered by this guarantee. Features that are experimental will be clearly labeled in the API documentation.)

Types of Versions

You can indicate which version of the API to load within your application by specifying it using the v parameter of the Maps Javascript API bootstrap request. Two options are currently supported:
  • The nightly (development) version, specified with v=3 or by omitting the v parameter. This version reflects the current version based off the trunk, including any bug fixes and new features as they are publicly released.
  • A numbered version, indicated with v=3.number, which specifies a feature set of the API. These numbered versions may either be a release version or afrozen version. (See below.)
The following bootstrap request illustrates how to request a specific version of the Maps Javascript API:
http://maps.google.com/maps/api/js?v=3.1&sensor=true_or_false
Each quarter, we will cut a new numbered version (the "release version") and release it for public use. Throughout the quarter we will continue to add bug fixes to this release version, which will be noted within the Maps Javascript API changelog, while ensuring that the feature set remains stable.
When we release a new numbered version, we will "freeze" the previous release version, meaning that we will no longer update it with any code changes, including bug fixes, ensuring it is completely stable. Each time we introduce a new frozen version in this manner we will retire the existing frozen version. That is, at any given time there will be only one frozen version available. Applications requesting numbered versions that have been retired will automatically receive the current frozen version.

Choosing an API version

The following guidelines apply when choosing the appropriate API version for your Maps API V3 application:
  • Production applications should always specify a minor version (eg. 3.1, 3.2, etc.).
  • The Maps API Premier SLA does not apply to the current Nightly (development) version. Maps API Premier applications must use the current Release version, or an earlier version to be covered by the SLA.
  • When developing a new Maps API v3 application, we recommend that you select the latest Nightly version by its version number (eg. 3.3), and then continue to use that version until such time as you need to add additional features available in a later version. In this way the version you are using will mature as your application develops, moving to be the Release and then Frozen version over time.
  • Production applications that request a version equal to or older than the current Frozen version should be tested against the latest Release version once per quarter in order to identify any issues with backwards compatibility in that version before it is frozen.



instead of cutting bits and pieces out i thought i would show you the whole document that it gives you to create these apis. These would be very helpful towards my site as it maybe one day could develop into an app that would show all the events on one app hopefully