Google Environment: Integrated Mobile Apps

 

The Google Apps Marketplace is a storefront for Google Apps customers to discover, purchase, deploy and manage web applications which are integrated with Google Apps. These applications are typically used from desktops and laptops, but many vendors on the Apps Marketplace have also optimized the experience for their users who are on-the-go. There are several different strategies for enabling a mobile workforce, and each requires a different approach to authentication and authorization.

Lightweight: Synchronize Contacts, Calendars and Docs with Google Apps

Google has written applications and synchronization clients to help ensure that the core Google Apps data is available to users on their mobile devices, whether they’re on their mobile phones or tablets. By storing contacts, dates and documents from your application in Google Apps using the application APIs, you can leverage these features to provide a mobile view for your users.

Since you’re only accessing the application APIs on your web application’s server, and the user has already linked up their mobile device to their Google account, there are no special techniques for authentication and authorization when using this lightweight approach.

Standards-based: Build a mobile-optimized web application

With the latest advances in HTML5 web technologies such as offline and local storage, it’s possible to build mobile interfaces for business apps which are full-featured and accessible to users on many devices. The primary goal in building the mobile web application is to optimize the user experience for different input devices, form factors and limitations in network availability and bandwidth.

Because the application is in a web browser, most of the changes to implement are in the frontend– HTML, JavaScript and CSS. User authentication and data authorization continue to use the same OpenID and OAuth technologies as are used for the desktop/laptop version of the application.

Device-custom: Build native companion apps for mobile devices

Does your application need access to hardware-specific APIs which are not available in a web browser, or do you feel a great user experience can only be achieved using native code? Several Apps Marketplace vendors have built native applications for popular mobile platforms like Android and iOS. Although it takes considerably more effort to build multiple native applications to cover the major platforms, these vendors can also take advantage of the additional distribution channels offered by mobile stores.

Authentication and authorization are often challenging for developers building native mobile applications because they cannot simply ask users for a password if their app supports single-sign on to Google with OpenID. We recently published an article describing a technique using an embedded webview for accomplishing OpenID authentication in mobile apps. This article includes references to sample code for Android and iOS.

Many Project Management applications, like Manymoon, store important dates on Google Calendar. These dates are then available on mobile devices.

GQueues has a HTML5 mobile app. Their founder has written about why they used this technique.

Native applications, such as the OpenID Sample Store displayed, can use an embedded webview to authenticate users.

GoogleCodeNews

Share|

High resolution in Static Google Maps API

The Static Maps API is a great service for when you need to quickly generate a static, lightweight map. Following the updates to the Maps API/Earth API Terms of Service earlier this year, mobile application developers are now free to use the Static Maps API in native mobile apps, providing the map links to the Google Maps app or website for the same location. However the high pixel density of some mobile screens can make the labels and icons on such a static map unreadably small.

For this reason, we’re introducing a new feature of the Static Maps API that smoothly doubles the size of the whole image including labels, icons, and overlays, to suit high resolution screens. To apply this upscaling to an existing Static Maps API image, simply append &scale=2 to the URL.

The image returned will contain the same level of detail, but be twice as wide and tall without the stepping or blurring that results from upscaling an existing image:

scale=1
(default)		 scale=2

Note that when using the scale parameter the pixel size of the returned image is the product of the size and scale values given in the URL. The size parameter therefore now specifies the size of the required image in Density-independent pixels or Points, as they are known in the Android SDK and iOS SDK respectively.

Web based apps can also benefit from higher resolution Static Maps by adding a scale=2 image to the page with a CSS width and height that matches the size parameter. By default, the browser on many mobile devices upscales images in web pages by a device specific factor based on the pixel density of the screen. However these devices will preserve additional detail in the image if the image pixel : CSS pixel ratio matches or exceeds the scaling factor, which can be found by querying window.devicePixelRatio in JavaScript.

For example, below are the above two maps side-by-side with the same CSS size. On a desktop screen with a window.devicePixelRatio of 1.0 these will look almost indistinguishable. However open this blog post on a device with a high resolution screen, such as a Samsung Nexus S or Apple iPhone 4, and the image on the right will look significantly sharper.

scale=1 scale=2

As an added benefit, Maps API Premier developers can also request maps with a scale factor of 4. Although this exceeds the maximum window.devicePixelRatio of current mobile devices it does facilitate generating maps for printing at high quality:

scale=4

Note however that the largest image pixel size that the Static Maps API can generate for Premier customers, regardless of the value of the scale parameter, is 2048×2048. Consequently at scale=4 the largest available value for the size parameter is 512×512. Note also that any use of the Static Maps API for generating maps to print must comply with the Permission Guidelines for Google Maps and Earth, which apply equally to Maps API Premier customers.

For more information on the scale parameter, and the other great Static Maps features, check out the Static Maps API documentation. We hope this feature helps your apps enjoy the full benefit of the high resolution screens that are increasingly popular, and makes them just that little bit easier on the eye!

Share|

Modular plug-in for customizable infobox control

As many of you know, the Bing Maps Locator Wizard is a portal that allows you to generate a Bing Maps Locator in minutes, and then have it hosted in Windows Azure for free. One of the steps in the wizard allows you to customize the style of various elements of the locator.
I was recently working on the wizard and required a highly customizable infobox control that would likely be put in an iframe. This article highlights some of the key features of the modular plug-in we created to allow for this requirement. The result far exceeded our expectations and InKnowledge has since released the code to the Bing Maps community so you can use it in your own applications. Feel free to download the complete source code, with sample implementations and documentation.


Modular Design The Bing Maps 7.0 Control was released last fall and is a complete rebuild from the ground up when compared to previous versions of Bing Maps. We have seen huge improvements in API performance and the size of the control. One feature of the map control was to use a modular framework; this allows you to register and load modules as they are needed. One result of this is faster loading speeds. Those interested in creating your own reusable modular plug-ins for Bing Maps should have a look at the documentation.
Custom Infoboxes When the 7.0 Control was originally released there were no infoboxes. The infobox control that Microsoft soon added was a bit different from past versions and was designed to be more flexible. While this is a great improvement, there are a couple of caveats to using this infobox control. The first is that the infobox always points up and to the right and does not reposition itself. This means that infoboxes that are anchored near the top are displayed outside of the map. This can be an issue if the map is being put in an iframe or the map is placed at the end of a webpage. The second caveat is that using custom HTML requires you to also generate the infobox arrow and content area, in addition to the content you want to display. Ideally we would be able to put custom HTML into the frame of the built-in infobox.
Positioning Our goal was to have the content positioned in the center of the map to ensure users can see the infobox. The solution: break the map into quadrants and modify the layout of the infobox such that the content is positioned in the middle of the map. For example, if the anchor point of an infobox is in the lower-left part of the map we want the infobox to be positioned to the right of the anchor point and pushed up. The easiest way to figure out what quadrant the anchor is located in is to convert the anchor coordinate to a pixel coordinate relative to the upper-left corner of the map. To determine if the anchor is to the left or right of the center of the map, simply check to see if the x-pixel coordinate is more or less than half the width of the map. Similar logic can be used to figure out if the anchor is above or below the middle of the map. Once we know if it is left or right of the center and above or below the center, we simply need to place the infobox so that it is in the opposite direction.
The Infobox Arrow One common issue that developers run into when trying to create customizable infoboxes is with the infobox arrow. In the past, these were almost always images that required edits if you wanted to change something as simple as the color. After a lot of research and experimenting, I found an ingenious solution: CSS borders. Years ago, when the web was young, webpages used to use really big borders to make things look like they were in a frame. As time went on the borders got smaller and smaller to the point where they are either not used or only 1 or 2 pixels wide. So where am I going with this? Well, if you look at a picture frame you might notice that the sides of the frame are connected in the corner at a 45-degree angle. This angle also occurs with CSS borders. If we take this and use a bit of fancy styling, we can modify the color and width of four edges of the border CSS class and generate an arrow. Not only can we generate an arrow, but with a little bit of logic and CSS styling, we can control the width, length. and color of the arrow. Check out this good article on creating angled shapes using the border style.
Additional Features The API for this custom infobox control is pretty basic. There are only four public methods that are exposed: hide, show, getOptions, and setOptions. The show method is pretty straightforward; it takes in a coordinate and content (either text or HTML). The content will be placed inside the infobox frame, rather than replacing it. By making the input generic we are able to use this infobox with pushpins, polylines, polygons, or on its own. As for options, not only can you set the dimensions and color of the arrow, you can also:
•    Set the background color of the content area of the infobox.
•    Set the color of the border on the infobox.
•    Specify minimum width and height for the content area.
•    Specify an offset distance from the anchor point.
•    Hide the arrow.
•    Hide the default close button.
•    Tether the infobox. The tether option allows one of two user experiences. When enabled the infobox will stay open and reposition itself as you move the map around until you close it. When disabled, the infobox will close when the map moves.
Implementing the Plug-in Implementing the custom infobox is easy. The first thing you must do is register the plug-in with the map control. You can do this using code similar to the following:
var map, customInfobox;
function GetMap() {
map = new Microsoft.Maps.Map(document.getElementById(“myMap”), { credentials: “Your_Bing_Maps_Key” });
//Register and load the Custom Infobox Module
Microsoft.Maps.registerModule(“CustomInfoboxModule”, “scripts/V7CustomInfobox.min.js”);
Microsoft.Maps.loadModule(“CustomInfoboxModule”, { callback: function () {
//Create an instance of the custom infobox control
customInfobox = new CustomInfobox(map);
}
});
}
To display an infobox, specify a coordinate and some content like the following:
customInfobox.show(map.getCenter(), “<b>Hello World</b>”);
We hope you find the plug-in helpful.
Share|

Bing Maps v7: The OnScriptLoad parameter

One positive thing that seems to have come out of the confusion regarding the recent Bing Maps v7 AJAX update has just been mentioned in a forum post by Chris Pendleton, in which he suggests a possible resolution to the lazy-loading errors (“xxx is undefined” / “yyy is not a Constructor function” etc.) is to make use of the OnScriptLoad parameter.

This parameter, which had been present throughout the v6.x versions of Bing Maps, was conspicuous by its absence in v7 and, despite several comments regarding its whereabouts, did not appear anywhere in the documentation for the v7 API. Based on Chris’ comments, it appears that this parameter has in fact always been present in v7, but accidentally omitted from the documentation. So, until that gets corrected, you can refer to the v6.3 documentation, taken from here: http://msdn.microsoft.com/en-us/library/cc980837.aspx

“onScriptLoad is a string parameter that specifies the name of a JavaScript function to call when the map control script is loaded. The name must contain only alphanumeric characters. The CSS and tiles will not be loaded when this function is called. (This parameter is useful for loading the map control script from an UpdatePanel in ASP.NET Ajax. Users can call Sys.Application.notifyScriptLoaded from their callback to tell ASP.NET Ajax the script has loaded.)”

Not only does this parameter provide an apparent workaround for some of the issues currently being experienced with the v7 control, but it also provides a useful method for any other functions in the future that you want to execute only after you are certain that the library has been loaded (note that this is not the same as when the map has been loaded into the page). To take the example from my last post, you can therefore safely create an instance of the Microsoft.Maps.Location class by calling the tryCreateLocation function from onScriptLoad callback, as follows:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
  <title>Bing Maps v7 Initialisation Bugs</title>
  <script src="http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=7.0&amp;onscriptload=tryCreateLocation" type="text/javascript"></script>
  <script type="text/javascript">
    function tryCreateLocation() {
      try {
        var MyLocation = new Microsoft.Maps.Location(51, -0.15);
        alert(MyLocation);
      }
      catch (e) {
        alert(e);
      }
    }
  </script>
</head>
<body></body>
</html>
Share|

Google I/O winners

It seems like only yesterday that we announced our Last Call for Google I/O contest. We’ve been keeping busy, judging Round 2 submissions for all 10 of our challenges. The winners have been notified via email and will receive a pass to this year’s sold-out Google I/O. Also, all of the Round 1 answers, as well as Round 2 prompts have been posted to the contest site.

We were really impressed with the quality of the submissions–especially with less than 24 hours to turn the code around! Check out screenshots of some of the winning entries below, along with notes from members of each Google Developer Relations group, and stay tuned for more surprises from the I/O team.

Android

Judging was easy for the Android challenge, because our first run through the apps produced a total of exactly 10 places where the reviewer said “Nice!”. Above you see a screenshot of the “Party mode” in Charles Vaughn’s “Bounce Clock”. Read about the details on our Android Developers Blog.

- Tim Bray, Android Developer Advocate

Chrome

(Click a doodle to go to its site and interact.)

We received a lot of nifty doodles and it was tough to pick only ten winners. Some of the particularly fun doodles were interactive or involved a game of some sort (like Pong, or Simon with the Chrome logo). We definitely appreciated being able to view the source code of the web page to see how developers took advantage of the latest HTML, CSS, and JS technologies.

- Jeffrey Chang, Chrome Product Manager

Games

(Click a screen shot to play a game.)

Congratulations to everyone who knew the Konami code and somehow managed to recall that Kuribo’s Shoe is only found on one stage of World Five in Super Mario Bros. 3…and after remembering all that, were still able to write a game in only 24 hours. Apparently playing video games as a kid doesn’t rot your brain as much as our moms said it would.

Almost all of our submissions were fun, technically impressive, or both. The judges were video game industry veterans, so we weren’t wowed by flashy graphics alone. We tried to reward a balance of fun gameplay and technical prowess. Some of the games were actually pretty addictive!

- Ian Lewis, Games Developer Advocate

YouTube

We saw some great submissions that put the new iframe Player API through its paces! The winning submissions offered a mix of cross-browser compatibility, stylish user interface, and the ability to reuse the player for arbitrary sequences anywhere on the web.

- Jeffrey Posnick, YouTube Developer Advocate

Apps

Our Google Apps challenge was built around Google Apps Script, a JavaScript cloud scripting language that allows developers to automate tasks across Google products and interact with 3rd-party APIs. In round 1, we asked contestants to find the median stock price of stock symbols. Round 2 was a fairly open challenge, and the winning submissions performed tasks such as predicting future traffic accidents on Google Maps, producing a daily meeting agenda using Google Calendar and LinkedIn, and sharing Flickr pictures via e-mail to friends and family.

- Ryan Boyd, Google Apps Developer Advocate

Accessibility

We enjoyed seeing how much the ten top entries were able to achieve in such a short time in developing a caption rating app for YouTube (at least one dedicated tweeter pulled an all-nighter). Our top picks really impressed us with the accessibility and polish of their UI. All of them have TalkBack speech support through the Android Accessibility API. Most of the winners have already published and open sourced their work. If these apps inspire you, take a look at the source and contribute!

- Naomi Black, Accessibility Technical Program Manager

Commerce

They say that great minds think alike, and in the case of Google Commerce, our developers created similar mashups. A simple store based on Google Product Search and Google Checkout could be a powerful tool for mom and pop shops. We hope our developers had fun learning about the commerce products that Google offers.

- Ossama Alami, Commerce/Geo Developer Relations

Geo

We asked developers to create a mobile web application to discover interesting walks around San Francisco. We had some really impressive entries, especially given they were developed in a very short timeframe.

- Ossama Alami, Commerce/Geo Developer Relations

Google Web Toolkit (GWT)

We were very impressed with the creativity and performance of the I/O countdown entries. All of the submissions were great examples of what is possible with GWT and HTML5/CSS3. It was an extremely tight competition that came down to tough decisions based on originality, visual appeal, and the size of the resulting JavaScript.

- Chris Ramsdale, GWT/Developer Tools Program Engineer

App Engine

Developers submitted a simple Fibonacci web app in Round 1, where the key was to demonstrate that you correctly handled bad input. We were amazed at the apps that were submitted for Round 2, where we asked developers to create an interesting app using one or more of several App Engine APIs. From making book recommendations to visualizing author impact on PubMed (a favorite of mine, my wife being an academic in medicine), we found many apps useful, well designed, and often quite elaborate.

- Patrick Chanezon, App Engine Developer Relations

Congratulations from the entire Google I/O team to the winners of all the challenges. The bar was quite high and even if you didn’t win, we hope you learned something while building your applications. We encourage you to hone your skills for challenges to come!

Share|