Sharing the joy of building software with someone that doesn’t have an engineering background is hard. Today it got a little easier with App Inventor for Android.

App Inventor for Android is a Google Labs project that makes it possible to create complex Android applications without having to write any code. This is because, instead of writing code, you can visually design the way the app looks and use blocks to specify behavior.

This helps introduce concepts about logic and programming in a compelling way, without getting lost in syntax and code. And while App Inventor for Android doesn’t have every feature available in the latest Android SDK, it has been used to create some very compelling applications.

For more information about how to participate, take a look at the announcement on the Google Blog.

We look forward to seeing what you think and hearing about your stories. And, yes, the irony of writing a Google Code blog post about avoiding the need to code is not lost on me. :-)

App Inventor for Android is possible due to some significant work done in research on education computing both inside and outside Google. The brainchild of Hal Abelson (visiting faculty), App Inventor for Android is an effort to see if the nature of introductory computing can be changed.

By Ali Pasha, Google Developer Programs

• Issue Tracker Data API Overview


• Issue Tracker Data API for Java


• Issue Tracker Data API for Python


• Issue Tracker Data API Reference

I recently gave a talk (preserved YouTube here) about the cache pattern and the Web Storage Portability Layer (WSPL) at Google I/O. It was exciting getting to give a talk at the Moscone Center as previously I had only ever been one of the audience members. The conference seemed to go by in a blur for me as I was sleep-deprived from getting the WSPL to "just good enough" to actually be released. (And some ofyou have already pointed out that I missed several bugs.) In my talk, I provided a general overview of the cache pattern and this post expands on the handling of hit determination and merging server and local changes.

The cache pattern is a design pattern for building an offline-capable web application. We implemented the cache pattern to make Gmail for Mobile tolerant of flaky wireless connections but the approach is generally applicable. Here's how it works. Consider a typical AJAX application. As shown in the diagram, we have a web application with a local model, view and controllers. The user interacts with theapplication and the controller dispatches XmlHttpRequests (XHRs for short) to the server. The server sends asynchronous requests to the application which it inserts into the model.

As shown in this next diagram, in the cache pattern, we insert a cache between the application and the server. Having done so, many requests that would otherwise require a round-trip to the network.

A software cache like this one shares a great deal conceptually with hardware caches. When designing the cache used in Gmail for mobile, we used this similarity to guide our design. For example, to keep our cache as simple as possible, we implemented a software equivalent to a write-through cache with early forwarding and LRU eviction. The cache pattern in general (and consequently our implementation) has four important data flows as shown in the diagram.

Coherency and Refresh

Perhaps the most complex aspect of the cache implementation is deciding how to get updated content from the server and how to merge server updates with changes made locally. A traditional hardware cache resolves this problem by only letting one processor modify its a cache at a time and have the memory broadcast any changes to all the other caches in the system. This approach cannot work here because the Gmail server can't connect to all of its clients and update their state. Instead, the approach we took for Gmail for Mobile was for the client device regularly poll the server for alterations.

Changes From The Server

Finally, we need to merge the changes from the server into the cache as is done in the insertUpdate method from the example. Here the flow is as follows:

Our iPhone SDK is compatible with iPhone OS 3.0, and our Android SDK is compatible with Android 1.5 SDK. The SDKs include a library that can be linked in to your application which exposes methods to fetch and show ads. You must place a maximum of one ad per screen at the top or bottom (see the screenshot from the Backgrounds iPhone application). When a user clicks on the ad in your application, you can choose whether the user should view the advertiser's website in iPhone Safari or a full-screen UIWebView on the iPhone. For Android applications, our API defaults to opening the advertiser's website in the native browser.

To get started with monetizing your iPhone or Android application, sign up today on the AdSense for Mobile Applications website. We can't wait to have you join our beta network!

• Updates for a user - http://code.google.com/feeds/u/{username}/updates/user/basic
• Developers a user is tracking - http://code.google.com/feeds/u/{username}/updates/projects/basic
• Projects a user is tracking - http://code.google.com/feeds/u/{username}/updates/developers/basic

<wiki:toc max_depth="1" />

• http://code.google.com/p/google-web-toolkit/updates/list
• http://code.google.com/p/fbug/updates/list
• http://code.google.com/p/digg/updates/list
  

• http://code.google.com/feeds/p/google-web-toolkit/updates/basic
• http://code.google.com/feeds/p/fbug/updates/basic
• http://code.google.com/feeds/p/digg/updates/basic

  <script type='text/javascript' src='http://www.google.com/jsapi'></script>
  
  <script type='text/javascript'>
    google.load('visualization', '1.0', {'packages': ['table']});
    google.setOnLoadCallback(draw);
    function draw() {
      // Create a datatable with your data.
      var dataTable = new google.visualization.DataTable();
      dataTable.addColumn('string', 'Equity / Index');
      dataTable.addColumn('number', '% Change');
      dataTable.addRows(5);
      var r = 0;
      dataTable.setCell(r, 0, 'Acme.com');
      dataTable.setCell(r, 1, 3.1, '3.1%');
      r++;
      dataTable.setCell(r, 0, 'Brick & Mortar Groceries Inc');
      dataTable.setCell(r, 1, -2.43, '-2.43%');
      r++;
      dataTable.setCell(r, 0, 'S&P 500');
      dataTable.setCell(r, 1, 0.94, '0.94%');
      r++;
      dataTable.setCell(r, 0, 'Dow Jones');
      dataTable.setCell(r, 1, 1.2, '1.2%');
      r++;
      dataTable.setCell(r, 0, 'Nikkei');
      dataTable.setCell(r, 1, -0.23, '-0.23%');
      // Create a table visualization.
      var container = document.getElementById('table');
      table = new google.visualization.Table(container);
      // Apply a number formatter to the 2nd column.
      var options = {'allowHtml' : true};
      var formatter = new google.visualization.TableArrowFormat();
      formatter.format(dataTable, 1);
      // Draw the table visualization with the applied formatting.
      table.draw(dataTable, options);
    }
  </script>

  <script type='text/javascript' src='http://www.google.com/jsapi'></script>
  
  <script type='text/javascript'>
    google.load('visualization', '1.0', {'packages': ['table']});
    google.setOnLoadCallback(draw);
    function draw() {
      // Create a datatable with your data.
      var dataTable = new google.visualization.DataTable();
      dataTable.addColumn('string', 'Account', 'account');
      dataTable.addColumn('number', 'Balance', 'balance');
      dataTable.addRows(5);
      var r = 0;
      dataTable.setCell(r, 0, 'Electronics');
      dataTable.setCell(r, 1, 12000);
      r++;
      dataTable.setCell(r, 0, 'Appliances');
      dataTable.setCell(r, 1, -1000);
      r++;
      dataTable.setCell(r, 0, 'Gadgets');
      dataTable.setCell(r, 1, -21000);
      r++;
      dataTable.setCell(r, 0, 'Accessories');
      dataTable.setCell(r, 1, 5560);
      r++;
      dataTable.setCell(r, 0, 'Casings');
      dataTable.setCell(r, 1, 13092);
      // Create a table visualization.
      var container = document.getElementById('table');
      table = new google.visualization.Table(container);
      // Apply an number formatter to the 2nd column.
      var options = {'allowHtml' : true};
      var formatter = new google.visualization.TableNumberFormat(
          {prefix: '$', negativeColor: 'red', negativeParens: true});
      formatter.format(dataTable, 1);
      // Draw the table visualization with the applied formatting.
      table.draw(dataTable, options);
    }
  </script>

  <script type='text/javascript' src='http://www.google.com/jsapi'></script>
  
  <script type='text/javascript'>
    google.load('visualization', '1.0', {'packages': ['table']});
    google.setOnLoadCallback(draw);
    function draw() {
      // Create a datatable with your data.
      var dataTable = new google.visualization.DataTable();
      dataTable.addColumn('string', 'Place', 'place');
      dataTable.addColumn('number', 'Altitude', 'altitude');
      dataTable.addRows(5);
      var r = 0;
      dataTable.setCell(r, 0, 'Dead Sea');
      dataTable.setCell(r, 1, -420);
      r++;
      dataTable.setCell(r, 0, 'Death Valley');
      dataTable.setCell(r, 1, -86);
      r++;
      dataTable.setCell(r, 0, 'Mt. Everest');
      dataTable.setCell(r, 1, 8848);
      r++;
      dataTable.setCell(r, 0, 'Mt. Kilimangaro');
      dataTable.setCell(r, 1, 5895);
      r++;
      dataTable.setCell(r, 0, 'Marianas Trench');
      dataTable.setCell(r, 1, -10924);
      // Create a table visualization.
      var container = document.getElementById('table');
      table = new google.visualization.Table(container);
      // Apply an arrow formatter to the 2nd column.
      var options = {'allowHtml' : true};
      var formatter = new google.visualization.TableBarFormat(
           {base: 0, showValue: true, min: 12000, max: 12000});
      formatter.format(dataTable, 1);
      // Draw the table visualization with the applied formatting.
      table.draw(dataTable, options);
    }  
  </script>

First, there's the AJAX API property that provides a simple way to get an approximate, region-level estimate of a user's location based on their IP address. It's as simple as referencing google.loader.ClientLocation, which is made available using the Google AJAX API Loader. This API does not require users to install any client-side software. You can see this new AJAX API in action as part of the 2008 US Election gadget -- the "News by State" will show local news for the state associated with the user's IP.

Second, the Gears Geolocation API provides a way to get a more precise estimate of a user's location. On mobile devices with Gears installed, the Geolocation API can use the cell-ID of nearby cell towers or on-board GPS (if either is available) to improve the postion fix. In the near future, we'll be adding data from your WiFi connection to improve accuracy even further, on both desktop and mobile. In all cases, Gears takes care of assimilating the results from each source and returning the best available position estimate.

The Geolocation API has two JavaScript methods: getCurrentPosition() makes a single, one-off attempt to get a position fix, while watchPosition() watches the user's position over time, and provides an update whenever the position changes. Both methods allow you to configure which sources of location information are used. Gears also keeps track of the best position fix obtained from these calls and makes it available as the lastPosition property. This is a simple way to get an approximate position fix with low cost in terms of both network and battery resources.

The privacy of users' location information is extremely important. The first time your site calls the Geolocation API to request a user's location, that user will be shown a permissions dialog where they can choose to allow or deny your site access. Users can change that decision at any time via the "Gears settings" dialog in the browser menu. Google does not keep location information about users when your site uses the Geolocation API.

To use the Geolocation API your users may need to install the Gears browser plugin, a simple process on both desktop and mobile. The Geolocation API is available on platforms currently supported by Gears, including Internet Explorer, Firefox and IE Mobile (selected devices only). For users to be able to use location-enabled features on mobile they will need a Windows Mobile device that supports GPS or cell-ID lookup (for example the Samsung BlackJack II and the HTC Touch Dual, see list of supported device models in our FAQ). We are working hard to bring Gears to more mobile platforms soon. You can download and install Gears at gears.google.com. Or try out some of the first location-enabled mobile web apps using Gears.

Like the rest of Gears, this new Geolocation API is open source. We're also doing our best to work with existing and emerging standards. Gears now implements the current editor's draft of the W3C Geolocation specification, which we've helped to define in collaboration with Microsoft, Mozilla, and others. We're committed to continued collaboration around the emerging HTML5 standard and the APIs specified by the W3C Web Applications Working Group. The goal for Gears is to advance browser capabilities, and part of that is helping define future web standards.

If you're interested in providing feedback or contributing to Gears, there's more info on the project website. There's also an AJAX APIs discussion group -- we're anxious to hear what you think.