Saturday, June 25, 2011

[Gd] GPE Support for Eclipse Indigo (3.7)

| More

Google Web Toolkit Blog: GPE Support for Eclipse Indigo (3.7)

Earlier this week Eclipse Indigo shipped to much fanfare. One of the features that we are personally happy to see ship is the embedded Window Builder support. Window Builder is the framework on which SWT, Swing, and (near and dear to our hearts) GWT Designer is built on top of.




To coincide with this announcement we now have a 2.3.2 version of GPE that is Indigo-compatible. For more information on installing this update, checkout the GPE quick start guide.




Chris Ramsdale, Product Manager, GWT and GPE cramsdale@google.com

URL: http://googlewebtoolkit.blogspot.com/2011/06/gpe-support-for-eclipse-indigo-37.html

Friday, June 24, 2011

[Gd] Fridaygram

| More

The official Google Code blog: Fridaygram


By Scott Knaster, Google Code Blog Editor

Even by the standards of web software, the Google App Engine team moves pretty quickly, with a new version every 6 weeks or so. (I learned how fast they go when I was writing App Engine technical docs and trying to keep up with what the engineers were creating.) This week, the team launched App Engine 1.5.1, with a nice collection of new features, including support in the SDK for testing the High Replication Datastore, an API to use ProtoRPC from Python, and support for user presence in the Channel API. You can see the complete list and more details in the App Engine Blog.

Nature does new releases too, although it usually takes a lot longer to add new features and fix bugs. Can the current version of humans sense a magnetic field? Scientists in Massachusetts found indirect clues by replacing a fly protein with a human one. In a study, the human cryptochrome protein restored the fly’s ability to respond to a magnetic field. Not only is that pretty cool, that BBC Science News page has an awesome picture of a fly.

Finally, if you have a few minutes this weekend, check out this nifty video that takes an original and fun look at multiplication.




Fridaygram posts are lighter than our usual fare. They're designed for your Friday afternoon and weekend enjoyment. Each Fridaygram item must pass only one test: it has to be interesting to us nerds.

URL: http://googlecode.blogspot.com/2011/06/fridaygram_24.html

Thursday, June 23, 2011

[Gd] Google Apps Script opens new ways to deliver workflow solutions for businesses

| More

Google Apps Developer Blog: Google Apps Script opens new ways to deliver workflow solutions for businesses

Editors note: This is cross-posted from the Google Enterprise Blog. Guest author John Gale is a developer at Appogee, a Google focused systems integrator in the UK. John helps Appogee customers make the most of the Google platform and is the author of Appogee Bookmarks for Android.

Google Sites offers an incredible way to author and distribute content, and we use it extensively both for ourselves and our clients. Therefore it was not surprising that our customers started requesting a content approval workflow in Google Sites. Now with Google Apps Script, we have been able to develop Appogee Content Approval for Google Sites.

The Solution
Appogee Content Approval for Google Sites (ACA) can be set up for any existing Google Site without having to make any changes to the site. ACA works as follows:
  1. The ACA spreadsheet generates a Content Submission Form and any content submitted is routed to a selected approver.
  2. The approver receives an email notification, which they can authorize or reject.
  3. Once authorized, the ACA spreadsheet writes the new content into the target Site using Apps Script’s Sites services. The new content is then visible to anyone with view permissions in the target site.

Approver receives an email containing the submitted content

The content submission URL can be shared to any group or published directly on the target Google Site, which represents the end goal on the workflow diagram below. Content may only be submitted by users that are logged into your domain and content can only be published with Approver sanction.
ACA Workflow Diagram

Google Apps Script made it easy
We used a number of Apps Script services to develop this application. Apps Script was an easy choice as it builds on pooled knowledge from the Google Web Toolkit (GWT) and uses Javascript syntax. Using Apps Script’s UI Services, we were able build up a working user interface quickly. Google has since introduced a new experimental feature to complement the UI Services, which provides a drag and drop GUI for building screens. We expect this feature to reduce development time required for building future apps, as well as offering a wide range of widgets and controls to improve the user experience. We used a standard Google spreadsheet as a kind of a data store in ACA. It’s worth mentioning that Apps Script’s documentation site has a plethora of tutorials covering everything from simple spreadsheet macros to full help desk applications.

One of Google Apps Scripts’ core features is the ability to seamlessly integrate different services together, in our case this was Google Sites and Spreadsheets, but many other services are accessible, such as Mail and Contacts. It was always the aim to make ACA a powerful tool without unnecessary complexity and thanks to Google Apps Script, we have successfully delivered content approval workflow to Google Sites. ACA represents our third off-the-shelf product to be listed in the Google Apps Marketplace.

Posted by John Gale, Solution Developer, Appogee

Want to weigh in on this topic? Discuss on Buzz

URL: http://googleappsdeveloper.blogspot.com/2011/06/google-apps-script-opens-new-ways-to.html

[Gd] Building UI in Apps Script just got a whole lot easier!

| More

Google Apps Developer Blog: Building UI in Apps Script just got a whole lot easier!

One of the most useful parts of Apps Script is the Ui service. UiApp lets you build a professional looking web app in just a few lines of code. Some of our users have built incredibly complex apps this way, all hosted by Google and running in any modern browser.

For a lot of users, though, UiApp seems a bit daunting. It can be hard to visualize how small changes to your code affect the look of your app, or how adding a component in one place of the UI can shift the positioning of a component in another place. We know what that’s like - we write scripts too! That’s why we’re excited to unveil the new Apps Script GUI Builder.

Creating User Interfaces by Drag and Drop

The GUI Builder lets you construct user interfaces for your scripts quickly and easily. Simply draw the application, set some properties, and you are ready to go! You can use a GUI you’ve constructed this way inside a Spreadsheets dialog, on a Sites page, or as a standalone web service at its own URL.

To use what you’ve built with the GUI Builder inside an app, use this snippet of code:
function doGet() {
var app = UiApp.createApplication();
var component = app.loadComponent(“MyGui”);
app.add(component);
return app;
}

The new loadComponent method loads your GUI and makes it available to the app. Then you can add it to the app like any other component. You can also add it inside another panel, instead of at the root of the app.

GUI Elements created in the Builder behave exactly as if you had created them in code. If you want to reference them in a script, you can do so with the app.getElementById() method. Every element from the GUI will have an ID property (you’ll see it in the GUI Builder) and you can use those to reference components and change them. For example, in the code below we are changing the text color of a button to red.
var button = app.getElementById(“Button1”);
button.setStyleAttribute(“color”, “red”);

Extending the User Interface

Of course, you can do anything you like with these references, such as adding new widgets to panels, or removing widgets created in the builder. You can also use these references to add only part of a GUI to an app. Suppose that inside your GUI is an AbsolutePanel called “Panel1”. This code displays only that panel:
function doGet() {
var app = UiApp.createApplication();
var component = app.loadComponent(“MyGui”);
app.add(component.getElementById(“Pane1l”));
return app;
}

Advanced Features of GUI Builder

Finally, you can add a component to the same app multiple times. If you do this, however, you need to do something extra to make sure that the ID properties don’t collide. Since every element in the GUI has an ID from the builder, you have to specify a different prefix for each copy of the app that you load. This code adds a GUI from the GUI Builder to the same app twice:
 var component = 
app.add(app.loadComponent(“MyGui”), {prefix: “a”});
app.add(app.loadComponent(“MyGui”), {prefix: “b”});

You can reference individual elements from each copy using these prefixes. “Button1” becomes “aButton1”, and so on.

Publishing Applications to your users

Once you’ve built a GUI, you can can enable your app as a web service from the Share > Publish as Service menu in the script editor. That will give you a URL for your app, and you’ll see the GUI you built right away! You can also show a GUI inside a spreadsheet using the sheet.show() method.

The GUI Builder currently supports a subset of UiApp widgets, but you can expect that set to continue to grow until all widgets are supported. In the meantime, you can augment a GUI with code, as is demonstrated above. We’ll also continue to improve UiApp - we’ve been listening to your feedback, and we have a lot of excited things planned.

Getting Started

GUI Builder can be accessed from the Apps Script Editor. Click File > Build a user interface and start building interfaces.

You keep building great apps. We’ll keep making it easier.

Corey Goldfeder profile

Corey is a Google software engineer on the Apps Script Project, based in New York. He has previously worked on Similar Shape search for 3DWarehouse, and as a robotics researcher before joining Google.



Want to weigh in on this topic? Discuss on Buzz
URL: http://googleappsdeveloper.blogspot.com/2011/06/building-ui-in-apps-script-just-got.html

[Gd] GQueues Mobile: a case for the HTML5 web app

| More

Google Apps Developer Blog: GQueues Mobile: a case for the HTML5 web app

This guest post by Cameron Henneke originally appeared last month on the Google Code blog as part of the Who's at Google I/O series. We don't normally cross-post one month later, but we think this post will be very valuable for Google Apps Marketplace developers evaluating their mobile strategy.

With the proliferation of mobile app stores, the intensity of the native app vs. web app debate in the mobile space continues to increase. While native apps offer tighter phone integration and more features, developers must maintain multiple apps and codebases. Web apps can serve a variety of devices from only one source, but they are limited by current browser technology.

In the Google IO session HTML5 versus Android: Apps or Web for Mobile Development?, Google Developer Advocates Reto Meier and Michael Mahemoff explore the advantages of both strategies. In this post I describe my own experience as an argument that an HTML5 app is a viable and sensible option for online products with limited resources.

Back in 2009 I started developing GQueues, a simple yet powerful task manager that helps people get things done. Built on Google App Engine, GQueues allows users to log in with Gmail and Google Apps accounts, and provides a full set of features including two-way Google Calendar syncing, shared lists, assignments, subtasks, repeating tasks, tagging, and reminders.




While I initially created an “optimized” version of the site for phone browsers, users have been clamoring for a native app ever since its launch two years ago. As the product’s sole developer, with every new feature I add, I consider quite carefully how it will affect maintenance and future development. Creating native apps for iOS, Android, Palm, and Blackberry would not only require a huge initial investment of time, but also dramatically slow down every new subsequent feature added, since each app would need updating. If GQueues were a large company with teams of developers this wouldn’t be as big an issue, although multiple apps still increase complexity and add overhead.

After engaging with users on our discussion forum, I learned that when they asked for a “native app,” what they really wanted was the ability to manage their tasks offline. My challenge was clear: if I could create a fast, intuitive web app with offline support, then I could satisfy users on a wide variety of phones while having only one mobile codebase to maintain as I enhanced the product.

Three months ago I set out to essentially rewrite the entire GQueues product as a mobile web app that utilized a Web SQL database for offline storage and an Application Cache for static resources. The journey was filled with many challenges, to say the least. With current mobile JavaScript libraries still growing to maturity, I found it necessary to create my own custom framework to run the app. Since GQueues data is stored in App Engine’s datastore, which is a schema-less, “noSQL” database, syncing to the mobile SQL database proved quite challenging as well. Essentially this required creating an object relational mapping layer in JavaScript to sit on top of the mobile database and interface with data on App Engine as well as input from the user. As a bonus challenge, current implementations of Web SQL only support asynchronous calls, so architecting the front-end JavaScript code required a high use of callbacks and careful planning around data availability.

During development, my test devices included a Nexus S, iPhone, and iPad. A day before launch I was delighted to find the mobile app worked great on Motorola Xoom and Samsung Galaxy Android tablets, as well as the Blackberry Playbook. This fortuitous discovery reaffirmed my decision to have one codebase serving many devices. Last week I launched the new GQueues Mobile, which so far has been met with very positive reactions from users – even the steadfast “native app” proponents! With a team of developers I surely could have created native apps for several devices, but with my existing constraints I know the HTML5 strategy was the right decision for GQueues. Check out our video and determine for yourself if GQueues Mobile stacks up to a native app.




Cameron Henneke
Cameron Henneke is the Founder and Principal Engineer of GQueues

Cameron is based in Chicago and loves Python and JavaScript equally. While not coding or answering support emails, he enjoys playing the piano, backpacking, and cheering on the Bulls.



Want to weigh in on this topic? Discuss on Buzz
URL: http://googleappsdeveloper.blogspot.com/2011/06/gqueues-mobile-case-for-html5-web-app.html

[Gd] A Deep Dive Into Location

| More

Android Developers Blog: A Deep Dive Into Location

[This post is by Reto Meier, Tech Lead for Android Developer Relations, who wrote the book on Android App development. — Tim Bray]

I'm a big fan of location-based apps, but not their seemingly-inevitable startup latency.

Whether it's finding a place to eat or searching for the nearest Boris Bike, I find the delay while waiting for the GPS to get a fix, and then for the results list to populate, to be interminable. Once I’m in a venue and ready to get some tips, check-in, or review the food, I’m frequently thwarted by a lack of data connection.

Rather than shaking my fist at the sky, I’ve written an open-source reference app that incorporates all of the tips, tricks, and cheats I know to reduce the time between opening an app and seeing an up-to-date list of nearby venues - as well as providing a reasonable level of offline support — all while keeping the impact on battery life to a minimum.

Show Me the Code

You can check-out the Android Protips for Location open source project from Google Code. Don’t forget to read the Readme.txt for the steps required to make it compile and run successfully.

What Does it Actually Do?

It uses the Google Places API to implement the core functionality of apps that use location to provide a list of nearby points of interest, drill down into their details, and then check-in/rate/review them.

The code implements many of the best-practices I detailed in my Google I/O 2011 session, Android Protips: Advanced Topics for Expert Android Developers (video), including using Intents to receive location updates, using the Passive Location Provider, using and monitoring device state to vary refresh rates, toggling your manifest Receivers at runtime, and using the Cursor Loader.

The app targets Honeycomb but supports Android platforms from 1.6 and up.

Nothing would make me happier than for you to cut/copy/borrow / steal this code to build better location-based apps. If you do, I’d love it if you told me about it!

Now that you’ve got the code, let’s take a closer look at it

My top priority was freshness: Minimize the latency between opening the app and being able to check in to a desired location, while still minimizing the impact of the app on battery life.

Related requirements:

  • The current location has to be found as quickly as possible.

  • The list of venues should update when the location changes.

  • The list of nearby locations and their details must be available when we’re offline.

  • Check-ins must be possible while we’re offline.

  • Location data and other user data must be handled properly (see our prior blog post on best practices).

Freshness means never having to wait

You can significantly reduce the latency for getting your first location fix by retrieving the last known location from the Location Manager each time the app is resumed.

In this snippet taken from the GingerbreadLastLocationFinder, we iterate through each location provider on the device — including those that aren't currently available — to find the most timely and accurate last known location.

List<String> matchingProviders = locationManager.getAllProviders();
for (String provider: matchingProviders) {
Location location = locationManager.getLastKnownLocation(provider);
if (location != null) {
float accuracy = location.getAccuracy();
long time = location.getTime();

if ((time > minTime && accuracy < bestAccuracy)) {
bestResult = location;
bestAccuracy = accuracy;
bestTime = time;
}
else if (time < minTime &&
bestAccuracy == Float.MAX_VALUE && time > bestTime){
bestResult = location;
bestTime = time;
}
}
}

If there is one or more locations available from within the allowed latency, we return the most accurate one. If not, we simply return the most recent result.

In the latter case (where it’s determined that the last location update isn't recent enough) this newest result is still returned, but we also request a single location update using that fastest location provider available.

if (locationListener != null &&
(bestTime < maxTime || bestAccuracy > maxDistance)) {
IntentFilter locIntentFilter = new IntentFilter(SINGLE_LOCATION_UPDATE_ACTION);
context.registerReceiver(singleUpdateReceiver, locIntentFilter);
locationManager.requestSingleUpdate(criteria, singleUpatePI);
}

Unfortunately we can’t specify “fastest” when using Criteria to choose a location provider, but in practice we know that coarser providers — particularly the network location provider — tend to return results faster than the more accurate options. In this case I’ve requested coarse accuracy and low power in order to select the Network Provider when it’s available.

Note also that this code snippet shows the GingerbreadLastLocationFinder which uses the requestSingleUpdate method to receive a one-shot location update. This wasn’t available prior to Gingerbread - check out the LegacyLastLocationFinder to see how I have implemented the same functionality for devices running earlier platform versions.

The singleUpdateReceiver passes the received update back to the calling class through a registered Location Listener.

protected BroadcastReceiver singleUpdateReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
context.unregisterReceiver(singleUpdateReceiver);

String key = LocationManager.KEY_LOCATION_CHANGED;
Location location = (Location)intent.getExtras().get(key);

if (locationListener != null && location != null)
locationListener.onLocationChanged(location);

locationManager.removeUpdates(singleUpatePI);
}
};

Use Intents to receive location updates

Having obtained the most accurate/timely estimate of our current location, we also want to receive location updates.

The PlacesConstants class includes a number of values that determine the frequency of location updates (and the associated server polling). Tweak them to ensure that updates occur exactly as often as required.

// The default search radius when searching for places nearby.
public static int DEFAULT_RADIUS = 150;
// The maximum distance the user should travel between location updates.
public static int MAX_DISTANCE = DEFAULT_RADIUS/2;
// The maximum time that should pass before the user gets a location update.
public static long MAX_TIME = AlarmManager.INTERVAL_FIFTEEN_MINUTES;

The next step is to request the location updates from the Location Manager. In this snippet taken from the GingerbreadLocationUpdateRequester we can pass the Criteria used to determine which Location Provider to request updates from directly into the requestLocationUpdates call.

public void requestLocationUpdates(long minTime, long minDistance, 
Criteria criteria, PendingIntent pendingIntent) {

locationManager.requestLocationUpdates(minTime, minDistance,
criteria, pendingIntent);
}

Note that we're passing in a Pending Intent rather than a Location Listener.

Intent activeIntent = new Intent(this, LocationChangedReceiver.class);
locationListenerPendingIntent =
PendingIntent.getBroadcast(this, 0, activeIntent, PendingIntent.FLAG_UPDATE_CURRENT);

I generally prefer this over using Location Listeners as it offers the flexibility of registering receivers in multiple Activities or Services, or directly in the manifest.

In this app, a new location means an updated list of nearby venues. This happens via a Service that makes a server query and updates the Content Provider that populates the place list.

Because the location change isn’t directly updating the UI, it makes sense to create and register the associated LocationChangedReceiver in the manifest rather than the main Activity.

<receiver android:name=".receivers.LocationChangedReceiver"/>

The Location Changed Receiver extracts the location from each update and starts the PlaceUpdateService to refresh the database of nearby locations.

if (intent.hasExtra(locationKey)) {
Location location = (Location)intent.getExtras().get(locationKey);
Log.d(TAG, "Actively Updating place list");
Intent updateServiceIntent =
new Intent(context, PlacesConstants.SUPPORTS_ECLAIR ? EclairPlacesUpdateService.class : PlacesUpdateService.class);
updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_LOCATION, location);
updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_RADIUS, PlacesConstants.DEFAULT_RADIUS);
updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_FORCEREFRESH, true);

context.startService(updateServiceIntent);
}

Monitor inactive providers for a better option

The snippet from PlacesActivity below shows how to monitor two important conditions:

  • The Location Provider we are using being deactivated.

  • A better Location Provider becoming available.

In either case, we simply re-run the process used to determine the best available provider and request location updates.

// Register a receiver that listens for when the provider I'm using has been disabled. 
IntentFilter intentFilter = new IntentFilter(PlacesConstants.ACTIVE_LOCATION_UPDATE_PROVIDER_DISABLED);
registerReceiver(locProviderDisabledReceiver, intentFilter);

// Listen for a better provider becoming available.
String bestProvider = locationManager.getBestProvider(criteria, false);
String bestAvailableProvider = locationManager.getBestProvider(criteria, true);
if (bestProvider != null && !bestProvider.equals(bestAvailableProvider))
locationManager.requestLocationUpdates(bestProvider, 0, 0,
bestInactiveLocationProviderListener, getMainLooper());

Freshness means always being up to date. What if we could reduce startup latency to zero?

You can start the PlacesUpdateService in the background to refresh the list of nearby locations while your app is in the background. Done correctly, a relevant list of venues can be immediately available when you open the app.

Done poorly, your users will never find this out as you’ll have drained their battery too quickly.

Requesting location updates (particularly using the GPS) while your app isn’t in the foreground is poor practice, as it can significantly impact battery life. Instead, you can use the Passive Location Provider to receive location updates alongside other apps that have already requested them.

This extract from the FroyoLocationUpdateRequester enables passive updates on Froyo+ platforms.

public void requestPassiveLocationUpdates(long minTime, long minDistance, PendingIntent pendingIntent) {
locationManager.requestLocationUpdates(LocationManager.PASSIVE_PROVIDER,
PlacesConstants.MAX_TIME, PlacesConstants.MAX_DISTANCE, pendingIntent);
}

As a result receiving background location updates is effectively free! Unfortunately the battery cost of your server downloads aren’t, so you’ll still need to carefully balance how often you act on passive location updates with battery life.

You can achieve a similar effect in pre-Froyo devices using inexact repeating non-wake alarms as shown in the LegacyLocationUpdateRequester.

public void requestPassiveLocationUpdates(long minTime, long minDistance, 
PendingIntent pendingIntent) {

alarmManager.setInexactRepeating(AlarmManager.ELAPSED_REALTIME,
System.currentTimeMillis()+PlacesConstants.MAX_TIME,
PlacesConstants.MAX_TIME, pendingIntent);
}

Rather than receiving updates from the Location Manager, this technique manually checks the last known location at a frequency determined by the maximum location update latency.

This legacy technique is significantly less efficient, so you may choose to simply disable background updates on pre-Froyo devices.

We handle updates themselves within the PassiveLocationChangedReceiver which determines the current location and starts the PlaceUpdateService.

if (location != null) {
Intent updateServiceIntent =
new Intent(context, PlacesConstants.SUPPORTS_ECLAIR ? EclairPlacesUpdateService.class : PlacesUpdateService.class);

updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_LOCATION, location);
updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_RADIUS,
PlacesConstants.DEFAULT_RADIUS);
updateServiceIntent.putExtra(PlacesConstants.EXTRA_KEY_FORCEREFRESH, false);
context.startService(updateServiceIntent);
}

Using Intents to passively receive location updates when your app isn't active

You’ll note that we registered the Passive Location Changed Receiver in the application manifest.


<receiver android:name=".receivers.PassiveLocationChangedReceiver"/>

As a result we can continue to receive these background updates even when the application has been killed by the system to free resources.

This offers the significant advantage of allowing the system to reclaim the resources used by your app, while still retaining the advantages of a zero latency startup.

If your app recognizes the concept of “exiting” (typically when the user clicks the back button on your home screen), it’s good form to turn off passive location updates - including disabling your passive manifest Receiver.

Being fresh means working offline

To add offline support we start by caching all our lookup results to the PlacesContentProvider and PlaceDetailsContentProvider.

Under certain circumstances we will also pre-fetch location details. This snippet from the PlacesUpdateService shows how pre-fetching is enabled for a limited number of locations.

Note that pre-fetching is also potentially disabled while on mobile data networks or when the battery is low.

if ((prefetchCount < PlacesConstants.PREFETCH_LIMIT) &&
(!PlacesConstants.PREFETCH_ON_WIFI_ONLY || !mobileData) &&
(!PlacesConstants.DISABLE_PREFETCH_ON_LOW_BATTERY || !lowBattery)) {
prefetchCount++;

// Start the PlaceDetailsUpdateService to prefetch the details for this place.
}

We use a similar technique to provide support for offline checkins. The PlaceCheckinService queues failed checkins, and checkins attempted while offline, to be retried (in order) when the ConnectivityChangedReceiver determines that we’re back online.

Optimizing battery life: Smart Services and using device state to toggle your manifest Receivers

There's no point running update services when we aren’t online, so the PlaceUpdateService checks for connectivity before attempting an update.

NetworkInfo activeNetwork = cm.getActiveNetworkInfo();
boolean isConnected = activeNetwork != null &&
activeNetwork.isConnectedOrConnecting();

If we’re not connected, the Passive and Active Location Changed Receivers are disabled and the the ConnectivityChangedReceiver is turned on.

ComponentName connectivityReceiver = 
new ComponentName(this, ConnectivityChangedReceiver.class);
ComponentName locationReceiver =
new ComponentName(this, LocationChangedReceiver.class);
ComponentName passiveLocationReceiver =
new ComponentName(this, PassiveLocationChangedReceiver.class);

pm.setComponentEnabledSetting(connectivityReceiver,
PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
PackageManager.DONT_KILL_APP);

pm.setComponentEnabledSetting(locationReceiver,
PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
PackageManager.DONT_KILL_APP);

pm.setComponentEnabledSetting(passiveLocationReceiver,
PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
PackageManager.DONT_KILL_APP);

The ConnectivityChangedReceiver listens for connectivity changes. When a new connection is made, it simply disables itself and re-enables the location listeners.

Monitoring battery state to reduce functionality and save power

When your phone is on its last 15%, most apps are firmly in the back seat to conserving what watts you have remaining. We can register manifest Receivers to be alerted when the device enters or leaves the low battery state.

<receiver android:name=".receivers.PowerStateChangedReceiver">
<intent-filter>
<action android:name="android.intent.action.ACTION_BATTERY_LOW"/>
<action android:name="android.intent.action.ACTION_BATTERY_OKAY"/>
</intent-filter>
</receiver>

This snippet from the PowerStateChangedReceiver disables the PassiveLocationChangedReceiver whenever the device enters a low battery state, and turns it back on once the battery level is okay.

boolean batteryLow = intent.getAction().equals(Intent.ACTION_BATTERY_LOW);

pm.setComponentEnabledSetting(passiveLocationReceiver,
batteryLow ? PackageManager.COMPONENT_ENABLED_STATE_DISABLED :
PackageManager.COMPONENT_ENABLED_STATE_DEFAULT,
PackageManager.DONT_KILL_APP);

You can extend this logic to disable all prefetching or reduce the frequency of your updates during low battery conditions.

What’s Next?

This is already a monster post, so I’m going to leave it there. I’ll follow up in the next week with a post on my personal blog, The Radioactive Yak, that will go in to more detail on the psychic and smooth elements of this app like using the Backup Manager and the Cursor Loader.

I also plan to build a similar reference app for news apps, so that I can spend more time reading and less time waiting.

In the mean time, happy coding!

URL: http://android-developers.blogspot.com/2011/06/deep-dive-into-location.html

[Gd] Introducing DOM Snitch, our passive in-the-browser reconnaissance tool

| More

Google Testing Blog: Introducing DOM Snitch, our passive in-the-browser reconnaissance tool

By Radoslav Vasilev from Google Zurich

Every day modern web applications are becoming increasingly sophisticated, and as their complexity grows so does their attack surface. Previously we introduced open source tools such as Skipfish and Ratproxy to assist developers in understanding and securing these applications.

As existing tools focus mostly on testing server-side code, today we are happy to introduce DOM Snitch — an experimental* Chrome extension that enables developers and testers to identify insecure practices commonly found in client-side code. To do this, we have adopted several approaches to intercepting JavaScript calls to key and potentially dangerous browser infrastructure such as document.write or HTMLElement.innerHTML (among others). Once a JavaScript call has been intercepted, DOM Snitch records the document URL and a complete stack trace that will help assess if the intercepted call can lead to cross-site scripting, mixed content, insecure modifications to the same-origin policy for DOM access, or other client-side issues.



Here are the benefits of DOM Snitch:
  • Real-time: Developers can observe DOM modifications as they happen inside the browser without the need to step through JavaScript code with a debugger or pause the execution of their application.

  • Easy to use: With built-in security heuristics and nested views, both advanced and less experienced developers and testers can quickly spot areas of the application being tested that need more attention.

  • Easier collaboration: Enables developers to easily export and share captured DOM modifications while troubleshooting an issue with their peers.


DOM Snitch is intended for use by developers, testers, and security researchers alike. Click here to download DOM Snitch. To read the documentation, please visit this page.

*Developers and testers should be aware that DOM Snitch is currently experimental. We do not guarantee that it will work flawlessly for all web applications. More details on known issues can be found here or in the project’s issues tracker.
URL: http://googletesting.blogspot.com/2011/06/introducing-dom-snitch-our-passive-in.html

Wednesday, June 22, 2011

[Gd] Sunsetting the Custom Player

| More

YouTube API Blog: Sunsetting the Custom Player

YouTube previously offered a specialized way of embedding playlists (as well as uploads and favorites feeds) for playback on third party sites in a customizable interface—we called this the Custom Player. While the Custom Player had its fans, it never saw a great deal of usage, and we recently removed support for the creation of new Custom Players. If you’ve already created a Custom Player and have it embedded on your site it should continue to work as-is; the only thing that has changed is that new Custom Players cannot be created.

One common concern is that owners cannot update the videos featured in existing Custom Players. We recommend that you update the associated playlist to reflect the videos that you would like to feature in the Custom Player, or embed a new playlist.

While we will not allow for the creation of new custom players at this time, similar functionality is available through creating embedded playlists, which can be accessed by visiting http://youtube.com/my_playlists, clicking Share, and then using the embed code given there.

We apologize that taking away the ability to create new Custom Players caught anyone off guard. Stay tuned to this blog for upcoming announcements about modern alternatives to the Custom Player—we’ve got some exciting things in store!

Cheers,
—David Boyle, YouTube Team
URL: http://apiblog.youtube.com/2011/06/sunsetting-custom-player.html

[Gd] Beta Channel Update

| More

Google Chrome Releases: Beta Channel Update

The Beta channel has been updated to 13.0.782.32 for Windows, Mac, Linux, and Chrome Frame.

The full list of changes is available in the SVN revision log.  Interested in switching to the Beta channel?  Find out how.  If you find a new issue, please let us know by filing a bug.

Anthony Laforge
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/06/beta-channel-update_22.html

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 14.0.797.0 for Mac, Windows, Linux, and Chrome Frame platforms

All

  • Updated V8 - 3.4.4.0
Windows
  • Improved support for the textarea element with screen readers.
Mac
  • Improved support for the textarea element with VoiceOver.

Resolved Issues

  • Print workflow: Chrome Frame displays both Print Dialog and Print Preview (Issue: 86226)
  • Crash when canceling print (Issue: 86229)
  • Mouse back and forward buttons stopped working  (Issue: 84836)

More details about additional changes are available in the svn log of all revisions.

You can find out about getting on the Dev channel here: http://dev.chromium.org/getting-involved/dev-channel.

If you find new issues, please let us know by filing a bug at http://code.google.com/p/chromium/issues/entry


Karen Grunberg
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/06/dev-channel-update_20.html

Tuesday, June 21, 2011

[Gd] App Engine 1.5.1 Release

| More

Google App Engine Blog: App Engine 1.5.1 Release

It’s been about a month since Google I/O 2011, so we thought it was time for another release. This month we are releasing ProtoRPC as an official Python API, making the High Replication Datastore (HRD) available in the SDK to help developers better understand the consistency model, adding presence to the Channel API, plus a few more goodies. Check them out below:


Serving Changes


  • Geolocation Header: App Engine will now include a header with every client request that represents a best-effort attempt to identify the country from which the request originated. This header, “X-AppEngine-country,” can allow you to customize content based on the origin of the user. We hope this means no more “Select your location” drop downs for users!

Updated Java and Python APIs


  • Channel API (Presence Support): You can now configure an inbound service for your application to detect user presence for the Channel API. This lets you take an action when a user connects or disconnects from the Channel.
  • Images API (WebP Support): The Images API now supports WebP images. If you haven’t checked it out, WebP is a new image format that Google open sourced earlier this year which provides lossy compression for images and can be up to 39% smaller than JPEG images of a similar quality!

New Python APIs


  • ProtoRPC: ProtoRPC is an open source framework for creating a well defined and easy to use web-based RPC service. While ProtoRPC is similar to using Google Protocol Buffers to define services, the goal of ProtoRPC is to make it easy for developers to start defining web based services, while still allowing those services to scale and evolve over time.

Datastore


  • High Replication in the SDK: Since releasing the High Replication Datastore, we’ve wanted to provide tools that help developers understand and test the new consistency model while developing their applications. The 1.5.1 SDKs for Java and Python can now emulate the HRD consistency model. This means that now, by setting the appropriate SDK config options, queries across entity groups will occasionally return results that don’t reflect the most recent data written. This should allow you to develop your application to be more resilient to this consistency model.

As with all releases, 1.5.1 contains some additional small features and many bugfixes, the full list of which is available in our release notes for Python and Java. Hopefully you’ll find this release useful. Either way feel free let us know what you think by posting in the App Engine group.


Thanks!


The App Engine Team
URL: http://googleappengine.blogspot.com/2011/06/app-engine-151-release.html

[Gd] Getting Started with the Tasks API on Google App Engine

| More

Google App Engine Blog: Getting Started with the Tasks API on Google App Engine

This is cross-posted from the Google Apps Developer Blog


Last month, we launched the Google Tasks API, which received a very warm welcome in the developer community. Google Tasks stores tasks that users enter via Gmail, their mobile device, calendar, or iGoogle homepage. The Google Tasks API provides developers with a powerful set of API endpoints for searching, reading, and updating Google Tasks content and metadata.


To help all of you get started using the Google Tasks API, we wrote a new hands-on tutorial: Getting Started with the Tasks API on Google App Engine. In this tutorial, you will learn how to:
  • Create a simple App Engine app using the Google APIs Client Library.
  • Provide Google Tasks users a mechanism to authorize your app to access their tasks.
  • Make authorized requests to the Tasks API.


By the end of the tutorial, you’ll have an App Engine app that creates a stylized list of tasks for a specific user delivered from the Tasks API:

Check out the tutorial and ask any questions you have in the Google Tasks API forum.


Posted by Johan Euphrosine, Developers Program Engineer
URL: http://googleappengine.blogspot.com/2011/06/getting-started-with-tasks-api-on.html

Monday, June 20, 2011

[Gd] Things That Cannot Change

| More

Android Developers Blog: Things That Cannot Change

[This post is by Dianne Hackborn, whose fingerprints can be found all over the Android Application Framework — Tim Bray]

Sometimes a developer will make a change to an application that has surprising results when installed as an update to a previous version — shortcuts break, widgets disappear, or it can’t even be installed at all. There are certain parts of an application that are immutable once you publish it, and you can avoid surprises by understanding them.

Your package name and certificate

The most obvious and visible of these is the “manifest package name,” the unique name you give to your application in its AndroidManifest.xml. The name uses a Java-language-style naming convention, with Internet domain ownership helping to avoid name collisions. For example, since Google owns the domain “google.com”, the manifest package names of all of our applications should start with “com.google.” It’s important for developers to follow this convention in order to avoid conflicts with other developers.

Once you publish your application under its manifest package name, this is the unique identity of the application forever more. Switching to a different name results in an entirely new application, one that can’t be installed as an update to the existing application.

Just as important as the manifest package name is the certificate that application is signed with. The signing certificate represents the author of the application. If you change the certificate an application is signed with, it is now a different application because it comes from a different author. This different application can’t be uploaded to Market as an update to the original application, nor can it be installed onto a device as an update.

The exact behavior the user sees when installing an application that has changed in one of these two ways is different:

  • If the manifest package name has changed, the new application will be installed alongside the old application, so they both co-exist on the user’s device at the same time.

  • If the signing certificate changes, trying to install the new application on to the device will fail until the old version is uninstalled.

If you change the signing certificate of your application, you should always change its manifest package name as well to avoid failures when it’s installed. In other words, the application coming from a different author makes it a different application, and its package name should be changed appropriately to reflect that. (Of course it’s fine to use the same package name for the development builds of your app signed with your test keys, because these are not published.)

Your AndroidManifest.xml is a public API

More than just your package name that is immutable. A major function of the AndroidManifest.xml is essentially to declare a public API from your application for use by other applications and the Android system. Every component you declare in the manifest that is not private (that is whose android:exported state is true) should be treated as a public API and never changed in a way that breaks compatibility.

A subtle but important aspect of what constitutes a break in compatibility is the android:name attribute of your activity, service, and receiver components. This can be surprising because we think of android:name as pointing to the private code implementing our application, but it is also (in combination with the manifest package name) the official unique public name for that component, as represented by the ComponentName class.

Changing the component name inside of an application can have negative consequences for your users. Some examples are:

  • If the name of a main activity of your application is changed, any shortcuts the user made to it will no longer work. A shortcut is an Intent that directly specifies the ComponentName it should run.

  • If the name of a service implementing a Live Wallpaper changes, then a user who has enabled your Live Wallpaper will have their wallpaper revert to the system default when getting the new version of your app. The same is true for Input Methods, Accessibility Services, Honeycomb’s new advanced Widgets, and so on.

  • If the name of a receiver implementing a Device Admin changes, then as with the live wallpaper example, the device admin will be disabled when the application is updated. This also applies to other kinds of receivers, such as App Widgets.

These behaviors are an outcome of how the Intent system is used on Android. There are two main kinds of Intents:

  • Implicit Intents only specify “what” they should match, using actions, categories, data, MIME types, and so on. The exact components that they will find are only determined at run-time, by the Package Manager matching it against the current applications.

  • Explicit Intents specify a single explicit “who” they should match, through a ComponentName. Regardless of whatever else is in the Intent, it is only associated with the exact manifest package name and class name as given in its ComponentName.

Both of these types of Intents are important to how Android interacts with your application. A typical example of this is how users browse and select live wallpapers.

To let the user pick a live wallpaper, the first thing Android must do is show them a list of the available live wallpaper services. It does this by building an implicit Intent with the appropriate action for a live wallpaper and asking the Package Manager for all services that support this Intent. The result is then the list of live wallpapers shown to the user.

When the user actually selects a specific live wallpaper they want to use, however, Android now must build an explicit Intent that identifies that particular live wallpaper. This is what is handed to the WallpaperManager to tell it which wallpaper to show.

This is why changing the name of the component in your manifest will cause the wallpaper to disappear: the explicit Intent that was previously saved is now invalid because the ComponentName it references no longer exists. There is no information available to indicate what the new name of the component is. (For example consider if your application had two different live wallpaper services the user could select.) Instead, Android must treat that live wallpaper as uninstalled and revert to its default wallpaper.

This is how input methods, device administrators, account managers, app widgets, and even application shortcuts work. The ComponentName is the public unique name of the components you declare in your manifest, and must not change if they are visible to other applications.

In conclusion: There are some parts of your application that can not change. Please be careful.

URL: http://android-developers.blogspot.com/2011/06/things-that-cannot-change.html

[Gd] Test Is Dead

| More

Google Testing Blog: Test Is Dead



My earthly body casts no shadows
'Tis my thoughts and words that bring umbrage
that is shade to some
and darkness to others

Testivus was but a bit of child play
to appetize

At GTAC 2011
the greater truth
shall be revealed

Test is dead

And I the executioner





Alberto Savoia
VI.XVII.MMXI


The Way of Testivus

"Floating Alberto" photograph courtesy of Patrick Copeland
URL: http://googletesting.blogspot.com/2011/06/test-is-dead.html

[Gd] Introducing Non-Admin Chrome Frame

| More

Chromium Blog: Introducing Non-Admin Chrome Frame

We released Google Chrome Frame in September 2009 to expand the reach of modern web technologies and help developers take advantage of HTML5's capabilities. Since then, we've seen great adoption of the plug-in by end users and developers. Even more exciting, we’ve heard from developers that Google Chrome Frame is enabling them to create legacy-free apps that are easier to build, maintain, and optimize.

However, there was one remaining obstacle to making Chrome Frame accessible to users of older browsers - users needed to have administrative privileges on their machines to install Chrome Frame. At this year's Google I/O we announced this obstacle has finally been removed.

Non-Admin Chrome Frame runs a helper process at startup to assist with loading the Chrome Frame plug-in into Internet Explorer. The helper process is designed to consume almost no system resources while running. Once installed, non-admin users will have the same no-friction experience that admin users of Chrome Frame have today.

You can try it yourself by installing the new non-admin version of Chrome Frame here. This is now available in our developer channel and is coming to stable channel very soon.

For more technical details, please see the Chrome Frame FAQ. Please share your feedback in our discussion group and if you encounter any bugs while using Chrome Frame, please file them on Chromium's issue tracker. We’ll be working hard to bring Non-Admin Chrome Frame up to the beta and stable channels over the coming weeks. You can help us move this up to stable as quickly as possible by trying out the current release and sending us your feedback!

Posted by Robert Shield, Software Engineer
URL: http://blog.chromium.org/2011/06/introducing-non-admin-chrome-frame.html

Sunday, June 19, 2011

[Gd] Testing Chromium: AddressSanitizer, a fast memory error detector.

| More

Chromium Blog: Testing Chromium: AddressSanitizer, a fast memory error detector.

Valgrind is a great tool for detecting memory errors. We are running many Chromium tests under Valgrind and it has helped us find hundreds of significant bugs. However, when we run binaries under Valgrind, testing becomes at least 10 times slower. This huge slowdown costs us more than just machine time; our trybots and buildbots can’t provide fast feedback and some tests fail due to timeouts.

A month ago we released AddressSanitizer (aka ASan), a new testing tool. ASan consists of two parts:
  • A compiler which performs instrumentation - currently we use a modified LLVM/Clang and we're trying to contribute our code to the core LLVM package.
  • A run-time library that replaces malloc(), free()and friends.

The custom malloc() allocates more bytes than requested and “poisons” the redzones around the region returned to the caller. The custom free() “poisons” the entire region and puts it into quarantine for some time. The instrumented code produced by the compiler checks if the address being accessed is poisoned and if so, reports an error. The compiler also inserts poisoned redzones between objects on stack to catch stack buffer overrun/underrun.

ASan helps us find a subset of bugs that are detectable by Valgrind like heap buffer overrun/underrun (out-of-bounds access) and “Use after free.” It can also detect bugs that Valgrind can not find, such as stack buffer overrun/underrun. Last month alone, ASan helped us find more than 20 bugs in Chromium including some that could have potentially led to security vulnerabilities.

What makes ASan even more powerful than other comparable tools is its speed. On SPEC CPU2006 benchmarks the average slowdown is about 2x. On Chromium’s “browser_tests”, the slowdown is about 20%. If you are curious to learn why ASan is faster than comparable tools read this article.

Today ASan works only on Linux (x86 and x86_64) and ChromiumOS, but we're planning to port it to other platforms in the near future. In the coming months we also plan to setup various ASan buildbots and trybots for Chromium.

The AddressSanitizer home page has the instructions for running it with your favorite project outside of Chromium. If you are working on Chromium, refer to this page for instructions. If you have any questions or suggestions, feel free to contact address-sanitizer@googlegroups.com

Posted by Kostya Serebryany, Software Engineer
URL: http://blog.chromium.org/2011/06/testing-chromium-addresssanitizer-fast.html

[Gd] New Chromium security features, June 2011

| More

Chromium Blog: New Chromium security features, June 2011

When the Google Chrome Security Team isn’t busy giving prompt attention to finding and fixing bugs, we’re always looking for new security features to add and hardening tweaks to apply. There are some changes worth highlighting in our current and near-future Chromium versions:

Chromium 11: strong random numbers for the web
We added a new Javascript API for getting access to a good source of system entropy from a web page. The new API is window.crypto.getRandomValues. Web pages should not currently be using Math.random for anything sensitive. Instead of making a round-trip to the server to generate strong random numbers, web sites can now generate strong random numbers entirely on the client.

Chromium 12: user-specified HSTS preloads and certificate pins
Advanced users can enable stronger security for some web sites by visiting the network internals page: chrome://net-internals/#hsts


You can now force HTTPS for any domain you want, and even “pin” that domain so that only a more trusted subset of CAs are permitted to identify that domain.

It’s an exciting feature but we’d like to warn that it’s easy to break things! We recommend that only experts experiment with net internals settings.

Chromium 13: blocking HTTP auth for subresource loads
There’s an unfortunate conflict between a browser’s HTTP basic auth dialog, the location bar, and the loading of subresources (such as attacker-provided <img&gt tag references). It’s possible for a basic auth dialog to pop up for a different origin from the origin shown in the URL bar. Although the basic auth dialog identifies its origin, the user might reasonably look to the URL bar for trust guidance.

To resolve this, we’ve blocked HTTP basic auth for subresource loads where the resource origin is different to the top-level URL bar origin. We also added the command line flag switch --allow-cross-origin-auth-prompt in case anyone has legacy applications which require the old behavior.

Chromium 13: Content-Security-Policy support
We added an initial implementation of Content Security Policy, which was first introduced in Firefox 4. You can use the X-WebKit-CSP header to experiment with our implementation. We’re working with Mozilla and others through the W3C to finish the standard. Once that’s done, we’ll remove support for the X-WebKit-CSP header and add support for the final header name. Please feel encouraged to kick the tires and let us know how we can improve this feature!

Chromium 13: built-in certificate pinning and HSTS
We’re experimenting with ways to improve the security of HTTPS. One of the sites we’re collaborating with to try new security measures is Gmail.

As of Chromium 13, all connections to Gmail will be over HTTPS. This includes the initial navigation even if the user types “gmail.com” or “mail.google.com” into the URL bar without an https:// prefix, which defends against sslstrip-type attacks.

The same HSTS technology also prevents users from clicking through SSL warnings for things such as a self-signed certificate. These attacks have been seen in the wild, and users have been known to fall for such attacks. Now there’s a mechanism to prevent them from doing so on sensitive domains.

In addition in Chromium 13, only a very small subset of CAs have the authority to vouch for Gmail (and the Google Accounts login page). This can protect against recent incidents where a CA has its authority abused, and generally protects against the proliferation of signing authority.

Chromium 13: defenses for self-XSS via javascript URLs
Working together with Facebook and other browser vendors, we’re trialing a self-XSS defense that makes it harder for users to shoot themselves in the foot when they are tricked into pasting javascript: URLs into the omnibox.

This is an interesting area because it’s hard to know what detail of instruction it is possible to trick a user into following. It is also hard to measure success until a large percentage of installed browsers have the defense (thus forcing the attackers to adapt their approach).

Still hiring!
We are always looking to expand the Google Chrome Security Team, and we’re looking for a wide range of talents for both Chrome and ChromeOS. We can promise exciting and varied work, working to protect hundreds of millions of users and working alongside the best in the industry. Why not have a look at our job posting?

Posted by Chris Evans of the Google Chrome Security Team. With thanks to Adam Barth, Adam Langley, Cris Neckar and Tom Sepez for implementing the above features.
URL: http://blog.chromium.org/2011/06/new-chromium-security-features-june.html

[Gd] Prerendering in Chrome

| More

Chromium Blog: Prerendering in Chrome

Google.com's new Instant Pages feature, announced earlier today, makes some sites appear to load almost instantly when you click on them from the search results page. The feature is enabled by prerendering, a technology that we built into the upcoming version of Chrome, currently in the Dev channel. You can see Instant Pages in action in this video:



What is prerendering? Sometimes a site may be able to predict with reasonable accuracy which link the user is most likely to click on next--for example, the 'next page' link in a multi-page news article. In those cases, it would be faster and better for the user if the browser could get a head start loading the next page so that when the user clicks the page is already well on its way to being loaded. That's the fundamental idea behind prerendering. The browser fetches all of the sub-resources and does all of the work necessary to display the page. In many cases, the site simply seems to load instantly when the user clicks.

Although Google.com is the most high profile site to use prerendering, it's a technology that is available to any site. Triggering prerendering well, however, is challenging to do correctly and will only be useful to a handful of sites that have a high degree of certainty of where their users will click next. Triggering prerendering for the wrong site could lead to the link the user did click on loading more slowly.

The vast majority of sites will automatically work correctly when a third party like Google.com asks Chrome to prerender them. If you're interested in testing how your page behaves when being prerendered you can use this sample page. If you want your page to behave differently, you can use Chrome's new experimental page visibility API to detect prerendering.

The page visibility API - which is in the early stages of standardization in the webperf working group - can help developers understand the visibility status of their page: whether it's in a foreground tab, a background tab, or being prerendered. This is still an experimental implementation and it may change or even be removed in the future, which is why for the time being we've prefixed the property names with "webkit.” Although the page visibility API is useful for detecting prerendering, it also has many other applications--for example, allowing a site to pause expensive physics calculations when the page isn't visible.

To learn more about the page visibility API and prerendering, check out the Using the Page Visibility API and Web Developers' Guide to Prerendering in Chrome articles.

Posted by Alex Komoroske
URL: http://blog.chromium.org/2011/06/prerendering-in-chrome.html