Posted by Roman Nurik, Senior Interactive Designer, and Richard The, Google Creative Lab
Last summer we launched Android Experiments: a showcase of creative Android projects, and an open invitation for all developers to submit their own experiments to the gallery. So far we’ve seen some amazing work from the developer community - from live wallpaper, to watch faces, to interesting hacks of the IOIO board - and we want to see more.
Today we announce the Android Experiments I/O Challenge: a chance for your experiment (and you) to go to I/O 2016!
From now through April 13, you can enter by submitting your experiments to the gallery. The top three winners of the contest will receive a trip to this year’s Google I/O, and the five runner-ups will get the new Nexus 6P.
So what makes a good Android Experiment? It’s a project that utilizes the unique capabilities of the Android platform in an innovative way. Here are a few suggestions:
Creative uses of Android’s new or distinctive features
Projects that explore how we interact with our devices, in small and big ways
Unique visual aesthetics
Open source projects that inspire other developers
Surprise us - we want to see the amazing things you’re cooking up
All projects on Android Experiments are open source. If you’re not sure where to start take a look on the site gallery, dig in and get inspired.
Android devices do a lot, whether it is taking pictures, getting directions or making phone calls. With all of this functionality comes a large amount of very sensitive user data including contacts, calendar appointments, current location, and more. This sensitive information is protected by permissions, which each app must have before being able to access the data. Android 6.0 Marshmallow introduces one of the largest changes to the permissions model with the addition of runtime permissions, a new permission model that replaces the existing install time permissions model when you target API 23 and the app is running on an Android 6.0+ device.
Runtime permissions give your app the ability to control when and with what context you’ll ask for permissions. This means that users installing your app from Google Play will not be required to accept a list of permissions before installing your app, making it easy for users to get directly into your app. It also means that if your app adds new permissions, app updates will not be blocked until the user accepts the new permissions. Instead, your app can ask for the newly added runtime permissions as needed.
Finding the right time to ask for runtime permissions has an important impact on your app’s user experience. We’ve gathered a number of design patterns in our new Permission design guidelines including best practices around when to request permissions, how to explain why permissions are needed, and how to handle permissions being denied.
Ask up front for permissions that are obvious
In many cases, you can avoid permissions altogether by using the existing intents system to utilize other existing specialized apps rather than building a full experience within your app. An example of this is using ACTION_IMAGE_CAPTURE to start an existing camera app the user is familiar with rather than building your own camera experience. Learn more about permissions versus intents.
However, if you do need a runtime permission, there’s a number of tools to help you. Checking for whether your app has a permission is possible with ContextCompat.checkSelfPermission() (available as part of revision 23 of the support-v4 library for backward compatibility) and requesting permissions can be done with requestPermissions(), bringing up the system controlled permissions dialog to allow the user to grant you the requested permission(s) if you don’t already have them. Keep in mind that users can revoke permissions at any time through the system settings so you should always check permissions every time.
A special note should be made around shouldShowRequestPermissionRationale(). This method returns true if the user has denied your permission request at least once yet have not selected the ‘Don’t ask again’ option (which appears the second or later time the permission dialog appears). This gives you an opportunity to provide additional education around the feature and why you need the given permission. Learn more about explaining why the app needs permissions.
Read through the design guidelines and our developer guide for all of the details in getting your app ready for Android 6.0 and runtime permissions. Making it easy to install your app and providing context around accessing user’s sensitive data are key changes you can make to build better apps.
Posted by Roman Nurik, Design Advocate, and Richard The, Google Creative Lab
Android was created as an open and flexible platform, giving people more ways to come together to imagine and create. This spirit of invention has allowed developers to push the boundaries of mobile development and has helped make Android the go-to platform for creative projects in more places—from phones, to tablets, to watches, and beyond. We set out to find a way to celebrate the creative, experimental Android work of developers everywhere and inspire more developers to get creative with technology and code.
Today, we’re excited to launch Android Experiments: a showcase of inspiring projects on Android and an open invitation for all developers to submit their own experiments to the gallery.
The 20 initial experiments show a broad range of creative work–from camera experiments to innovative Android Wear apps to hardware hacks to cutting edge OpenGL demos. All are built using platforms such as the Android SDK and NDK, Android Wear, the IOIO board, Cinder, Processing, OpenFrameworks and Unity. Each project creatively examines in small and big ways how we think of the devices we interact with every day.
Today is just the beginning as we’re opening up experiment submissions to creators everywhere. Whether you’re a student just starting out, or you’ve been at it for a while, and no matter the framework it uses or the device it runs on, Android Experiments is open to everybody.
Check out Android Experiments to view the completed projects, or to submit one of your own. While we can’t post every submission, we’d love to see what you’ve created.
The Design Support Library is now available, simplifying the implementation of elements like the Floating Action Button, check out the post for details.
Original Post:
Material design is a new system for visual, interaction and motion design. We originally launched the Topeka web app as an Open Source example of material design on the web.
Today, we’re publishing a new material design example: The Android version of Topeka. It demonstrates that the same branding and material design principles can be used to create a consistent experience across platforms.
While the project demonstrates a lot of different aspects of material design, let’s take a quick look at some of the most interesting bits.
Transitions
Topeka for Android features several possibilities for transition implementation. For starters the Transitions API within ActivityOptions provides an easy, yet effective way to make great transitions between Activities.
To achieve this, we register the shared string in a resources file like this:
For multiple transition participants with ActivityOptions you can take a look at the CategorySelectionFragment.
Animations
When it comes to more complex animations you can orchestrate your own animations as we did for scoring.
To get this right it is important to make sure all elements are carefully choreographed. The AbsQuizView class performs a handful of carefully crafted animations when a question has been answered:
The animation starts with a color change for the floating action button, depending on the provided answer. After this has finished, the button shrinks out of view with a scale animation. The view holding the question itself also moves offscreen. We scale this view to a small green square before sliding it up behind the app bar. During the scaling the foreground of the view changes color to match the color of the fab that just disappeared. This establishes continuity across the various quiz question states.
All this takes place in less than a second’s time. We introduced a number of minor pauses (start delays) to keep the animation from being too overwhelming, while ensuring it’s still fast.
The code responsible for this exists within AbsQuizView’s performScoreAnimation method.
FAB placement
The recently announced Floating Action Buttons are great for executing promoted actions. In the case of Topeka, we use it to submit an answer. The FAB also straddles two surfaces with variable heights; like this:
To achieve this we query the height of the top view (R.id.question_view) and then set padding on the FloatingActionButton once the view hierarchy has been laid out:
private void addFloatingActionButton() { final int fabSize = getResources().getDimensionPixelSize(R.dimen.fab_size); int bottomOfQuestionView = findViewById(R.id.question_view).getBottom(); final LayoutParams fabLayoutParams = new LayoutParams(fabSize, fabSize, Gravity.END | Gravity.TOP); final int fabPadding = getResources().getDimensionPixelSize(R.dimen.padding_fab); final int halfAFab = fabSize / 2; fabLayoutParams.setMargins(0, // left bottomOfQuestionView - halfAFab, //top 0, // right fabPadding); // bottom addView(mSubmitAnswer, fabLayoutParams); }
To make sure that this only happens after the initial layout, we use an OnLayoutChangeListener in the AbsQuizView’s constructor:
addOnLayoutChangeListener(new OnLayoutChangeListener() { @Override public void onLayoutChange(View v, int l, int t, int r, int b, int oldLeft, int oldTop, int oldRight, int oldBottom) { removeOnLayoutChangeListener(this); addFloatingActionButton(); } });
Round OutlineProvider
Creating circular masks on API 21 onward is now really simple. Just extend the ViewOutlineProvider class and override the getOutline() method like this:
@Override public final void getOutline(View view, Outline outline) { final int size = view.getResources(). getDimensionPixelSize(R.id.view_size); outline.setOval(0, 0, size, size); }
and setClipToOutline(true) on the target view in order to get the right shadow shape.
We use vector drawables to display icons in several places throughout the app. You might be aware of our collection of Material Design Icons on GitHub which contains about 750 icons for you to use. The best thing for Android developers: As of Lollipop you can use these VectorDrawables within your apps so they will look crisp no matter what density the device’s screen. For example, the back arrow ic_arrow_back from the icons repository has been adapted to Android’s vector drawable format.
The vector drawable only has to be stored once within the res/drawable folder. This means less disk space is being used for drawable assets.
Property Animations
Did you know that you can easily animate any property of a View beyond the standard transformations offered by the ViewPropertyAnimator class (and it’s handy View#animate syntax)? For example in AbsQuizView we define a property for animating the view’s foreground color.
// Property for animating the foreground public static final Property FOREGROUND_COLOR = new IntProperty("foregroundColor") {
@Override public void setValue(FrameLayout layout, int value) { if (layout.getForeground() instanceof ColorDrawable) { ((ColorDrawable) layout.getForeground()).setColor(value); } else { layout.setForeground(new ColorDrawable(value)); } }
This can later be used to animate changes to said foreground color from one value to another like this:
final ObjectAnimator foregroundAnimator = ObjectAnimator .ofArgb(this, FOREGROUND_COLOR, Color.WHITE, backgroundColor);
This is not particularly new, as it has been added with API 12, but still can come in quite handy when you want to animate color changes in an easy fashion.
Tests
In addition to exemplifying material design components, Topeka for Android also features a set of unit and instrumentation tests that utilize the new testing APIs, namely “Gradle Unit Test Support” and the “Android Testing Support Library.” The implemented tests make the app resilient against changes to the data model. This catches breakages early, gives you more confidence in your code and allows for easy refactoring. Take a look at the androidTest and test folders for more details on how these tests are implemented within Topeka. For a deeper dive into Testing on Android, start reading about the Testing Tools.
What’s next?
With Topeka for Android, you can see how material design lets you create a more consistent experience across Android and the web. The project also highlights some of the best material design features of the Android 5.0 SDK and the new Android Design Library.
While the project currently only supports API 21+, there’s already a feature request open to support earlier versions, using tools like AppCompat and the new Android Design Support Library.
Have a look at the project and let us know in the project issue tracker if you’d like to contribute, or on Google+ or Twitter if you have questions.
Trello is a visual collaboration tool that gives teams a shared perspective on projects. It’s built around the concept of a traditional office whiteboard. Simplicity and flexibility are core to the product, so the Trello team recently redesigned their Android app using the material design guidelines to double down on that effort.
According to Fyza Hashim, Designer at Trello, material design had an immediate impact on streamlining app-design and -development at the company. She added that, “Because the guidelines are so thorough and well thought out, you don’t have to go back and forth with developers.”
Sharing is a key component of Trello, so material design helped continue the same cohesive design and intuitive experience on both web and mobile. This makes sharing even easier. As a result, Trello has also seen double digit growth in user engagement with more and more sessions added per week.
Watch the video where we caught up with Michael Pryor, CEO; Hamid Palo, Mobile Lead; and Fyza at the Trello offices in New York to learn more.
Material design — learn more about material design and how it helps you create beautiful, engaging apps.
Posted by Peter Lubbers, Senior Program Manager, Google Developer Training
We know how important it is for you to efficiently develop the skills to build better Android apps and be successful in your jobs. To meet your training needs, we’ve partnered with Udacity to create Android training courses, ranging from beginner to more advanced content.
Last week at Google I/O we announced the Android Nanodegree, an education credential that is designed for busy people to learn new skills and advance their careers in a short amount of time from anywhere at any time. The nanodegree ties together our Android courses, and provides you with a certificate that may help you be a more marketable Android developer.
Training courses
All training courses are developed and taught by expert Google instructors from the Developer Platform team. In addition to updating our popular Developing Android Apps course and releasing Advanced Android App Development, we now have courses for everyone from beginning programmers to advanced developers who want to configure their Gradle build settings. And then there's all the fun stuff in between—designing great-looking, high performance apps, making your apps run on watches, TVs, and in cars, and using Google services like Maps, Ads, Analytics, and Fit.
Each course is available individually, without charge, at udacity.com/google. Our instructors are waiting for you:
Android Nanodegree
You can also enroll in the new Android Nanodegree for a monthly subscription fee, which gives you access to coaches who will review your code, provide guidance on your project, answer questions about the class, and help keep you on track when you need it.
More importantly, you will learn by doing, focusing only on where you need to grow. Since the Nanodegree is based on your skills and the projects in your portfolio, you do not need to complete the courses that address the skills you already have. You can focus on writing the code and building the projects that meet the requirements for the Nanodegree credential. We’ll also be inviting 50 Android Nanodegree graduates to Google's headquarters in Mountain View, California, for a three day intensive Android Career Summit in November. Participants will have the opportunity to experience Google’s company culture and attend workshops focused on developing their personal career paths. Participants will then leverage the skills learned from Udacity’s Android Nanodegree during a two-day hackathon.
To help you learn more about this program and and courses within it, Google and Udacity are partnering up for an "Ask the Experts" live streamed series. In the first episode on Wednesday, June 3rd at 2pm PDT, Join Sebastian Thrun, Peter Lubbers and Jocelyn Becker who will be answering your questions on the Nanodegree. RSVP here and ask and vote for questions here.
Android training in Arabic
We also believe that everyone has the right to learn how to develop Android apps. Today, there is a great need for developers in countries outside of the United States as software powers every industry from food and transportation to healthcare and retail. As a first step in getting the Android Nanodegree localized and targeted for individual countries, we have worked with the Government of Egypt and Udacity to create end-to-end translations of our top Android courses into Arabic (including fully dubbed video). Google will offer 2,000 scholarships to students to get a certificate for completing the Arabic version of the Android Fundamentals course. Google will also host job fairs and sessions for students with local employers and the Egyptian Government. For more information, see www.udacity.com/egypt.
Complete Android course catalog
Here are the currently-planned courses in the Android Nanodegree:
Android 5.0 Lollipop was one of the most significant Android releases ever, in no small part due to the introduction of material design, a new design language that refreshed the entire Android experience. Our detailed spec is a great place to start to adopt material design, but we understand that it can be a challenge for developers, particularly ones concerned with backward compatibility. With a little help from the new Android Design Support Library, we’re bringing a number of important material design components to all developers and to all Android 2.1 or higher devices. You’ll find a navigation drawer view, floating labels for editing text, a floating action button, snackbar, tabs, and a motion and scroll framework to tie them together.
Navigation View
The navigation drawer can be an important focal point for identity and navigation within your app and consistency in the design here can make a considerable difference in how easy your app is to navigate, particularly for first time users. NavigationView makes this easier by providing the framework you need for the navigation drawer as well as the ability to inflate your navigation items through a menu resource.
You use NavigationView as DrawerLayout’s drawer content view with a layout such as:
You’ll note two attributes for NavigationView: app:headerLayout controls the (optional) layout used for the header. app:menu is the menu resource inflated for the navigation items (which can also be updated at runtime). NavigationView takes care of the scrim protection of the status bar for you, ensuring that your NavigationView interacts with the status bar appropriately on API21+ devices.
The simplest drawer menus will be a collection of checkable menu items:
You’ll get callbacks on selected items by setting a OnNavigationItemSelectedListener using setNavigationItemSelectedListener(). This provides you with the MenuItem that was clicked, allowing you to handle selection events, changed the checked status, load new content, programmatically close the drawer, or any other actions you may want.
Floating labels for editing text
Even the humble EditText has room to improve in material design. While an EditText alone will hide the hint text after the first character is typed, you can now wrap it in a TextInputLayout, causing the hint text to become a floating label above the EditText, ensuring that users never lose context in what they are entering.
In addition to showing hints, you can also display an error message below the EditText by calling setError().
Floating Action Button
A floating action button is a round button denoting a primary action on your interface. The Design library’s FloatingActionButton gives you a single consistent implementation, by default colored using the colorAccent from your theme.
In addition to the normal size floating action button, it also supports the mini size (fabSize="mini") when visual continuity with other elements is critical. As FloatingActionButton extends ImageView, you’ll use android:src or any of the methods such as setImageDrawable() to control the icon shown within the FloatingActionButton.
Snackbar
Providing lightweight, quick feedback about an operation is a perfect opportunity to use a snackbar. Snackbars are shown on the bottom of the screen and contain text with an optional single action. They automatically time out after the given time length by animating off the screen. In addition, users can swipe them away before the timeout.
By including the ability to interact with the Snackbar through swiping it away or actions, these are considerably more powerful than toasts, another lightweight feedback mechanism. However, you’ll find the API very familiar:
You’ll note the use of a View as the first parameter to make() - Snackbar will attempt to find an appropriate parent of the Snackbar’s view to ensure that it is anchored to the bottom.
Tabs
Switching between different views in your app via tabs is not a new concept to material design and they are equally at home as a top level navigation pattern or for organizing different groupings of content within your app (say, different genres of music).
The Design library’s TabLayout implements both fixed tabs, where the view’s width is divided equally between all of the tabs, as well as scrollable tabs, where the tabs are not a uniform size and can scroll horizontally. Tabs can be added programmatically:
However, if you are using a ViewPager for horizontal paging between tabs, you can create tabs directly from your PagerAdapter’s getPageTitle() and then connect the two together using setupWithViewPager(). This ensures that tab selection events update the ViewPager and page changes update the selected tab.
CoordinatorLayout, motion, and scrolling
Distinctive visuals are only one part of material design: motion is also an important part of making a great material designed app. While there are a lot of parts of motion in material design including touch ripples and meaningful transitions, the Design library introduces CoordinatorLayout, a layout which provides an additional level of control over touch events between child views, something which many of the components in the Design library take advantage of.
CoordinatorLayout and floating action buttons
A great example of this is when you add a FloatingActionButton as a child of your CoordinatorLayout and then pass that CoordinatorLayout to your Snackbar.make() call - instead of the snackbar displaying over the floating action button, the FloatingActionButton takes advantage of additional callbacks provided by CoordinatorLayout to automatically move upward as the snackbar animates in and returns to its position when the snackbar animates out on Android 3.0 and higher devices - no extra code required.
CoordinatorLayout also provides an layout_anchor attribute which, along with layout_anchorGravity, can be used to place floating views, such as the FloatingActionButton, relative to other views.
CoordinatorLayout and the app bar
The other main use case for the CoordinatorLayout concerns the app bar (formerly action bar) and scrolling techniques. You may already be using a Toolbar in your layout, allowing you to more easily customize the look and integration of that iconic part of an app with the rest of your layout. The Design library takes this to the next level: using an AppBarLayout allows your Toolbar and other views (such as tabs provided by TabLayout) to react to scroll events in a sibling view marked with a ScrollingViewBehavior. Therefore you can create a layout such as:
Now, as the user scrolls the RecyclerView, the AppBarLayout can respond to those events by using the children’s scroll flags to control how they enter (scroll on screen) and exit (scroll off screen). Flags include:
scroll: this flag should be set for all views that want to scroll off the screen - for views that do not use this flag, they’ll remain pinned to the top of the screen
enterAlways: this flag ensures that any downward scroll will cause this view to become visible, enabling the ‘quick return’ pattern
enterAlwaysCollapsed: When your view has declared a minHeight and you use this flag, your View will only enter at its minimum height (i.e., ‘collapsed’), only re-expanding to its full height when the scrolling view has reached it’s top.
exitUntilCollapsed: this flag causes the view to scroll off until it is ‘collapsed’ (its minHeight) before exiting
One note: all views using the scroll flag must be declared before views that do not use the flag. This ensures that all views exit from the top, leaving the fixed elements behind.
Collapsing Toolbars
Adding a Toolbar directly to an AppBarLayout gives you access to the enterAlwaysCollapsed and exitUntilCollapsed scroll flags, but not the detailed control on how different elements react to collapsing. For that, you can use CollapsingToolbarLayout:
This setup uses CollapsingToolbarLayout’s app:layout_collapseMode="pin" to ensure that the Toolbar itself remains pinned to the top of the screen while the view collapses. Even better, when you use CollapsingToolbarLayout and Toolbar together, the title will automatically appear larger when the layout is fully visible, then transition to its default size as it is collapsed. Note that in those cases, you should call setTitle() on the CollapsingToolbarLayout, rather than on the Toolbar itself.
In addition to pinning a view, you can use app:layout_collapseMode="parallax" (and optionally app:layout_collapseParallaxMultiplier="0.7" to set the parallax multiplier) to implement parallax scrolling (say of a sibling ImageView within the CollapsingToolbarLayout). This use case pairs nicely with the app:contentScrim="?attr/colorPrimary" attribute for CollapsingToolbarLayout, adding a full bleed scrim when the view is collapsed.
CoordinatorLayout and custom views
One thing that is important to note is that CoordinatorLayout doesn’t have any innate understanding of a FloatingActionButton or AppBarLayout work - it just provides an additional API in the form of a Coordinator.Behavior, which allows child views to better control touch events and gestures as well as declare dependencies between each other and receive callbacks via onDependentViewChanged().
Views can declare a default Behavior by using the CoordinatorLayout.DefaultBehavior(YourView.Behavior.class) annotation,or set it in your layout files by with the app:layout_behavior="com.example.app.YourView$Behavior" attribute. This framework makes it possible for any view to integrate with CoordinatorLayout.
Available now!
The Design library is available now, so make sure to update the Android Support Repository in the SDK Manager. You can then start using the Design library with a single new dependency:
compile 'com.android.support:design:22.2.0'
Note that as the Design library depends on the Support v4 and AppCompat Support Libraries, those will be included automatically when you add the Design library dependency. We also took care that these new widgets are usable in the Android Studio Layout Editor’s Design view (find them under CustomView), giving you an easier way to preview some of these new components.
The Design library, AppCompat, and all of the Android Support Library are important tools in providing the building blocks needed to build a modern, great looking Android app without building everything from scratch.
