Google Code: News

Debugging KML Balloon Content in Google Earth

2012-02-09T09:00:00.000-08:00

KML Balloons in Google Earth - starting with version 5.0 - support HTML, CSS, and almost full JavaScript. This can be a great tool for developers looking to add rich content and interactivity into their KML files.

However, it’s not always obvious how to debug that KML content. Google Earth doesn’t have a full set of tools like Chrome Developer Tools. However, it does allow you to view console output, so console.log() output, as well as errors that would normally appear in the Chrome console or Firebug will appear in the console instead. Note, Google Earth does not allow the presentation of system dialogs (namely the functions alert, confirm, and prompt).

Here’s some quick tips on how to get it to work:

Linux: Launch Google Earth from the terminal window. Console output will then appear in the terminal window.
Mac OS X: You can launch it directly from the command line, “/Applications/Google Earth.app/Contents/MacOS/Google Earth” and read the console output in the command line.
Windows: Install DebugView, which is from Microsoft, and look for system messages in the output.

Here's a screenshot from Mac OS X:

Balloon content is rendered by WebKit, and Google Earth currently supports the equivalent of Safari 4.0.4 (which is WebKit-based). If you want to know if a particular JavaScript or CSS feature is supported, one option is to search for it on http://caniuse.com/.

Posted by Mano Marks, Maps API Developer Relations Team

Share With Intents

2012-02-09T07:20:00.000-08:00

[This post is by Alexander Lucas, an Android Developer Advocate bent on saving the world 5 minutes.�—Tim Bray]

[Please join the discussion on Google+.]

Intents are awesome. They are my favorite feature of Android development. They make all sorts of stuff easier. Want to scan a barcode? In the olden platforms, if you were lucky, this involved time and effort finding and comparing barcode-scanning libraries that handled as much as possible of camera interaction, image processing, an internal database of barcode formats, and UI cues to the user of what was going on. If you weren’t lucky, it was a few months of research & haphazard coding to figure out how to do that yourself.

On Android, it’s a declaration to the system that you would like to scan a barcode.

public void scanSomething() {
    // I need things done!  Do I have any volunteers?
    Intent intent = new Intent("com.google.zxing.client.android.SCAN");

    // This flag clears the called app from the activity stack, so users arrive in the expected
    // place next time this application is restarted.
    intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET);

    intent.putExtra("SCAN_MODE", "QR_CODE_MODE");
    startActivityForResult(intent, 0);
}
...
public void onActivityResult(int requestCode, int resultCode, Intent intent) {
    if (requestCode == 0) {
        if (resultCode == RESULT_OK) {
            //  The Intents Fairy has delivered us some data!
            String contents = intent.getStringExtra("SCAN_RESULT");
            String format = intent.getStringExtra("SCAN_RESULT_FORMAT");
            // Handle successful scan
        } else if (resultCode == RESULT_CANCELED) {
            // Handle cancel
        }
    }
}

See that? That’s nothing. That’s 5 minutes of coding, 3 of which were just to look up the name of the result you wanted to pull. And that was made possible because the Barcode Scanner application is designed to be able to scan barcodes for whatever other applications may need it.

More important, our app is completely decoupled from the BarcodeScanner app. There’s no integration- in fact, neither application is checking to verify that the other exists. If the user preferred, they could remove “Barcode Scanner” and replace it with a competing app. As long as that app supported the same intent, functionality would remain the same. This decoupling is important. It’s the easy way. It’s the lazy way. It’s the Android way.

Sharing Data Using Intents

One of the most inherently useful Android intents is the Share intent. You can let the user share data to any service they want, without writing the sharing code yourself, simply by creating a share intent.

Intent intent=new Intent(android.content.Intent.ACTION_SEND);
intent.setType("text/plain");
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET);

// Add data to the intent, the receiving app will decide what to do with it.
intent.putExtra(Intent.EXTRA_SUBJECT, “Some Subject Line”);
intent.putExtra(Intent.EXTRA_TEXT, “Body of the message, woot!”);

... and starting it with a chooser:

startActivity(Intent.createChooser(intent, “How do you want to share?”));

With these 5 lines of code, you get to bypass authenticating, credential storage/management, web API interaction via http posts, all sorts of things. Where by “bypass”, I mean “have something else take care of.” Like the barcode scanning intent, all you really had to do was declare that you have something you’d like to share, and let the user choose from a list of takers. You’re not limited to sending text, either. Here’s how you’d create an intent to share an image:

private Intent createShareIntent() {
    ...
    Intent shareIntent = new Intent(Intent.ACTION_SEND);
    shareIntent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET);
    shareIntent.setType("image/*");

    // For a file in shared storage.  For data in private storage, use a ContentProvider.
    Uri uri = Uri.fromFile(getFileStreamPath(pathToImage));
    shareIntent.putExtra(Intent.EXTRA_STREAM, uri);
    return shareIntent;
}

Note that just by using setType() to set a MIME type, you’ve filtered down the list of apps to those that will know what to do with an image file.

Intents over Integration

Think about this for a second. By making the simple assumption that any user of any service (Task Manager, Social Network, Photo sharing site) already has some app on their phone that can share to that service, you can leverage the code that they’ve already written. This has several awesome implications:

Less UI�—�You don’t have to clog up your UI with customized, clickable badges of services you support. Just add a “share” button. It’s okay, we’ve made sure all your users know what it does [insert smiley here].
Leveraged UI�—�You can bet that every high-quality web service out there has spent serious time on the UI of their Android app’s “share” activity. Don’t reinvent the wheel! Just grab a couple and go for a ride.
Filtered for the user�—�If I don’t have a Foo-posting app on my phone, there’s a good chance I don’t care about posting to Foo. Now I won’t see Foo icons everywhere that are useless to me.
Client App Ecosystem�—�Much like an email client, anyone can write a client for any service. Users will use the ones they want, uninstall the ones they don’t. Your app supports them all.
Forward Compatible with new services�—�If some swanky new service springs up out of nowhere with an Android Application, as long as that application knows how to receive the share intent, you already support it. You don’t spend time in meetings discussing whether or not to wedge support for the new service into your impending Next Release(tm), you don’t burn engineering resources on implementing support as fast as possible, you don’t even upload a new version of anything to Android Market. Above all, you don’t do any of that again next week, when another new service launches and the whole process threatens to repeat itself. You just hang back and let your users download an application that makes yours even more useful.

Avoid One-Off Integrations

For each pro of the Intent approach, integrating support to post to these services one-at-a-time has a corresponding con.

Bad for UI�—�If your photo-sharing app has a Foo icon, what you might not immediately understand is that while you’re trying to tell the user “We post to Foo!” what you’re really saying is “We don’t post to Bar, Baz, or let you send the photo over email, sms, or bluetooth. If we did, there would be icons. In fact, we probably axed those features because of the space the icons would take on our home screen. Oh, and we’ll probably use some weird custom UI and make you authenticate through a browser, instead of the Foo client you already have installed.” I’m not going to name names, but a lot of you are guilty of this. It’s time to stop. (I mean it. Stop.)
Potentially wasted effort�—�Let’s say you chose one service, and integrated it into your UI perfectly. Through weeks of back-and-forth with Foo’s staff, you’ve got the API and authentication mechanisms down pat, the flow is seamless, everything’s great. Only problem is that you just wasted all that effort, because none of your user-base particularly cares for Foo. Ouch!
Not forward compatible for existing services�—�Any breaking changes in the API are your responsibility to fix, quickly, and that fix won’t be active until your users download a newer version of your app.
Won’t detect new services�—�This one really hurts. If a brand new service Baz comes out, and you’ve actually got the engineering cycles to burn, you need to get the SDK, work out the bugs, develop a sharing UI, have an artist draw up your own “edgy” (ugh) but legally distinct version of the app’s logo so you can plaster it on your home screen, work out all the bugs, and launch.

You will be judged harshly by your users. And deservedly so.

Ice Cream Sandwich makes it even easier

With the release of ICS, a useful tool for sharing called ShareActionProvider was added to the framework, making the sharing of data across Android applications even easier. ShareActionProviders let you populate lists of custom views representing ACTION_SEND targets, facilitating (for instance) adding a “share” menu to the ActionBar, and connecting it to whatever data the user might want to send.

Doing so is pretty easy. Configure the menu items in your Activity’s onCreateOptionsMenu method, like so:

@Override
public boolean onCreateOptionsMenu(Menu menu) {
    // Get the menu item.
    MenuItem menuItem = menu.findItem(R.id.menu_share);
    // Get the provider and hold onto it to set/change the share intent.
    mShareActionProvider = (ShareActionProvider) menuItem.getActionProvider();

    // Attach an intent to this ShareActionProvider.  You can update this at any time,
    // like when the user selects a new piece of data they might like to share.
    mShareActionProvider.setShareIntent(yourCreateShareIntentMethod());

    // This line chooses a custom shared history xml file. Omit the line if using
    // the default share history file is desired.
    mShareActionProvider.setShareHistoryFileName("custom_share_history.xml");
      . . .
}

Note that you can specify a history file, which will adapt the ordering of share targets based on past user choices. One shared history file can be used throughout an application, or different history files can be used within the same application, if you want to use a separate history based on what kind of data the user wants to share. In the above example, a custom history file is used. If you wish to use the default history for the application, you can omit that line entirely.

This will help optimize for an important feature of the ShareActionProvider: The user’s most common ways to share float to the top of the drop-down, with the least used ones disappearing below the fold of the “See More” button. The most commonly selected app will even become a shortcut right next to the dropdown, for easy one-click access!

You’ll also need to define a custom menu item in XML. Here’s an example from the ActionBar Dev Guide.

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:id="@+id/menu_share"
          android:title="@string/share"
          android:showAsAction="ifRoom"
          android:actionProviderClass="android.widget.ShareActionProvider" />
</menu>

And with that, you can have an easy sharing dropdown that will look like the screenshot here. Note that you get the nice standard three-dots-two-lines “Share” glyph for free.

Remember: Smart and Easy

The share intent is the preferred method of sharing throughout the Android ecosystem. It’s how you share images from Gallery, links from the browser, and apps from Android Market. Intents are the easiest path to writing flexible applications that can participate in a rapidly expanding ecosystem, but they’re also the smart path to writing applications that will stay relevant to your users, letting them share their data to any service they want, no matter how often their preferences change over time. So take a step back and stop worrying about if your user wants to tweet, digg, post, email, im, mms, bluetooth, NFC, foo, bar or baz something. Just remember that they want to share it. Android can take it from there.

Google Code-in 2011 Stats to Ponder

2012-02-08T12:00:00.000-08:00

For Google Code-in 2011 we had 542 pre-university students (ages 13-17) from 56 countries complete an astounding 3,054 tasks for 18 open source organizations during the eight week contest period. 59.8% of the students completed 3 or more tasks in the contest.

The graph below illustrates the 10 countries with the highest number of students participating in Google Code-in 2011.

The five schools with the largest number of students participating in Google Code-in 2011 are listed below:
- Technical School Electronic Systems associated with Technical University - Sofia in Bulgaria had an impressive 49 students participating.
- XIV Liceum Og�lnokształcące im. Stanisława Staszica w Warszawie in Poland
- Roman-Vodă National College in Romania
- Ankara Polis Koleji in Turkey
- "Tiberiu Popoviciu" I.T. High School from Cluj-Napoca in Romania

We had 307 dedicated mentors and organization administrators from 51 countries helping the students throughout the contest. Mentors hailed from all corners of the globe from places such as New Zealand, Uzbekistan, Peru, Bangladesh, Germany, South Africa and all parts in between.

Thank you to all of the students, mentors and organization administrators who helped make Google Code-in 2011 a success.

Stay tuned to this blog as we will announce the 10 grand prize winners for Google Code-in 2011 on February 14.

If you are a university student at least 18 years of age and would like to work on open source projects this summer (or winter for our southern hemisphere friends) then please look into our Google Summer of Code 2012 program that we recently announced.

By Stephanie Taylor, Open Source Programs

Charts, Gmail, Maps and Properties Services Graduating from Experimental

2012-02-08T11:59:00.000-08:00

The Google Apps Script team strives to achieve a very high level of responsiveness to our community. We iterate fast to deliver new features and functionality. Releasing new Apps Script services under the “Experimental” flag allows us to gather valuable feedback from you. Real world exposure to these new experimental Apps Script services makes it easy for us to prioritize features, improve API design and documentation, and identify bugs and use cases. On top of that, experimental releases give us a way to support our more advanced users, who are perfectly happy to live on the cutting edge and get their hands on cool new Apps Script services as early as possible.

We put thorough consideration into the use of the Experimental flag. Not every new Apps Script service that we launch is experimental. In October, we launched the Lock and Cache service as non-experimental. We believed that these two services were fundamentally mature, and thus able to be launched as non-experimental.

Today, we are graduating four services from experimental status:

You can expect us to continue on this path of careful deliberation in deciding when to use the experimental flag. We will continue to evaluate the design, documentation, and overall strengths of each experimental API and continue to work hard to graduate them to fully supported APIs. We welcome your feedback in helping us make Apps Script better. You can post your feature requests on our tracker and ask any question in our forum. If you are curious on how to use the above mentioned APIs then check out the tutorials for the Charts and Gmail Services, the Maps Service and excellent example of using Properties Service.

The Apps Script team is standing by to help you!

Saurabh Gupta profile | twitter | blog

Saurabh is a Developer Programs Engineer at Google. He works closely with Google Apps Script developers to help them extend Google Apps. Over the last 10 years, he has worked in the financial services industry in different roles. His current mission is to bring automation and collaboration to Google Apps users.

The BugSense hybrid app: experiences using Clojure on Google App Engine

2012-02-07T14:21:00.000-08:00

Today’s post comes to us from Jon Vlachogiannis and Panos Papadopoulos, founders of BugSense, a mobile error analytics service. We hope you find their insights on using Clojure on Google App Engine informative.

BugSense is a cross-platform error analytics infrastructures for mobile devices. BugSense uses Google App Engine to power its backend, processing more than 1.6 million daily errors, generated by more than 45 million devices around the world. Chances are one of the applications installed on your smart phone (like SoundCloud or Trulia) is already using BugSense.

The Problem
Lots of our clients want to optimize and protect their mobile apps (through code obfuscation) using ProGuard. ProGuard creates more compact code, resulting in faster transfer across networks, faster loading, and smaller memory footprints. On top of that it makes programs and libraries harder to reverse-engineer.

However, because the Android Market doesn't automatically de-obfuscate of stack traces from ProGuard-ed apps, developers who want to analyse errors from their apps must get the stack trace from the Market, format it and use ProGuard locally. The whole process for just a single error could take more than 3 minutes, so we decided to add support for ProGuard to BugSense to make debugging easier and faster.

The Solution: Clojure and Python
The main data-serving portion of our app is written in Python, our language of choice, but ProGuard is an open source project in Java. For easier development, we ported parts of ProGuard to Clojure, a dynamic language belonging to the Lisp family that runs on the JVM. This allows us to “beat the averages” by exploiting all the great features that a LISP language offers (such as macros and exploratory programming). Using Clojure and having access to a vast number of Java libraries assisted us in tackling the difficult problem of de-obfuscation, with great results.

Once we were done, we deployed using AppEngineMagic and now it's trivial (one click) for our users to de-obfuscate their stacktraces. Now we have the best of two worlds: Python for serving data and Java/Clojure for doing calculations, all in the same Google App Engine application. And it scales automatically and runs even faster than running ProGuard on your laptop!

Practically, that means that we can have a heterogeneous app on Google App Engine so that we can keep programming in our favourite language, Python, but still harness the tremendous wealth of Java libraries using Clojure. Running a hybrid app on App Engine is trivial since they share the same resources task queues, Datastore, and memcache.

However, because our app is implemented in multiple languages, we need to start two different local instances (one for Python and one for Clojure). We use a combination of mocks for both of the instances in order to emulate the hybrid app and their interaction in a local environment for development and testing.

Google App Engine, a success factor
We started as a two-developer startup and our product rapidly became popular across the world. Building on Google App Engine helped us focus on product development and forget about infrastructure and administration, thus enabling us to focus more on our customers' needs. (And sleep tight at night.) Furthermore it helped us to keep costs low and iterate quickly.

To learn more about BugSense, check out our website. If you have comments or questions about this post or just want to reach out directly, you can find us at +jonromero or +bugsense.

isocket and Shiny Ads deliver new innovations using the DFP API

2012-02-07T10:00:00.000-08:00

Editor’s note: We’d like to share with you this post from John Park about the growing DFP API ecosystem and a few success stories from our partner directory. -- Adam Rogal, Ads Developer Relations Team

With thousands of publishers using the DFP and DFP Small Business ad serving platforms, we know first-hand that no two publishers are identical. Publishers may use in-house billing systems, have unique approval workflows, or use third-party tools to handle their ad operations.

To give publishers the flexibility to easily integrate their unique processes and systems with their ad server, DFP offers publishers an open API to easily create tools that complement their ad operations.

We’ve seen hundreds of developers build new ad serving innovations using the API, including applications to manage inventory, create orders, pull reports, and more. The API has created a new ecosystem of partner innovations, giving publishers access to new ad serving tools and applications. Two such applications come from isocket and Shiny Ads who have used the DFP API to build applications that help publishers manage and sell their ad space.

isocket uses the API to create tools that streamlines sales

Seeing the need to streamline the manual steps involved with buying and selling inventory, isocket engineered a direct and self-service ad sales tool to simplify sales workflows. By leveraging the DFP API, isocket was able to build an application to automate sales processes and save money. “We were interested in using the API because it allowed us to eliminate the hassle of manually coordinating campaigns, while still keeping the important parts like publisher control and approval. Integrating with the DFP API has allowed us to make things a lot simpler for publishers,” said Ben Trenda, VP of Sales at isocket.

Read more about how isocket integrated with the DFP API.

Shiny Ads builds application to help publishers save time

To help facilitate publishers’ direct ad campaign management, Shiny Ads began using
the DFP API to integrate its self-serve advertising platform with DFP in order to help publishers streamline their sales processes. This integration has helped save publishers time since they no longer need to manually book sales orders. “Our solution needs to support DFP - our customers demand it” said CEO and founder Roy Pereira. “The API made integrating with DFP easy for us, and most importantly, easy for our clients. Without the DFP API, Shiny Ads would not have the fully functional solution we have today.”

Read more about how Shiny Ads integrated with the DFP API.

Over the coming months, we’ll share more stories on how our partners are using the DFP API to deliver exciting ad serving innovations. For a complete list of partners who have built applications using the DFP API, please visit our partner directory.

Posted by John Park, Partner Programs Manager, and Adam Rogal, Developer Relations

Announcing v201201 of the DFP API

2012-02-06T15:00:00.000-08:00

The newest version of the API, v201201, brings some frequently requested features including using date time strings in PQL statements, filtering objects based on last modified date and times, including a PQL statement to limit a report (such as just running a report for one order), and more. A full list of features can be found on our release notes page.

Filtering

In v201201, we’ve focused on improving filtering with PQL statements across the entire API. We’ve introduced a better way to do date time filtering, a new lastModifiedDateTime field to search on, and the ability to filter from within a report.

With the ability to filter by date and time fields directly in the PQL statement, you’ll now be able to limit the objects on the server, rather than fetch all line items and checking their startDateTime property one at a time. For example, if you want to retrieve all line items that started so far in January, include

startDateTime

as a predicate of your filter with a date and time string, e.g.

WHERE startDateTime >= ‘2012-01-01T00:00:00’

. Note here that the date and time are in ISO 8061 format, i.e.

YYYY-MM-DDThh:mm:ss

, and the time zone is assumed to be that of the network’s. You can also bind a DateTime object instead of using a string, i.e.

WHERE startDateTime > :dateTime

, where

:dateTime

is bound to a DateTimeValue.

We’ve also added the new lastModifiedDateTime field to companies, creatives, ad units, line item creative associations, line items, orders, and placements. Using this field, you can now query for objects that have changed recently. Combined with the new date and time filtering feature mentioned above, you will be able to pull all objects changed so far this year, e.g.

WHERE lastModifiedDateTime >= ‘2012-01-01T00:00:00’

. If you are a developing an application that has to keep in sync with changes made through the UI, only pulling down objects that have changed since your last fetch time will speed up your calls and decrease processing time.

Finally, one of the largest requests from our developers was to limit what data is returned from within a report. We’ve add the ability to define a PQL statement in a report definition to do just that. Now when you create a report, you’ll be able to supply statements to limit it to just one order, e.g.

WHERE orderId = :orderId

, or with only one salesperson as well, e.g.

WHERE orderId = :orderId AND salespersonId = :salespersonId

.

Creatives

In v201102, we’ve added three new creative types that are only available to small business networks:

FlashExpandableCreative - an expandable creative where the collapsed size is a Flash SWF file and the expanded size is another Flash SWF file.
FlashPushdownCreative - a creative that pushes page content down when the creative expands.
TextAdCreative - a text-based creative.

Teams

We’ve introduced a new service with this version, TeamService, which lets you group users into teams. Although currently not editable via the API, teams will be used to limit access to entities such as companies, inventory, and orders.

Coming soon

Over the next few weeks, you’ll learn about all of the features a bit more in the Discover v201201 series starting first with a discussion of filtering and syncing best practices. Let us know if you want to see anything else on our forum.

- Adam Rogal, DFP API Team

Google+ Developers Page

2012-02-06T10:03:00.000-08:00

Today we’re launching the Google+ Developers page to help you stay connected to all the latest Google+ platform news, events, community, and more. As the lead of the Google+Developer Relations team, I’m really looking forward to meeting you there -- add the page to your circles to join the conversation, comment on posts, and join our hangouts.

Our team will host regular hangouts to talk about the +Platform, your experiences with it, and share tips and tricks with the community. Our weekly office hours hangouts take place every Wednesday at 11:30am - 12:15pm PDT, and can be accessed from our Google+ Developers page. The +Platform team will also share Google+ developer events, conferences and hackathons, as well as photos and videos of the events. In addition, we’ll announce and discuss our +Platform launches on our page.

2012 is going to be a very exciting year for the Google+ Platform -- I look forward to seeing you on our new Google+ Developers page!

Posted by Chris Chabot, Google+ Developer Relations Team Lead

Google+ Developers Page

2012-02-06T10:03:00.000-08:00

Google Summer of Code 2012 is on!

2012-02-04T12:08:00.000-08:00

By Carol Smith, Open Source Team

Cross-posted with the Google Open Source Blog

Today at FOSDEM I was proud to announce Google Summer of Code 2012.

This will be the 8th year for Google Summer of Code, an innovative program dedicated to introducing students from colleges and universities around the world to open source software development. The program offers student developers stipends to write code for various open source projects with the help of mentoring organizations from all around the globe. Over the past seven years Google Summer of Code has had 6,000 students from over 90 countries complete the program. Our goal is to help these students pursue academic challenges over the summer break while they create and release open source code for the benefit of all.

Spread the word to your friends! If you know of a university student that would be interested in working on open source projects this summer, or if you know of an organization that might want to mentor students to work on their open source projects, please direct them to our Google Summer of Code 2012 website where they can find our timeline along with the FAQs. And stay tuned for more details coming soon!

Posted by Scott Knaster, Editor