Episode 37 Webview

Richard, Chet, Ben, and not Tor in the spacious London studio

In this Tor-less episode, Chet talks with Ben Murdoch and Richard Coles from the Android WebView team. We talk about WebViews ability to update outside of platform releases, the transition from the original WebView to the new Chromium WebView widget, about some of the new features and APIs in recent releases, and about cute kitten bitmaps.

Tor didnt have much to say, about kittens or anything else.

Subscribe to the podcast feed or download the audio file directly.

Relevant Links

Beta Channel for Android WebView
Google+ Beta Channel Community
Bug Tracker
Chrome Dev Tools
WebView API


Ben Murdoch: google.com/+BenMurdoch, @ksasq
Richard Coles: google.com/+RichardColesGoogle
Tor: google.com/+TorNorbye, @tornorbye
Chet: google.com/+ChetHaase, @chethaase

Also, thanks to continued support by Bryan Gordon, our audio engineer who puts this stuff together every time.

Read More..

Because its gotta be super easy to share files

Posted by Alex Vogenthaler, Group Product Manager, Google Drive

(Cross-posted on the Google Drive Blog.)

When you store your important files somewhere, you want to have peace of mind that theyll be safe and easy-to-access later. Thats why everything in Drive is always encrypted. And why we encourage all of our users to complete a simple Security Checkup every now and then. Of course, this should include file sharing as well -- it should be super easy to control who sees what.

With this in mind, were making a number of improvements to Drive today, so you can store your photos and documents safely and get them where they need to go.

Get sharing notifications
You may have noticed recently that it’s easier to select and share multiple files and folders on iOS and Android — but checking your email may not be the fastest way to find out when something’s been shared with you. So starting today, you’ll receive mobile notifications to alert you immediately when files or folders are shared with you and a single tap can take you right to them.

Request and grant file access
Drive lets you quickly grab a link to files and folders so you can share them using other apps, but if you share a link before you’ve granted access, the person you’re sending it to won’t be able to open it. Now, the Drive for Android app lets recipients request access with a single tap. And on Android and iOS, file owners will be notified of the request instantly so they can quickly grant access.

Preview files without a Google Account on Android
Until now, you needed a Google Account to view shared files on your Android device. Now, you can do this without a Google Account just like on the web.

Some of the features mentioned are already available. Look for the rest to roll out in the coming week or so.

Read More..

Parsing XML wit SAX parser

Android provides org.xml.sax package that has that provides the event-driven SAX parser.
to parse the previous response with SAX parser, we have to create a class extending DefaultHandler and override the following methods:

1. startDocument(): invoked when the xml document is open, there we can initialize any member variables.
2. startElement(String uri, String localName, String qName, Attributes attributes): invoked when the parser encounters a xml node, here we can initialize specific instances of our person object.
3. endElement(String uri, String localName, String Name): invoked when the parser reaches the closing of a xml tag. here the element value would have been completely read.
4. characters(char[] ch, int start, int length): this method is called when the parser reads characters of a node value.

we want to parse this xml response:

<?xml version="1.0"?>
<person>
 <firstname>Jack</firstname>
 <lastname>smith</lastname>
 <age>28</age>
</person>

so our parsing class will be like this:

/**
 * SAX parser to parse persons response
 */
 public class PersonParser extends DefaultHandler
 {

 // arraylist to store person objects
 ArrayList persons;
 // temporary person object
 Person tempPerson;
 // string builder acts as a buffer
 StringBuilder builder;

 /**
 * Initialize the arraylist
 * @throws SAXException
 */
 @Override
 public void startDocument() throws SAXException {
 pesons=new ArrayList();

 }

 /**
 * Initialize the temp person object which will hold the parsed in//fo
 * and the string builder that will store the read characters
 * @param uri
 * @param localName
 * @param qName
 * @param attributes
 * @throws SAXException
 */
 @Override
 public void startElement(String uri, String localName, String qName,
 Attributes attributes) throws SAXException {

 if(localName.equalsIgnoreCase.equals("person")){
 tempPerson=new Person();
 builder=new StringBuilder();
 }

 }
 /**
 * Finished reading the person tag, add it to arraylist
 * @param uri
 * @param localName
 * @param qName
 * @throws SAXException
 */
 @Override
 public void endElement(String uri, String localName, String qName)
 throws SAXException {
 // finished reading a person, add it to the arraylist
 if(localName.toLowerCase().equals("person"))
 {
 this.persons.add(tempPerson);
 }
 // finished reading "firstname" tag assign it to the temp person
 else if(localName.toLowerCase().equals("firstname")){
 tempPerson.firstName=builder.toString();
 }
 // finished reading "lastname" tag assign it to the temp person
 else if(localName.toLowerCase().equals("lastname")){
 tempPerson.lastName=builder.toString();
 }
 // finished reading "age" tag assign it to the temp person
 else if(localName.toLowerCase().equals("age")){
 tempPerson.age=Integer.parseInt(builder.toString());
 }
 }

 /**
 * Read the value of each tag
 * @param ch
 * @param start
 * @param length
 * @throws SAXException
 */
 @Override
 public void characters(char[] ch, int start, int length)
 throws SAXException {
 // read the characters and append them to the buffer
 String tempString=new String(ch, start, length);
 builder.append(tempString);
 }
 }

the code is pretty easy, the parser iterates over each node, you check the current node name and take an action.

then we call the parser like this:

public ArrayList getPersons(final String response) throws ParserConfigurationException, SAXException, IOException
 {
 BufferedReader br=new BufferedReader(new StringReader(response));
 InputSource is=new InputSource(br);
 PersonParser parser=new PersonParser();
 SAXParserFactory factory=SAXParserFactory.newInstance();
 SAXParser sp=factory.newSAXParser();
 XMLReader reader=sp.getXMLReader();
 reader.setContentHandler(parser);
 reader.parse(is);
 ArrayList persons=parser.persons;

 return persons;

 }

Read More..

Pixels and Pixellation

How many pixels do you need? This is a question many, many people ask and to be honest I think its the wrong one. Let me give you a few numbers!

First of all, its widely accepted that a monitor with more than 100 "dots per inch" or "pixels per inch" placed 18-24 inches from your face looks pretty good - with outstanding monitors at that distance having 130-170ppi. Im also going to assume that the average monitor resolution is 1080p - thats 1920x1080 pixels in a 16:9 rectangle. This is actually quite generous but Ive done that deliberately. Now when youre printing images on paper, its generally accepted that 200ppi is "reasonably good" quality, and 300ppi is "excellent".

Full image - 2688x1520 (4 million pixels) displayed at 600 x 339

So - with a 4 million pixel image in a 16:9 arrangement, your image dimensions are going to be close to 2688x1520. If we divide that by 300ppi for printing we get a print size of 8.96" x 5.07". Call it 9" x 5" for round numbers and youre looking at an "Excellent" quality image bigger than most commercially bought prints which would be 6" x 4" or 7" x 5". Start blowing up from 9" x 5" and youre slowly going to start losing image quality. Pixellation will likely begin to occur at about 13" across. For displaying on a screen its a completely different story: 1920 x 1080 pixels is about 2 million pixels altogether; and at the very best quality Ive ever seen for myself (130ppi) thats a monitor size of 14.76" x 8.31" (about a 17" 16:9 monitor). So - if you display a 4 million pixel image on this monitor youre zoomed out so that half of the pixels in the image are never displayed. If you zoom in so that every pixel is displayed you can only see half of the images area: but still at 130ppi you cant see individual pixels and the image quality is absolutely perfect. On my monitor at work, which is 22" 1680 x 1050 (90ppi) I begin to be able to resolve individual pixels with the naked eye when zoomed in to around 350% - where each image pixel is represented by 3.5 screen pixels on average.

So - lets use these as our ballpark figures; zoom in to 350% or print larger than 13" for individual pixels to appear on a 4 million pixel image.

The original image, cropped to 600 x 339 pixels and displayed at full size. Note the complete lack of pixellation - although there is a certain fuzziness to the detail.

Now, lets look at how the vast majority of mobile phone users use the photos they take. Please dont think of yourself or your friends here; think of the millions of people buying smartphones and how THEY use their pics. Look at Facebook, Flickr, Tumblr, Twitter, etc. Thats right - MOST people - the vast majority - use the photos the way they come out. They dont edit, they dont crop, they dont zoom, they dont do any more than perhaps a bit of red-eye removal. And how are those images distributed in the main? They are very rarely displayed at their full size (in fact Facebook almost never even holds the pictures at full size but "processes" them in a way which removes massive amounts of detail and image quality to save storage space). Most places (Facebook included) allow you to choose a range of sizes to upload at, to optimise data traffic and storage space use.

The original image, cropped down to 198 x 146 pixels, and displayed at 600 x 339 to keep the playing field level with the other images. Note the fuzziness; and you can start to see individual pixels. This is now less than 9% of the original image, AND its blown up to four times actual size.

So - the image you see on the screen is usually displayed to you at 600-1000 pixels across - far less than the original photo. At this resolution, a photo taken at 13 million pixels and a photo taken at 2 million pixels will look EXACTLY THE SAME. There is simply no way to see the original detail because making the picture that size has destroyed it - and if both are now the same width with the same scene depicted the remaining detail in the picture is also the same.

Now - there are a minority of smartphone camera users who shout "but I crop, zoom, edit my images - 4 million pixels is not enough!". I dont want to make fun of those people but - if you take a photograph so poorly that the image you want from the original picture is 30% or less of what you photographed, youre doing it wrongly. Take the photograph you want in the first place rather than taking a wider scene and then cropping it down to a postage stamp. Move closer to the subject and frame it properly. If you cant move close enough that the subject is easily visible in the frame, then a smartphone camera is the wrong tool for that image. Use a camera with a nice big lens, optical zoom and a nice big sensor. Smartphone cameras were (and are) intended for quick opportunist snaps; although a skilled photographer can capture some outstanding images with even a 4 million pixel smartphone camera because theyre a skilled photographer. For examples of what I mean, look up Colby Brown who uses smartphone cameras to take many of his unbeatable images. All are displayed on his site at 1140 pixels across and yet they look absolutely fantastic regardless of the camera he used. Another up-and-coming digital photographer is Craig Fish who also uses a 4MP smartphone camera for many of his shots.

To prove my point, here are links to one image which has been progressively halved in size until the smallest one is HALF A MILLION PIXELS. I challenge you to see the loss of quality without zooming in... until you get below the resolution of your monitor.

Original image: 4 million pixels

Half Size – 2 million pixels

Quarter size: 1 million pixels

One eighth size: half a million pixels

This article is also to be found on its author personal blog.

Have any questions or comments? Feel free to share! Also, if you like this article, please use the media sharing buttons (Twitter, G+, Facebook) under this post!

Read More..

Lean ops for startups 4 leaders share their secrets

Posted by Ori Weinroth, Google Cloud Platform Marketing

As a CTO, VP R&D, or CIO at a technology startup you typically need to maneuver and make the most out of limited budgets. Chances are, you’ve never had your CEO walk in and tell you, “We’ve just closed our Series A round. You now have unlimited funding to launch version 1.5.”

So how do you extract real value from what you’re given to work with? We’re gathering four start technology leaders for a free webinar discussion around exactly that: their strategies and tactics for operating lean. They will cover key challenges and share tips and tricks for:

• Reducing burn rate by making smart tech choices
• Getting the most out of a critical but finite resource - your dev team
• Avoiding vendor lock-in so as to maximize cost efficiencies

We’ve invited the following technology leaders from some of today’s most dynamic startups:

• Yorick Phoenix, CTO, Issio Solutions
• Erich Ess, CTO, Simple Relevance
• Greg Roodt, CTO, AirHelp
• Raphael Ouzan, CTO, BillGuard

Sign up for our Lean Ops Webinar in your timezone to hear their take:

Americas
Wednesday, 13 August 2015
11:00 AM PT
[Click here to register]

Europe, Middle East and Africa
Wednesday, 13 August 2015
10:00 AM (UK), 11:00 AM (France), 12:00 PM (Israel)
[Click here to register]

Asia Pacific
Wednesday, 13 August 2015
10:30AM (India), 1:00 PM (Singapore/Hong Kong), 3:00PM (Sydney, AEDT)
[Click here to register]

Our moderator will be Amir Shevat, senior program manager at Google Developer Relations. We look forward to an insightful and open discussion and hope you can attend.

Read More..

For Technical Leads and Senior Developers

Thanks for the wonderful response for the below post ... The Positions are closed now :)

Hi,

Technical Leads Needed in Bangalore Tesco
I work for Tesco and we are looking for Leads/Architects who are hands-on and understand design principles well enough to apply them for Android development. Any one with above 7 years of experience in software development with atleast 2-3 years in Android, please get in touch with me by replying to this post with a way to contact you.

We are using some cutting edge architecture at Tesco with principles of reuse across device sizes (tablets, phones, kiosks, TVs, wall screens, digital signages) across countries (12 of them) and across platforms (iOS, Android and Windows) and still keeping the apps completely native. Sounds interesting? Please feel free to get in touch with me for joining this cutting edge team :)

Senior Developers Needed in Bangalore Tesco
Also senior Android developers with 5+ years of experience with 3 years on Android can get in touch with me for the same team.

NOTE: Please do not send me resumes or get in touch if your experience is below 5 years.

Read More..

Introducing gRPC a new open source HTTP 2 RPC Framework

Today, we are open sourcing gRPC, a brand new framework for handling remote procedure calls. It’s BSD licensed, based on the recently finalized HTTP/2 standard, and enables easy creation of highly performant, scalable APIs and microservices in many popular programming languages and platforms. Internally at Google, we are starting to use gRPC to expose most of our public services through gRPC endpoints as part of our long term commitment to HTTP/2.

Over the years, Google has developed underlying systems and technologies to support the largest ecosystem of micro-services in the world; our servers make tens of billions of calls per second within our global datacenters. At this scale, nanoseconds matter. Efficiency, scalability and reliability are at the core of building Google’s APIs.

gRPC is based on many years of experience in building distributed systems. With the new framework, we want to bring to the developer community a modern, bandwidth and CPU efficient, low latency way to create massively distributed systems that span data centers, as well as power mobile apps, real-time communications, IoT devices and APIs.

Building on HTTP/2 standards brings many capabilities such as bidirectional streaming, flow control, header compression, multiplexing requests over a single TCP connection and more. These features save battery life and data usage on mobile while speeding up services and web applications running in the cloud.

Developers can write more responsive real-time applications, which scale more easily and make the web more efficient. Read more about the features and benefits in the FAQ.

Alongside gRPC, we are releasing a new version of Protocol Buffers, a high performance, open source binary serialization protocol that allows easy definition of services and automatic generation of client libraries. Proto 3 adds new features, is easier to use compared to previous versions, adds support for more languages and provides canonical mapping of Proto to JSON.

The project has support for C, C++, Java, Go, Node.js, Python, and Ruby. Libraries for Objective-C, PHP and C# are in development. To start contributing, please fork the Github repositories and start submitting pull requests. Also, be sure to check out the documentation, join us on the mailing list, visit the IRC #grpc channel on Freenode and tag StackOverflow questions with the “grpc” tag.

Google has been working closely with Square and other organizations on the gRPC project. We’re all excited for the potential of this technology to improve the web and look forward to further developing the project in the open with the help, direction and contributions of the community.

Post by Mugur Marculescu, Product Manager

Read More..