Saturday, September 24, 2011

[Gd] Fall 2011 App Engine events

| More

Google App Engine Blog: Fall 2011 App Engine events





Buenos días desde Buenos Aires!! Wow, we are just blazing through the summer! We had an exciting Google I/O in May where we saw the launch of the Go runtime, introduction of the Backends feature, and confirmed Google's commitment to the platform with our plans to leave preview mode, not to mention the five releases since that time. We then hit the road this summer with team members appearing around the globe, including mega events like the Cloud Computing Expo, EuroPython, and OSCON.



At Google I/O, many App Engine team members gave in-depth technical sessions. Alfred Fuller, an App Engine Datastore engineer, revealed how the High Replication datastore gives greater reliability and availability for users. Michael Handler, one of App Engine’s talented Site Reliability Engineers, discussed how App Engine works in production. At OSCON, the largest open source event in the world, yours truly gave a three-hour App Engine overview and workshop to help new users get up to speed, and earlier in the year at PyCon, described how Python users can avoid “vendor lock-in” via the Django-nonrel project by porting their applications from webapp to Django, allowing them to move on to or off of App Engine as they please with only minor configuration changes. We participate in events like these because we like to communicate with users to find out what they like & don’t like about the platform, and we often take their suggestions to heart!



This fall we have a full schedule, appearing at many developer events worldwide, including Google Developer Days and Google DevFests. At the Google events, we'll recap App Engine and those announcements we made at I/O, and you’ll learn how to build exciting applications using App Engine and other Google cloud technologies as well as how to build games in the cloud. Here are the dates, events, and locations that we will be visiting:



Fall 2011

Sep 19-20 - Google Developer Day Argentina - Buenos Aires - Wesley Chun, Chris Schalk

Sep 19-23 - Strata - New York - Chris Schalk

Sep 23-24 - PyCon Argentina - Junín - Wesley Chun

Sep 26-30 - Congresso Brasileiro de Software - São Paulo - Wesley Chun

Sep 29-Oct 1 - Python Brasil[7] - São Paulo - Wesley Chun

Oct 8-9 - Silicon Valley CodeCamp - Los Altos Hills - Wesley Chun

Oct 10 - Google Developer Day Russia - Moscow - Iein Valdez, Fred Sauer

Oct 18 - Google Developer Day Czech Republic - Prague - Iein Valdez, Fred Sauer

Oct 20 - Google DevFest France - Paris - Iein Valdez, Johan “Proppy“ Euphrosine

Nov 1 - Google Developer Day Japan - Tokyo - Takashi Matsuo, Johan “Proppy“ Euphrosine

Nov 8 - Google Developer Day Australia - Sydney - Chris Schalk, Johan “Proppy“ Euphrosine

Nov 8 - Google DevFest Spain - Barcelona - Iein Valdez, Michael Manoochehri

Nov 12 - Google DevFest Singapore - Singapore - Chris Schalk

Nov 13 - Google Developer Day Israel - Tel-Aviv - Michael Manoochehri

Nov 14 - Devoxx - Antwerp - Iein Valdez

Nov 16 - Google DevFest Indonesia - Jakarta - Chris Schalk

Nov 19 - Google Developer Day Germany - Berlin - Michael Manoochehri



If these aren't close enough to you, keep an eye out on this list as we'll add new events and locations as they are scheduled. A calendar with all of Google's developer events is also available. We look forward to meeting you soon!



Posted by Wesley Chun (@wescpy), Google cloud Developer Relations team

URL: http://googleappengine.blogspot.com/2011/09/fall-2011-app-engine-events.html

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update


The Dev channel has been updated to 16.0.889.0 for Windows, Mac and Chrome Frame. Due to known bug, Linux isn't updated.
  • Updated V8 - 3.6.4.0
  • FTP: fixed compatibility with servers which send 451 response for CWD command. (Issue 96401)
  • Windows and Mac: Enabled multi-users (multi-profiles) by default.
  • Fixed many known stability issues.
Full details about what changes are in this build are available in the SVN revision log.  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.

Dharani Govindan
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/09/dev-channel-update_22.html

Friday, September 23, 2011

[Gd] Fridaygram: EU Hackathon, electron Pong, sounds from space

| More

The official Google Code blog: Fridaygram: EU Hackathon, electron Pong, sounds from space


By Scott Knaster, Google Code Blog Editor

Hackathons are a blast. There are few experiences better than writing code all night with dozens or hundreds of others, consuming free food, and converting that sweet sleep deprivation into creativity as you hack. As hackathons go, this one is spectacular: Hack4Transparency takes place in Brussels at the European Parliament. The goal of this event is to make data more accessible and intelligible to consumers and to government.


You expect food and WiFi at a hackathon. But this is really cool: if you’re selected to attend, the hackathon pays your travel and accommodation expenses, and a couple of the best hacks will win a prize of €3.000. If that got your attention, read the full story on our Open Source Blog, and then apply to attend.

When I was a wee hacker, I would sometimes break up my coding sessions with a primitive videogame called Pong. Physicists at Cambridge University are still playing this game, sort of, except now they’re knocking a single electron back and forth. As if that Pong ball wasn’t small and easy to miss enough already.

Finally, if you have some time this weekend and you’re not coding or playing video games, you can check out this excellent collection of sounds from spaceflights posted by NASA. You can even make them into ringtones, so if you want to hear a 50-year-old Sputnik beep when your friends call, go for it.

URL: http://googlecode.blogspot.com/2011/09/fridaygram-eu-hackathon-electron-pong.html

Thursday, September 22, 2011

[Gd] Chrome Beta Release

| More

Google Chrome Releases: Chrome Beta Release


The Chrome team is happy to announce the arrival of Chrome 15.0.874.24 to the Beta channel for Windows, Mac, and Chrome Frame and 15.0.874.21 for Linux.

Chrome 15 contains some really great improvements including:
  • A brand new New Tab Page
  • Javascript Fullscreen API is now enabled by default 
  • Chrome Web Store items can now be installed inline by their verified site (more information for developers can be found here.)
  • Omnibox History is now an additional sync data type
More on what's new at the Official Chrome Blog.

You can find full details about the changes that are in Chrome 15 in the SVN revision log. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Karen Grunberg
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/09/chrome-beta-release.html

[Gd] Dev Channel Updates for Chromebooks

| More

Google Chrome Releases: Dev Channel Updates for Chromebooks

The Dev channel has been updated to 15.0.874.23 (Platform version: 1011.30) for Chromebooks(Acer AC700, Samsung Series 5, and Cr-48).

Highlights:
  • Flash updated to 11.0.31.108
  • Updated Netflix plugin to 1.2.6
  • Update GTK+ to 2.20.1 and ATK to 1.29.2
  • Fix several functionality and stability issues
Known issues:
  • 19931 gmail : rendering issue seen on scrolling down long email thread .
  • 19651: On the WebUI user selection screen, the name of the selected user is not spoken
  • 20014: WebUI: Device offline message on X-86 machines even though network connected
If you find new issues, please let us know by visiting our help site or filing a bug. You can also submit feedback using "Report an issue" under the wrench icon. Interested in switching to the Beta channel? Find out how.

Josafat Garcia
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/09/dev-channel-updates-for-chromebooks_21.html

[Gd] Read the Gmail Inbox Feed with .NET and OAuth

| More

Google Apps Developer Blog: Read the Gmail Inbox Feed with .NET and OAuth

Gmail servers support the standard IMAP and POP protocols for email retrieval but sometimes you only need to know whether there are any new messages in your inbox. Using any of the two protocols mentioned above may seem like an overkill in this scenario and that’s why Gmail also exposes a read only feed called Gmail Inbox Feed which you can subscribe to and get the list of unread messages in your inbox.

The Gmail Inbox Feed is easily accessible by pointing your browser to https://mail.google.com/mail/feed/atom and authenticating with your username and password if you are not already logged in.


Using basic authentication to access the inbox feed doesn’t provide a very good user experience if we want delegated access. In that case, we should instead rely on the OAuth authorization standard, which is fully supported by the Gmail Inbox Feed.

OAuth supports two different flows. With 3-legged OAuth, an user can give access to a resource he owns to a third-party application without sharing his credentials. The 2-legged flow, instead, resembles a client-server scenario where the application is granted domain-wide access to a resource.

Let’s write a .NET application that uses 2-legged OAuth to access the Gmail Inbox Feed for a user in the domain and list unread emails. This authorization mechanism also suits Google Apps Marketplace developers who want to add inbox notifications to their applications.

There is no dedicated client library for this task and the Inbox Feed is not based on the Google Data API protocol but we’ll still use the .NET library for Google Data APIs for its OAuth implementation.

Step-by-Step

First, create a new C# project and add a reference to the Google.GData.Client.dll released with the client library. Then add the following using directives to your code:

using System;
using System.Linq;
using System.Net;
using System.Net.Mail;
using System.Xml;
using System.Xml.Linq;
using Google.GData.Client;

The next step is to use 2-legged OAuth to send an authorized GET request to the feed URL. In order to do this, we need our domain’s consumer key and secret and the username of the user account we want to access the inbox feed for.

string CONSUMER_KEY = "mydomain.com";
string CONSUMER_SECRET = "my_consumer_secret";
string TARGET_USER = "test_user";

OAuth2LeggedAuthenticator auth = new OAuth2LeggedAuthenticator("GmailFeedReader", CONSUMER_KEY, CONSUMER_SECRET, TARGET_USER, CONSUMER_KEY);
HttpWebRequest request = auth.CreateHttpWebRequest("GET", new Uri("https://mail.google.com/mail/feed/atom/"));
HttpWebResponse response = request.GetResponse() as HttpWebResponse;

The response is going to be a standard Atom 0.3 feed, i.e. an xml document that we can load into an XDocument using the standard XmlReader class:

XmlReader reader = XmlReader.Create(response.GetResponseStream());
XDocument xdoc = XDocument.Load(reader);
XNamespace xmlns = "http://purl.org/atom/ns#";

All the parsing can be done with a single LINQ to XML instruction, which iterates the entries and instantiates a new MailMessage object for each email, setting its Subject, Body and From properties with the corresponding values in the feed:

var messages = from entry in xdoc.Descendants(xmlns + "entry")
from author in entry.Descendants(xmlns + "author")
select new MailMessage() {
Subject = entry.Element(xmlns + "title").Value,
Body = entry.Element(xmlns + "summary").Value,
From = new MailAddress(
author.Element(xmlns + "email").Value,
author.Element(xmlns + "name").Value)
};

At this point, messages will contain a collection of MailMessage instances that we can process or simply dump to the console as in the following snippet:

Console.WriteLine("Number of messages: " + messages.Count());
foreach (MailMessage entry in messages) {
Console.WriteLine();
Console.WriteLine("Subject: " + entry.Subject);
Console.WriteLine("Summary: " + entry.Body);
Console.WriteLine("Author: " + entry.From);
}

If you have any questions about how to use the Google Data APIs .NET Client Library to access the Gmail Inbox Feed, please post them in the client library discussion group.

Claudio Cherubino   profile | twitter | blog

Claudio is a Developer Programs Engineer working on Google Apps APIs and the Google Apps Marketplace. Prior to Google, he worked as software developer, technology evangelist, community manager, consultant, technical translator and has contributed to many open-source projects, including MySQL, PHP, Wordpress, Songbird and Project Voldemort.

URL: http://googleappsdeveloper.blogspot.com/2011/09/read-gmail-inbox-feed-with-net-and.html

[Gd] Euro Android Developer Labs

| More

Android Developers Blog: Euro Android Developer Labs

This series started last month, and now registration is open for the European leg:

  • Berlin — September 28 and 29.

  • London — October 3 and 5.

  • Paris — TBD (late October), but register now.

Remember, this ADL series isn’t another set of introduction-to-Android sessions, nor any other kind of general overview. It's specifically aimed at optimizing Android apps for tablets, in particular creating high-quality tablet apps with an emphasis on polish and user-experience.

Registration is a two-step process. Anyone can register, but we can only accommodate a relatively small number of attendees from among the registrants, based on whether they already have an Android app with the potential to be a top-tier tablet app in terms of quality, fit, and finish. The goal is to bring your app to the ADL, and leave equipped to make it into one that makes Android tablet users smile.

URL: http://android-developers.blogspot.com/2011/09/euro-android-developer-labs.html

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update


The Dev channel has been updated to 15.0.874.21 for Windows, Mac, Linux, and Chrome Frame.

All
  • Fixed a bug that caused a crash if you tried to use the speech input keystroke (Ctrl+Shift+Period) on a (non-speech-enabled) textarea.
  • Fixed many known stability issues.
Mac
  • Added bubble UI to notify the user when a page requests fullscreen mode.
  • Fixed a bug where pages requesting fullscreen mode on OS X Lion would put the browser into fullscreen mode rather than presentation mode.
Full details about what changes are in this build are available in the SVN revision log.  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.

Dharani Govindan
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/09/dev-channel-update_20.html

[Gd] Beta and Stable Channels Update for Chromebooks

| More

Google Chrome Releases: Beta and Stable Channels Update for Chromebooks

The Beta and Stable channels have been updated to 14.0.835.186 (Platform version 0.14.811.117) for Chromebooks (Acer AC700, Samsung Series 5, and Cr-48).

Release highlights:

  • Pepper flash: update to 10.3.200.107
  • Crash fixes
If you find new issues, please let us know by visiting our help site or filing a bug. You can also submit feedback using "Report an issue" under the wrench icon.

Orit Mazor
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/09/beta-and-stable-channels-update-for.html

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update

The Beta and Stable channels have been updated to 14.0.835.186 for Windows, Mac, Linux, and Chrome Frame.

This release includes an update to Flash Player that addresses a zero-day vulnerability.

If you find a new issue, please let us know by filing a bug.

Anthony Laforge
Google Chrome
URL: http://googlechromereleases.blogspot.com/2011/09/stable-channel-update_20.html

[Gd] g|uae & g|jordan are coming to town

| More

The official Google Code blog: g|uae & g|jordan are coming to town


By Rania Hadi, MENA Outreach Manager

Get your laptops ready – Google is coming to town! We are announcing our back-to-back Google Days in Dubai and Amman in October. Packed with dynamic sessions on all things Google, Googlers will provide developers, webmasters, students, IT and business professionals the chance to see and learn about the latest technologies.

g|uae will take place from Oct 19-20, and g|Jordan from Oct 23-24. Building on previous Google Days in MENA, each day of the 2-day conferences will cater to a different audience. From developers to computer science students, digital advocates to entrepreneurs, women in technology to tech marketers, we will have a wide variety of sessions delivered by a cross section of international Googlers. They’ll be there to interact with you, answer questions, brainstorm ideas, and provide both beginner lectures and hands-on codelabs and workshops.

While we’d love to accommodate as many as possible, space is limited so please register for g|uae and g|jordan as soon as possible. You will then be fully registered as soon as we send you a confirmation. If you still aren’t convinced, check out the fun we’ve had at past events.



Hope to see you at g|uae and g|jordan 2011!


Rania Hadi has been with Google since 2004 and now works on Outreach in MENA. She focuses on building relationships and promoting Google technologies with the developer and tech communities.

Posted by Scott Knaster, Editor


URL: http://googlecode.blogspot.com/2011/09/guae-gjordan-are-coming-to-town.html

[Gd] OpenSocial 2.0 Brings Us Closer to the Socialized Enterprise

| More

OpenSocial API Blog: OpenSocial 2.0 Brings Us Closer to the Socialized Enterprise


Now that the final version of the OpenSocial 2.0 spec has been announced, we at Wrike, asone of the companies leading the charge on social collaboration, are excited about seeingmore enterprises lean into this type of integration. In fact, we’ve just developed our own OS 2.0widget, which will help transform email functionality within Wrike’s collaboration tools. But beforewe tell you more about that, here’s why OpenSocial has our collaborative juices flowing.

Open season for innovation


It’s a safe bet that the typical iPhone user is used to working with direct access to multiple appsthat can help him work and play more effectively. iPhone Marketplace was a bigger sourceof innovation for users than the phone hardware itself. Many enterprise solutions miss that open ecosystem opportunity today. For example, Outlook has millions of users spending their whole working days in front of it, who would love the same type of easy access to useful apps that would enhance their workflow. Yet, how many of those users installed Outlook plug-ins? OpenSocial 2.0 has the potential to open up innovation for enterprise software, bringing the right apps with the right integrations in a safe package, directly in front of users who want to benefit from them.

Bridging gaps between the apps


The improved safety, compatibility and connectivity that the OpenSocial standard offers, makes it a lot easier to build bridges between useful enterprise apps. Bridges that go beyond simple data integrations into the land of fully integrated user experiences. Taking my own company, Wrike, as just one example, we’re based on the belief that project management tools should be inherently social, and this is a fundamental part of our value proposition to companies around the world. So, it’s easy to see why OpenSocial has us excited about ways we can keep improving our users’ experience and their productivity, by plugging into the networks and tools they are already comfortable using.

Potential to turn email into a structured, real-time platform


A couple of days ago, Wrike’s widget appeared in the OpenSocial 2.0 sandbox with examples of embedded experiences in the activity stream, emailbox and a compact dashboard. I’d like to focus a bit more on the email component of the widget and share why we see great potential in it.

Email software has effectively been on “lock-down” since its inception. When you receive dozens of emails on a daily basis, it gets really challenging to turn that type of inbox chaos into the cohesive big picture of your projects and goals. From the start, a key pillar of Wrike’s product vision has always been to open up that software and bring emails into a centralized system, turning long email discussion threads into neat plans. This is why Wrike created its email integration, which allows users to create, assign, schedule and discuss tasks right from their inboxes.

Today, people use email even more than when Wrike was conceived. So, instead of try to push email out of the office toolkit “nest” (which seems like a hard and unproductive thing to do), we wanted to leverage the good things about it. OpenSocial 2.0 gives us new opportunities to implement our exciting idea – to turn 40-year email functionality into a structured, well-organized, real-time platform that supports sharing, discussions and other actions you need for collaboration. Wrike’s widget brings emails to life and integrates them fully into the project management process. Users don’t even need to change anything in their working habits.

In parallel with developing our widget for OpenSocial 2.0, we’ve been working on Wrike’s new add-on for Outlook. For the end user, the experience will be very similar to what they get with our OS widget. However, if we look at it from the development side of things, building this add-on atop Outlook is a more laborious and complicated process, a whole other world. That’s where we see the big difference between open platforms and closed systems – in how easily can you plug into them.

With the potential that OpenSocial 2.0 offers and the ease that you can build widgets on top of it, I believe that the world will quickly become attuned to getting this kind of experience for many more email clients. People still strongly rely on email in their work and they just need a way to naturally bring those messages into their collaboration process. So, it turns out that email isn’tdead as some claim, it just needed a rebirth, And OpenSocial 2.0 is an essential part of that evolution.

What’s next?


The new generation of apps, built on the open platform, will bring a new wave of innovation and productivity. OpenSocial has already gained support from many players in the enterprise software market. I’m sure we can expect new marketplaces and ecosystems, and faster innovation as others follow suit.

Users will of course be the ones to benefit, but it’s a win-win for everyone, as we continually find new ways to improve the way that we work. Your company’s mission should they choose to accept it? To socialize the enterprise.

Andrew Filev
Andrew Filev (@andrewsthoughts)
Andrew Filev is a software entrepreneur with more than 10 years of experience in project and product management. He is the founder and CEO of Wrike, a Silicon Valley-based providerof project management and collaboration software. To learn more about Andrew and his views, you cansubscribe to his Project Management 2.0 blog or follow him on Twitter (@andrewsthoughts).
URL: http://blog.opensocial.org/2011/09/opensocial-20-brings-us-closer-to.html

[Gd] Introducing the Google+ Hangouts API

| More

The official Google Code blog: Introducing the Google+ Hangouts API


By Richard Dunn, Technical Lead, Google+ platform for Hangouts

Cross-posted from the Google+ Platform Blog

In the three months since we launched face-to-face-to-face communication in Google+ Hangouts, I’ve been impressed by the many ways people use them. We’ve seen Hangouts for game shows, fantasy football drafts, guitar lessons and even hangouts for writers to break their solitary confinement. That’s just the beginning. Real-time applications are more engaging, fun, and interactive, but were hard for developers to deliver. Until now.

Today we’re launching the Developer Preview of the Hangouts API, another small piece of the Google+ platform. It enables you to add your own experiences to Hangouts and instantly build real-time applications, just like our first application, the built-in YouTube player.

The integration model is simple -- you build a web app, register it with us, and specify who on your team can load it into their Hangout. Your app behaves like a normal web app, plus it can take part in the real-time conversation with new APIs like synchronization. Now you can create a "shared state" among all instances of your app so that all of your users can be instantly notified of changes made by anyone else. (This is how the YouTube player keeps videos in sync.) And we’ve added our first few multimedia APIs so you can, for example, mute the audio and video feeds of Hangout participants.

When you’re ready to start hacking, we’re ready for you -- read the documentation, sign up, and start coding. We’re anxious to get your feedback, since this is a very early version of the API. We’ll be making improvements and moving towards full production based on what we learn together. And we’ll be releasing new updates on a regular basis, so stay tuned!

Follow the conversation on Google+.

Richard Dunn is Technical Lead, Google+ platform for Hangouts


Posted by Scott Knaster, Editor

URL: http://googlecode.blogspot.com/2011/09/introducing-google-hangouts-api.html

[Gd] Submit Pagemaps directly to Custom Search

| More

Google Custom Search: Submit Pagemaps directly to Custom Search

Custom Search users have long been able to create Richer Snippets by adding Pagemaps to their webpages. Today we’re enabling direct submission of Pagemaps via either Sitemaps or On-Demand Indexing requests. This means you no longer have to modify your pages to expose Pagemaps, or wait for Google to crawl your site to process them. This saves time when you want to make a quick change to your metadata. If you have data you would like to be displayed on your site, such as reviews snippets, you can submit it directly to Google instead of putting it in publicly visible markup on your pages. For added security, you can even choose to add a private key to your Pagemap and we will only serve it in Custom Search results when that key is provided.

We hope you enjoy the added convenience these new submission options offer. Let us know what you think in our discussion forum.

Posted by: Rui Jiang, Software Engineer


URL: http://feedproxy.google.com/~r/blogspot/Syga/~3/iIKmugKirtw/submit-pagemaps-directly-to-custom.html

[Gd] Client Library Updates

| More

AdWords API Blog: Client Library Updates

We have recently made the following changes to the AdWords client libraries.

Ruby

  • Made performance improvements.
  • Added unit spend information to responses.
  • Added support for Proxy servers.

Python

  • Updated common module to version 2.1.0, which may impact your code. See the ChangeLog for more details.
  • Fixed issues 161, 162, 163 in version 14.2.3.
  • Added a tarball in the download section that collects all the required modules for this client library into a single download with an installer script.

You can download updated versions of the AdWords API client libraries from their respective sites, or see a list of all the client libraries.

If you have any questions or would like to discuss these changes, please post on the forum.

, AdWords API Team
URL: http://adwordsapi.blogspot.com/2011/09/client-library-updates.html

[Gd] Pictarine: pictures in the cloud

| More

Google Web Toolkit Blog: Pictarine: pictures in the cloud

Cross posted from the Google App Engine blog.






Pictarine is a photo management web application, launched in 2010, that allows people to easily manage and share all of their photos from Flickr, Picasa, Facebook, Twitter and other sites. Pictarine developers Guillaume Martin and Maxime Rafalimanana have contributed the following post discussing their experiences using Google App Engine and Google Web Toolkit.



From the start, we used Google technologies in developing Pictarine and we wanted to share our experience with them so far. In this post, we will shed some light on the weaknesses and strengths we found in Google Web Toolkit (GWT) and Google App Engine. We will also discuss how we leveraged GWT to build a new technology that allows Pictarine to seamlessly display photos from the computer directly into the browser. The following diagram is an overview of how our application works.







Building a mashup in the cloud with Google App Engine



The Pictarine team is made of a web designer and two developers who previously worked mainly with Java based enterprise technologies and had a little experience with web technologies. When we started the project in early 2009, we were quite open on learning new languages like Python or Ruby, but when App Engine announced that Java would be supported, we were really excited to give Google App Engine a try.



The first few months, learning about the App Engine environment was quite easy and dare I say fun. Testing our code on Google’s servers from Eclipse IDE was only one click away. So we built our first prototype fast and we quickly decided to adopt App Engine. Then we started to build the core of our application: the engine that uses the API from Flickr, Picasa, Facebook to fetch the users’ photos. This is where we hit the first limitations of App Engine. Most users have a lot of photos on these services and retrieving them can take some time. But App Engine has strict limits on how long a request should last: an outgoing HTTP request cannot last more than 10 seconds and cannot process a request for more than 30 seconds. So while building our architecture we found ourselves writing approximately one third of our code dealing with these limitations: paginating our requests, creating background tasks to store data in small batches, etc.



In early 2010, when we launched our alpha version, everything went smoothly. We had some good press coverage and App Engine met our expectations in handling our first users. During 2010, we worked on implementing new features requested by our users, and during this period of time we were really impressed by the way App Engine evolved. Many of the limitations were lifted and great new features were added. We are now able to use Task Queues for requests that last up to 10 minutes, which we fully use to sync our users’ photos and albums. One of the features we like the most is the Channel API, a push notification system that allows us to instantly show a photo in every connected browser as soon as it is uploaded.
App Engine is still not perfect but has greatly improved and when we see its roadmap, we are quite confident it will continue to improve.



Building a fresh photo experience with Google Web Toolkit 



When we started Pictarine, we wanted a fast, distraction free interface that would allow our users to focus on their photos. We wanted the interface to adapt to the screen resolution, displaying a lot of photos on large screens and fewer on small ones. We wanted it to be automatically updated when new comments or new photos are added. We wanted a web application. As we eliminated Flash quite quickly (based on our user experience...) we started to look at tools to build HTML/CSS/Javascript applications. We settled quickly on GWT: while coding in Java, with all the tools we are used to (even the debugger), we could produce optimized Javacript that would run in every browser! When we started with GWT, it was already 3 years old, so we had few complaints about it. The main issue was that we had to always keep in mind that the Java code we produced was ultimately translated to Javascript. So some Java methods, such as the Reflection API, are not allowed. Another thing that was not obvious to us when we started with GWT was that a java developer needs an intimate knowledge of HTML/CSS if he/she wants to go beyond the basic user interface provided by the GWT widgets.



What we really like about GWT in our architecture is the ability to share code between client and server: we can use the same Photo or Album class on the client and the server and the GWT RPC system allows us to automatically share the same Java object on both side. We can also have the same data validation code on both sides: we can alert the user immediately on errors and still validate the data on the server just in case.



Another great feature we like about GWT is its handling of internationalisation. From the beginning we wanted to build a website available for all Internet users, so supporting English as well as our native language (French) was almost obligatory. Fortunately, GWT makes it really easy to generate centralized localization files so that we just have to translate.



Finally, to illustrate how great Javascript generation is, when IE9 came out, we waited a few weeks for GWT to support it and our application was compatible after a recompile! Of course, the IE9 team also did a good job with their HTML5/CSS3 engine.



Building an universal uploader 



After the launch of our alpha in 2010, our users were able to see and share their photos from Flickr, Picasa, Facebook. But they still had to put their photos on these websites first before coming to Pictarine. This limitation quickly became the first request on our feedback system. We needed to let our users do everything from Pictarine, including uploading photos. Uploading many photos from a website is still not a trivial process. Most websites choose Flash to allow users to upload multiple files at once, but our experience with it was that it often crashed after a while. Some use Java applets, but they are never well integrated and always look odd. At Pictarine we decided to tackle this problem by using Java Applet for their stability across all platforms but without using it to render photos or folders.



We have built a technology that uses the GWT RPC mechanism to talk to a Java Applet: photos, upload progression are rendered in HTML/CSS and the applet takes care of photos resizing and uploading. Sharing a photo from a camera is now a one-step process. This technology also allows users to browse their local files directly in their browser and it is fully integrated in our design.



We believe that this new use of Java applets can help blur the line between the Desktop and the Cloud by seamlessly integrating desktop files in any web application.









In conclusion, we can say that we are really happy with the choices we made with App Engine and GWT. App Engine is a great service that perfectly handled the spike in traffic we saw right after articles on Mashable and Lifehacker were published. So we recommend it to every lean startup out there who loves developing in Java, Python or Go.
URL: http://googlewebtoolkit.blogspot.com/2011/09/pictarine-pictures-in-cloud.html

[Gd] Preparing for Handsets

| More

Android Developers Blog: Preparing for Handsets

[This post is by Scott Main, lead tech writer for developer.android.com. — Tim Bray]

Early this year, Honeycomb (Android 3.0) launched for tablets. Although Honeycomb remains tablets-only, the upcoming Ice Cream Sandwich (ICS) release will support big screens, small screens, and everything in between. This is the way Android will stay from now on: the same version runs on all screen sizes.

Some Honeycomb apps assume that they’ll run only on a large screen, and have baked that into their designs. This assumption is currently true, but will become false with the arrival of ICS, because Android apps are forward-compatible — an app developed for Honeycomb is compatible with a device running ICS, which could be a tablet, a phone, or something else.

So, if you’ve developed a tablet app on Honeycomb, it’s important that your app do one of two things: prevent installation on smaller screens or (preferably) support smaller screens with the same APK.

Making your Honeycomb app for tablets only

If you don’t want your app to be used on handsets (perhaps it truly makes sense only on a large screen) or you need more time to update it, add the following <supports-screens> declaration to your manifest:

<manifest ... >
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true"
android:requiresSmallestWidthDp="600" />
<application ... >
...
</application>
</manifest>

This describes your app’s screen-size support in two different ways:

  • It declares that the app does not support the screen size buckets “small”, “normal”, and “large”, which are traditionally not tablets

  • It declares that the app requires a screen size with a minimum usable area that is at least 600dp wide

The first technique is for devices that are running Android 3.1 or older, because those devices declare their size based on generalized screen size buckets. The requiresSmallestWidthDp attribute is for devices running Android 3.2 and newer, which added the capability for apps to specify their size requirements based on a minimum number of density-independent pixels. In this example, the app declares a minimum width requirement of 600dp, which generally implies a 7”-or-greater screen.

Your size choice might be different, of course, based on how well your design works on different screen sizes; for example, if your design works well only on screens that are 9” or larger, you might require a minimum width of 720dp.

The catch is that you must compile your application against Android 3.2 or higher in order to use the requiresSmallestWidthDp attribute. Older versions don’t understand this attribute and will raise a compile-time error. The safest thing to do is develop your app against the platform that matches the API level you’ve set for minSdkVersion. When you’re making final preparations to build your release candidate, change the build target to Android 3.2 and add the requiresSmallestWidthDp attribute. Android versions older than 3.2 simply ignore that XML attribute, so there’s no risk of a runtime failure.

For more information about why the “smallest width” screen size is important for supporting different screen sizes, read New Tools for Managing Screen Sizes (really; it’s got lots of things you need to know).

Making your Honeycomb app work on handsets

On the other hand, if you want to distribute your app to devices of all sizes, we recommend that you update your existing Honeycomb app to work on smaller screens as well, rather than publishing multiple APKs.

Optimizing for handsets can be tricky if your designs currently use all of a large screen to deliver content. It’s worth the effort, though, because Ice Cream Sandwich brings the Honeycomb APIs to handsets and you’ll significantly increase the user-base for your app. Using a single APK for all devices also simplifies your updating and publishing process and makes it easier for users to identify your app.

Here are two guidelines to help make your Honeycomb tablet app work well on handsets:

  • Build your design around Fragments that you can reuse in different combinations, in single-pane layouts on handsets and multi-pane layouts on tablets

  • Be conservative with your Action Bar design so the system can adjust its layout based on the screen size

Creating single-pane and multi-pane layouts

The most effective way to optimize your app for both handsets and tablets is to combine fragments in different ways to create “single-pane” layouts for handsets and “multi-pane” layouts for tablets. There are two approaches to doing this:

  • For any screen in which your tablet version displays multiple fragments, use the same activity for handsets, but show only one fragment at a time — swapping the fragments within the activity when necessary.

  • Use separate activities to host each fragment on a handset. For example, when the tablet UI uses two fragments in an activity, use the same activity for handsets, but supply an alternative layout that includes just one fragment. When you need to switch fragments (such as when the user selects an item), start another activity that hosts the other fragment.

The approach you choose depends on your app design and personal preferences. The first option (single activity) requires that you dynamically add each fragment to the activity at runtime---rather than declare the fragments in your activity’s layout file — because you cannot remove a fragment from an activity if it’s been declared in the XML layout. You might also need to update the action bar each time the fragments change, depending on what actions or navigation modes are provided for the fragment. In some cases, these factors might not matter to your app, so using one activity and swapping fragments will work well. Other times, however, using just one activity and dynamically swapping fragments can make your code more complicated, because you must manage all the fragment combinations in the activity’s code rather than leveraging alternative layout files.

I’m going to talk about the second option in more detail. It might be a little more up-front work, because each fragment must work well across separate activities, but it usually pays off. It means that you can use alternative layout files that define different fragment combinations, keep fragment code modular, simplify action bar management, and let the system handle all the back stack work.

The following figure demonstrates how an application with two fragments can be arranged for both handsets and tablets when using separate activities for the handset design:

In this app, Activity A is the “main activity” and uses different layouts to display either one or two fragments at a time, depending on the size of the screen. When on a handset-sized screen, the layout contains only Fragment A (the list view); when on a tablet-sized screen, the layout contains both Fragment A and Fragment B.

Here’s res/layout/main.xml for handsets:

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent">
<fragment class="com.example.android.TitlesFragment"
android:id="@+id/list_frag"
android:layout_width="match_parent"
android:layout_height="match_parent"/>
</FrameLayout>

And res/layout-large/main.xml for tablets:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="horizontal"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:id="@+id/frags">
<fragment class="com.example.android.TitlesFragment"
android:id="@+id/list_frag"
android:layout_width="@dimen/titles_size"
android:layout_height="match_parent"/>
<fragment class="com.example.android.DetailsFragment"
android:id="@+id/details_frag"
android:layout_width="match_parent"
android:layout_height="match_parent" />
</LinearLayout>

How the application responds when a user selects an item from the list depends on whether Fragment B is available in the layout. If Fragment B is there, Activity A notifies Fragment B to update itself. If Fragment B is not in the layout, Activity A starts Activity B (which hosts Fragment B).

To implement this pattern for your application, it's important that you develop your fragments to be highly compartmentalized. Specifically, you should follow two general guidelines:

  • Do not manipulate one fragment directly from another.

  • Keep all code that concerns content in a fragment inside that fragment, rather than putting it in the host activity’s code.

To avoid directly calling one fragment from another, declare a callback interface in each fragment class that it can use to deliver events to its host activity, which implements the callback interface. When the activity receives a callback due to an event (such as the user selecting a list item), it acts appropriately based on the current fragment configuration.

For example, Activity A from above handles item selections like this:

/** This is a callback that the list fragment (Fragment A) calls
when a list item is selected */
public void onItemSelected(int position) {
DisplayFragment fragB = (DisplayFragment) getFragmentManager()
.findFragmentById(R.id.display_frag);
if (fragB == null) {
// DisplayFragment (Fragment B) is not in the layout,
// start DisplayActivity (Activity B)
// and pass it the info about the selected item
Intent intent = new Intent(this, DisplayActivity.class);
intent.putExtra("position", position);
startActivity(intent);
} else {
// DisplayFragment (Fragment B) is in the layout, tell it to update
fragB.updateContent(position);
}
}

When DisplayActivity (Activity B) starts, it reads the data delivered by the Intent and passes it to the DisplayFragment (Fragment B).

If Fragment B needs to deliver a result back to Fragment A, then the process works similarly with a callback interface between Fragment B and Activity B. That is, Activity B implements a callback interface defined by Fragment B. When Activity B gets the callback, it sets the result for the activity and finishes itself. Activity A then receives the result and delivers it to Fragment A.

For a complete demonstration of this technique for creating different fragment combinations for different tablets and handsets, look at the code for this updated version of the Honeycomb Gallery sample (ZIP file).

Making the Action Bar work on handsets

As long as you’ve been using the framework’s implementation of ActionBar for your tablet app (rather than building your own), the conversion from tablets to handsets should be painless. The Android system will do the work for you; all you need to do is ensure that your action bar design is flexible. Here are some important tips:

  • When setting a menu item to be an action item, avoid using the “always” value. Use “ifRoom” for action items you’d like to add to the action bar. Now, you might need “always” when an action view does not have an alternative action for the overflow menu or when a menu item added by a fragment is low in the menu order and it must jump into the action bar at all times. But you should not use “always” more than once or twice.

  • When possible, provide icons for all action items and declare showAsAction="ifRoom|withText". This way, if there’s not enough room for the text, but there is enough for the icon, then just the icon may be used.

  • Avoid using custom navigation modes in the action bar. Use the built-in tab and drop-down navigation modes — they’re designed to be flexible and adapt to different screen sizes. For example, when the width is too narrow for both tabs and other action items, the tabs appear below the action bar. If your app requires a custom navigation mode in the action bar, thoroughly test it on smaller screens when Ice Cream Sandwich becomes available and make any adjustments necessary for a narrow action bar.

For example, the mock ups below demonstrates how the system might adapt an app’s action bar based on the available screen space. On the handset, only two action items fit, so the remaining menu items appear in the traditional menu and the tabs appear in a separate row. On the tablet, more action items can fit in the action bar and so do the tabs.

Some other tips

  • When working with a ListView, consider how you might provide more or less information in each list item based on the available space. That is, you can create alternative layouts to be used by the items in your list adapter such that a large screen might display more detail for each item.

  • Create alternative resource files for values such as integers, dimensions, and even booleans. Using size qualifiers for these resources, you can easily apply different layout sizes, font sizes, or enable/disable features based on the current screen size.

Testing your handset support

At this point you might be wondering, “How do I test my layout for smaller screens without a handset that runs Honeycomb?” Well, until Ice Cream Sandwich is available for the SDK, you technically can’t. So don’t publish your changes until you’re able to test on a device or emulator running ICS.

However, you can begin some early testing of your alternative layouts with a little trick: instead of using the “large” configuration qualifier for the tablet layouts, use the “land” qualifier (that is, instead of res/layout-large/main.xml, use res/layout-land/main.xml). This way, a Honeycomb tablet (or emulator) in landscape orientation uses your tablet design and the same device in portrait orientation uses your handset design. Just be certain to switch back to using the size qualifiers once you’re able to test on ICS.

Conclusion

Ice Cream Sandwich is coming, and with it, handsets will be able to install apps built on Honeycomb. We haven’t released the ICS SDK just yet, but you can start preparing your Honeycomb apps by thinking about how they should work on smaller screens.

So if you have a Honeycomb tablet app out there (and by that, I mean an app with minSdkVersion="11" or higher), you should make sure it’s available only on large screen devices for now. We hope that you’ll then follow our advice here and optimize your tablet app to support smaller screens, using the same APK for both tablets and handsets.

If your app supports API levels lower than 11, then there’s probably nothing you need to do right now, because your app is already running on handset devices. When the ICS SDK does arrive, though, it’ll still be important that you verify your app’s performance on the new platform.

Stay tuned to the blog for more information about ICS as it nears release.

URL: http://android-developers.blogspot.com/2011/09/preparing-for-handsets.html