Topic Browser

We’ve just launched Tripline (http://www.tripline.net), and we’re excited to talk about how we’re using Google Maps. We’ve been laboring for months in solitude, so it feels great to finally talk about what we’ve built.

Tripline is all about maps. The Tripline concept goes back to 2005 when I started manually creating map-based plans to visualize upcoming trips. I’m one of those people who can stare at the moving map on an airplane for the duration of a long flight, so my desire to understand travel from a geographical viewpoint is inherent, and I think quite common. And, as we so often see in movies, a moving line on a map is a great way to tell a story.

The Tripline Player uses the Google Maps API for Flash and animates progression from point to point using a simplified KML-like data structure. We chose Flash primarily because it was the best platform to combine the maps, animation, and soundtrack elements that were part of the design. It also means that trips are shareable, as you can see from the example embedded above. We chose the terrain view because we think it best conveys the feeling of an adventurous journey. One of my favorite things to do is to press play, enter full screen mode and just sit back and watch a story unfold. The Google Maps API for Flash helps make that experience smooth and beautiful. It’s essential to our product.

The player represents the end-product of a created trip, but what about the creation process itself? Our goal was to make trip-creation as simple and flexible as typing a bullet list, and we spent a lot of time working towards that goal. We’re using many different Maps API components in our trip editor, including geodesic polylines, custom markers and custom infowindows. To add places, we’re using the Google AJAX Search API and the Geocoder API, and for trip thumbnails, we’re using the Google Static Maps API.

Speed and reliability are also essential. Users will forgive a lack of features and even bad design, but if your application is slow, you’re dead. The Google Maps APIs are always on and always fast, which is something that very few services can guarantee. That's one of the key reasons why we use Google services to support the core capabilities of our product. We’ve been live now for just under a month, and it’s been smooth sailing. We’re also hard at work on our next release, so stay tuned for more. Thanks Google.

Posted by Byron Dumbrill, Founder & CEO, Tripline

This is a guest post by Owen Barton, partner and director of engineering at CivicActions. Owen has been working with Google's “Make the Web Faster” project team and the Drupal community to make improvements in Drupal 7 front-end performance. This is a condensed version of a more in-depth post over at the CivicActions blog.

Drupal is a popular free and open source publishing platform, powering high profile sites such as The White House, The New York Observer and Amnesty International. The Drupal community has long understood the importance of good front-end performance to successful web sites, being ahead of the game in many ways. This post highlights some of the improvements developed for the upcoming Drupal 7 release, several of which can save an additional second or more of page load times.

Drupal 7 has made its caching system more easily pluggable - to allow for easier memcache integration, for example. It has also enabled caching HTTP headers to be set so that logged out users can cache entire pages locally as well as improve compatibility with reverse proxies and content distribution networks (CDNs). There is also a patch waiting which reduces both the response size and the time taken to generate 404 responses for inlined page assets. Depending on the type of 404 (CSS have a larger effect than images, for example) the slower 404s were adding 0.5 to 1 second to the calling page load times.

Drupal currently has the ability to aggregate multiple CSS and JavaScript files by concatenating them into a smaller number of files to reduce the number of HTTP requests. There is a patch in the queue for Drupal 7 that could allow aggregation to be enabled by default, which is great because the large number of individual files can add anything from 0-1.5 seconds to page loads.

One issue that has become apparent with the Drupal 6 aggregation system is that users can end up downloading aggregate files that include a large amount of duplicate code. On one page the aggregate may contain files a, b and c, whilst on a second page the aggregate may contain files a, b and d - the “c” and “d” files being added conditionally on specific pages. This breaks the benefits of browser caching and slows down subsequent page loads. Benchmarking on core alone shows that avoiding duplicate aggregates can save over a second across 5 page loads. A patch has already been committed that means files need to be explicitly added to the aggregate, and fix Drupal core to add appropriate files to the aggregate unconditionally.

Drupal has supported gzip compression of HTML output for a long time, however for CSS and JavaScript, the files are delivered directly by the webserver, so Drupal has less control. There are webserver based compressors such as Apache’s mod_deflate, but these are not always available. A patch is in the queue that stores compressed versions of aggregated files on write and uses rewrite and header directives in .htaccess that allow these files to be served correctly. Benchmarks show that this patch can make initial page views 20-60% faster, saving anything from 0.3 to 3 seconds total.

The Drupal 7 release promises some real improvements from a front-end performance point of view. Other performance optimizations will no doubt continue to appear and be refined in contributed modules and themes, as well as in site building best practices and documentation. In Drupal 8 we will hopefully see further improvements in the CSS/JS file aggregation system, increased high-level caching effectiveness and hopefully more tools to help site builders reduce file sizes. If you have yet to try Drupal, download it now and give it a try and tell us in the comments if your site performance improves!

...Over 150 people attended the day long event that included 12 sessions related to Eclipse and Google technology. The presentations are now available online. There was lots of great information presented, like upcoming improvements to the Android SDK (based on Eclipse), Git support in Eclipse, a review of the Instantiations tools that Google just purchased and an introduction to the new Tools for Mobile Web project.

• Android - With the continued momentum and growth of the platform, we would like to continue the conversation with you at Developer Day. We will feature sessions on Android performance, mobile user experience and best practices on building apps, and we will also deep dive on a new feature, Cloud to Device Messaging (C2DM).


• Chrome & HTML5 - We will discuss how to build an app for the Chrome Web Store and how to improve its development and performance. We’ll show which aspects of HTML5, Chrome Developer Tools and Native Client can be most useful to you. Finally, we will cover everything auth-related to show you when and where to use various authentication tools and how they integrate with our APIs and products.


• Cloud Platform - Building off of our series of announcements at Google I/O, we will feature sessions on App Engine, App Engine for Business, Spring integration, Google Web Toolkit, Google Storage for Developers, BigQuery and Prediction API. Be prepared for code samples, how to optimize performance and a glimpse into what else is on our roadmap.

• Sao Paulo, Brazil - Mario Queiroz, VP Product Management


• Munich, Germany - Dr. Wieland Holfelder, Engineering Director


• Moscow, Russia - Gene Sokolov, Head of Moscow Engineering

[This post is by Dan Morrill, Open Source & Compatibility Program Manager. — Tim Bray]

Way back in November 2007 when Google announced Android, Andy Rubin said “We hope thousands of different phones will be powered by Android.” But now, Android’s growing beyond phones to new kinds of devices. (For instance, you might have read about the new 7” Galaxy Tab that our partners at Samsung just announced.) So, I wanted to point out a few interesting new gadgets that are coming soon running the latest versions of Android, 2.1 and 2.2.

For starters, the first Android-based non-phone handheld devices will be shipping over the next few months. Some people call these Mobile Internet Devices or Personal Media Players — MIDs or PMPs. Except for the phone part, PMP/MID devices look and work just like smartphones, but if your app really does require phone hardware to work correctly, you can follow some simple steps to make sure your app only appears on phones.

Next up are tablets. Besides the Samsung Galaxy Tab I mentioned, the Dell Streak is now on sale, which has a 5” screen and blurs the line between a phone and a tablet. Of course, Android has supported screens of any size since version 1.6, but these are the first large-screen devices to actually ship with Android Market. A tablet’s biggest quirk, of course, is its larger screen.

It’s pretty rare that we see problems with existing apps running on large-screen devices, but at the same time many apps would benefit from making better use of the additional screen space. For instance, an email app might be improved by changing its UI from a list-oriented layout to a two-pane view. Fortunately, Android and the SDK make it easy to support multiple screen sizes in your app, so you can read up on our documentation and make sure your app makes the best use of the extra space on large screens.

Speaking of screen quirks, we’re also seeing the first devices whose natural screen orientation is landscape. For instance, Motorola’s CHARM and FLIPOUT phones have screens which are wider than they are tall, when used in the natural orientation. The majority of apps won’t even notice the difference, but if your app uses sensors like accelerometer or compass, you might need to double-check your code.

Now, the devices I’ve mentioned so far still have the same hardware that Android phones have, like compass and accelerometer sensors, cameras, and so on. However, there are also devices coming that will omit some of this hardware. For instance, you’ve probably heard of Google TV, which will get Android Market in 2011. Since Google TV is, you know, a stationary object, it won’t have a compass and accelerometer. It also won’t have a standard camera, since we decided there wasn’t a big audience for pictures of the dust bunnies behind your TV.

Fortunately, you can use our built-in tools to handle these cases and control which devices your app appears to in Android Market. Android lets you provide versions of your UI optimized for various screen configurations, and each device will pick the one that runs best. Meanwhile, Android Market will make sure your apps only appear to devices that can run them, by matching those features you list as required (via tags) only with devices that have those features.

Android started on phones, but we’re growing to fit new kinds of devices. Now your Android app can run on almost anything, and the potential size of your audience is growing fast. But to fully unlock this additional reach, you should double-check your app and tweak it if you need to, so that it puts its best foot forward. Watch this blog over the next few weeks, as we post a series of detailed “tips and tricks” articles on how to get the most out of the new gadgets.

It’s official folks: we’re living in the future! Happy coding.

[This post is by Trevor Johns, who's a Developer Programs Engineer working on Android. — Tim Bray]

The Android Market licensing service is a powerful tool for protecting your applications against unauthorized use. The License Verification Library (LVL) is a key component. A determined attacker who’s willing to disassemble and reassemble code can eventually hack around the service; but application developers can make the hackers’ task immensely more difficult, to the point where it may simply not be worth their time.

Out of the box, the LVL protects against casual piracy; users who try to copy APKs directly from one device to another without purchasing the application. Here are some techniques to make things hard, even for technically skilled attackers who attempt to decompile your application and remove or disable LVL-related code.

• You can obfuscate your application to make it difficult to reverse-engineer.

• You can modify the licensing library itself to make it difficult to apply common cracking techniques.

• You can make your application tamper-resistant.

• You can offload license validation to a trusted server.

This can and should be done differently by each app developer. A guiding principle in the design of the licensing service is that attackers must be forced to crack each application individually, and unfortunately no client-side code can be made 100% secure. As a result, we depend on developers introducing additional complexity and heterogeneity into the license check code — something which requires human ingenuity and and a detailed knowledge of the application the license library is being integrated into.

Technique: Code Obfuscation

The first line of defense in your application should be code obfuscation. Code obfuscation will not protect against automated attacks, and it doesn’t alter the flow of your program. However, it does make it more difficult for attackers to write the initial attack for an application, by removing symbols that would quickly reveal the original structure of a compiled application. As such, we strongly recommend using code obfuscation in all LVL installations.

To understand what an obfuscator does, consider the build process for your application: Your application is compiled and converted into .dex files and packaged in an APK for distribution on devices. The bytecode contains references to the original code — packages, classes, methods, and fields all retain their original (human readable) names in the compiled code. Attackers use this information to help reverse-engineer your program, and ultimately disable the license check.

Obfuscators replace these names with short, machine generated alternatives. Rather than seeing a call to dontAllow(), an attacker would see a call to a(). This makes it more difficult to intuit the purpose of these functions without access to the original source code.

There are a number of commercial and open-source obfuscators available for Java that will work with Android. We have had good experience with ProGuard, but we encourage you to explore a range of obfuscators to find the solution that works best for you.

We will be publishing a separate article soon that provides detailed advice on working with ProGuard. Until then, please refer to the ProGuard documentation.

Technique: Modifying the license library

The second line of defense against attack from crackers is to modify the license verification library in such a way that it’s difficult for an attacker to modify the disassembled code and get a positive license check as result.

This actually provides protection against two different types of attack: it protects against attackers trying to crack your application, but it also prevents attacks designed to target other applications (or even the stock LVL distribution itself) from being easily ported over to your application. The goal should be to both increase the complexity of your application’s bytecode and make your application’s LVL implementation unique.

When modifying the license library, there are three areas that you will want to focus on:

• The core licensing library logic.

• The entry/exit points of the licensing library.

• How your application invokes the licensing library and handles the license response.

In the case of the core licensing library, you’ll primarily want to focus on two classes which comprise the core of the LVL logic: LicenseChecker and LicenseValidator.

Quite simply, your goal is to modify these two classes as much as possible, in any way possible, while still retaining the original function of the application. Here are some ideas to get you started, but you’re encouraged to be creative:

• Replace switch statements with if statements.

• Use XOR or hash functions to derive new values for any constants used and check for those instead.

• Remove unused code. For instance, if you’re sure you won’t need swappable policies, remove the Policy interface and implement the policy verification inline with the rest of LicenseValidator.

• Move the entirety of the LVL into your own application’s package.

• Spawn additional threads to handle different parts of license validation.

• Replace functions with inline code where possible.

For example, consider the following function from LicenseValidator:

public void verify(PublicKey publicKey, int responseCode, String signedData, String signature) {
    // ... Response validation code omitted for brevity ...
    switch (responseCode) {
        // In Java bytecode, LICENSED will be converted to the constant 0x0
        case LICENSED:
        case LICENSED_OLD_KEY:
            LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
            handleResponse(limiterResponse, data);
            break;
        // NOT_LICENSED will be converted to the constant 0x1
        case NOT_LICENSED:
            handleResponse(LicenseResponse.NOT_LICENSED, data);
            break;
        // ... Extra response codes also removed for brevity ...
    }

In this example, an attacker might try to swap the code belonging to the LICENSED and NOT_LICENSED cases, so that an unlicensed user will be treated as licensed. The integer values for LICENSED (0x0) and NOT_LICENSED (0x1) will be known to an attacker by studying the LVL source, so even obfuscation makes it very easy to locate where this check is performed in your application’s bytecode.

To make this more difficult, consider the following modification:

public void verify(PublicKey publicKey, int responseCode, String signedData, String signature) {
       // ... Response validation code omitted for brevity …
        
        // Compute a derivative version of the response code
        // Ideally, this should be placed as far from the responseCode switch as possible,
        // to prevent attackers from noticing the call to the CRC32 library, which would be
        // a strong hint as to what we're done here. If you can add additional transformations
        // elsewhere in before this value is used, that's even better.
        java.util.zip.CRC32 crc32 = new java.util.zip.CRC32();
        crc32.update(responseCode);
        int transformedResponseCode = crc32.getValue();

        // ... put unrelated application code here ...
        // crc32(LICENSED) == 3523407757
        if (transformedResponse == 3523407757) {
            LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
            handleResponse(limiterResponse, data);
        }
        // ... put unrelated application code here ...
        // crc32(LICENSED_OLD_KEY) == 1007455905
        if (transformedResponseCode == 1007455905) {
            LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
            handleResponse(limiterResponse, data);
        }
        // ... put unrelated application code here ...
        // crc32(NOT_LICENSED) == 2768625435
        if (transformedResponseCode == 2768625435):
            userIsntLicensed();
        }
    }

In this example, we’ve added additional code to transform the license response code into a different value. We’ve also removed the switch block, allowing us to inject unrelated application code between the three license response checks. (Remember: The goal is to make your application’s LVL implementation unique. Do not copy the code above verbatim — come up with your own approach.)

For the entry/exit points, be aware that attackers may try to write a counterfeit version of the LVL that implements the same public interface, then try to swap out the relevant classes in your application. To prevent this, consider adding additional arguments to the LicenseChecker constructor, as well as allow() and dontAllow() in the LicenseCheckerCallback. For example, you could pass in a nonce (a unique value) to LicenseChecker that must also be present when calling allow().

Note: Renaming allow() and dontAllow() won’t make a difference, assuming that you’re using an obfuscator. The obfuscator will automatically rename these functions for you.

Be aware that attackers might try and attack the calls in your application to the LVL. For example, if you display a dialogue on license failure with an “Exit” button, consider what would happen if an attacker were to comment out the line of code that displayed that window. If the user never pushes the “Exit” button in the dialog (which is no not being displayed) will your application still terminate? To prevent this, consider invoking a different Activity to handle informing a user that their license is invalid, and immediately terminating the original Activity; add additional finish() statements to other parts of your code that get will get executed in case the original one gets disabled; or set a timer that will cause your application to be terminated after a timeout. It’s also a good idea to defer the license check until your application has been running a few minutes, since attackers will be expecting the license check to occur during your application’s launch.

Finally, be aware that certain methods cannot be obfuscated, even when using a tool such as ProGuard. As a key example, onCreate() cannot be renamed, since it needs to remain callable by the Android system. Avoid putting license check code in these methods, since attackers will be looking for the LVL there.

Technique: Make your application tamper-resistant

In order for an attacker to remove the LVL from your code, they have to modify your code. Unless done precisely, this can be detected by your code. There are a few approaches you can use here.

The most obvious mechanism is to use a lightweight hash function, such as CRC32, and build a hash of your application’s code. You can then compare this checksum with a known good value. You can find the path of your application’s files by calling context.GetApplicationInfo() — just be sure not to compute a checksum of the file that contains your checksum! (Consider storing this information on a third-party server.)

A simpler, and perhaps less obvious approach, is to simply check how your application was installed. If you know that your application will only be distributed through Android Market, you can verify that Android Market is listed as the installer for the application:

PackageManager pm = context.getPackageManager();
String installer = pm.GetInstallerPackageName(getApplicationInfo().packageName);

if (!"com.google.android.feedback".equals(installer)) {
    // Application was installed via other means than Android Market.
    // Assuming there are no other distribution channels, this APK has probably been
    // tampered with.
}

Consider using obfuscation techniques so that the installer package name never actually appears in your compiled source. For example, you can use the crc32() trick mentioned earlier, compute a md5(), or even use ROT13.

Also, you can check to see if your application is debuggable. If your application tries to keep itself from performing normally if the debug flag is set, it may be harder for an attacker to compromise:

boolean isDebuggable =  ( 0 != ( getApplcationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE ) );

Technique: Offload license validation to a trusted server

If your application has an online component, a very powerful technique to prevent piracy is to send a copy of the license server response, contained inside the ResponseData class, along with its signature, to your online server. Your server can then verify that the user is licensed, and if not refuse to serve any online content.

Since the license response is cryptographically signed, your server can check to make sure that the license response hasn’t been tampered with by using the public RSA key stored in the Android Market publisher console.

When performing the server-side validation, you will want to check all of the following:

• That the response signature is valid.

• That the license service returned a LICENSED response.

• That the package name and version code match the correct application.

• That the license response has not expired (check the VT license response extra).

• You should also log the userId field to ensure that a cracked application isn’t replaying a license response from another licensed user. (This would be visible by an abnormally high number of license checks coming from a single userId.)

To see how to properly verify a license response, look at LicenseValidator.verify().

As long as the license check is entirely handled within server-code (and your server itself is secure), it’s worth nothing that even an expert cracker cannot circumvent this mechanism. This is because your server is a trusted computing environment.

Remember that any code running on a computer under the user’s control (including their Android device) is untrusted. If you choose to inform the user that the server-side license validation has failed, this must only be done in an advisory capacity. You must still make sure that your server refuses to serve any content to an unlicensed user.

Conclusion

In summary, remember that your goal as an application developer is to make your application’s LVL implementation unique, difficult to trace when decompiled, and resistant to any changes that might be introduced. Realize that this might involve modifying your code in ways that seem counter-intuitive from a traditional software engineering viewpoint, such as removing functions and hiding license check routines inside unrelated code.

For added protection, consider moving the license check to a trusted server, where attackers will be unable to modify the license check code. While it’s impossible to write 100% secure validation code on client devices, this is attainable on a machine under your control.

And above all else, be creative. You have the advantage in that you have access to a fully annotated copy of your source code — attackers will be working with uncommented bytecode. Use this to your advantage.

And above all else, listen to your users and keep them happy. The best defense against piracy isn’t technical, it’s emotional.

In the last 5 months, we've worked with over 150 companies who have launched apps in the Google Apps Marketplace. In our conversations with developers, marketing teams, and business execs, it's become clear we would all benefit from a wider conversation and debate -- beyond one-on-ones.

So we took the logical next step and created an email-based Google Apps Marketplace forum, and then embedded it in our documentation and program sites so it’s easier to find. Starting today, it's the best place we know of to engage folks in the Apps Marketplace community to discuss trends, pricing models, brainstorm features, or just gripe about stuff.

Join the forum and dive in!

But wait, there’s more

There’s a wider Google Apps solution provider community beyond Marketplace developers however. Google Apps resellers, integrators, and consultants are equally passionate about innovating with customers in the cloud. And here at Google, we’re growing an equally passionate team to work with you all, our extended community.

But our team has a problem: we have a lot of news and observations to share, large and small, but no good way to share them in a way that enables an easy conversation. You know, Twitter-style, but with the ability to actually find the comment thread that develops around an interesting post. So we created a Google Apps Ecosystem team Buzz stream for that very purpose.

Follow us on Buzz and share your thoughts in the comments!

We like shaking hands too

We love the Internet, but sometimes we would rather meet face-to-face. We do that too when possible. For example, we recently held a Google Apps Hackathon here in Mountain View, where dozens of cloud app developers, IT developers and systems integrators joined together to code and learn about Google Apps APIs.

We kicked of the day with great presentations by Jeremy Glassenberg of Box.net on their Marketplace app, and Chris McGarry and Neel Patel from Omnetic talking about opportunities for system integrators to build on and extend Google Apps. There was strong interest in the 9 short technical side sessions on many of our APIs, though a little less coding than expected. Our quick survey of attendees gave us some great feedback, so we plan on iterating and doing more in the future.

So please do reach out, both to us here at Google as well as your fellow community members, using these new virtual water coolers.

Posted by Scott McMullan, Google Apps Partner Lead

Want to weigh in on this topic? Discuss on Buzz

Posted by Mano Marks, Geo APIs Team

Lockheed Martin Corporation recently announced the release of its first open source software initiative around social media called Eureka Streams. Eureka Streams is a social media platform that integrates activity streams and OpenSocial apps. Lockheed Martin has spent the past several years growing a strategy of Social Software within the Enterprise to bring widely distributed employees together. Eureka Streams takes that vision further by incorporating what works well on the internet and builds a platform based on open standards to expand social media even further.

Eureka Streams, initially built internally, is now being made available
under the Apache License as open source. Shindig version 1.1 (beta)
integration provides the framework to offer the OpenSocial 0.9
features, creating a user focused OpenSocial gadget container that can
access the user profiles and activity data created within the tool.
The UI has been developed using Google Web Toolkit to provide a
flexible JavaScript front end developed in Java.

Eureka Streams is currently released to open source at version
0.9. The team has placed a heavy focus on user interaction,
performance, and scalability to this point, but is shifting their
focus to the developer and looking for support from the open source
community.

For more information and to learn how to get started, please visit the Eureka Streams web site.

Posted on behalf of Steve Terlecki, Lockheed Martin Corp, by Mark Weitzel, President, OpenSocial Foundation

As part of the GWT team's ongoing effort to address the needs of the Maven community, the Google Plugin for Eclipse (GPE) team is working to improve interoperability with Maven in future releases. Plugin version 1.3.3 makes it possible to use Maven in a GPE project with a little tweaking, and future versions aim to improve this experience. There is already good support from the open source community for using Maven with GWT and/or App Engine projects; however, it has been difficult to enable both Maven and GPE for the same project. This article explains how to do that. It assumes you already have some Maven knowledge.

Working with GWT and GAE in Maven

First, here are a few tips on using Maven with GWT and GAE.

The open source community has written Maven plugins for both GWT and App Engine which wrap the native development tools for these platforms.

• maven-gae-plugin provides Maven goals to run, debug, deploy, and rollback a GAE application as well as a handful of utility goals. In addition, the plugin automatically retrieves all GAE runtime dependencies from the plugin's SVN repo (Google is working on publishing these dependencies to the central Maven repo, as well).
• gwt-maven-plugin from codehaus.org provides Maven goals to compile GWT applications, and run or debug in hosted mode using the dev mode console.

Both projects provide Maven archetypes to generate a pom.xml and project skeleton. In addition, you can find a GWT+GAE+Roo sample POM within the Expenses sample project in GWT trunk. It contains everything you need to build a GWT 2.1 app (as of 2.1.0 M3) with Spring Roo and deploy to App Engine. If you're not using Spring, you can remove the Spring dependencies.

The documentation for each plugin lists all of the Maven goals available, but we'll briefly look at the most common:

• mvn gae:run starts the App Engine development server.
• mvn gae:deploy deploys your application to App Engine.
• mvn gwt:run runs your GWT app in hosted mode using the standalone dev mode console. If you're using maven-gae-plugin, it will also invoke gae:run.
• mvn gwt:debug runs your GWT app in hosted mode and additionally enables the debugger port hook so you can debug in Eclipse as a Remote Java Application on the standard debugger port (8000). It is generally easier, however, to launch the debugger within Eclipse using GPE. We'll look at how to enable that shortly.
• mvn gwt:compile compiles your GWT app for production.
• mvn eclipse:eclipse creates an Eclipse project that you can import into Eclipse. The sample POM referenced above contains configuration for the maven-eclipse-plugin which adds the gwt and gae project natures used by Google Plugin for Eclipse. After you run Maven eclipse:eclipse, you can import your project into Eclipse using File | Import | Project | Existing Project.

Using the goals provided by the GWT and GAE Maven plugins, it is not necessary to use the Google Plugin for Eclipse at all, as you can use Maven instead to run / debug / deploy. However, GPE provides tighter integration with Eclipse Run / Debug launch, code completion, warnings and errors, etc., so it's useful to enable it also.

Enabling Google Plugin for Eclipse to work with an existing Maven project

If you have an existing Maven project in Eclipse and want to enable GPE functionality, follow these steps:

1. In Eclipse, open your project's properties (Alt+Enter or right-click, Properties)
2. Under Google | App Engine, select the version of the App Engine SDK you're using. GPE is not yet able to use the version defined in your Maven POM, so you may need to download your SDK version using the Eclipse software updater (see http://code.google.com/eclipse/docs/download.html)
3. Under Google | Web Toolkit, likewise select the version of the GWT SDK you're using. As with the App Engine SDK, install it via the Eclipse plugin update site if needed.
4. Under Google | Web Application, check the "This project has a WAR directory" box and point it to your project's src/main/webapp directory. This is the standard WAR source folder for Maven Web projects. Be sure that the "Launch and deploy from this directory" box is NOT checked.
5. Under Java Build Path, select the Order and Export tab and move all Maven dependencies to the BOTTOM. Otherwise, GPE will see the App Engine and GWT SDKs from the Maven repo on the build path and complain that they are not valid. This is because GPE expects a specific SDK structure used to enable other tooling.
6. Also under Java Build Path, select the Source tab and ensure that the Build output directory is enabled and pointing to target/your-project-name/WEB-INF/classes. If you created the project with mvn eclipse:eclipse, this should be done for you automatically.
7. Finally, and this is very important, the first time you launch your project using Run As | Web Application (or Debug), you will be prompted to select the war directly. This is NOT src/main/webapp, but rather the WAR output folder, which is target/your-project-name. If you make a mistake, simply go to Run | Run Configurations... and remove any old configurations for the project. GPE will then ask you again next time you try to Run As | Web Application.

Mavenizing an existing GPE project

To use Maven with an existing GPE project, follow these steps:

1. Create a pom.xml using one of the project archetypes or sample POM discussed above. Make sure it contains configuration for gwt-maven-plugin, maven-eclipse-plugin, and maven-gae-plugin (if you're using App Engine).
2. Maven projects use a different layout than the default GPE project, so create folders for your Java code (src/main/java) and static resources (src/main/webapp).
3. Move all source files under the GPE-created war directory into src/main/webapp. These include any config files (web.xml, etc.) under war/WEB-INF and static resources such as images and CSS. After you've moved the source files, you can delete the war directory, as Maven will create output folders for your GWT modules under the target directory, not the war directory.
4. Add Maven dependencies in your pom.xml for each jar that had been in WEB-INF/lib.
5. Run mvn eclipse:clean eclipse:eclipse in the project directory to recreate your Eclipse project file, then Refresh it in Eclipse (select project and press F5 or right-click, Refresh).
6. Follow the steps in the previous section to enable GPE support with Maven.

Let me conclude with a hearty thank you to everyone who has contributed to the development of maven-gae-plugin and gwt-maven-plugin. Your contributions are an indispensable part of Google's ability to better meet the needs of the Maven community.

Last week we announced our 1.3.6 release with lots of new, exciting features to try out. After it was released, developers dug into all the new functional and discovered a pair of issues that required a quick fix. Today we are releasing version 1.3.7 of the SDK in both Java and Python to fix two issues that shipped with last week’s release 1.3.6.

The first issue was with the Python SDK, which was missing the functionality to assign a namespace based on the Google Apps domain. With this release the function google_apps_namespace() should exist and function as documented.

The second issue we fixed was with the Java SDK. The getServingUrl() function for the new dynamic image resizing service was throwing a SecurityException in the SDK. This issue has now been fixed and this function should work as expected.

Thank you to all the people who reported these issues. Please visit the download page to get the new version of the SDK.

This week, a lot.

Today we’re excited to announce the band Arcade Fire’s new project “The Wilderness Downtown,” an interactive HTML5 music experience that is being showcased on Google’s Chrome Experiments site. The project was created by writer/director Chris Milk with Arcade Fire and Google.

We put everything except the proverbial kitchen sink into this project: It features HTML5 audio, video, and canvas, animated windows with JavaScript controllers, mash-ups with Google Maps and Street View APIs, and an interactive drawing tool. You can take a look at how all this works by viewing the source code.

Check out the project or learn more about the techniques used to make it happen at www.chromeexperiments.com/arcadefire.

We hope you enjoy it.

Solve360

Smartsheet

Video Demonstration

Harvest

"So many actions and todos originate from emails. Today, with contextual gadgets, we deliver the user their timesheet so it's incredibly convenient for them to fill out."
- Danny Wen, Harvest Co-founder.

Video Demonstration

Head over to the Google Enterprise Blog if you want more detail on these applications.

Contextual Gadgets greatly accelerates user adoption by bringing the application directly to the user in context and in their normal work flow. Many great apps fail to gain user traction because they are separated from the normal workflow. Gmail Contextual Gadgets solve that problem for developers, and make it much easier for the end users to see the benefits.

If you think you’re ready to start saving time for the users of your application, then dive right into the Developer’s Guide for Gmail Contextual Gadgets. Since gadgets are based on the OpenSocial gadget specification, they’re developed in the technologies you’re already familiar with -- HTML, JavaScript and CSS. Get started now, and be sure to share what you build!

Posted by Ryan Boyd, Google Apps Marketplace Team

Want to weigh in on this topic? Discuss on Buzz

• Acre is based on Rhino, Mozilla's implementation of Javascript in Java. (In fact, "Acre" stands for "A Crash of Rhinos Evaluating.") Acre, by default, uses the Jetty servlet engine as its HTTP server, but can be run in any servlet container.
• Acre includes a module system that supports high-latency source retrieval using extensive caching. Although Acre was originally designed to fetch data only from Freebase itself, it can also fetch data from disk and will support a wider range of require() options such as WebDAV.
• Acre is capable of running on Google AppEngine, with support for the Keystore and for synchronous and asynchronous HTTP requests. Soon, Freebase's own Acre installation will run on AppEngine.

Posted by Don Dodge, Google Apps Team

Want to weigh in on this topic? Discuss on Buzz

<repository>
  <id>google-maven-snapshot-repository</id>
  <name>Google Maven Snapshot Repository</name>
  <url>https://oss.sonatype.org/content/repositories/google-snapshots/</url>
  <snapshots>
    <enabled>true</enabled>
  </snapshots>
</repository>

Back in May, at Google IO, we announced an integration between VMware’s popular Spring framework for server-side development and GWT for the client-side. Since then we have been excited by the feedback and comments from customers building real world apps with this technology. In response to their feedback, and pushing towards delivering on our our promises form IO, we are very happy to announce release M3. Looking forward we expect our production quality, GA (general availability), drop to land in a few months.

Some key features included in this release are built-in history support in Activities and Places, relationship management within RequestFactory, and the ability to call instance methods on entities themselves. The overarching goal was to nail down the API and deliver on features and functionality that are vital to creating industry-grade business apps.

For the Spring Roo community, we're continuing to build-out the integrated stacks that we announced back at Google I/O. GWT 2.1 M3 includes a parallel Roo 1.1 M3 that will allow you to take advantage of all the features mentioned above. Also, in the spirit of co-operative and transparent development, you can find a full list of features and functionality over at Roo's issue tracker.

GWT 2.1 M3 is available on our Google Code download site. We’d love to hear your feedback and thoughts on this release, and our GWT Developer Forum would be the best place to post this information.

It’s been reported that someone has figured out, and published, a way to hack some Android apps to bypass our new Android Market licensing server. We’ll be saying more on this, but there are a few points that deserve to be made right now:

• The licensing service, while very young, is a significant step forward in terms of protection over the plain copy-protection facility that used to be the norm. In the how-to-pirate piece, its author wrote: “For now, Google’s Licensing Service is still, in my opinion, the best option for copy protection.”

• The licensing service provides infrastructure that developers can use to write custom authentication checks for each of their applications. The first release shipped with the simplest, most transparent imaginable sample implementation, which was written to be easy to understand and modify, rather than security-focused.

• Some developers are using this sample as-is, which makes their applications easier to attack. The attacks we’ve seen so far are also all on applications that have neglected to obfuscate their code, a practice that we strongly recommend. We’ll be publishing detailed instructions for developers on how to do this.

• The number of apps that have migrated to the licensing server at this point in time is very small. It will grow, because the server is a step forward.

• 100% piracy protection is never possible in any system that runs third-party code, but the licensing server, when correctly implemented and customized for your app, is designed to dramatically increase the cost and difficulty of pirating.

• The best attack on pirates is to make their work more difficult and expensive, while simultaneously making the legal path to products straightforward, easy, and fast. Piracy is a bad business to be in when the user has a choice between easily purchasing the app and visiting an untrustworthy, black-market site.

Android Market is already a responsive, low-friction, safe way for developer to get their products to users. The licensing server makes it safer, and we will continue to improve it. The economics are already working for the developers and against the pirates, and are only going to tilt further in that direction.