Cast Remote Display API Processing

Posted by Leon Nicholls, Developer Programs Engineer

Remote Display on Google Cast allows your app to display both on your mobile and Cast device at the same time. Processing is a programming language that allows artists and hobbyists to create advanced graphics and interactive exhibitions. By putting these two things together we were able to quickly create stunning visual art and display it on the big screen just by bringing our phone to the party or gallery. This article describes how we added support for the Google Cast Remote Display APIs to Processing for Android and how you can too.

An example app from the popular Processing toxiclibs library on Cast. Download the code and run it on your own Chromecast!

A little background

Processing has its own IDE and has many contributed libraries that hide the technical details of various input, output and rendering technologies. Users of Processing with just basic programming skills can create complicated graphical scenes and visualizations.

To write a program in the Processing IDE you create a “sketch” which involves adding code to life-cycle callbacks that initialize and draw the scene. You can run the sketch as a Java program on your desktop. You can also enable support for Processing for Android and then run the same sketch as an app on your Android mobile device. It also supports touch events and sensor data to interact with the generated apps.

Instead of just viewing the graphics on the small screen of the Android device, we can do better by projecting the graphics on a TV screen. Google Cast Remote Display APIs makes it easy to bring graphically intensive apps to Google Cast receivers by using the GPUs, CPUs and sensors available on the mobile devices you already have.

How we did it

Adding support for Remote Display involved modifying the Processing for Android Mode source code. To compile the Android Mode you first need to compile the source code of the Processing IDE. We started with the source code of the current stable release version 2.2.1 of the Processing IDE and compiled it using its Ant build script (detailed instructions are included along with the code download). We then downloaded the Android SDK and source code for the Android Mode 0232. After some minor changes to its build config to support the latest Android SDK version, we used Ant to build the Android Mode zip file. The zip file was unzipped into the Processing IDE modes directory.

We then used the IDE to open one of the Processing example sketches and exported it as an Android project. In the generated project we replaced the processing-core.jar library with the source code for Android Mode. We also added a Gradle build config to the project and then imported the project into Android Studio.

The main Activity for a Processing app is a descendent of the Android Mode PApplet class. The PApplet class uses a GLSurfaceView for rendering 2D and 3D graphics. We needed to change the code to use that same GLSurfaceView for the Remote Display API.

It is a requirement in the Google Cast Design Checklist for the Cast button to be visible on all screens. We changed PApplet to be an ActionBarActivity so that we can show the Cast button in the action bar. The Cast button was added by using a MediaRouteActionProvider. To only list Google Cast devices that support Remote Display, we used a MediaRouteSelector with an App ID we obtained from the Google Cast SDK Developer Console for a Remote Display Receiver.

Next, we created a class called PresentationService that extends CastRemoteDisplayLocalService. The service allows the app to keep the remote display running even when it goes into the background. The service requires a CastPresentation instance for displaying its content. The CastPresentation instance uses the GLSurfaceView from the PApplet class for its content view. However, setting the CastPresentation content view requires some changes to PApplet so that the GLSurfaceView isn’t initialized in its onCreate, but waits until the service onRemoteDisplaySessionStarted callback is invoked.

When the user selects a Cast device in the Cast button menu and the MediaRouter onRouteSelected event is called, the service is started with CastRemoteDisplayLocalService.startService. When the user disconnects from a Cast device using the Cast button, MediaRouter onRouteUnselected event is called and the service is stopped by using CastRemoteDisplayLocalService.stopService.

For the mobile display, we display an image bitmap and forward the PApplet touch events to the existing surfaceTouchEvent method. When you run the Android app, you can use touch gestures on the display of the mobile device to control the interaction on the TV. Take a look at this video of some of the Processing apps running on a Chromecast.

Most of the new code is contained in the PresentationService and RemoteDisplayHelper classes. Your mobile device needs to have at least Android KitKat and Google Play services version 7.5.71.

You can too

Now you can try the Remote Display APIs in your Processing apps. Instead of changing the generated code every time you export your Android Mode project, we recommend that you use our project as a base and simply copy your generated Android code and libraries to our project. Then simply modify the project build file and update the manifest to start the app with your sketch’s main Activity.

To see a more detailed description on how to use the Remote Display APIs, read our developer documentation. We are eager to see what Processing artists can do with this code in their projects.

Read More..

Retiring the Email Migration API

Posted by Wesley Chun, Developer Advocate, Google Apps

Last summer, we launched the new Gmail API, giving developers more flexible, powerful, and higher-level access to programmatic email management, not to mention improved performance. Since then, it has been expanded to replace the Google Apps Admin SDKs Email Migration API (EMAPI v2). Going forward, we recommend developers integrate with the Gmail API.

EMAPI v2 will be turned down on November 1, 2015, so you should switch to the Gmail API soon. To aid you with this effort, weve put together a developer’s guide to help you migrate from EMAPI v2 to the Gmail API. Before you do that, here’s your final reminder to not forget about these deprecations including EMAPI v1, which are coming even sooner (April 20, 2015).

Read More..

Quota for Calendar API v3 now 10 times higher

Posted by Lucia Fedorova, Tech Lead, Google Calendar API

At Google we like to make 10x rather than 10% improvements. In this spirit, we are increasing the default quota for the Calendar API v3 by a factor of ten, to 1 million requests per day. That means your application can support ten times as many users without any need to apply for more quota.

And if you need even more free quota, you can apply for it in the developer console under APIs -> Calendar API -> Quota -> “Apply for higher quota.” We have also streamlined the process of quota handling to make sure you receive your quota as quickly as possible.

A few tips to work efficiently with your quota:

• Use push notifications instead of polling.
• If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).
• Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.
• Increase page size to retrieve more data at once by using the maxResults parameter.
• Update events when they change, avoid re-creating all the events on every sync.
• Use exponential backoff for error retries.

Read More..

The Realtime API In memory mode debug tools and more

Posted by Cheryl Simon Retzlaff, Software Engineer on the Realtime API team

Originally posted to the Google Apps Developer blog

Real-time collaboration is a powerful feature for getting work done inside Google docs. We extended that functionality with the Realtime API to enable you to create Google-docs style collaborative applications with minimal effort.

Integration of the API becomes even easier with a new in memory mode, which allows you to manipulate a Realtime document using the standard API without being connected to our servers. No user login or authorization is required. This is great for building applications where Google login is optional, writing tests for your app, or experimenting with the API before configuring auth.

The Realtime debug console lets you view, edit and debug a Realtime model. To launch the debugger, simply execute gapi.drive.realtime.debug(); in the JavaScript console in Chrome.

Finally, we have refreshed the developer guides to make it easier for you to learn about the API as a new or advanced user. Check them out at https://developers.google.com/drive/realtime.

For details on these and other recent features, see the release note.

Read More..

Lookup manufacturer info by MAC address using www macvendorlookup com API

Last post show how to "Retrieve IP and MAC addresses of Android WiFi tethering clients from /proc/net/arp". This example show how to get vendor/manufacturer info of the associated MAC addresses.

(You can download runnable APK from link on bottom)

http://www.macvendorlookup.com/api provide API to lookup MAC Address Vendor/Manufacturer info.

Notice that this example havent handle error condition.


MainActivity.java

package com.blogspot.android_er.androidlistclient;

import android.os.AsyncTask;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.view.View;
import android.widget.AdapterView;
import android.widget.ArrayAdapter;
import android.widget.Button;
import android.widget.ListView;
import android.widget.TextView;
import android.widget.Toast;

import org.json.JSONArray;
import org.json.JSONException;
import org.json.JSONObject;

import java.io.BufferedReader;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;
import java.util.ArrayList;

public class MainActivity extends AppCompatActivity {

 Button btnRead;
 TextView textResult;

 ListView listViewNode;
 ArrayList<Node> listNote;
 ArrayAdapter<Node> adapter;

 @Override
 protected void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 setContentView(R.layout.activity_main);
 btnRead = (Button)findViewById(R.id.readclient);
 textResult = (TextView)findViewById(R.id.result);

 listViewNode = (ListView)findViewById(R.id.nodelist);
 listNote = new ArrayList<>();
 ArrayAdapter<Node> adapter =
 new ArrayAdapter<Node>(
 MainActivity.this,
 android.R.layout.simple_list_item_1,
 listNote);
 listViewNode.setAdapter(adapter);

 listViewNode.setOnItemClickListener(new AdapterView.OnItemClickListener() {
 @Override
 public void onItemClick(AdapterView<?> parent, View view, int position, long id) {
 Node node = (Node) parent.getAdapter().getItem(position);
 Toast.makeText(MainActivity.this,
 "MAC: " + node.mac + " " +
 "IP: " + node.ip + " " +
 "company: " + node.company + " " +
 "country: " + node.country + " " +
 "addressL1: " + node.addressL1 + " " +
 "addressL2: " + node.addressL2 + " " +
 "addressL3: " + node.addressL3 + " " +
 "type: " + node.type + " " +
 "startHex: " + node.startHex + " " +
 "endHex: " + node.endHex + " " +
 "startDec: " + node.startDec + " " +
 "endDec: " + node.endDec,
 Toast.LENGTH_SHORT).show();
 }
 });

 btnRead.setOnClickListener(new View.OnClickListener() {
 @Override
 public void onClick(View v) {
 new TaskReadAddresses(listNote, listViewNode).execute();
 }
 });
 }



 class Node {
 String ip;
 String mac;

 String jsonBody;
 String startHex;
 String endHex;
 String startDec;
 String endDec;
 String company;
 String addressL1;
 String addressL2;
 String addressL3;
 String country;
 String type;

 String remark;

 String queryString = "http://www.macvendorlookup.com/api/v2/";

 Node(String ip, String mac){
 this.ip = ip;
 this.mac = mac;
 queryMacVendorLookup();
 }

 @Override
 public String toString() {
 return "IP: " + ip + " " + "MAC: " + mac + " " + company + " " + remark;
 }

 private String sendQuery(String qMac) throws IOException{
 String result = "";

 URL searchURL = new URL(queryString + qMac);

 HttpURLConnection httpURLConnection = (HttpURLConnection) searchURL.openConnection();

 if(httpURLConnection.getResponseCode() == HttpURLConnection.HTTP_OK){
 InputStreamReader inputStreamReader = new InputStreamReader(httpURLConnection.getInputStream());
 BufferedReader bufferedReader = new BufferedReader(
 inputStreamReader,
 8192);

 String line = null;
 while((line = bufferedReader.readLine()) != null){
 result += line;
 }

 bufferedReader.close();
 }

 return result;
 }


 private void ParseResult(String json){

 try {
 JSONArray jsonArray = new JSONArray(json);
 JSONObject jsonObject = (JSONObject) jsonArray.get(0);
 startHex = jsonObject.getString("startHex");
 endHex = jsonObject.getString("endHex");
 startDec = jsonObject.getString("startDec");
 endDec = jsonObject.getString("endDec");
 company = jsonObject.getString("company");
 addressL1 = jsonObject.getString("addressL1");
 addressL2 = jsonObject.getString("addressL2");
 addressL3 = jsonObject.getString("addressL3");
 country = jsonObject.getString("country");
 type = jsonObject.getString("type");
 remark = "OK";

 } catch (JSONException e) {
 e.printStackTrace();
 remark = e.getMessage();
 }

 }

 private void queryMacVendorLookup(){
 try {
 jsonBody = sendQuery(mac);
 ParseResult(jsonBody);
 } catch (IOException e) {
 e.printStackTrace();
 }
 }
 }

 private class TaskReadAddresses extends AsyncTask<Void, Node, Void> {

 ArrayList<Node> array;
 ListView listView;

 TaskReadAddresses(ArrayList<Node> array, ListView v){
 listView = v;
 this.array = array;
 array.clear();
 textResult.setText("querying...");
 }

 @Override
 protected Void doInBackground(Void... params) {
 readAddresses();

 return null;
 }

 @Override
 protected void onPostExecute(Void aVoid) {
 textResult.setText("Done");
 }

 @Override
 protected void onProgressUpdate(Node... values) {
 listNote.add(values[0]);
 ((ArrayAdapter)(listView.getAdapter())).notifyDataSetChanged();

 }

 private void readAddresses() {

 BufferedReader bufferedReader = null;

 try {
 bufferedReader = new BufferedReader(new FileReader("/proc/net/arp"));

 String line;
 while ((line = bufferedReader.readLine()) != null) {
 String[] splitted = line.split(" +");
 if (splitted != null && splitted.length >= 4) {
 String ip = splitted[0];
 String mac = splitted[3];
 if (mac.matches("..:..:..:..:..:..")) {
 Node thisNode = new Node(ip, mac);
 publishProgress(thisNode);
 }
 }
 }

 } catch (FileNotFoundException e) {
 e.printStackTrace();
 } catch (IOException e) {
 e.printStackTrace();
 } finally{
 try {
 bufferedReader.close();
 } catch (IOException e) {
 e.printStackTrace();
 }
 }
 }
 }
}

layout/activity_main.xml

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout 
 
 android_layout_width="match_parent"
 android_layout_height="match_parent"
 android_padding="16dp"
 android_orientation="vertical"
 tools_context="com.blogspot.android_er.androidlistclient.MainActivity">

 <TextView
 android_layout_width="wrap_content"
 android_layout_height="wrap_content"
 android_layout_gravity="center_horizontal"
 android_autoLink="web"
 android_text="http://android-er.blogspot.com/"
 android_textStyle="bold" />

 <Button
 android_id="@+id/readclient"
 android_layout_width="match_parent"
 android_layout_height="wrap_content"
 android_textAllCaps="false"
 android_text="Read Ip/MAC addresses"/>

 <TextView
 android_id="@+id/result"
 android_layout_width="match_parent"
 android_layout_height="wrap_content"/>

 <ListView
 android_id="@+id/nodelist"
 android_layout_width="match_parent"
 android_layout_height="wrap_content"/>
</LinearLayout>

uses-permission of "android.permission.INTERNET" is needed in AndroidManifest.xml

Download runnable APK .

Next:
- Get HostName of WiFi hotspot clients, and check if it is still connected.

Read More..

No map is an island Introducing a connected JavaScript Maps API experience

Cross-posted from the Google Geo Developers blog

Our digital lives are increasingly connected. We research on our laptops, look up directions on our phones and even navigate with our watches. And by creating maps unique to each user and offering features such as saved places, Google Maps has been making it easier to continue these tasks as we move from device to device.

However, although maps embedded from Google Maps are now built uniquely for every Google user, most of the now two million active sites and apps using the Maps APIs are still islands. When I look for a place to eat on Zagat, I can’t see how far away it is from work. When I look at a travel map in the New York Times, I can’t save those places in order to navigate to them later.

Today we’re taking a step towards connecting these two million sites and apps by introducing a signed-in JavaScript Maps API experience and a feature called attributed save. To help illustrate, we’ve partnered with the New York Times to bring this experience to their 36 hours travel column.

A connected JavaScript Maps API

When you add &signed_in=true to the Google Maps JavaScript API source url, your end users will have the option to sign into the map with their Google account. When they do so, your users will receive a map built for them, in the context of your app. Their saved places — including home and work addresses (if set by the end user) as well as other relevant places — will appear automatically on their map, providing a layer of context that anchors your content and makes it stand out even more.

Attributed save

Once users are signed into the Google Maps in your app, we can together create an integrated experience between your map content and Google Maps. With attributed save, signed-in users can save places from your app to be accessed later, with attribution and linkbacks, on Google Maps for the web, Android and iOS.

What’s more, you can also enable deep links into your mobile applications. For instance, users can save a place from your desktop app (such as Zagat.com), open up the place on Google Maps on their Android device, and deep link directly into your Android app.

Enabling attributed save is easy — just specify your app name, a link and a place search string or place ID when creating a marker and info window. Or use our SaveWidget to enable attributed save in your own custom info window.

In addition, we’re also launching attributed save across all embedded maps today. Attribution and linkback parameter will be inferred automatically from the domain and referrer of the host site, so if you’re using our embedded maps, you don’t need to do anything! If you’re using the Google Maps Embed API, you may customize the source and link back parameters yourself.

One final point: we’ve stated in the past that the JavaScript Maps API is cookieless if loaded from maps.googleapis.com. As of today, to enable the signed in maps experience on sites across the web, the signed-in version of the JavaScript Maps API now does rely on cookies to detect the end user’s signed-in state. Please review our documentation for further details.

That’s all for now. Go try it out. And remember, no map is an island, entire of itself...

Posted by Ken Hoetmer, Product Manager, Google Maps APIs

Read More..

Quake III on your TV with Cast Remote Display API

Posted by Leon Nicholls, Developer Programs Engineer and Antonio Fontan, Software Engineer

At Google I/O 2015 we announced the new Google Cast Remote Display APIs for Android and iOS that make it easy for mobile developers to bring graphically intensive apps or games to Google Cast receivers. Now you can use the powerful GPUs, CPUs and sensors of the mobile device in your pocket to render both a local display and a virtual one to the TV. This dual display model also allows you to design new game experiences for the display on the mobile device to show maps, game pieces and private game information.

We wanted to show you how easy it is to take an existing high performance game and run it on a Chromecast. So, we decided to port the classic Quake® III Arena open source engine to support Cast Remote Display. We reached out to ID Software and they thought it was a cool idea too. When all was said and done, during our 2015 I/O session “Google Cast Remote Display APIs for Games” we were able to present the game in 720p at 60 fps!

During the demo we used a wired USB game controller to play the game, but weve also experimented with using the mobile device sensors, a bluetooth controller, a toy gun and even a dance mat as game controllers.

Since youre probably wondering how you can do this too, heres the details of how we added Cast Remote Display to Quake. The game engine was not modified in any way and the whole process took less than a day with most of our time spent removing UI code not needed for the demo. We started by using an existing source port of Quake III to Android which includes some usage of kwaak3 and ioquake3 source code.

Next, we registered a Remote Display App ID using the Google Cast SDK Developer Console. There’s no need to write a Cast receiver app as the Remote Display APIs are supported natively by all Google Cast receivers.

To render the local display, the existing main Activity was converted to an ActionBarActivity. To discover devices and to allow a user to select a Cast device to connect to, we added support for the Cast button using MediaRouteActionProvider. The MediaRouteActionProvider adds a Cast button to the action bar. We then set the MediaRouteSelector for the MediaRouter using the App ID we obtained and added a callback listener using MediaRouter.addCallback. We modified the existing code to display an image bitmap on the local display.

To render the remote display, we extended CastPresentation and called setContentView with the game’s existing GLSurfaceView instance. Think of the CastPresentation as the Activity for the remote display. The game audio engine was also started at that point.

Next we created a service extending CastRemoteDisplayLocalService which would then create an instance of our CastPresentation class. The service will manage the remote display even when the local app goes into the background. The service automatically provides a convenient notification to allow the user to dismiss the remote display.

Then we start our service when the MediaRouter onRouteSelected event is called by using CastRemoteDisplayLocalService.startService and stop the service when the MediaRouter onRouteUnselected event is called by using CastRemoteDisplayLocalService.stopService.

To see a more detailed description on how to use the Remote Display APIs, read our developer documentation. We have also published a sample app on GitHub that is UX compliant.

You can download the code that we used for the demo. To run the app you have to compile it using Gradle or Android Studio. You will also need to copy the "baseq3" folder from your Quake III game to the “qiii4a” folder in the root of the SD card of your Android mobile device. Your mobile device needs to have at least Android KitKat and Google Play services version 7.5.71.

With 17 million Chromecast devices sold and 1.5 billion touches of the Cast button, the opportunity for developers is huge, and it’s simple to add this extra functionality to an existing game. Were eager to see what amazing experiences you create using the Cast Remote Display APIs.

QUAKE II © 1997 and QUAKE III © 1999 id Software LLC, a ZeniMax Media company. QUAKE is a trademark or registered trademark of id Software LLC in the U.S. and/or other countries. QUAKE game assets used under license from id Software LLC. All Rights Reserved

QIII4A © 2012 n0n3m4. GNU General Public License.

Q3E © 2012 n0n3m4. GNU General Public License.

Read More..

Introducing the new Calendar Resource API

Originally Posted on Google Apps Developers blog

Posted by Muzammil Esmail, Product Manager, Google for Work and Wesley Chun, Developer Advocate, Google Apps

Over the years, we’ve been updating our APIs with new versions across Drive and Calendar, as well as those used for managing Google Apps for Work domains. These new services offer developers improvements over previous functionality and introduces new features that help Apps administrators better manage their domains.

To deliver even more granular control, today we are announcing the new Calendar Resource API as part of the Admin SDK’s Directory API that enables Google for Work customers to manage their physical resources, like conference rooms, printers, nap pods, tennis courts, walkstations, etc. These physical resources can be added to meetings by end users as needed. The API released today replaces the GDATA Calendar Resource API, so we encourage developers to begin moving their applications and tools to the new API. Please note that we will begin deprecation in January 2016 and sunset the existing API in January 2017. Stay tuned for a formal deprecation announcement with details.

Read More..