Saturday, November 12, 2011

[Gd] Join us at the Google Apps Developer Hackathons!

| More

Google Apps Developer Blog: Join us at the Google Apps Developer Hackathons!

We are very excited to invite all Google Apps developers to our upcoming round of hackathons! We are hosting the hackathons at our Mountain View, CA campus, and at our New York City campus.

The hackathons enable teams of developers to build something integrating the Google experience into a product. Come to the hackathons for fun, food, and the experience. Increase your knowledge of the Google Apps developer platform, while also building something really cool. Meet other developers, Google engineers, and share stories of your integrations and experience. We are handing out prizes for the best projects, including the best new projects, and the best integrations into existing projects -- more details, including the rules and prizes, will be sent out to registrants soon. Don’t worry if you don’t have a team or an existing project-- impromptu teams are great!

Specific details of each event follow. Space is limited, so make sure to register as soon as possible. Confirmation emails are sent to accepted registrants.

Google Apps Developer Hackathon, NYC
Click here to register
Thursday, December 1, 2011
1:00pm - 8:00pm EST
Google NYC
111 8 Ave.
New York, NY 10011

Google Apps Developer Hackathon, Mountain View
Click here to register
Tuesday, December 6, 2011
1:00pm - 8:00pm PST
Google
1300 Crittenden Lane
Mountain View, CA

Drinks, after-lunch snacks, and dinner will be provided. Please bring your laptop. Power and wireless internet access will also provided.



Vic Fryzel   profile | twitter | blog

Vic is a Google engineer and open source software developer in the United States. His interests are generally in the artificial intelligence domain, specifically regarding neural networks and machine learning. He's an amateur robotics and embedded systems engineer, and also maintains a significant interest in the security of software systems and engineering processes behind large software projects.

URL: http://googleappsdeveloper.blogspot.com/2011/11/join-us-at-google-apps-developer.html

[Gd] Google Apps EMEA developer tour

| More

Google Apps Developer Blog: Google Apps EMEA developer tour

A few of us from Developer Relations will be going around EMEA in the next few months to meet with developers and talk about some Google Apps technologies for developers.

This tour will start with Ryan Boyd and Michael Manoochehri speaking about different Google Apps topics at Google Developer Days in Tel-Aviv and Berlin, and a GTUG meeting in Munich.

Then I will be giving an Apps Script talk at the Barcelona Developers Conference followed by a series of Apps Script Hackathons in France (multiple locations), Zurich, Munich and Dublin.

For more information about the tour and to register for these events, please visit the Google Apps EMEA Developer Tour website.



We plan to organize many other Google Apps events close to you in the near future. Look for updates on the Google Apps EMEA Developer Tour website or keep an eye out for further announcements on this blog.

Nicolas Garnier profile | twitter | events

Nicolas joined Google’s Developer Relations in 2008. Since then he's worked on commerce oriented products such as Google Checkout and Google Base. Currently, he is working on Google Apps with a focus on the Google Calendar API, the Google Contacts API, and the Tasks API. Before joining Google, Nicolas worked at Airbus and at the French Space Agency where he built web applications for scientific researchers.

URL: http://googleappsdeveloper.blogspot.com/2011/11/google-apps-emea-developer-tour.html

[Gd] Introducing Closure Stylesheets

| More

Closure Tools Blog: Introducing Closure Stylesheets

(CSS is for programming, not for pasting)

When the Closure Tools were first released a little over two years ago, they gave web developers the ability to organize and optimize their JavaScript and HTML in a new way. But there was something missing, namely, a tool to help manage CSS.

You see, the nature of CSS runs contrary to the DRY principle that is exhibited in good software engineering. For example, if there is a color that should be used for multiple classes in a stylesheet, a developer has no choice but to copy-and-paste it everywhere because CSS has no concept of variables. Similarly, if there is a value in a stylesheet that is derived from other values, there is no way to express that because CSS also lacks functions. Common patterns of style blocks are duplicated over and over because CSS has no macros. All of these properties of CSS conspire to make stylesheets extremely difficult to maintain.

To this end, we are excited to introduce the missing piece in the Closure Tools suite: Closure Stylesheets. Closure Stylesheets is an an extension to CSS that adds variables, functions, conditionals, and mixins to standard CSS. The tool also supports minification, linting, RTL flipping, and CSS class renaming. As the existing Closure Tools have done for JavaScript and HTML, Closure Stylesheets will help you write CSS in a maintainable way, while also empowering you to deliver optimized code to your users. We hope you enjoy it! Please let us know what you think in the discussion forum.

By Michael Bolin, Open Source Engineer

Cross posted from the Google Open Source Blog.
URL: http://closuretools.blogspot.com/2011/11/introducing-closure-stylesheets.html

[Gd] Updated NDK for Android 4.0

| More

Android Developers Blog: Updated NDK for Android 4.0

Today we are releasing an updated version of the Android NDK, now in revision 7. The updated NDK lets developers who are using native code get started with the new native APIs available in Android 4.0.

Android NDK r7 includes a number of build system improvements and bug fixes, but most importantly it gives you access to two new sets of APIs:

Low-level streaming multimedia: A new API based on Khronos OpenMAX AL 1.0.1 provides a direct, efficient path for low-level streaming multimedia. The new path is ideal for applications that need to maintain complete control over media data before passing it to the platform for presentation. For example, media applications can now retrieve data from any source, apply proprietary encryption/decryption, and then send the data to the platform for display.

Audio decoding into PCM: Extensions to the existing native audio API based on Khronos OpenSL ES let native apps decode compressed audio assets to PCM format.

For detailed information about how to use these new APIs, please see the documentation included with the Android NDK r7 package. To read about the build system improvements and bug fixes included in this release, check out the release notes.

URL: http://android-developers.blogspot.com/2011/11/updated-ndk-for-android-40.html

Friday, November 11, 2011

[Gd] Discovering v201109: How to target Campaigns

| More

AdWords API Blog: Discovering v201109: How to target Campaigns

With the introduction of v201109 we’ve made some changes in the AdWords API with regards to targeting campaigns.  This blog post will discuss these changes in detail.

From CampaignTargets to Criterion

Targeting campaigns in v201109 is now accomplished via the CampaignCriterionService. Previously, the CampaignTargetService had a large number of CampaignTargets that could be used to better direct who saw your ads. For v201109, almost all of these targets have been transformed into Criterion objects and moved to the CampaignCriterionService.

Some of these criteria can only be targeted (CampaignCriterion) or only excluded (NegativeCampaignCriterion).  The individual criteria are documented as to whether they are targetable-only or excludable-only on their individual documentation pages.  The table below shows a comparison between the old CampaignTargets and their respective Criterion as well as whether they are Targetable-only, Excludable-only or both.




A rose by any other name (or ID)

Please note that except for Proximity Criteria, we have changed all these targeting criteria to work with IDs instead of names.  This allows us to update the text of display values without requiring developers to change their applications.  Below is an example of the old and new ways to represent LanguageTarget/Language.

Old
<targets>
 <Target.Type>LanguageTarget</Target.Type>
 <languageCode>en</languageCode>
</targets>

New
<criterion xsi:type="Language">
 <id>1000</id>
 <type>LANGUAGE</type>
 <Criterion.Type>Language</Criterion.Type>
 <code>en</code>
</criterion>



Note that the “New” example shows the Language Criterion as it would be returned by the API.  When sending the value to the API, you only need to specify id and xsi:type, all other fields are ignored and read-only and documented as such.

We hope this blog post helps you as you update your application with the new Campaign Criteria.  If you have any questions about this service or how to use it, please post on the forum or try to attend our Google+ Hangouts with members of the AdWords API Developer Relations Team.

, AdWords API Team
URL: http://adwordsapi.blogspot.com/2011/11/discovering-v201109-how-to-target.html

[Gd] Discover v201109: Changes to accounts identification

| More

AdWords API Blog: Discover v201109: Changes to accounts identification

The AdWords API allows you to manage a large number of accounts using a single login credential set. In order to determine which account to run a query against, a customer identifier is required.

Previously we allowed the use of either client email address or client customer ID as account identifier. Using email addresses does not handle a number of situations, though, such as address change, multiple accounts associated with one email and others. In addition, AdWords accounts created with no email address are just not accessible by this identifier.

In order to unify account identification we decided to remove support for email addresses as account identifiers starting with v201109. From this version onward only client customer IDs are supported by the AdWords API.

Migrating to client customer ID

Most applications managing more than one AdWords account hold account identifiers in some form of a local storage. In case your application uses client email addresses as identifiers, you will need to convert those to client customer IDs, or add an extra field for the IDs.

In order to make this migration smoother, we’ve provided an example that demonstrates how to obtain a client ID for a given email address. This example is included in every client library and also available online.

It is easy to change how you identify a client account when making API requests if you use our client libraries. Depending on the language you use, you will need to update the configuration file or constructor parameter to include clientCustomerId instead of clientEmail. In case you construct your queries manually, please refer to the SOAP headers documentation page for more details.

We would like to remind you that all existing versions that support identification by email addresses are scheduled for shutdown in Feb 2012.


Please join us on forum or in our upcoming Google+ Hangouts if you have any questions regarding this change.

Danial Klimkin, AdWords API Team.
URL: http://adwordsapi.blogspot.com/2011/11/discover-v201109-changes-to-accounts.html

[Gd] Fridaygram: Nigel Tufnel’s delight

| More

The official Google Code blog: Fridaygram: Nigel Tufnel’s delight

Author Photo
By Scott Knaster, Google Code Blog Editor

One of the most rewarding aspects of working on neat technology is when you can make a difference in the real world. Our Custom Search team has been collaborating with U. S. agencies to produce a job search engine for use by returning military veterans. This is especially cool because today is Veterans Day in the U. S.


Once you’ve seen the customized job search engine, I hope you’ll be inspired to use Custom Search or some other interesting technology to make a difference with your own projects. And speaking of interesting projects...

Wan and exhausted, a team of six men emerged last week from a mock spacecraft after spending almost a year and a half on a simulated trip to Mars. The six lived in windowless capsules in Moscow for 520 days to see how they would react to the confinement.

One physiologist, a trainer, a surgeon, and three engineers made up the diverse crew, who were said to be in good health at the end of the mission. Their virtual trip to Mars qualifies as either a really grueling job or a bizarre vacation.

Wonderful as the simulated Mars mission was, it can’t compete with this classic video – especially today. Have a great weekend!


Wondering what this post is doing on Google Code Blog? Once a week, on Friday, we lighten up and have a little fun, posting curious, clever, and interesting bits and pieces. One more thing: we hope you find one not-so-hidden date-appropriate message in this post.

URL: http://googlecode.blogspot.com/2011/11/fridaygram-nigel-tufnels-delight.html

[Gd] New Layout Widgets: Space and GridLayout

| More

Android Developers Blog: New Layout Widgets: Space and GridLayout

[This post is by Philip Milne, who is part of the Android framework team. — Tim Bray]

Ice Cream Sandwich (ICS) sports two new widgets that have been designed to support the richer user interfaces made possible by larger displays: Space and GridLayout.

The most commonly used class for layout in Android is LinearLayout, which allows its children to be aligned in the usual ways: along either the horizontal or vertical axes. It’s often possible to take a complicated layout and break it down into a set of nested linear layouts and, provided this nesting doesn’t get too deep, this is still recommended as the first thing to consider if you are writing your user interface by hand.

A number of posts and articles (e.g. Android Layout Tricks #1, Flattening The Stack) have highlighted drawbacks of nested layouts; which fall into three basic categories:

  • Inability to control alignment along both axes simultaneously

  • Performance problems in hierarchies that are too deep

  • Unsuitability for design tools that support free-form editing

A simple example of the first problem is the following form:

As the font and the text of the “Email address” label change, we want the label to remain aligned with the baseline of the component to its right, and aligned with the right edge of the label below it. It’s not possible to do this with nested LinearLayouts because the label needs to be aligned with other components both horizontally and vertically.

These problems aren’t new to Android, or UI toolkits in general, but we’ve used them to drive our work in enriching platform support for flatter hierarchies.

GridLayout

To provide better support for layouts like these we have added a new layout to the Android framework: GridLayout, which can be used to solve the above problems by dividing the container’s real estate into rows and columns:

Now the “Email address” label can belong both to a row that is baseline-aligned, and a column that is right-aligned.

GridLayout uses a grid of infinitely-thin lines to separate its drawing area into: rows, columns, and cells. It supports both row and column spanning, which together allow a widget to occupy a rectangular range of cells that are next to each other. We’ll use the words row, column, and cell in the text below as shorthand for row group, column group and cell group respectively, where groups have one or more contiguous elements.

Similarities with LinearLayout

Wherever possible, GridLayout uses the same conventions as LinearLayout for all its XML API — so it should be easy to start using GridLayout if you’ve already used LinearLayout. In fact, the APIs are so similar that changing a tag name from LinearLayout to GridLayout in an XML file that uses LinearLayout will often produce a similar UI without requiring any other changes. When it doesn’t, you’ll still generally end up with a good starting point for a two-dimensional layout.

Getting Started

Two examples in the samples area of the Android 4.0 SDK show typical use of the programmatic and XML APIs respectively:

[Both examples produce the same UI.]

Here’s a slightly simpler version of the above XML layout.

<?xml version="1.0" encoding="utf-8"?>
<GridLayout
xmlns:android="http://schemas.android.com/apk/res/android"

android:layout_width="match_parent"
android:layout_height="match_parent"

android:useDefaultMargins="true"
android:alignmentMode="alignBounds"
android:columnOrderPreserved="false"

android:columnCount="4"
>

<TextView
android:text="Email setup"
android:textSize="32dip"

android:layout_columnSpan="4"
android:layout_gravity="center_horizontal"
/>

<TextView
android:text="You can configure email in just a few steps:"
android:textSize="16dip"

android:layout_columnSpan="4"
android:layout_gravity="left"
/>

<TextView
android:text="Email address:"

android:layout_gravity="right"
/>

<EditText
android:ems="10"
/>

<TextView
android:text="Password:"

android:layout_column="0"
android:layout_gravity="right"
/>

<EditText
android:ems="8"
/>

<Space
android:layout_row="4"
android:layout_column="0"
android:layout_columnSpan="3"
android:layout_gravity="fill"
/>

<Button
android:text="Next"

android:layout_row="5"
android:layout_column="3"
/>
</GridLayout>

The first difference you’ll notice in these examples is the absence of the WRAP_CONTENT and MATCH_PARENT constants that normally adorn Android layout resources. You don’t normally need to use these with GridLayout, for reasons that are described in the API doc for GridLayout.LayoutParams.

Row and Column Indices

The second thing you may notice in the XML resources is that widgets don’t always explicitly define which cells they are to be placed in. Each widget’s layout parameters have row and column indices that together define where the widget should be placed but when either or both of these values are not specified, GridLayout supplies default values rather than throwing an exception.

Automatic Index Allocation

As children are added to a GridLayout, it maintains a cursor position and a “high-water mark” that it uses to place widgets in cells that don’t yet have anything in them.

When GridLayout’s orientation property is horizontal and a columnCount has been set (to 8 in this example) the high-water mark (shown above in red) is maintained as a separate height value for each column. When indices need to be created, GridLayout first determines the size of the cell group (by looking at the rowSpan and columnSpan parameters of the new widget) and then, starting at the cursor, goes through the available locations from: left to right, top to bottom, so as to find the row and column indices of the first location that’s free.

When GridLayout’s orientation is vertical, all of the same principles apply, except that the roles of the horizontal and vertical axes are exchanged.

If you want multiple views to be placed in the same cell, you have to define the indices explicitly, as the default allocation procedure above is designed to place widgets in separate cells.

Sizes, Margins and Alignment/Gravity

In GridLayout, specifying sizes and margins is done just as with a LinearLayout. Alignment/gravity also works just like gravity in LinearLayout and uses the same constants: left, top, right, bottom, center_horizontal, center_vertical, center, fill_horizontal, fill_vertical and fill.

Flexibility

Unlike most grids in other toolkits, GridLayout does not associate data with rows or columns. Instead, everything to do with alignment and flexibility is associated with the components themselves. GridLayout departs from the norm here to provide a more general system that allows subtle relationships between ancestors in deeply nested layouts to be accommodated in a single layout configuration.

The flexibility of columns is inferred from the gravity of the components inside the column. If every component defines a gravity, the column is taken as flexible, otherwise the column is considered inflexible. Full details are in GridLayout’s API docs.

Emulating Features from other Layouts

GridLayout does not incorporate all of the features of every layout in the Android platform but it has a rich enough feature set that idiomatic use of other layouts can normally be emulated from inside a single GridLayout.

Although LinearLayout can be considered a special case of a GridLayout, for the degenerate case when a set of views are aligned in a single row or column, LinearLayout is the better choice when this is all that is required as it clarifies the purpose of the container and may have some (relatively small) performance advantages.

TableLayout configurations are normally straightforward to accommodate, as GridLayout supports both row and column spanning. TableRows can be removed, as they are not required by GridLayout. For the same UI, a GridLayout will generally be faster and take less memory than than a TableLayout.

Simple RelativeLayout configurations can be written as grids simply by grouping the views that are related to each other into rows and columns. Unlike conventional grids, GridLayout uses a constraints solver to do the heavy lifting of the layout operation. By using GridLayout’s rowOrderPreserved and columnOrderPreserved properties it’s possible to free GridLayout from the confines of traditional grid systems and support the majority of RelativeLayout configurations — even ones that require grid lines to pass over each other as children change size.

Simple FrameLayout configurations can be accommodated within the cells of a GridLayout because a single cell can contain multiple views. To switch between two views, place them both in the same cell and use the visibility constant GONE to switch from one to the other from code. As with the LinearLayout case above, if all you need is the functionality described above, FrameLayout is the better choice and may have some small performance advantages.

One key feature that GridLayout lacks is the ability to distribute excess space between rows or columns in specified proportions — a feature that LinearLayout provides by supporting the principle of weight. This omission and possible ways around it are discussed in GridLayout’s API docs.

The Phases of the Layout Operation

It’s useful to distinguish the allocation phase for cell indices discussed above from the layout operation itself. Normally the phase that allocates indices happens once, if at all, when a UI is initialized. The index-allocation phase only applies when indices have been left unspecified, and is responsible for ensuring that all views have a defined set of cells in which they are to be placed at layout time.

The layout operation happens after this and is recalculated each time a view changes size. The GridView measures the size of each child during the layout operation so it can calcuate the heights and widths of the rows and columns in the grid. The layout phase completes by using gravity to place each of the components in its cell.

Although index allocation normally only happens once, GridLayout is technically a dynamic layout, meaning that if you change its orientation property or add or remove children after components have been laid out, GridLayout will repeat the above procedure to reallocate indices in a way that is right for the new configuration.

From a performance standpoint, it is worth knowing that the GridLayout implementation has been optimized for the common case, when initialization happens once and layout happens frequently. As a result, the initialization step sets up internal data structures so that the layout operation can complete quickly and without allocating memory. Put another way, changes either to GridLayout’s orientation or the number of children it has are much more expensive than an ordinary layout operation.

Conclusion

GridLayout’s feature set incorporates much of the functionality of the Android framework’s existing general-purpose layouts: LinearLayout, FrameLayout, TableLayout and RelativeLayout. As such, it provides a way to replace many deeply nested view hierarchies with a single highly optimized layout implementation.

If you are starting a UI from scratch and are not familiar with Android layouts, use a GridLayout — it supports most of the features of the other layouts and has a simpler and more general API than either TableLayout or RelativeLayout.

We anticipate that the combination of FrameLayout, LinearLayout and GridLayout together provide a feature set that’s rich enough to allow most layout problems to be solved without writing layout code by hand. It’s worth spending some time deciding which of these layouts is right for the top of your tree; a good choice will minimize the need for intermediate containers and result in a user interface that is faster and uses less memory.

URL: http://android-developers.blogspot.com/2011/11/new-layout-widgets-space-and-gridlayout.html

[Gd] GWT and Dart

| More

Google Web Toolkit Blog: GWT and Dart

The Google Web Toolkit team has been asked recently about our plans following the announcement of the Dart programming language a few weeks ago.


Dart and GWT both share the goal of enabling structured web programming. In fact, many of the same engineers who brought you GWT are working on Dart. We view Dart as an ambitious evolution of GWT’s mission to make web apps better for end users, and we’re optimistic about its potential. As Dart evolves and becomes ready for prime time, we anticipate working closely with the GWT developer community to explore Dart.


Meanwhile, rest assured that GWT will continue to be a productive and reliable way to build the most ambitious web apps — and even games like Angry Birds. Key projects within Google rely on GWT every day, and we plan to continue improving (and open-sourcing) GWT based on their real-world needs.

URL: http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html

[Gd] A more efficient way to manage your Google Groups settings

| More

Google Apps Developer Blog: A more efficient way to manage your Google Groups settings

If you’re a Google Apps administrator and you want to create multiple Google Groups for your domain, you can do so using the Google Apps Provisioning API. However, until today, there was no way for you to programmatically update the settings for the groups you created. Some organizations have hundreds or even thousands of groups, and you’ve told us that you want a more streamlined method for managing these groups’ settings. That’s why we’re pleased to announce the Google Apps Groups Settings API, which allows you to control settings for all of your groups much more efficiently.

The Google Apps Groups Settings API is available for Google Apps for Business, Education and ISPs and can be used to manage:

  • Access settings for a group, such as who can subscribe and post
  • Email delivery settings, including maximum message size and reply options
  • Message moderation settings, such as whether messages from new members should be moderated, all messages should be moderated, or no moderation should be used

To begin using the Google Groups Settings API today, follow the instructions in the API documentation. You will need to sign in to the Google APIs Console and request access to the API. We hope the API will allow you to more quickly and easily manage all of the groups in your domain. If you have any questions about this API, please ask them in the Domain Information and Management APIs forum.



Piyush Nigam   profile | twitter | site

Piyush is a Google software engineer in India working on Google Apps APIs. His interests are generally in scalable architectures and web services. Before joining Google he worked on large scale platform systems at Amazon.


URL: http://googleappsdeveloper.blogspot.com/2011/11/more-efficient-way-to-manage-your.html

[Gd] Beta Channel Update

| More

Chrome Releases: Beta Channel Update


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

For an overview of key features in this release check out the Google Chrome Blog.  Interested in switching to the Beta or Stable channels?  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/11/beta-channel-update_10.html