Friday, October 18, 2013

App Discoverability - Thinking Outside The 4 Inch Box

Talk by Michael Ludden from Samsung

Many app builders look to the OS designer for a partner to work with but looking toward the Carrier or hardware manufacturer may yield much higher returns in market and revenue share.

For example, SK Telecom's T-Store is more popular in South Korea than Apple's App Store or the Google Play Store. These carrier stores are commonly overlooked by American developers because of the stigma found in this country but should be invested in because they are rarely used and can provide an easy source of interest and revenue.

Fragmentation can be an issue but these other paths can lead to success and they offer more options to be the first-to-market. 

The Samsung Developers Conference is October 27th to 29th and will provide many different tracks for developers. This is Samsung's big push to get software developers on the bandwagon.

Overview of Google Wallet APIs

Talk by Nasir Khan, developer advocate at Google, Inc.

Google Wallet has been implemented as the primary payment processor for all Google services including Play, Drive and Chrome. It is also used across the Internet through the 'pay with Google' button. In the real world you find payment options at kiosks as well as transaction details in your phone but now you can transmit money through Google Wallet to other users.

Google Wallet works like any ordinary wallet in how it keeps your payments, offers, loyalty and more in one secure app.
In the past couple years transactions and accounts have grown year after year.
The APIs involved are:
1. Instant Buy API on Web and mWeb
2. Instant Buy API on Android for physical goods
3. Digital Goods API on Web
4. In-app Billing on Android for digital goods
5. Wallet objects API for loyalty and offers

The challenge for mobile commerce is that 97 percent of users abandon a mobile purchase in mid-flow. This has been accounted to browsing but other statistics show a significant amount of shoppers abandoning purchases already in the cart. To solve this, Google uses Instant Buy. Instant buy provides a faster checkout, allows users to skip registration and sign-in, features enhanced security, has a lightweight integration and includes no additional fees.

This works by having users access their Google Wallet, grab their information that is stored there and sends it to the merchant or payment processor. The information sent isn't the actual information of the user but a proxy card that keeps the user safe behind a level of security as well as the shipping and billing information needed.

The Instant Buy API includes simple JavaScript API for back end independent integration, a JavaScript library that renders the Google Wallet button assets and a Web application needed to implement the payment. The API also uses JSON Web Tokens that are cryptographically signed and base64url encoded to verify the originator of the message and includes the signature that is used shared secretly and verified by the Web tokens.

The Buy with Google Button can be implemented in as few as four lines of HTML or five lines of JavaScript. This uses the Masked Wallet call that gives the masked payment credentials, shipping address, billing address and phone number to the application. Clicking the button sends the request  and the information is encrypted.

Clicking through the prompts send the full wallet request which will have the full, exact amount including tax and shipping. The response will contain the Proxy card details and billing address that is backed by the security and encryption found earlier.

The Instant Buy Architecture is part of Google Play Services and so every device running Android 2.2 and higher will have it installed. To utilize it a thin client library is compiled in your app. To set this up, establish a connection to Google Play Services.  This will fetch a masked wallet. The user then clicks on the button and it will then prompt whether or not there is a Google Wallet account already active and whether it is set as default payment. If not, it will work through the authorization prompts. If the user is already authorized then it will move immediately to the confirmation page. The user has to confirm to get the actual full wallet. This is the first point in the whole transaction that the full wallet information is sent.

Some of the apps already using Google Wallet that show increased productivity:
TabbedOut: 25% Google Wallet Purchases
Rue lala: 50% are return customers
Fancy: 20% Conversions 14% basket size

Digital Goods API is also known as the in-app payments API. It is optimized for digital content and is used through the apps. This was designed to let developers handle their app while Google handles the payment.

This API is built around three principles. First a streamlined experience that provides and easy way for consumers to navigate the payment process. Second is a simple integration so developers will feel no stress in implementing them in their applications. Last is attractive pricing, which is run completely through Google at the most aggressive pricing in the industry.

The Wallet Objects API is here to solve the fat wallet challenge. The first part of the challenge is the quantity of cards including loyalty cards, points cards and credit cards. The second is the time consuming sign-up involved for each and every card. Third are the lost benefits. It is estimated that 16 billion dollars in points go unused every year. The Google Wallet Objects API is here to have everything in one place.

This brings back to the three things the Objects API brings, all of your cards in one place, little to no enrollment and a deeper engagement in the programs you are enrolled in. This is designed to be easily integrated into existing loyalty systems.

Two million users have used the new app in the past three weeks since the last app launch. This includes a 23% increase in the Alaska Airlines Mileage Plan since the App launch.
For more information, go to

Developing High Performance Websites and Modern Apps with Java script and HTML 5

Talk by Doris Chen, Ph.D.

Web Site and Modern Apps

Modern Apps are native JavaScript apps written either for Windows 8 or Windows Desktop. With JavaScript and Windows 8 you will be able to take Web apps and implement them natively as Windows 8 apps without modifying any of the code.

General Best Practices for JavaScript Development

Some tips and tricks that still work for JavaScript Development include:
1. For Safe dynamic content, use innerHTML to create your DOM
2. Link CSS styles heels at the top of the page, not at the bottom
3. Avoid inline JavaScript and inline CSS styles
4. Don't parse JSON by hand, use JSON.parse
5. Build Session "50 performance tricks to make your HTML5 apps and sites faster"

Game: Make it Run Faster
5 Principles to improve your performance

An example game includes a matrix of players with arms outstretched at 90 degree angles. When one is clicked, it spins and high-fives it's neighbor if they are aligned right. By pressing the F12 key while running an app you can track the UI responsiveness in the app you are running, allowing one to track the CPU utilization and the Visual throughput. Some of the metrics involved include Loading, Scripting, GC, Styling, Rendering and Image decoding. What actually impacts the visual throughput includes networking, HTML, CSS, collections, Javascript, Marshalling, DOM, Formatting, Block Building, Layout and Rendering. These are the variables you need to control to keep the framerate at or above 60 fps. When one needs a more detailed profiler, check out Windows Performance Toolkit at

Principle #1: Memory Usage: Stay Lean
Keeping track of Garbage Collection will show you where your code needs to be more efficient. Things that trigger a garbage collection include every call to new or implicit memory allocation which reserves GC memory and when a pool is exhausted.
Using the example, instead of creating a new object for each person in each direction, create the person as an object and set the different directions as the states for the objects, cleaning up the object pool.
In this example, the GC time was reduced to 1/3rd the amount of the original code.
This shows that the best practices for staying lean include avoid unnecessary object creation, use object pools when possible and to be aware of allocation patters especially when setting closures to event handlers, dynamically creating DOM (sub) trees and implicit allocations in the engine.

Principle #2: Use fast objects and do fast manipulations
Make sure the order is the same when creating multiple objects or you will create multiple objects rather than states of the same object. You need to also make sure you don't add properties conditionally. This follows the old adage, "Less is More", where programmers should set parameters first in as few lines as possible. One should also make sure not to default properties on prototypes.
Deleting also slows down properties because it forces conversion. You should instead set properties to 0 or undefined to close it off. You should also restrict the total properties to stay away from slower property bags. To keep from those slow property bags you should also restrict using getters, setters and property descriptors in perfect critical paths.

Principle #3 Write Fast Arithmetic
All numbers in JavaScript are IEEE 64-bit floating point numbers which are great for flexibility but present a performance and optimization challenge. To help with this, avoid creating floats if they are not needed. The fastest way to indicate integer math is |0. You can also take advantage of type - specialization for arithmetic by creating separate functions for its and floats by using consistent argument types.

Principle #4 Use Fast Arrays
When writing your arrays, pre-allocate them to speed them up. For mixed arrays, provide an early hint. This will avoid delayed type conversion and copy. You should use typed arrays when possible. This avoids tagging of integers and allocating heap space for floats. One should also keep values in arrays consistent since numeric arrays are treated like typed arrays internally. Keep arrays dense. Explicit caching of length avoids repetitive property accesses.

Principle #5 Do less (cross-subsystem) work
Avoiding chatting with the DOM will relieve the code of excess cycles. Avoid automatic conversions of DOM values. Values from the DOM are strings by default. Paint as much as your users can see. Aligning timers to display frames will cut down your work.
These principles will create a great user experience that will extend the battery life and make the app much richer than before.

Check out BizSpark and DreamSpark for useful tools.
Contact Doris Chen,

Augmentation and Telepresence #throughglass

Talk by Martin Wojtzcyk and Devy Tan-Wojtczyk

Augmented reality is when you enhance reality with computer-generated images, allowing for one to either see or be put into a virtual reality.
Telepresence is the use of virtual reality technology to transmit video and/or audio to communicate with others.

To program for Google Glass, there are a couple methods:
Using Google's Mirror API connects Glassware (HTML) with Google and then to Glass. This allows for easy programming and implementation but causes a lag between the device and the database where your program would lay.
Using GPK, developers would be able to program directly for Glass and upload their programs directly to the device to allow for real time zero-lag environments.

There are many use cases that we are tackling through our startup.
Map overlays allow for people to find the store and will navigate to the shop. Overlay changes to on-screen display showing products to purchase. When selected, Glass navigates shopper to the item and describes prices, reviews of products.
Telepresence allows management to contact workers in factories around the world and see through hangouts what the workers see. This enables management to keep track of projects while being in another country.
Telepresence also allows robotics to be implemented in labs to allow for sample checking from home. This also allows for exploration and rescue to be manned from safety.

Mirror API
Google ask samples
OpenCV4Android SDK

Functional Fashion and the Future of Mobile - Wearable Android

Wearing Android

The future of mobile devices is wearable

Talk by Siamak Ashrafi, researcher at YLabs

Embedded devices are all around us in card readers, registers, etc. This is the wrong way of doing things.

MEMS sensors are so prolific that you will find them in all mobile devices. The sensors include acceleration, temperature, gravity, gyroscope, light, magnetic field, orientation, pressure, proximity, humidity, vector, camera, microphone and touch. Antennas include CDMA, GSM WiFi, NC and Bluetooth. Sensors make a smartphone close to self aware. Code that includes gravity, accelerometer and linear accelerometer allow devices to sense if you have taken a fall and will notify those needed. 

These sensors allow for seeing, hearing and feeling through camera microphone and touch. This sensor data, coupled with Android, utilizes Google Cloud Messaging to pair sensor suites with devices to connect to the Internet and send the data to anything. Near Field Communication tags allow for quick transfer of information including Bluetooth handshakes, Credit Card information and Wi-Fi passwords. These NFC tags only work when in extremely close proximity, aka skin-to-skin. These low energy devices allow for a bevy of Wearable devices.

The uses of device-based objects are shown in the differences between Rovio and Romo:
Device required specialized hardware and components and was late-to-market because of problems with the Specialized hardware.
Device added wheels to an iPhone and was able to do the same as the Rovio for a fraction of the cost and without the problems thanks to the hardware being already vetted and tested by Apple.

Mind versus Body shift
We have been shifting from using our body to survive to using our mind to survive and our bodies have not adapted to the current level of inactivity and has led to numerous problems.

There are two types of Android devices on the market, those that run Android and those that only utilize Android.

Devices that utilize android but do not run it include the Jawbone Up, Lark, FitBit and the Nike+ Fuelband. The Jawbone Up tracks your sleep, activity, food and drink, mood and others but only mentions what it has been doing when you plug it in. Lark does a lot of what the Jawbone up does but includes a small display while the FitBit includes a large enough display to show a clock and other data in future devices. Nike+ FuelBand only works on iOS but includes a display akin to the FitBit.

Pebble Watch: Runs other OS, Black and White
Sony Watch: Runs some Android, Color
Samsung Watch: Runs full Android, same hardware as top-level devices a year ago.
Apple M7 Motion Co-Processor
Glass UP: Read-only and includes mail, messages, text messages and notifications.
Recon Jet: Android without Google software
Google Glass

Applications allow new technology to succeed by allowing anyone to adapt and utilize something new. Glass is the next device that won't be left at home.  While Glass is currently in the Explorer Edition, it will change to be more attractive and fashionable in the future. The hardware includes all of the pieces except for the cell antenna, keeping the high-power devices away from your head.

Glass originally used Google's Mirror API to connect to AppEngine to develop applications, now you can write through the GDK to directly program apps. While the GDK allows for deeper implementation, the Mirror API lets programmers unfamiliar with Android to develop with all of the tools needed to get information on Glass.

For Glass, one primary feature is the built-in augmented reality. This required a combination of powerful processors and sensors that wasn't accessible by the public until today's Smartphones.

Android and Bluetooth Low Energy

Talk by Dario Laverde, Senior Developer Evangelist for HTC

Bluetooth Low Energy began in 2001 was introduced with Nokia's Wibree and merged with the main standard in 2010 with Bluetooth 4.0.

The Bluetooth 4.0 core specifications include the classic Bluetooth technology, Bluetooth Low Energy and Bluetooth SMART. Hardware-wise Classic Bluetooth is limited to a 100 meter range with a transfer rate of one to three Mbit/s and uses under 30 mA while BLE utilizes a max range of 50 meters, has a 1 Mbit/s transfer rate and uses under 15 mA of power.

We have seen Bluetooth Low Energy used in health, fitness and proximity but there are many more possibilities. These uses have their own specifications known as BLE Profiles. These are for particular applications and manufacturers are expected to implement specs to ensure compatibility but are not required by the core specification itself.

Some profiles include:
HRP: Heart Rate Profile for pulse monitoring
HTP: Health Thermometer Profile for medical temperature measurement
GLP: Glucose Profile for blood glucose monitors
CSCP: Cycling Speed and Cadence Profile
RSP: Running Speed Profile
FMP: Find Me Profile
PXP: Proximity Profile that allows the device to detect if another device is near

BLE manufacturers are encouraged by Bluetooth SIG to create new profiles and extend others with proprietary characteristics to expand the original ones. This does create difficulty, however, with app developers having to contact the 3rd party manufacturers for specifications. BLE Profiles sit on top of the Generic Attribute Profile on the Host and shares the same radio with the classic Bluetooth but has many layers removed to make it more efficient.

BLE Protocols
General Attribute Profile (GATT)
Phone, the master/central role has the GATT Client, and the BLE Smart device, which is Slave/Peripheral and contains the Service and the Characteristic with the value and descriptors. There are some roles left out including the Broadcast Role. Android BLE only supports the central role but IOS supports both.

BLE GATT Clients and Servers
Servers expose the attributes while the clients use them. The Client Actions include discovering, reading, writing, confirming and indicating while the Server Actions include responding to the client actions, sending notifications and indicating.
To find more information, go to the Bluetooth SIG portal.

BLE Developer Device Kits
BLE chipset OEMs provide device kits which support different profiles. Texas Instruments' Sensorial has a bevy of sensors including acceleration, rotation, pressure, humidity, magnetic field and temperature.

Prior to Android 4.3, several OEMs already have devices on the market that support BLE and each provide their own BLE API including HTC, Samsung, Motorola and others. The BLE API was formally announced at Google IO 2013 and includes API Level 18. In most, if not all, cases, you will build on top of the GATT profile so your app must include the implementation of your required BLE profiles.

Scanning works slightly different than Classic Bluetooth in that it has its own callbacks.
It is more efficient in that by searching for Low Energy devices allows much faster scans compared to a scan for both classic and low energy Bluetooth devices. Sadly a known issue in Android is that, for the time being, it will only allow four sensor notifications.

Q & A
Bluetooth SIG, Google IO 2013,,
contact info:


Greetings Google DevFest West 2013!

We'd like to start off by thanking Google for providing the facilities, room and the teeshirts and other prizes, GDG Silicon Valley and GDG San Francisco for putting on the event and Josh for doing the website.

To view the schedule as well as look at a couple of the talks go to .
For those at the talks, lunch will be on the patio behind the building and there will be a break for lunch and dinner that will be catered. Talks will be held in building CL2 (Crane Beach Room) and CL3 (Maxwell Room).

Thanks for coming and have a great DevFest!

Setting up for DevFest West!

Badges and lanyards out, volunteers prepped, we are ready to go! We will have registration inside Building CL2's lobby (employee entrance). Open the floodgates!