Hello, and welcome to Google I.O. 2017, our annual developer festival. I'm Timothy Jordan, developer advocate at Google, and I'll be touring the I.O. venue throughout the next three days, exploring the sandboxes, interviewing Googlers, and giving you eyes on the ground. That's right, even though you're joining remotely, this year you'll get an in-depth look at everything happening at Shoreline, not just the sessions. You can follow along on any of the live stream channels on Google.com slash I.O. Google I.O. is an outdoor developer festival hosting 7,200 attendees at Shoreline Amphitheater, along with millions of viewers on the live stream. That's you. And thousands of developers at more than 450 local I.O. extended events across 80 countries. We have 14 content tracks with over 150 breakout sessions, all live streamed on Google.com slash I.O. There's also over 70 codelabs live to get you up and running with our latest APIs today at g.co slash I.O. slash codelabs. But before you get to any of that, let's review a handful of the announcements you just heard. Smart Reply, available in inbox by Gmail and Allo, saves you time by suggesting quick responses to your messages. It utilizes machine learning to give you better responses the more you use it and it already drives 12% of replies in inbox on mobile. Starting today, Smart Reply is coming to Gmail for Android and iOS too. We're excited to announce that our second generation Tenser processing units are coming to Google Compute Engine as cloud TPUs where you can connect them to virtual machines of all shapes and sizes and mix and match them with other types of hardware including Skylake CPUs and NVIDIA GPUs. You can program these cloud TPUs with TensorFlow, the most popular open source machine learning framework on GitHub, and we're introducing high level APIs which will make it easier to train machine learning models on CPUs, GPUs or cloud TPUs with only minimal code changes. Many top researchers don't have access to anywhere near as much compute power as they need to help as many researchers as we can and further accelerate the pace of open machine learning research, we will make 1000 cloud TPUs available at no cost to ML researchers via the TensorFlow Research Cloud. Android O coming later this year will bring more fluid experiences to your smaller screen as well as improvements to battery life and security. With Pitcher & Pitcher, you can seamlessly do two tasks simultaneously and smart text selection improves copy and paste by using machine learning to recognize entities on the screen. Google Play Protect is Google's comprehensive security services for Android which provides powerful new protections and greater visibility into your device security. Play Protect is built into every device with Google Play, is always updating and automatically takes action to keep your data and device safe. We also have an early preview of a new initiative for entry-level Android devices that internally we call Android Go. The goal is to get computing into the hands of more people by creating a great smartphone experience on all Android devices with one gigabyte or less of memory.  Of course, way more was covered in the Google keynote including new ways to share with Google Photos including photo books, new ways that Google Assistant can help you do even more, investments in the core technologies that enable VR and AR and in platforms that make them accessible to more people. Have questions about IO17? Tweet them starting today through May 19th using hashtag IO17 request. A team of Googlers will be on site chasing down answers for you. Make sure to also follow the conversation on hashtag IO17 and on the Google Developers blog. Make sure to tune in to the developer keynote at 1 p.m. Pacific Time and I'll see you right here on the live stream between all the sessions. This is Google IO 2017. I'm Sarah from the Google Developer Certification Team. Last year we launched the Associate Android Developer Certification at IO. Now we're adding two certifications for mobile web developers. Why mobile? Mobile now accounts for over half of all web traffic. Users expect their small screen experiences to be as quick and intuitive as those on the desktop. But making the mobile web fast and easy takes some special skills. How can you prove you've learned them? We've created two new certifications to help developers get recognized for their knowledge and skill. Introducing the mobile site certification and the mobile web specialist certification. One focuses on sites and the other on web apps. Let's talk about mobile sites. What happens to your beautiful site if it takes too long to load? 53% of mobile visitors will leave a page if it takes more than three seconds to load. But the average mobile page loads in 22 seconds. Making this even one second faster increases conversion rates up to 27%. Google believes in the mobile web and so do our customers. That's why we've created the Google mobile site certification to help site owners find the best talent. Passing this exam demonstrates you have the knowledge for building high performing mobile sites. It also highlights your understanding of best practices and current browser technologies. To pass, you'll need to be proficient across mobile site design, UX best practices and site speed optimization. This certification is especially useful for developers working in-house for agencies or clients. To prepare, use the online study guide or e-learning course. Both are free. Once certified, you can promote your certificate on your Google partners public profile and social media. What if you're developing mobile web apps? Developing applications requires even more specialized skills than sites, so we have a certification for that. The mobile web specialist certification shows you can build quality web apps including progressive web apps. You take this exam by solving a series of coding problems. We'll test your skills in many in-demand areas including responsive design, accessibility and progressive web application development. This certification is especially useful for developers looking to move up in their careers. It will prepare you to tackle a wide range of challenges. We also provide a study guide and a range of courses to help you prepare. With multiple certifications, how do you know which one to take? Are you building mobile sites and need to demonstrate you have the knowledge to do it? Take the mobile site certification exam. Need to show that you have the skills to build a mobile web app? Take the mobile web specialist exam. Visit our certification page under the Google Developers website to learn more about our programs. Get the study guides, get ready and let's go. Okay Google, what's the temperature like at Mount Everest? The temperature there is minus 14. Ooh, I better pack a jacket. Oh hi, I'm Wayne Pekarski and today I'm going to talk about the Google Assistant and how you can develop your own actions to be a part of this new ecosystem. At Google, we've been providing assistance to users for years across many of our products but we think there's much more we can do to help people get things done right when they need it in a conversational way. And that's why we're building the Google Assistant. The Google Assistant can help users get things done throughout their day whether they're at home or on the go. And it powers devices like, for example, the Google Home, a voice-activated speaker. To better serve user requests, the Google Assistant needs to work well with an ecosystem of everyone's favorite services. Actions on Google allows you as a developer to integrate your services with the Google Assistant and that is what we're going to explain how to do in this video. Conversation actions enable you to fulfill a user's request directly via a two-way dialogue. Users don't need to pre-enable skills or install new apps to interact with any actions you build. When a user asks for your action by name, we'll connect them with you immediately. Let's first go through a detailed example of a user interacting with a conversation action. Think about something as simple as helping a user choose what to have for dinner based on their mood and the ingredients they have around. Let's call this action personal chef. The user first needs to invoke your action with something like, OK Google, let me talk to personal chef. The Assistant will then introduce your action and now the user is talking to you directly. From this point onwards, you get to interact with the user and have a conversation. OK Google, let me talk to personal chef. Sure, here's personal chef. Hi, I'm your personal chef. What are you in the mood for? Well, it's kind of cold outside so I'd like something to warm me up, like a hot soup, and I want it fast. Alright, what protein would you like to use? I have some chicken and also some canned tomatoes. OK, well I think you should try the chicken tomato soup recipe I found on example.com. Hmm, sounds good to me. So this is a pretty rich interaction. Think about all the sentences I spoke and how the action needs to extract the meaning out of this. How would you implement this? If you're an expert in the area of natural language processing, use the conversation API which allows you to process the raw strings that contain the spoken text from the user. You can then use the actions SDK that includes all the tools and libraries you need to build the actions. However, if you don't want to process the user's transcribed speech yourself, you can use one of the tools that have integrated with actions on Google. One of these tools is API.ai which provides an intuitive graphical user interface to create conversational interfaces and it does the heavy lifting in terms of managing conversational state and filling out slots and forms. This means you'll no longer need to process the raw strings. API.ai can do this for you. To handle a conversation, use the API.ai developer console to create an intent. This is where you define the information you need from the user. For our example, finding a kitchen recipe, this would be the type of food, the ingredients, the temperature, and the cooking time. You then specify example sentences. API.ai pauses these sentences and uses them to train its machine learning algorithm to process other possible sentences from your users. You don't have to write regular expressions or a pauser. You can also manually set what the acceptable values are for each piece of information. Once this is done, API.ai uses these definitions to extract meaning out of spoken sentences. The user can provide information naturally, out of order, all at once, or in pieces. The action can ask follow-up questions as needed. Pretty neat, right? Once you've set up everything in the API.ai console, you can then test it out immediately with example sentences. Then, you can test your project with the web simulator, preview it on Google Home, or deploy the full project to Google, or from within API.ai. Next, you can connect up an optional webhook to your intent to allow it to interact with a back-end server. When all the details you need are filled in, your webhook is called with the appropriate details provided as JSON data. You don't need to worry about pausing strings or dealing with responding back with follow-up questions for the user. You can also develop the webhook using the language and hosting platform of your choice. It's just an HTTP callback. So API.ai makes this really simple. It's easy to get started, and you can have a prototype working in just a few minutes. You should check out our screencast video where we show all the steps to make this happen. So the Google Assistant is the next big opportunity for developers. By developing actions on Google, you'll get cutting-edge experience in natural conversation interfaces, and be ready to actively participate in the emerging space of AI-first computing. In addition, you'll be able to help shape the platform and grow your audience in all the devices and contexts where the Assistant will be available in the future. And thanks to conversational interface building tools like API.ai, as well as Google's unique understanding of the user's interests and contexts, you'll be able to create frictionless, intelligent experiences for people that engage with the Google Assistant. You can find out more about actions on Google by reading the documentation at developers.google.com. We also have an actions on Google developer community on Google+, so you can ask questions and share your ideas with everyone. We look forward to seeing what you build, and I'll see you next time. Hi, I'm Nandini from Google's Conversation Design Team, here to give you some tips on how to design your own voice and chat UIs using actions on Google. Before we dive in, let's have a conversation about conversation. Consider this, all human inventions start as ideas. By definition, conversation is the exchange of ideas by spoken words. And by definition, civilization is the most advanced stage of human social development. It's the tangible expression of our common understanding and values, which is expressed through language, and language is molded and refined by conversations. A conversation is a contract between two participants with a mutual investment in the outcome, but all of that is really hard to codify. Building natural human-to-computer conversations is hard, but that's because human-to-human conversations are only deceptively easy. People are not going to change how they converse anytime soon, so the key to closing that gap between modern interfaces and thousands of years of evolution is to use what we know to be true about human-to-human conversation to teach our computers to talk to humans and not the other way around. So the key to building a good voice interface is not to fall into the trap of simply converting a GUI into a VUI. Obviously, I can't teach you an entire design discipline in a few minutes, but I can give you five pro tips to set you up for success. Let's design a simple number guessing game along the way. Here we go. Number one, leverage your brand and give yourself a persona. I don't mean a caricature or a mascot necessarily, but you can do that too to make it even more accessible. A persona is more than that. It's the consistent character captured by the voice and interactive experience. It's the face of that experience for the user. First, list the core attributes of your brand and what you stand for. Come up with the corresponding attributes that can be conveyed through design elements and, of course, the voice dialogue itself. For example, if your brand is known for speed, something we at Google are known for, some attributes of the design might be to be intuitive and data-driven since both of those elements cut out steps for the user. Some voice attributes for the actual dialogue wording might be engaging or apt or approachable, since those also tighten up the dialogue by removing ambiguity or making it easier for the user to have confidence in the interaction. Write a short style guide covering things like pace, tone, energy level, vocal attributes, and the overall impression that you're shooting for. Try to create a simple biosketch of a character that might embody all of these attributes. Give it a name if you want. Also, there's a practical reason for creating a persona as well. It's a good grounding mechanism for you long-term. Designers and developers will come and go or multiple people could work on it at once. It'll give everyone something to fall back on for consistency. Finally, don't forget to identify yourself as a separate entity from the Google Assistant. That means greet the user. Number two, think outside the box, literally. It's tempting to draw out a conversation path visually and plug in the dialogue, and then dive right into the code or start stringing together blocks of context to write a working agent, and then back into the experience iteratively. We don't recommend this. You can, but I promise you it'll save time and give you a much richer experience to map out the core conversation paths ahead of time. This doesn't mean just the so-called happy path. It doesn't mean error paths either. Instead, write out your core experiences like you would a screenplay. This can be as scrappy as acting it out and documenting it on paper, or create an interactive prototype you tweak and play with until you're ready to start coding. And then, when you draw out your initial vision, keep it at a high level, where the boxes present entire dialogues or user intents, but leave out the individual wording you'll use in the interaction. Number three, context. Here are just some types of context you can consider and infuse into a conversation to make it more meaningful. Where is the user? What are they doing? What type of device are they interacting on? How is the experience influenced over time? Where is the user's frame of mind in relation to what they're trying to do? Try to cater to their intent, not to a specific feature. Number four, speech recognition technology isn't perfect, but it's getting better all the time. So for the most part, you might want to treat that as a black box that'll continue to improve. You have to, of course, be aware of its limitations, but try to step back and look at the interaction from the user's perspective when something goes wrong. You don't have to try to steer the user back to the original question if they don't get recognized immediately. There are so many reasons they might not have been. People hardly ever say nonsense. Try to take those so-called errors and make them into another meaningful turn in the dialogue. Finally, I leave you with a challenge. This new world of conversation design for machines opens up a great deal of opportunity that hasn't existed before for us to use technology to advance our lives. Sure, as you get started, create some games, but I urge you to think bigger eventually. Help give someone access to information or technology that they couldn't use before because of a physical, mental, or an economic disadvantage. We're excited to help you do that with Actions on Google. Check out the description for some resources, and we can't wait to see what you create. We're bringing together a really talented group of designers and developers to collaborate and innovate and generate exciting ideas for what can be done on the Android platform. Within this context of a sprint, I really think that the distinction between designer and developer is blurred. It's all about problem-solving and getting it done. You're not working with designers as an engineer making a mistake to begin with. I feel like every designer or engineer brings a perspective to a project, and that's what's nice about working with a designer. You think like an engineer and designer comes and brings a perspective. In this group, I'm happy to work with super talented designers. It helps me understand Android better because I see how they're thinking about it. It kind of kills my prejudgments about the product, and I start thinking about it from a fresh perspective. We focus in on generating a broad range of ideas that are really innovative and far-reaching, and then prototype and pull together concepts and prototypes to demonstrate and create a vision for what those concepts could be. I never was really familiar with the idea of using this type of process for ideation, and it's impressive to see the degree of precision that Kai specifically has introduced. In the way that she's run this process, it's been really enjoyable to see specifically how one exercise the next and the next and the next, and how that can actually effectively yield good ideas. We're a very small company, so effectively we're doing similar things all the time, but we often rush straight to the solution. It was nice to see some structure around the process. So it starts here and you don't get to fix it straight away.  And that kind of structure, though it seems kind of burdensome, it actually improved the overall thing we came up with. When you're in a company, you tend to think about how the company does something and how the things that you've learned in the past, and then here is just kind of like a blank canvas again. You get to start new and then rediscover the things that kind of work in a workflow or in a much more creative space. I mean, here we try to build something in three days, which is insane. This is the first time we've actually been in a sprint with just doing Android 2. I would like love to bring some more of the Android sprinting back to our company. I think design sprints facilitate interdisciplinarity, interoperability, and all of the kind of amazing things that can happen from a good collaboration. One of the really exciting features of Android is that it's a very open platform. Anyone can come and write their own apps and create their own concepts. We want to bring that opportunity of openness to the design community and inspire designers to generate concepts and ideas and design really cool apps that leverage the openness of the platform. I was impressed with the openness of Android. It's definitely a unique thing that you might not find on iOS or other systems. In our app in particular, there's things that we definitely couldn't have done on iOS that are actually really useful. And it is nice because the app can organically come with you into the rest of your life. I think for me one of the big awesome parts of it was that I was able to begin to learn Android, which is something that I've always wanted to do as a prototyper. I just would like to get to know Android better and this is like a really big jump start. One of the few constraints that they put on us here at the Design Sprint was like to sort of like come up with something that's like unique to the Android ecosystem. And as we were going through all of our, you know, crazy aids and all of the myriad ideas that we had come up with, we actually abandoned some of them that were cool because they were kind of like something that could feasibly be built on any platform. And I think that giving us that constraint infused our other ideas with more creative solutions and I think what we came up with is like so simple and so delightful and only available on Android. I am Ashok Kumar. I am Ashok Kumar. I used to play a lot of computer games. I was completely fascinated about it. I started to feel like I should prepare such games. I just wanted to learn how these applications react to humans. Somewhere the dots were not getting connected. So I started reading blogs on all the possible online resources. Luckily from GDG Bangalore, I got an invitation for Google Mobile India 2015. If I attend this competition, I could get a sponsorship for nano degree. I was completely excited. I figured out that's what I required to connect the dots. It's like being really in front of our teacher. It enabled me to develop a production-ready application and converting my idea into reality, something that helps education and make the world a better place. Now I am feeling relaxed. When we want to learn something, it's not very comfortable for girls. Generally, they don't go out and learn with other colleagues. They don't prefer learning with someone. The reason I go to Udacity is because a friend of mine told me about how wonderful the course is and even if you know nothing about Android. The courses are designed so that you don't have to have very much detailed experience in Java or Android. So when I started the course, I was very scared that maybe it will be too technical for me to understand because I don't know very much about Android or Java in very deep. How to have some logic into a program and how to code in general. But the instructors like my favorite way, Catherine, she makes it so interesting and so normal. You don't feel like that you are learning something and it's a good way to learn online. Whatever I feel like learning today, I could just go and then search for it and there will be a course available for that. I was an HR. I was working as a recruiter and I was completely unaware as to what I am supposed to do. I used to feel that I just don't want to be a recruiter. I want to be on that other side, talking technology and talking about gadgets and how technology is changing our day to day lives. One of our relatives he challenged me that you are a girl and engineering requires a lot of designs and drawings. I wanted to prove him wrong and that was the time when I heard about Udacity. I started taking some online courses in Java and Android. Very basic things. It is little difficult but it's just that I don't want to feel that sense of regret. I just don't want that.  The quality of the projects is very good. After completing those, you feel like you have conquered something. Actually, I finished my run at V yesterday and so today it's just going to be the celebration. You can be happier to be here to see the launch of the Android Skilling Program. There's going to be so many new great Android developers here in India. Good morning everyone. Thank you so much for coming. Some of you know I'm from Delhi. Always fun coming back and meeting all of you. We can scale up developers and scale up mobile developer training to help make India a global leader in mobile app development. Having the universities teamed up with us in the Skilling Program is going to be a huge opportunity to make a huge difference. Finally, we've launched it. It's been a year since we first introduced this program. Two million developers. I think that it's a really achievable goal and I think that it would do a lot for improving the environment in the country in terms of hands-on programming. So I think it's great. It's a massive number. The possibilities are immense. India will be the largest developer based globally and just to get everyone to start thinking about Android and developing for Android, we're at the cusp of a revolution. Let's do something big. More games, more users, more success. Yes. Developing a successful app isn't easy. To reach a broad audience, you'll need to consider your iOS, Android and mobile web users. And to build for these platforms, you'll need a back-end server to store data and support the apps. Of course, you want to get your users logged in, hopefully lots of users, which means your back-end will have to scale. Then after you've solved your scaling problems, you'll have to find more ways to spread the word to get new users, but have you found a way to measure all this activity? And, oh no, your app is crashing and causing servers to melt down and you haven't even made a dime yet. Don't you wish this could be easier? This is why we built Firebase. It has all the tools you need to build a successful app. It helps you reach new users, keep them engaged, scale up to meet that demand, in addition to getting paid. From the beginning, with Firebase, you'll have test lab and crash reporting to prevent and diagnose errors in your app. Your back-end infrastructure problems are solved with our real-time database, file storage, and hosting solutions. Acquiring new users is easy with invites, adwords, and dynamic links. And, using the authentication component, you can get those users logged in with minimal friction. Once installed, you can keep your users engaged with notifications, cloud messaging, and app indexing. Then, with Remote Config, you'll have the freedom to experiment with new features and optimize the user experience in real-time. And, of course, you can earn money with the same AdMob component that's been monetizing great apps for years. Last, but certainly not least, our all-new Analytics component, designed uniquely for Firebase, brings insight into how well these components are working for you and your users. With Firebase Analytics, you can measure and optimize your advertising campaigns, discover who are your most valuable users, and understand exactly how they are using your app. Now, all these components work great on their own and provide a solid infrastructure to build out your app, but they work even better when combined in creative ways. So let Firebase handle the details of your app's backend infrastructure, user engagement and monetization, while you spend more time building the apps your users will love. To get started right now with Firebase on Android, iOS, or the web, follow these links for more information. Then, to manage and monitor your apps connected to Firebase, there's a web console to view crashes, set up experiments, track analytics, and a whole lot more. And to learn more about Firebase and all of its components, you can read the documentation right here. We can't wait to see what you build. Thank you for joining us here today. India is coming along the way, as I just mentioned. Today, India is the second largest country in the world in terms of number of developers. Soon, it's going to be number one. What we want to invest in is actually training the faculty from your colleagues. The potential is so great, and what Google is doing to help catalyze that innovation is really an exciting time for these campuses. We are really trying to provide the best possible experience to teachers in these faculty hubs, because the first step to training 2 million developers is to train the teachers that are going to teach those 2 million. Industry, as of now, demands a lot of updated curriculum, developing 2 million Android developers. Being working in a technical university we can contribute hugely on developing those 1 million app developers. So we're excited that all the raw materials are there to create an innovation revolution in India. I really think the students are going to make some great things, and I can't wait to see what comes out. There's a lot of potential in India, and we need to take it forward. With Google, we can provide rich opportunities to all. That is the essence of Google Program, which I have seen. This is a good move, and this program will definitely be useful to the students, because app development is going to rule the world for the next few years, really. Hello, and welcome to Google I.O. 2017, our annual developer festival. I'm Timothy Jordan, developer advocate at Google, and I'll be touring the I.O. venue throughout the next three days, exploring the sandboxes, interviewing Googlers, and giving you eyes on the ground. That's right, even though you're joining remotely, this year you'll get an in-depth look at everything happening at Shoreline, not just the sessions. You can follow along on any of the livestream channels on Google.com slash I.O. Google I.O. is an outdoor developer festival hosting 7,200 attendees at Shoreline Ampitheater, along with millions of viewers on the livestream. That's you. And thousands of developers at more than 450 local I.O. extended events across 80 countries. We have 14 content tracks with over 150 breakout sessions all livestreamed on Google.com slash I.O. There's also over 70 codelabs live to get you up and running with our latest APIs today at g.co slash I.O. slash codelabs. But before you get to any of that, let's review a handful of the announcements you just heard. Smart reply, available in inbox by Gmail and Allo, saves you time by suggesting quick responses to your messages. It utilizes machine learning to give you better responses the more you use it, and it already drives 12% of replies in inbox on mobile. Starting today, Smart Reply is coming to Gmail for Android and iOS too. We're excited to announce that our second generation Tensor Processing units are coming to Google Compute Engine as cloud TPUs, where you can connect them to virtual machines of all shapes and sizes and mix and match them with other types of hardware, including Skylake CPUs and NVIDIA GPUs. You can program these cloud TPUs with TensorFlow, the most popular open source machine learning framework on GitHub, and we're introducing high level APIs which will make it easier to train machine learning models on CPUs, GPUs, or cloud TPUs with only minimal code changes. Many top researchers don't have access to anywhere near as much compute power as they need to help as many researchers as we can and further accelerate the pace of open machine learning research, we will make 1000 cloud TPUs available at no cost to ML researchers via the TensorFlow Research Cloud. Android O, coming later this year, will bring more fluid experiences to your smaller screen as well as improvements to battery life and security. With Pitcher & Pitcher, you can seamlessly do two tasks simultaneously, and smart text selection improves copy and paste by using machine learning to recognize entities on the screen. Google Play Protect is Google's comprehensive security services for Android, which provides powerful new protections and greater visibility into your device security. Play Protect is built into every device with Google Play, is always updating, and automatically takes action to keep your data and device safe. We also have an early preview of a new initiative for entry-level Android devices that internally we call Android Go. The goal is to get computing into the hands of more people by creating a great smartphone experience on all Android devices with one gigabyte or less of memory.  Of course, way more was covered in the Google Keynote, including new ways to share with Google Photos, including photo books, new ways that Google Assistant can help you do even more investments in the core technologies that enable VR and AR, and in platforms that make them accessible to more people. Have questions about IO17? Tweet them starting today through May 19th using hashtag IO17Request. A team of Googlers will be on-site chasing down answers for you. Make sure to also follow the conversation on hashtag IO17 and on the Google Developers blog. Make sure to tune in to the Developer Keynote at 1 p.m. Pacific Time, and I'll see you right here on the livestream between all the sessions. This is Google I.O. 2017. Hello and welcome to Google I.O. 2017. I'm Timothy Jordan, and I'll be here between sessions to guide you around the in-person experiences at the festival. That's right, even though you're joining remotely, this year you'll get an in-depth look at everything happening on the ground. Have a question about IO17? Tweet it our way today through the 19th using hashtag IO17Request and a team of Googlers will be on-site tracking down answers for you. You just saw our Developer Keynote where Jason Titus led you through our investments in tools and services for developers. That's you. It's our goal to simplify repetitive tasks like dealing with user login, analytics, or synchronizing real-time data. We're providing tools to make it easier to solve these and other everyday problems in simple and powerful ways, and we want to help you build amazing new experiences with machine learning, VR, and voice-enabled interactions. Let's review a handful of the announcements you just heard along those lines. Android is officially supporting the Kotlin programming language, in addition to the Java language and C++. Kotlin is a brilliantly designed, mature, production-ready language that we believe will make Android development faster and more fun. Android Studio 3.0 Canary is our new preview that includes three major features to accelerate the development flow, a new suite of app-performance profiling tools to quickly diagnose performance issues, support for the Kotlin programming language, and increased Gradle build speeds for large-sized app projects. With Firebase, we're providing more insights to understand app performance through a new product, Firebase Performance Monitoring. We're also introducing integration between hosting and cloud functions, adding support for phone number authentication and improving analytics. Oh, and we've also started open-sourcing our SDKs. We've introduced new innovations for you to make it easy for your users to pay for services with the Google Payment API to build profitable businesses with a completely redesigned AdMob and to grow a user base with universal app campaigns. There are several powerful new features and reports in the Play Console to help you improve your app's performance, manage releases with confidence, reach a global audience, and grow your business. Android Instant Apps is a new way to run Android apps without requiring installation. Now anyone can build and publish an Instant App. There are also more than 50 new experiences available for users to try out from a variety of brands such as Jet, New York Times, Vimeo, and Zillow. And finally, we're adding two new certifications for web developers, the mobile site certification and the mobile web specialist certification. Those are some of the highlights. Check out our Google Developers blog for a more in-depth recap of this afternoon's announcements. We have 14 content tracks with over 140 breakout sessions all live-streamed, and in between them all, you'll be your all-access pass with sandbox tours, interviews, and even a peek or two at the parties. Tune into the live-stream on Google.com slash IO, catch me in-between sessions on any of the live-stream channels, and follow the conversation on hashtag IO17. This is Google IO 2017. Good afternoon, everybody. Thanks for coming to IO 2017. Yes, we got a great one to start. I'm so excited to kick this off. My name is Taylor Savage. I'm a product manager here at Google on the Chrome web platform team. Now, we work on a number of different web developer-facing products on this Chrome web platform team, and here today I am here to talk about one of our biggest, which is the Polymer Project. So the Polymer Library is a small JavaScript library that makes it easier to build web components. Now, building big complex things out of smaller, less complex things is a pretty fundamental part of any engineering discipline, and it's certainly fundamental to web development. It's hard to imagine building any kind of large, complex website or web app of any meaningful scale without some way of encapsulating and reusing logical and interface components. In the past, though, the web platform itself has never really provided us developers with a clear way to build components. We've had HTML elements baked into the platform, but we haven't had a platform-provided way to actually design and build our own components. That method has been nowhere to really be found. So as developers, we've always had to kind of drag along our own component model in JavaScript. So along with our application code that actually ran our applications, we've had to ship an invented abstraction in order to build any sort of meaningfully large application or to be able to reuse components in any sort of meaningful way. Now we have web components. Web components provide us with a very flexible, a very low-level, but a fundamentally standardized way for building components on the web. It gives us encapsulation and reusability and interoperability all things that a good component model needs, but baked directly into the web platform itself. Now we've been excited about the prospect of web components for a few years now, and we've been working hard on the Polymer project to make it easier to take advantage of the promise of web components today. But this year, this I.O. is by far the most exciting moment that we've ever had throughout the entire history of web components. Because as of this year, Safari now natively supports web components. Yeah. Yeah, this is incredibly exciting with Safari 10. The Safari browser shipped native platform support for custom elements and Shadow DOM, the two most critical web component APIs. Chrome supports these APIs. Opera supports these APIs. We've been on stage at I.O. promising web components for a few years now, but now they're here. They're actually here. So with these browsers, there are over a billion active mobile devices in the world, in our pockets right now, in all of your pockets right now, that natively support web components with their browsers. Web components are no longer some distant future. Web components aren't really even that cutting edge anymore. Web components are just a reality of today's web. A massively powerful new tool in our toolbox as web developers, and really a deeply fundamental change to the way the web platform itself works that makes it a much more capable development platform to build the types of experiences that all of our users expect today. So our mission on the Polymer project on the Polymer team is not just to build useful tools for web development, but to work to fundamentally move the web platform itself forward, and to make this future of web development more possible today. So the Polymer project as a whole started a few years back with a directive from some engineers on the Chrome team, and they said, we need to put together a team of web developers that can live in the future, on the web platform, not as it is today, but as it will be, and then kind of report back to the present to help us, the web platform team on Chrome, know what direction to go. So the Polymer project in this way was kind of designed as a laboratory for future web platform features that we wanted to bake directly into browsers. To find out what worked, to find out what didn't work, to provide feedback back to browser implementers and spec writers, and to do whatever we could to then bridge the gap between the web platform as it existed today and the new platform features that developers were going to be able to take advantage of in the near future. So fortunately, we are not alone on the Polymer project in this mission. We have friends also looking towards a web development future. In fact, we have a lot of friends looking forward to a web development future. The open source web ecosystem is a dazzling place. There is a ton of innovation, as everybody here knows, happening all the time when it comes to web development. React has brought functional reactive programming for UIs into the mainstream. Preact has made this possible at a fraction of the size. View takes a very bottom-up and modular approach to framework design. Spell looks to start with this framework and then compile it all away. There's so much exciting stuff happening all the time in the web development open source ecosystem. It's an awesome place to work. There are luminaries charting new paths, trying new things, guiding the way all the time. So on the Polymer project, we look at our mission, we look at our contribution to this open source ecosystem through the lens of being part of the web platform team here at Google. So the Polymer team itself is really half web developers and half web platform implementers. And what we quickly realized was that web platform users, web developers, framework authors have ways that they like building web apps. And web platform implementers, so browser engineers who spend their days optimizing platform features, building consensus around new platform features and APIs across different browser vendors, web platform implementers have ways that they think web apps should be built in order to be fast, in order to take advantage of all the things that this web platform does well and avoid the things that it doesn't do well. And these two worlds, how web developers like to build and how browser implementers like to build, sometimes don't agree. And sometimes they loudly disagree. So before web components, in order to build an application of any meaningful scale or size on the web, you needed to use a large JavaScript framework. It was an absolute requirement. And JavaScript frameworks can be really amazing.  They help developers avoid foot guns that are in the platform. They grow large communities and ecosystems in and of themselves in their own rights. But fundamentally, as web implementers, we see the fact that you can't really build apps with just the platform as a flaw of the platform itself. So with the Polymer project, we are pushing to make it possible to build and deploy apps that are closer to the web platform and use that platform the way implementers intend it to be used rather than substituting a separate platform on top. And we think, of course, that there can be some very real benefits to using the platform directly to build an app. We need to have a better interaction, shallower learning curves, better performance, better usability and interoperability, faster load times, and ultimately a better user experience. So we sum up this mission in our slogan and rallying cry, which is to use the platform. There are two properties of the web platform that make it great. One is it's standards-based, and two is that it's open and distributed. Anyone can look at the specs and build a browser to see if they are open source and no single entity can decide what makes up the web. So what we end up with is a number of different browser vendors in this collaborative competition with each other, this cooperation, each looking to provide a great user experience to its users in its own right and each building off the same kind of general set of specs, but inevitably providing its own slight interpretation of what this web platform is. And so the end result is a web platform that moves very slowly and very methodically. Now there are benefits to a slow-moving methodical platform, but today more than ever, we need that platform to change and to adapt. The original web platform was designed for documents, and then it allowed you to style those documents and then maybe it allowed you to script some things in those documents, but the platform itself wasn't fundamentally constructed around the idea of building applications. It's lacked very basic things you need to build an application. It lacked proper encapsulation. It lacked a component model. It lacked an efficient way to load resources. And frameworks do an amazing job of making it possible to build apps that can survive on this web platform. They bring along the things you might need to build an app. They provide encapsulation. They provide a component model. They create a layer of abstraction that lets developers do things that the low-level web platform hasn't let them do. On the Polymer project, though, we have our web platform hats on. We have our browser implementer hats on. We want the platform itself to be rich and lush and powerful. We want the code you write to be eminently reusable. We want it to be more maintainable. We want it to be lighter weight and faster. We want it to be possible to build higher quality applications closer to this platform itself. And for your applications built close to this platform to directly benefit from all the hard work that's going on all the time to make the platform better and faster. So on the Polymer project, again, with our web platform hats on, we don't want to find a way to work around the web. We want to terraform the web itself. We want to make it easier for developers to take advantage of what the platform does well and actually change what the web doesn't do well. And that is what we mean by use the platform. Now, of course, use the platform doesn't necessarily mean use only the platform and nothing else. That's not reasonable. There's this wonderful symbiosis that exists between the platform and the JavaScript community. And there's plenty that other frameworks can do that the platform can't provide, that Polymer can't provide. There's plenty that libraries and tools can do that wouldn't necessarily make sense in the platform or that you couldn't reasonably build cross-browser consensus around in order to get baked directly into the platform. So with use the platform, we're just trying to go from the bottom up. We're trying to help raise the tide of the partnership code that's absolutely just the code that's absolutely unique to their application and let the platform itself handle more and more of the glue. So the ultimate success for us on the Polymer Project would not to be to have everyone in the world using Polymer. The ultimate success for us would be for the platform itself to be powerful and extensible enough that Polymer and our tools would no longer have to exist at all. So with web component shipping broadly, along with other new powerful platform features like HTTP2, like ServiceWorker, use the platform is not some hypothetical vision. It's a very real strategy that major companies and major projects are using today. So we get asked a lot who is using Polymer? And the answer is a lot of people. So Comcast, the largest media company in the world, uses Polymer to share components across multiple different Xfinity properties that they own. USA Today uses Polymer to build rich interactive experiences like they had for the Olympics and the election. ING, the largest online bank in Europe, uses Polymer to share components across the dozens of different applications they have built for dozens of different markets. Netaporte, the largest luxury fashion e-commerce company, uses Polymer to share rich components to keep a consistent design across multiple properties and pages. BBVA, one of the largest banks in Spain and Latin America, uses Polymer to share components to be able to quickly build new applications. Coca-Cola, the largest beverage company in the world, uses Polymer components to ensure consistent branding across all their different digital signage. Electronic Arts, one of the largest game companies in the world, uses Polymer components to quickly spin up beautiful new sites for all the new games they're coming out with. And General Electric uses Polymer for Predix, which is their industrial Internet of Things platform to make it easy to build all kinds of great data visualization applications on top of the Predix platform. So companies around the world are using Polymer to build applications, and companies around the world are also using Polymer and the Polymer App Toolbox to build lightning-fast progressive web applications that use less data that load fast. Sites like Jumea Travel and Conga, the two largest e-commerce platforms in Nigeria, have production progressive web apps built using Polymer. Wego, one of the largest travel booking sites in the Middle East in Asia, has a blazing fast progressive web app built with Polymer. And OlaCab, the largest ride-hailing company in India, just launched a progressive web app using Polymer. And of course at Google, we like to use the platform as well. So there are over 700 Google projects that use Polymer. In fact, Polymer is one of the largest front-end dependencies used here at Google. We use it in production on products like Chrome and YouTube Gaming and Play Music. The new Google Earth just launched using Polymer. And the new YouTube redesign is built using Polymer, one of the biggest web properties in the world making a bet on web components. So we're seeing huge momentum in Polymer web components, but this is only the beginning. We've been working on a ton of new stuff as well, which we're extremely excited to share with you today. So here to talk about some of the latest projects that we're working on on the Polymer team is Wendy Gitzberg, the product manager of the Polymer project. Thanks, Taylor. The first version of the Polymer library was released about three years ago, and it was one of those, you go live in the future, report back and tell us what you found, proof-of-concept projects that Taylor was talking about before. It was a proof-of-concept that you could take these nascent web APIs and wire them together in such a way that you could build encapsulated, reusable, platform-based components. And we hacked through that for a while, explicitly as a non-production-grade developer preview, but that didn't really seem to stop anyone. We saw that developers were still picking it up and trying it and using it, and they really liked it.  So we took the next logical step, and we decided to move out of a proof-of-concept and take Polymer into the big leagues to graduate a little bit as a production-quality web-components library with Polymer 1.0. And since we launched 1.0, we've seen a great deal of advancement and traction that Taylor was talking about before, and Polymer 1.0 came a really long way on its own. We've seen a flourishing production in web apps all the way from Southeast Asia to North America. And with these web-components APIs supported widely across browsers, we have the perfect opportunity to realize this initial vision even further. So we've taken the best of the Polymer library and the best the platform has to offer and fused them together to form the next major version of the Polymer library. I'm proud to announce Polymer 2.0. Polymer 2.0 is based on web platform standards that are natively supported on over one billion mobile devices. Because of advancements in the platform, Polymer 2.0 is one quarter the size of 1.0. And all of this makes web-components built with Polymer 2.0 interoperable by default, meaning you can use them more easily in popular JavaScript frameworks. Here to talk more about Polymer 2.0's main goals and how we achieve them is one of the tech leads on our core Polymer team, Kevin Schauff. Thank you, Wendy. So on behalf of the entire Polymer engineering team, we are really excited to get this new release out to all of you. So I'm going to give a brief introduction of Polymer 2.0 by talking about three key goals that we organize ourselves around for this release. So first is aligning to the latest platform features that are shipping across browsers today. Delivering on the promise of web-components interoperability and then providing a smooth migration path for our existing customers to Polymer 2.0. So in the last couple of years since Polymer 1.0 shipped, all of the web browser vendors got together and agreed on a new set of web standards for defining web components. And in the modern browser, defining a new web component is as simple as writing an ES6 class that extends from HTML element. Now you may not be familiar with HTML element is actually the built-in base class that all elements in the browser extend from. And now using ES6 classes, we can do that very idiomatically. This is as simple as it is to define a new element that extends the browser. And then by registering that element in the custom elements API, we can associate that class with an HTML tag name. And then anytime the browser sees an instance of that element, either in static markup or created dynamically, say via a framework, it's going to create an instance of our class. It's going to run the constructor. And it's here in a few other lifecycle callbacks provided by custom elements that we can implement the unique behavior of our element. And that's where Shadow DOM comes in. So Shadow DOM allows us to create a scoped subtree of Shadow DOM that's completely hidden from the outside. All of the styling in DOM are completely encapsulated and self-contained. And this is the real key to ensuring that web components are interoperable and can run in any environment. And what's awesome is that the code that I had up there on that previous slide requires no library code at all. So that three or four lines of JavaScript, we can actually just paste into an inspector, plugged into any one of your phones right now, hit Enter, and it shows how to construct and render that element, that component. Web components are native, right? So you may be wondering if the browser is becoming so capable, if we have this built-in component model, why do we need Polymer at all? So Polymer's goal in life is to fill in a few key features that we find useful when building custom elements. Things like being able to render the contents of the Shadow DOM from a template, keeping the elements in that template in sync with the element state via data binding, a little bit of declarative sugar for things like custom event handlers. And then Polymer elements also keep their property and attribute APIs in sync so that you can send initial configuration down in markup and then interact with your element after that via properties in JavaScript. So this is a sampling of the features that we provide in Polymer. In Polymer 1.0, we provided these as kind of an opaque function call that kind of hid a lot of the beauty, the elegance of web components. So now that ES6 classes are native in the browser, we're actually, in Polymer 2.0, moving to a new syntax where we're layering the Polymer features onto that native, elegant syntax in the browser. So if you're just getting started with web commands, I actually really recommend you take this little snippet of code and play with it in the inspector in the browser. You can just get a feel for the web APIs right there. And then as soon as you're ready to start layering in some of the functionality that Polymer provides, it's as simple as changing the base class so in Polymer 2.0 to use the features of Polymer, all you have to do is extend from Polymer element instead of HTML element and then provide a little bit of metadata on your class to start taking advantage of those features. And because we're aligning to the ES6 class syntax, you get things like native inheritance for free. So you can extend an element that you've created or found on the internet, change some of its implementation details. I might return a different template that I want to render and define a new element that has some extra information from functionality. So to recap, Polymer 2.0 is aligning ourselves to these new platform features that are shipping across all of the web browsers. So ES6 classes, custom elements, Shadow DOM, and CSS custom properties. So I didn't really show custom properties in action, but this is very analogous to how custom elements allows us to extend HTML. CSS custom properties are a new native browser feature that are actually shipping across all browsers now. As of Edge 15 that shipped a couple of weeks ago, we can now use CSS custom properties to define a custom styling API for our custom elements and for that Shadow DOM. And of course, for the remaining browsers, which are mostly users on desktop, right? So most of our mobile browsers with Chrome and Safari all have all of these features natively. For the remaining desktop browsers, we'll continue to provide a set of high quality production polyfills that you can use to target all of these features. And the result of all of this is a dramatic reduction in code payload. On top of using these platform features, we're also shipping Polymer 2.0 with an improved polyfill loader that detects the capabilities of the client and only loads the polyfills necessary for that individual browser. And the result is this really nice reduction in payload. So as the capabilities of the browser go up, the amount of code that you need to load and run on the client to use all of Polymer's features goes down. And if we compare this to Polymer 1.0, you can see this is a huge improvement, especially for the most capable browsers. We're able to use Polymer's features in a fraction of size. And this slide right here is really the promise of Web Components in action, right? Aligning to the latest platform features. So I'll move to the next goal. This is around interoperability. And interoperability is a feature of Web Components that we promised from the beginning. That building your components around a state of a set of standard APIs that the browser can use in any environment means that you can use them in any environment. So we've always known that Polymer elements could be used here in static markups from the server or inside of other Polymer elements. But the promise has really been that you could use Polymer elements here in Angular component, for example. Or even in some of the hottest new JavaScript frameworks out there like Preact. But unfortunately in Polymer 1.0, the realities of polyfilling these browser features kind of got in the way. When we set out to ship Polymer 1.0, we found that the mobile browsers of the day kind of back in 2014, weren't capable enough for us to robustly polyfill the entire Shadow DOM spec. And so we made a conscious decision to really, we really reluctantly shipped a proprietary API for interacting with Polymer elements in the DOM that mimicked a lot of the Shadow DOM features so that you could use those features today on those underpowered devices. But unfortunately, this obviously broke that promise of interoperability. So I'm really excited to say that things are different now. With all of the mobile browsers that we're all using now shipping Shadow DOM and now being able to leverage Shadow DOM, the importance of the polyfills is slowly fading away. And so in Polymer 2.0, we've taken the opportunity to rewrite the Shadow DOM Polyfill to be completely transparent so that any framework that's rendering the DOM is actually using Shadow DOM. And the result of this is that Polymer elements built with Polymer 2.0 will now be able to be rendered by all of the JavaScript libraries out there today. And as you know in the JavaScript community, all the frameworks that everyone's going to be using tomorrow are probably going to be totally different. But the key point to take away is that elements built with Polymer 2.0 and Web components will still be compatible with them, right? The promise of Web components. All right, so last I want to touch on the migration path that we've charted for Polymer 2.0. So as Taylor mentioned, there's a ton of really awesome companies making huge strategic changes to Polymer and Web components. And we're really excited to get this release out to all of you. But we also know how scary a big breaking change can be to the foundation of your tech stack, something like the component model that you're building everything from, right? And so we spend a ton of time and effort on the Polymer team to craft a really nice migration path from Polymer 1 to Polymer 2. So on the left here, I've got an example of the Polymer 1.0 syntax. And if you're not familiar with it, that's fine. All I want to do is get your attention to the right and get a feel for the amount of work that will be required to port from Polymer 1.0 to Polymer 2.0. All right, everybody spot the difference? That's right, there's not any. Because Polymer 2.0 is shipping with a backward compatibility layer that allows elements written with the Polymer 1.0 API to still target Polymer 2.0 and all of the native browser features that we're taking advantage of. And so for the vast majority of Polymer 1.0 code out there, the only changes to migrate are some minor changes to the template to align to the new Shadow DOM spec. But that's really mechanical. So for the users getting started with Polymer 2, we'll have a really nice set of options for getting started. A lot of users will be able to just start right with the ESX class syntax and get all the benefits of using native classes in the browser like inheritance and native supercalls. On the other hand, a lot of users that have existing Polymer 1.0 code will be excited to be able to port that to 2.0 as quickly as possible. And for those users, they can just simply load the compatibility layer, make those minor changes to the template and be off and running. And then migrate ESX classes in over time as they see fit. And then last, we're also shipping with what we're calling a hybrid pattern which allows users to port elements to a common subset of features in Polymer 1.0 and 2.0. And then those elements can actually run in applications targeting either version of Polymer 1.0 or 2.0. And this will be really useful for organizations shipping a lot of components to a lot of production applications at the same time because it means they won't have to freeze their application development while they're porting their whole element set.  We're also hearing really good things from the community that the migration from Polymer 1.0 to 2.0. So that's Polymer 2.0 in a nutshell. We're aligning to the latest platform features. We're delivering on the promise of WebCabon center operability, and we're providing that smooth migration path for people to get up and started with it today. So with that, I'll hand it back to Wendy to talk about all the other awesome stuff that's happening on the project. Thank you. All right. Thanks, Kevin. So the Polymer project isn't just about the Polymer library.  The Polymer web development nowadays can be unnecessarily challenging. So we bring a whole suite of tools, libraries, and patterns to support you. We have our elements, a collection of about 100 web components made by our team. This includes Material Design UI components, Firebase integration pieces, data storage elements, and much more. To make development with web components as streamlined and accessible as possible, we have a full suite of web component that allows you to use Polymer or any other sort of web components you're using. To learn best practices for rendering web components both reliably and at scale, we've created a few helpful patterns. Most recently, we've developed the purple pattern, which focuses on fast-first load emphasizing time to interactive and reliability in all network conditions, including usability offline. And with the Polymer library is the foundation for building components and tools and patterns to help along the way. We've also gone that next step and built the Polymer app toolbox. The Polymer app toolbox is a set of tools, templates, and off-the-shelf components to help you build web component-based progressive web apps more easily. So that's quite a lot under the Polymer project umbrella. And over the past year, we've advanced each portion of the library and the other projects to pack in more power and help you build for the future of the Polymer app. So the Polymer library exists to help you build encapsulated reusable components. We know this. So, of course, the Polymer team uses it ourselves to power all of the elements that we've made. And as Kevin mentioned, we've taken all of our elements, about 100 of them, and ported them over to hybrid mode so they can be used in projects built with Polymer 1.0 or 2.0. And so, sure, there are a bunch of elements that we've made, including source, off-the-shelf, high-quality web components that you can use today. And if you want to find any elements to use, they're all conveniently located in the same place. On webcomponents.org. Webcomponents.org launched just a few months ago, and it's a consolidated home for high-quality, open-source web components of all types made with plain JavaScript or library-based. And since it's released just a few months ago, we've seen an overwhelming wave of organic growth on the site and the community around it. As of now, there are almost 1,000 elements up there to choose from. And besides that large selection, there's a rich feature set on the site that makes it an awesome place to search for, try, and vet components before downloading. So there's automatically generated documentation across the entire site that gives a consistent look and feel no matter which component you're looking at. There's also inline editable demos. So if you watch here, if you're looking at this game card component, you can click, see that CSS animation inline. You can even edit the attributes down there and change the rank to an ace of five. It updates real-time, pop in another one, unrevealed, and the card flips over. It's pretty awesome. You don't have to download a thing. This works right there on the page. We also have collections. If you want to make it even easier to find different elements that are related, this is the Google Cast Collection. So if you want to add Cast Integration to any of your projects, it's as easy as finding this collection and popping one of those elements in. There's also a couple from IBM Research and other developers in the community who have collected really great components together. And lastly, if you really want to vet and see how popular a component is before you download, here's a super helpful one if you want to add emoji range to any of your projects, because, of course, we all want to do that and we've got 120 stars on GitHub. You can check out Forks, Active Maintainers, and see the health of an element in the open-source community before downloading. And lastly, I just wanted to show some super cool elements that I really like that you can install, import, and insert directly into your code. On the top left, you can check out that game card. It's got those beautiful CSS animations and resizable SVG graphics. The cleans and the jacks look awesome. There's that sign here element with a really cool ink texture for the signature. And there are way, way more. And if any of these look cool to you, just remember that this is a tiny sampling of what's on webcomponents.org. And there are many more useful interoperable components. Anybody can get up there and publish an element. So anybody here, if you want to go home tonight and do that, it's open to you. And a big reason I really love webcomponents.org is because of that community-driven variety that only continues to grow and flourish, including web components of all types, because Polymer is just one way to build web components. It's that same philosophy which inspires our tooling team's commitment to building tools for all web components, not just those built with Polymer. Because it's 2017 and where would a web developer be without her trusty tools? I know that a lot of developers, including myself, have a love-hate relationship with tooling, so we make sure to make our tools as straightforward as possible so they really empower you while you're developing to be better. Two of our most popular tooling projects are our IDE plugins and our CLI. And yes, they work for Polymer and vanilla web components. I'm not going to go into too much detail on these because we have a whole talk about this tomorrow. But real quick, our IDE plugins are awesome for Polymer and web component development. We have them for Adam and VS Code, and they include features like type ahead completion, real-time linting, real-time error checking, and even inline documentation, so you can check out docs as you're typing to get reminded of different properties. We also have the Polymer CLI, which you can think of as your web component multi-tool or your Swiss Army knife. And it's simple, it's smart, it's got just a handful of really powerful commands that make building with web components smooth and efficient. So by using the Polymer CLI and all of the commands, you can get a web app template with a responsive design, client-side routing, and an automatically generated service worker with little-to-no effort on your part. Just a few command line scripts. So our CLI is built around the concept of taking all of the best practices of progressive web apps with web components and making them as simple and straightforward and accessible to achieve as possible. So I wanted to dive into one of our newest best practices how many of you are familiar with the purple pattern? Oh, awesome. Awesome. So the purple pattern was designed by the Polymer team to promote efficient scalable loading on client-side web apps. We introduced it last year, actually Kevin did, on the stage at I.O., and we've seen it really take off since then. You'll hear a bunch of folks talking about it at I.O., including Adi Asmani and Alex Russell, and it's pretty apt that Alex Russell talks about it. So some of you might be familiar with Alex Russell or slightly late on Twitter, but if not, know that he, one, cares a lot about web performance, and two, is very active about that on Twitter. He's also an engineer on the Chrome team who sits just a few feet away from us, and us being on the same team does not make us immune to that. It actually makes us a really conveniently located audience. So in fact, it was one of our many performance discussions with Alex that led to the creation of the purple pattern. So you all have to him to thank for that. And even though we read it as purple, it has nothing to do with the color. It's just a really convenient acronym highlighting key loading techniques, and you could think of it a lot like AJAX, and that it doesn't specify one specific API that you must use, rather kind of a roadmap for how you should be building and loading. The first P stands for push, proactively delivering all of the resources necessary to satisfy our users' initial request, and you can do that using HTTP2 server push or preload. R is for render, render only the requested route, because the most important thing when loading is getting that initial critical view rendered and interactive. The next P stands for pre-cache. Pre-cache the resources necessary that a user might want to access later, and you can do this using a service worker, and that will keep you one step ahead of a user as they interact with your app. And L is for lazy load, which is how you'll be loading your code or your resources, whether that's from the cache or by making an additional network request. So this might seem like a lot to do, but with the power of the Polymer CLI, and mostly just the inherently granular declarative and low over nature of web components, we've done much of this grunt work and automated it away. So now getting started with purple is as simple as choosing a purple-ready app template, running a CLI command or two to let us analyze your dependency graph and generate a manifest, and then follow instructions to deploy to a serving environment, like Firebase or App Engine. That's it. And if you want to learn more about purple, you can see it in action, both in demos and production today. Purple is actually being used in the most high-profile PWA on the web, Twitter Lite, Twitter's new progressive web experience. And Twitter Lite isn't even built with Polymer. It's just using these purple principles in action. But if you want to build purple experiences faster, we've got you covered with the Polymer App Toolbox and our Polymer App Toolbox sample apps. Polymer News is a full-featured, open-source progressive web app built using the Polymer App Toolbox. Along with a demo and all of the code, full documentation, outlining our design decisions, architecture choices, and even advanced features, like integration with AMP or how to include ads, all of that is outlined for you online. But that's not all our apps team has been working on. We tasked a few of the engineers to build something awesome out of the newest APIs. We challenged them to deliver a mobile web experience that you would only expect from native and, of course, do it in a fraction of the size. And they did. And they called it cheese. So let's take a look at the demo. When cheese opens up, it looks like a native app, but I can assure you it is a full web experience. It's got that jumping up and down button that says, say cheese at the bottom, encouraging you to either upload a photo or take a photo. So we're going to upload a photo. And the photo pops right onto the screen and you can see these beautiful CSS animations scanning the image for facial expressions and for her face.  It's pretty cool, yeah? And then you can even swipe through and find all of the other great things we've added. And when you find one you like, let's go all the way back. I think I like that first one a little bit. You can even move the emoji. So maybe we want to take the cheese off of Valjean's head and put it on a Frankie's because he looks pretty good with it. And then you can download the photo and share it later. And as you can see, our team, our family, our friends had a blast using cheese and Google's Vision APIs to jazz up our photos with emoji. You can check out Kevin's kids looking really great there. My dad blending in with some sheep in the top left. And it was really fun to use cheese but Frankie, Valjean and Keanu who built it had such a great time building it because they got to use all the latest web technologies. They built a Polymer 2 class-based syntax progressive web app using purple pattern with H2 push on Firebase. All of that earned them 100 out of 100 on Lighthouse which means it has offline support. And it uses Google's machine learning technology through the Vision API to power all of that finding your expression, finding your eyes, your nose and even cooler it's got some great accessibility features. So it uses Google AI to read your image, figure out what's in it and add an alt tag right on there so you can use voiceover and listen to what you took a photo of. It's pretty crazy. Here's the URL for cheese cheese.polymer-project.org We'd love to see your selfies whether you're here at I.O. or watching somewhere around the world and then you can share them with us on Twitter. See if you can come up with any crazy combinations. So that's everything. That's the Polymer 2.0 library built for platform-based interoperable web component development. Web components.org and our house-made Polymer elements all ported to hybrid mode, a suite of web component tooling with our CLI and our IDE plugins, the purple pattern for scalable, efficient loading and the app toolbox and app toolbox reference implementation, Polymer News. This is our mission in action, bringing the future of web development into the present by enabling web developers to more easily lean on everything new and powerful the web platform has to offer. We are committed as a team to researching and developing better ways to leverage all of these new platform features. We're going to continue to advance our library and support developers and companies large and small that depend on us and we'll focus on spreading news and best practices to make sure that developers can build with the platform symbiotically for the long term. The future is here and with all of the recent and revolutionary platform advancements right now is a really awesome time to be a web developer. So we hope you enjoyed hearing all about the latest releases from Chrome's Polymer project. There will be many, many more ways to learn about us all throughout I.O. In fact, this is our largest presence at I.O. yet. If you want to learn more, yeah. If you want to learn more about 2.0 and Alucard, you can check out Monica's talk bright and early 8.30 tomorrow on stage one. If you want to learn more about tools, you can check out Justin's talk tomorrow right here on this stage at 3.30. We've got refreshed brand new code labs. We've got onboarding material on our site. We're going to be in the web sandbox and at office hours. You can come talk to members of the team. Most excitingly, you'll have to make it to the after hours event tonight to check out the Polymon battle stage. If you were at CDS, if you played Santa Tracker, if you're at the Polymer Summit, you'll know about this. But it's a progressive web app where you can battle with your team. And if you want to see even more about Polymer after I.O. is said and done, there's a full event dedicated to it, the Polymer Summit. And we're extremely excited to bring it back for a third time in Copenhagen. The summit will be in Copenhagen on August 22nd and 23rd. And this time we want to hear from you, the community. So if you want to talk on stage at a Google developer event, now is your chance. Go to this URL at co-slash Polymer Summit 2017 to hear more about tickets, which are free as always, and updates. Hope to see you all there. That's all for us. If you have questions or just want to say hi, feel free to stop by. Thanks. Welcome. This is our first certification summit. You guys and ladies are among the first certified Android developers. The developer base growing very fast. Going and becoming the largest developer base in the world. The interesting point is that India is a mobile first market. However, the percentage of developers developing for mobile is relatively low. So we're trying to really supercharge that. India is one of the emerging markets. 80% of the smartphone growth rate is expected till 2019. You guys are Android certified developers. And just imagine that you are going to reach these many people with your applications that you're going to develop. They're not trying to solve for the entire world. They're trying to solve for their own users. You are at the end of the day developing a product, not for you also. You're developing for an consumer. So I'm going to talk to you guys about what's new with Android O. Any of you guys use some of the Firebase 2.0 features? Yes. It's about recognition about getting a job. It's about growing your career. But there are bigger forces at play. I feel that development, mobile development, Android can make a difference actually in the world. Fixing problems in one's own community. Whether it's water, education, environment. But we want to support you connecting to communities and create change in the world. Firebase makes authentication easy for end users and developers. Most applications need to know the identity of a user so they can provide a customized experience and keep their data secure. Firebase supports lots of different ways for your users to authenticate. If your users want to authenticate with their email address, you can build that for them. Firebase Auth has built-in functionality for third-party providers such as Facebook, Twitter, GitHub and Google. It can also integrate with your existing account system if you have one. You're given the choice about how to present login to the user. You can build your own interface or you can take advantage of our open source UI which is fully customizable and incorporates years of Google's experience in building simple sign-in UX. No matter which one you use once a user authenticates three things happen. Information about the user is returned to the device via callbacks. This allows you to personalize your app's user experience for that specific user. The user information contains a unique ID which is guaranteed to be distinct across all providers never changing for specific authenticated user. This unique ID is used to identify your user and what parts of your backend system they're authorized to access. Firebase will also manage your user's session so that users will remain logged in after the browser or application restarts. And of course it works on Android, iOS and the web. That's Firebase off allowing you to focus on your users and not the sign-in infrastructure to support them. Did you know that the average user has 36 apps on their device and doesn't use three quarters of them most of the time and of those about one third of them have only ever been used once. Well what if that's your app? You've done the research, you've written the code, you've performed the testing you've perfected the design you've gotten the installs and then nothing. So how do you prevent this? App indexing helps you re-engage with your users through tight integration with Google search. As well as appearing in search results it surfaces your app through autocomplete and now on tap. All you have to do is get your app in the index and when users search for the content that's already in your app they'll be able to see your app directly in the search results and be able to launch it right from there. It's as easy as that but how does it work? If your app and site have similar content you associate them with each other. Then your app can receive incoming links from search. On Android these are achieved using standard Android app links and on iOS using standard iOS universal links. When a user searches for your content they can then find your app. If you have the app installed it will allow you to link directly to it. When the app launches it sees the address of the index content and decides which screen to load to show it. It's really as easy as that. You can also use the app indexing SDK to submit content of the search engine based on how people use your app content. When people use your app your search position can be improved. With app indexing you get into the index putting your app into Google search and allowing you to re-engage your users. So you've built an amazing mobile app that your users are going to love. But you want to get into people's hands and let them see just how awesome it is. Well AdWords helps you do this putting ads for your app in front of billions of people that use search, YouTube, Google Play and more. You can quickly set up an ad campaign to reach the type of users that might be interested in your app. You only pay if the user clicks on that ad and you can set the budget and acquisition costs that you're comfortable with. But how do you know you're reaching the right users? Maybe some will install your app and forget about it, while others will make it part of their daily lives. Firebase Analytics helps you do this. You can define events that happen in your app that you consider to be important such as reaching the first level of your game, purchasing a fancy new pair of sunglasses or returning every morning to check out new products. You can tell AdWords which of these events are most important to you. Then AdWords will display ads to people who are more likely to complete these important actions in the future. You can also build audiences which are specific segments of users and have AdWords display your app to them. For example, imagine that you have a group of users who are very active, have added a product to their cart but haven't purchased yet. Well you can use Firebase to create an audience of just these people and then use AdWords to give them specific ads and encourage them to come back to your app and take action. Understanding your users and engaging with them at just the right time and in the right way will help you build loyal users for your app. Firebase and AdWords working together to help you grow your user base. Get started today. Your new users are waiting. Android Instant Apps make it possible for users to access your app without having to install it first. Imagine users opening your app just by clicking on a link in an email or a text message. We've recently made Android Instant Apps available to all Android developers. To take full advantage of this we have some best practices to help you make your Instant Apps user experience as great as that in your installed app or maybe even better. You can find all this and more at the URL in the description below. It's important to keep in mind that by enabling your app to run instantly without installation, you're not creating another additional app. We're thinking of Instant Apps as another way to use the app your users already without installation. By adding the ability to access your app directly from a link, a search result or another app, it's much easier for users to engage with your app and get excited about it. If they decide to keep your app on their device permanently, they can then install it right from within the Instant App. The ability to launch an app without having to install it provides an enormous opportunity. For a long time, app developers have focused on the number of app installations as a proxy for the metrics their business really cares about. Without installation, users simply weren't able to engage with the developer's offerings at all. Removing this barrier to entry enables you to think about the metrics your business really cares about. Your audience is now just one tap away from engaging with your service. Your Instant App is just another mode your app can run in. So don't branch your UI and make any unnecessary changes regarding the layout, the interface, design or experience of your Instant App. The transition from Instant to installed mode after installation should be as smooth and seamless as possible. Your users should have a rich and full app experience even if they haven't installed your app. Rather than thinking of Instant Apps as a limiting factor to what your audience can do, think of it as an opportunity to get them to your functionality quicker and a way to foster your relationship with them. Avoid prompting your users to install the app when they're in the middle of a task. They'll be much more inclined to place your app onto their device permanently after it has had the opportunity to prove its usefulness. Refrain from bouncing them back and forth between your Instant App and your mobile web offerings. You can probably tell by now Instant Apps are all about removing friction for your users and getting them closer to your functionality. Think about ways you can remove friction for your users. For example, wait until users can see the benefit of making an account and signing in until the value of doing so becomes apparent. Asking users to create an account after installation seems like a small additional ask when they've already gone through the app installation flow and are only just getting started. However, when they're coming from a link looking for specific content or functionality, being asked to register can feel very disruptive. Make sure to use available APIs to make your and your user's life easier. Using Google Smart Lock for example makes signing up and signing in a much simpler and straightforward experience. In summary, we really think that Instant Apps will unlock a lot of opportunity to engage your audience more directly. Users will be able to focus on what it is they want to accomplish rather than having to spend time maintaining and updating apps on their phone. That's what we're working with. Everything I talked about here and much more you can find on g.co. Thanks for watching. At this time, please find your seat. Our session will begin soon. All right. Hi. Good afternoon. If you're just coming in, please get settled quietly. We have to get started to stay on schedule. So hi. I'm Mike Claran. I'm on the Android team. We're going to be talking today in a lot of detail about some big changes to how we recommend that you build Android applications. But before we go into a lot of the details, I thought it'd be helpful to step back a bit and frame the discussion by talking about where we came from and where we're going. So let's do that. So to start, Android has always been based on some strong principles. Not surprisingly, those were best expressed by Diane Hackborn. She's the one who actually architected most of the Android framework. She wrote a post about this a few months back and I have some excerpts from that here. If you look at our core primitives, activity, broadcast receiver, service content provider, you might reasonably think that those constitute an application framework. But that's not the right way to go. These classes are actually contracts between the application and the operating system. They represent the minimal amount of information necessary so the OS knows what's going on inside your app so we can manage it properly. So as an example, if your app is running in the background, but it's also exposing data to another application through a content provider, the OS needs to know that the content provider is a mechanism that tells us that so that we can keep you alive. So we think of these core classes as really being like the fundamental laws of physics for Android, hence the illustration. That is the cover of the manuscript where Isaac Newton first presented the basic laws of motion. Now, fundamental laws are a good thing. I use a shorthand when talking about this. I say Android has good bones even though people look at me funny after I say that. But what I mean by that is that Android is based on a small, stable, cohesive set of core primitives and that allows a common programming model across a really incredibly diverse range of devices from wearables to phones to tablets to TVs to cars and more. This model also gives application developers the freedom to choose whatever framework they want inside their application for their internal framework. So that means that we on the Android team don't have to get involved in debates about whether MVC is better than MVP or whether MVP is better than MVVBM. You guys can pick whatever makes sense to you. Now, that's a pretty good story if you are in the operating system business, like say me. But if you're in the app development business, like say all of you, that's really only chapter one of the story. And the reason for that is because while strong fundamentals and freedom of choice are good things, we know that in your day-to-day jobs, and we know this because you told us, you want more from us. So I'm going to abuse my analogy a bit here. We can all appreciate the simple elegance of Newton's laws of motion. But if your job is to land a rover on Mars, you don't want to come to work each day and start with only f equals ma and derive everything from first principles. So we've been talking to developers both inside and outside of Google and taking a hard look at the app development experience. And we've realized a couple of things. First, there are peaks and valleys. Some aspects of app development are better served by our APIs than others. For example, we think RecyclerView is at the better end of that spectrum. So with RecyclerView, we didn't say, hey, we give you events and you can draw stuff, and in between you have a touring complete language. So good luck with everything else. On the other hand, maybe activity and fragment life cycles belong down in that dark shadowy place because there I think too much of it is indeed left as an exercise for the reader. And we want to fix that. So as we thought about this, we realized a good solution has some key properties. First, we have to solve the right problems. This is going to be a sustained effort, like sustained for us on Android. But for the first cut we want to make sure that we are going after the problems that every developer faces, the things that are hard to do right now. Again, app life cycles is a really good example. If you don't get that right in your app, nothing is going to work on top of that. And that's true for your app, but that's also true for the frameworks we're trying to build. We have to get that right before we can do anything else. Second, we have to play well with others. We know that you all have huge investments in your existing code bases and we can't create a model where the first thing we say to you is throw all that out and start over. So we're trying to create APIs that you can adopt a little bit at a time and also that interoperate well with other libraries or other frameworks. Third, we want to be more opinionated. We want to take a stronger clear stance on how to Android an app the right way, at least as we see it. Now, this is all still optional and if you already have something that works for you, then great. But developers are telling us that they want more guidance on how apps should be built. And by the way, we're not changing any of the laws of physics here, we're just layering some higher level constructs on top because, after all, F is going to equal NA whether you believe it should or not. Next, it needs to scale. We want solutions that are industrial strength and that will scale to the real-world requirements of real-world applications. We don't want to build something that's awesome for hello world, but then it's going to collapse the first time it bumps into the messy complexities of reality. And finally, reach. For this problem, for making it easier for you to write Android applications the right way, what we think is the right way, we want to use libraries like supportlib wherever possible, rather than adding new APIs to the platform, because that lets our solution reach older versions of the OS as well. Okay, so that's the background of what we're trying to accomplish and why we're here. Now I'd like to introduce Yiit, toolkit engineer extraordinaire, and he's going to walk you through what we actually built. Thank you. Hello, everybody. Okay, that was the background. What are we shipping today? The very first thing we are shipping is an architecture guide on developer Android.com. Now for over years you've been asking us for our opinion, like how do we think an application should be built, and this is that guide. So we believe that it's a very good covers loss of application cases, but even if you have an architecture that you are comfortable with, you can keep it, but you can probably learn something from this guide. Second, we are shipping a new set of libraries that we call architecture components. These are more fundamental components where you can build your application on top. The first thing is life cycles. So this is the biggest developer complaint we have. Life cycles are hard, life cycles are hard. We say, okay, we should solve this problem and the first level of this needs a set of components. Second one is life cycle-level observables, which we'll go in detail later, but this is basically things that can do something based on the life cycle. Third, we are going to introduce a lightweight view model, which is all of our effort to take out that code outside of your activities and fragments and put it somewhere else where you can easily test it. Last but not least, we are going to introduce a new object mapping library for SQLite. And all of this is available for you today on MavenGoogle.com. Okay. Let's look about life cycles. What's hard about life cycles? Why do we hear so many complaints about that? Let's go through an example. We have an activity where we want to show the location of the device on the screen. So you will write something like this. You create a location listener on create method. You need to initialize it with the context and you have a callback that it calls whenever the location changes to the object.  You also need to go ahead and override on start and then tell it to start and override on stop and tell it to stop. You always need to do this babysitting for these components, but this is acceptable. This is a simple example. This looks all right. But then your product manager comes for location, then your developer says, sure, that's an easy change. I'm going to change this method to first call this utility method which probably makes a web service call to check the user settings. And then if the user is enrolled, then we want to start the location listener, which looks like a very simple change. You will think this would work, but let's look at what happens in that activity's life cycle. So our activity was created. Okay, let's start check if the user's status is enrolled. Then meanwhile, the user wants to rotate the device, which rotation means a configuration change which means Android is going to recreate that activity. So on stop, we knew about this and we said, okay, location manager, stop. And then the new activity came, it also goes through the same thing. Looks all right, except, do you remember this call we made before? And then it decided to come back. Hey, users enrolled. And then what we did, we said, okay, then start. Now you realize the bug, we called start after calling on stop, which means our activity will live forever. We are going to observe the location forever. The battery will drain. We will have said users. This is a situation, right? We want to get rid of this. We want to put an end to this. So we said, okay, we need to acknowledge, as Mike mentioned, we cannot change the loss, but we can make it easier to deal with these things. So we decided to introduce a new interface called lifecycle owner. This is a thing with a lifecycle. Is your activity, is your fragment, or maybe you have your own UI framework, whatever the container you have there is a lifecycle owner. And we have these lifecycle observers, which are the things that care about the lifecycle. Like the location listener we had, it cares about the lifecycle. It wants to stop itself if the lifecycle is not active. So we said, okay, we will acknowledge this and we have lifecycle observers. I will go through our activity. Now we make our activity extend the lifecycle activity class. This is the temporary class until these components reach 1.0, then everything in support library will implement this lifecycle owner interface. Inside our activity, when we initialize our location listener, we are going to tell it this is the lifecycle you care about. And that's all we will do. The rest is the same. It calls back. We update the UI. So how can we change our location listener to take advantage of this lifecycle? Oh, we do the same thing for the users as well. Okay. So there is some boilerplate code here to get the fields. It doesn't really matter. But we have this enable method which gets called if the user is enrolled. Inside this enable method, now we want to start listening to location only if the activity is started. Now you can do this. You can say what is my current state, which is amazing, we didn't have this API until now. But now you can. So, okay, that was a simple change. But we also get notified what if we get enrolled when the activity was in the back stake and user comes back to the activity, now we should actually start the location manager. For this, we want to observe that lifecycle. To do that, we implement this interface which allows us to write these methods. You can annotate a method saying that if one start happens, call this method. And the new components will take care of calling it. So if you are already enabled, you can do that. You can do that. You can do that. You can do that. You can do that. And on stop, you disconnect. And last but not least, if the activity is destroyed, there is nothing you want to do with that activity, so you can unregister. So now you might be asking yourself, well, you just move those on start on stop methods from the activity into this location manager, like how come it is without the activity babysitting itself? Like I'm sure if you look at your code today, your activity on start on stop methods are like at least 20, 30 lines of code. We want them to be zero lines of code. If we go back to activity, I want to point out something that look in on create, we initialize these components, and that's all we did. We didn't overwrite, we didn't on stop on start, we don't overwrite any of those components. We want to introduce a life cycle component. It's a component that can get a life cycle and do the right things. It can take care of itself so that in your activity, you can just initialize it and forget about it. You know that it's not going to leak you. Now, of course, it was like more of moving the complexity from activity to the location manager and then it still needs to deal with life cycle. We said, okay, we want to do that, but we want more. We want very convenient to handle this common case. It's very common that your activity or fragment, it observes some data and whenever that data changes, it wants to refresh itself. Like it happens basically almost every single UI. And we want to share resources across multiple fragments or activities. The location of the device is the same from fragment to fragment. If you have two devices, you need to create two listeners to listen to the same location. As we created this new live data class, let's look at that. So live data is a data holder. It's just awesome data. It's like an observable. But the tricky thing about live data is that it is life cycle everywhere. It understands about life cycles. Because it understands about life cycles, it automatically manages everything. If you are observing a live data, you don't need to unsubscribe. The right things will happen in the right times. So if that location listener was a live data and a singleton because location is singleton, we could write the code like this. Get the instance, start observing. And when you observe, you say, this is my life cycle. This is all you need to do. Before on Android, if you were using the same live data, you would have to use the same live data. Everyone would give like minus 2 to that code review. Now you can do this. This is safe. Nothing ever leaks. So if you want to change your location listener to use this API, we get a lot of all unnecessary things. All we need is a context to connect. But we say this is a live data. This is a live data of a location. We have an active observer. And the other one says on inactive, which means you don't have any observers that are active. Now at this point, you're probably asking yourself, what is an active observer? Now we define an active observer as an observer that's in the started or resumed state, which is like an activity user is currently seeing. So if you have an observer in the back stack, there's no reason to call this inactive. There's no reason to see what's going on there. So inside our connect method, all we need to do is whenever the system location manager sends us a new location, we call set value on ourselves. Then the live data knows which are the active observers and delivers the data to those observers. Or if one of the observers was like on the back stack and then becomes visible again, live data takes care of sending the latest data back to that observer. And then there's no reason to call this inactive. So we don't need multiple instances. So if we look at live data, it is a life cycle observable. It has very simple start and stop semantics. Doesn't matter how many observers you have or what state they are, we merge all of it into one life cycle. And it doesn't have any activities or fragments inside it, but it works with both of them. And it's also really simple. And if you know about this like infamous fragment transaction exception, we guarantee that your observer will never ever be called in a state where you cannot run a fragment transaction. So this is very, very specifically designed to work well with your activities and fragments. Okay. Let's think about configuration changes. Now that example was easy because location is global, but most of the activity is inactive. So if we had an activity where we show a user profile and we implemented a web service that can return the data as a live data, which we can safely observe without risking leaking our activity, this all looks nice. You will never leak this activity. It will work very well except what happens if the user rotates the device. Let's look at the life cycle of the user. And then while you are fetching the user, the user decides, I want to rotate the phone. And then the activity is destroyed. Luckily we don't leak it, which is great. But then the new activity starts which makes the name call. Now this is okay, but not great. What do we want? We want to actually retain that data, right? We're already making that request. Why we make it? So we want our graph to be the same. So if the new activity comes, we should be able to give it back the same V model, which is a new class called V model. So we are introducing this new class very specific to this thing where you should put the data inside your activities into the V model and make the activities data-free. So if you want to change this activity, we create this new class. It extends the V model. And in the V model, all we do is inside the get user method, if this is the first call, get it from the web service, otherwise return the existing value. Now it's super simple. And inside our activity, we get it off all that code. We say get the V model providers of this. So each activity or fragment has a V model provider that you can obtain and that V model provider knows how to do it. So the first time you make this call, we will give you an instance. When the rotated activity comes back, it's going to reconnect to the same V model. And then the rest of the code is the same. So if you look at the lifecycle, this is what we wanted. The new activity started, it reconnects. And when the new activity is finished, like when we don't have anything to do with that activity, it takes you to the only method in the V model class. So it's very simple. So if you look at life cycles, they hold the data for the activity, they serve our configuration changes. They should never ever reference views because they outlive the activity. So you cannot reference back to the activity. That's why you use things like live data or XJava or data binding to the V model. Now, another big topic is persistence. Now, we know that to write a good responsive Android app, you need to save the data on disk. If you come to Android, there's these three major APIs we have. One of them is content providers, which is to talk between processes. It really has nothing to do with persistence. In reality, the other one is shared preferences that you can put very little data into that. And the last one is SQLite, which is something we have been shipping since Android 1. So you know you need to use SQLite if you want to save big data. And so you go into the developer Android com, this is the very first saving your data slide. This is so confusing. This is very sad. So we said, okay, we want to make this sad. We want to make it sad. So there's one time it tries to say, I want to select these three columns with this constraint and I want to order them like this. It's actually very, very simple SQL query, but you need to write all this code, plus this code doesn't even show where you define all those constants. So what do we really want? We want to get rid of that boiler free code. When you're writing Java, if you make a typo in Java, it works very well. We still want to use SQLite because on every single Android device it's a proven technology. We know it works very well. But we want to compile time verification. So we don't want the boiler plate code. We want to compile time verification. So we said, well, we came up with room, which is an object mapping library for SQLite. So if you look at this query, we said, okay, let's move this to SQLite. And we have this feed object, which we want to save in the database. I want to put that query inside an interface. You want to create the feed DAW. The DAW stands for data access object. Usually in database, the best practice to put your database access into certain interfaces. Then we just need to tell room, this is a DAW, tell room, this is an entity. And finally we had a database class which is a data access object. And I have these data access objects. This is all you write. Once you write that you can get an implementation of it from room. It's very similar to how you use retrofit or dagger. You define the interfaces, we provide the implementation. Now once we know this is a DAW, well we can do these shortcut methods, like insert these items or delete these items as long as you can read it and it makes sense, room will understand it. But the most important part of room is it understands your SQL. So the part like all those constants I mentioned we defined to get compile time guarantees, room actually gives all of these for free. So when room sees this query it says, okay you are receiving these three columns from this table where the title looks like this keyword. Where is this keyword here? Well, it's coming from the function parameters, makes sense. And what does it want to return? It wants to return a list of feeds and then room goes and checks. Does their columns return, mesh the object the user wants to return and once they are equal it says okay I can generate this code. You can even say select start like you don't need to list them. Room really really understands your query. You can even like join 10 tables it will still work. But what does it want to do? You can even type instead of saying feed table you wrote feeds. Now if this happens room is going to give you an error at compile time. So it goes at and verifies your query against the schema you have defined and it tells you if something is wrong. That's not the only thing it does. So if you say if your query is correct you want to fetch ID and title this is a valid query but you want to return it as a one string that doesn't make sense and it's going to give you a compile time error again. And it's a very nice way to fix this in room you can create any Java class it doesn't need to be annotating there's nothing special about that pojo and tell the room to return it. As long as whatever query returns matches what you want to return room will write the code for you. And observability which is very important right if you have a query like this now you're showing lists you obviously want to get notified when the data changes. And in room if you want to do this all you have to do is tell it to return a live data and it will do it for you. Because it knows your query it knows what things affected so it can let you know if that query changes. And this is the part where all these architecture components work well together. Room already knows about live data. So in your v-model all you will write is from the database called this query and this all you will do whenever the data changes your UI will get a new update and it only happens if the UI is visible. Last but not least room also supports RxJava 2. Okay if you look at room in a nutshell it tries the boiler plate code for you it has full SQLite support you can just write in SQLite there's no builders it verifies your queries at compile time it incentivizes best practices which helps you with testing, migrations and it's also observable out of the box. Okay architecture our last topic today it's all where we started right and now you might be asking yourselves what has changed in 2017 that you are talking about architecture. Well actually nothing has changed we've been talking about this topic a lot Adam Powell and I gave a lot of talks on this topic there's even a talk from 2010 which I watch as a developer so this is a topic we have been walking about but what is missing was a well-defined reference architecture so it's what we are shipping today if you go to developer Android come today after the session there's a section about how to architect an Android application so by the way this is a reference guide this is not your religious book we believe this is a very good way to write applications but you don't have to write all of it long by line so I'm going to briefly go through this architecture but if you get lost don't worry we have all of this documented on developer Android come with sample applications so we think that applications composed of four main things there's UI controllers the V models, a repository and the data sources so let's look at these in detail UI controllers are your activities, fragments, custom features they have very simple task they observe the fields of the V model and update themselves and they have one more responsibility whenever user takes an action on the UI they understand the action and call the V model to express whatever the user wanted to do if you go to our V model V model is the one which prepares the data for the UI and holds on to it this is where the data for the UI lives and it knows how to get that data usually it has like live data if you're using an observable or data binding observables it survives configuration changes that's why we put the data into the V models and it's also the gateway you can also consider it as your UI controller only ever talks to the V model to reach to the rest of the application and what's the repository now the V model serves as a store for your UI controller right repository saves as a data store for all of your application so it's the complete data model for the app and it provides this data with simple APIs to the rest of the application like you can have a user repository where you pass a user ID and it returns you a live data of user how it gets the data you don't care it's the repository's job so how does it do that it talks to the like fetching syncing take looking at the database we're talking to your retrofit backend is the repository's job and last but not least we have our data sources like your REST API client you might be using retrofit or you have SQLite storage you might be using room or you might be using grand doesn't really matter or you might be talking to other content providers from other processes these are things we call data sources and we think that all of these layers can discover each other through a dependency injection system which we recommend using Dagger but we also realize that understanding dependency injection is not very trivial like it's a more complex topic and sometimes it might be an overkill and you can also use a service locator if you feel more comfortable with it so let's go back to go through a concrete example let's say we have a UI that shows a user profile and we have data sources which like we save it to database we also can get it from the network how do we connect these two things well we said we first need a user repository user repository knows it should check the database it's not there make a web request or meanwhile also turn on the database it doesn't matter how it does it but it knows how to create a live data of a user or unobservable doesn't matter and then we need to remodel right now let's go back to the data for the UI that lives in the v-model so we create this profile v-model which talks to the repository to get this information and then the actual fragment gets the data from the v-model so that if the fragment comes back the live data will be there in the profile v-model but if the fragment disappears completely we will get rid of the v-model and the data can be garbage collected now we made if you notice every single component only talks to the one right below it which helps to scale your application it also has a great side benefit which is called testing you're testing right so let's say you want to test your UI now people say UI testing is hard UI testing is yes it's harder but it's usually hard because you put all of your code into that activity now we said put most of it into the v-model and you know that the UI only talks to the v-model so you can get rid of the other two you only need to create a fake v-model to test your UI testing your UI becomes super easy with Espresso and we have a sample app on GitHub that you can check how we test the UI and the same thing is valid for v-models if you want to test the v-model you know it only talks to the repositories you replace it with a mock repository and it works so you will test your v-models on your host machine on JVM and last but not least you can test the repository the same way you just mock the data sources you can easily test your repositories as J unit tests now I know this has been out of information we have two sessions tomorrow and lots of documentation but now I want to call our product manager Lukas to talk about what to do next like it said we just covered a lot of ground and actually we glossed over a lot of detail while we did that but luckily you don't have to remember everything that you just heard we have a lot of material for you to check out at developer.android.com slash arch and that link should start working in 21 minutes so we wanted to give you guys a chance to kind of blog and tweet about this before anybody else so we held it back so yeah we made having good documentation and samples a priority from the beginning of this project since you know providing good guidance is really one of the major goals so you're going to find in depth documentation that's written from the perspective of an app developer you're going to find really meaty sample apps that show how to build a real app and just as an example of how much work went into this we have a github browser sample app that probably has better test coverage than many real world apps written by that guy and of course we have the guide to app architecture which internally we called the opinionated guide for a while and we think that label still applies but even if you're not planning to use our recommended architecture we think people should check out the guide it has principles that we think apply to all apps on Android and you're probably asking yourself do I not you know what's the impact of this going to be on me am I going to have to kind of change the way that I'm doing everything you know if you're starting a new project or if you have an existing app that you want to improve the core architecture then yeah we recommend taking a look at this stuff it's still preview we won't be hitting 1.0 for a few months but we think it's definitely ready for you guys to check out and use in projects but if you're happy with what you have you don't need to use the app so in the spirit of be together not the same we're not dictating what everyone has to use if you're happy with your app architecture you can keep it if you're happy with your existing ORM you don't have to use room architecture components are designed to work well together but they do work perfectly fine stand alone and mixing and matching applies not only to architecture components but also third-party libraries so waiting for the slide to come up so yeah so you can kind of use what you have and start to integrate architecture components where they make sense so for example if you're happy with rx java but you really like the life cycle aware components stuff that you just showed so you have these kind of like self-sufficient components you can use live data together with rx java so you can get all the power of rx java operators and now it's life cycle safe so kind of the best of both worlds and we've got additional integrations to come we're definitely looking at a lot of stuff internally that would be nice if it were kind of like self-sufficient and life cycle aware and if you're a library developer we really recommend checking out life cycles and life cycle observer because we think there is a really bright future and a lot of potential in making libraries and components that are life cycle aware by default but before you go do that we have a lot more for you at iO this year we have two more talks one on life cycles that's even more in depth than what we just showed tomorrow morning we have another one on room and persistence and going a little bit beyond room starting at 12.30 tomorrow and we'll be we'll have people who are kind of well versed in architecture components in the sandbox for all the iO and we also have code labs which we're pretty happy with and there's more to come so we think we've just scratched the surface of ways that we can improve the experience of using Android frameworks and we're looking to applying this approach in other areas as well so some things are already in the works and we're also interested in hearing from you on kind of what else you'd like to see so come by talk to us tell us what you like, what you don't and stay tuned because we're really excited about the future of Android development thank you so for example you can send a message to all of your users who have made an in-app purchase giving them a special offer allowing you to re-engage with them the Firebase notifications console integrates with analytics so you can measure the effectiveness of your messages and explore insights based on your users activities so you can grow your application by easily engaging your users through the Firebase notifications console so you can share your experience that people love to share things about themselves such as photos, videos and gifs that express their feelings so what do you do to let them store and share these files through your app that's where Firebase storage can help our storage API lets you upload your users files to our cloud so they can be shared with anyone else and if you have specific rules for sharing files with certain users you can use the intent for users logged in with Firebase authentication security of course is our first concern all transfers are performed over a secure connection also all transfers with our API are robust and will automatically resume in case the connection is broken this is essential for transferring large files over slow or unreliable mobile connections and finally our storage backed by Google cloud storage that's a petabytes that's billions of photos to meet your app's needs so you will never be out of space when you need it so give your users space to share their lives with Firebase storage available right now for iOS, Android and web applications and to learn more about Firebase storage check out the documentation available right here analytics we all know they're important to building a successful app which is why there are many different kinds of analytics tools for app developers to use there are in-app behavioral analytics which measure who your users are what they're doing and so on and then you've got attribution analytics which you can use to measure the effectiveness of your advertising and other growth campaigns not to mention push notification analytics and crash reporting but quite often this work is being done by completely different analytics libraries which means you've got reports living in various tools across the web and trying to understand trends across these different reports much less get them to talk to each other it's always easy that's why we've created Firebase Analytics Firebase Analytics is built from the ground up to provide all the data that mobile app developers need in one easy place and it starts by giving you free and unlimited logging and reporting that's right, no quotas no sampling and no paid tier to worry about simply by installing the Firebase SDK Analytics automatically starts providing insight into your app you receive demographic information on who your users are how regularly they visit your app how much time they've spent using it and how much money they've spent in your app but not all apps are alike and you can get detailed information about what your users are up to by logging events specific to your app these can include common events that Firebase Analytics has already defined like when your users add an item to their cart and there's also support for custom events you create yourself like when a user completes a workout in your fitness app or when they take a selfie in your photo app geez it's not just about seeing what your users are doing it's also about discovering who your users are so in addition to demographic information you can also discover how your different groups of users behave by setting custom user properties have a music app and want to find out whether your classical music fans are browsing more albums than your jazz fusion fans that's the kind of data you can easily break out thanks to custom user properties and Firebase Analytics doesn't just measure what's happening inside your app it lets you combine your behavioral reporting what your users are doing with attribution reporting or what growth campaigns are bringing people to your app in the first place so if you want to know which ad campaigns are bringing you the users who spend the most money or are sharing the app with their friends or have unlocked the last level in your game and are ready for the sequel you can do all of that in Firebase Analytics but don't stop there once you have all this information you can take action on it using Firebase Analytics audiences Firebase Analytics gives you the power to measure the groups of users or audiences out of just about anything you can measure in your app want to targe