Suleiman's Blog

How I use AI to partner on design problems

Mon, 11 May 2026 00:00:00 GMT

Working through a complex design problem means holding a lot in my head. Research synthesis, product metrics, a Slack thread with stakeholder feedback, Figma comments, decisions made in the last iteration. Multiply that across iterations, and it's hard to keep up.

Most AI tools push toward visual generation. Faster UI, pretty mockups, vibe-coded prototypes. It's fast, and it looks good. But it skips the hard part. I always thought design was about solving problems.

So what if AI could help me think through the problem instead? Hold all of the project's context and surface the right piece at the right moment. Something that compounds context over a project's life. Like a mind palace?

Once set up, I can go from a well-defined problem to a few data-informed code prototypes quickly. Not vibe-coded UI. Concepts grounded in the actual problem and project context. And I'm not using regular AI chat or Projects.

I'll walk through it using Beacon — a fictional local discovery app with made-up research, personas, and one design problem: users bouncing before the data loads. The data and examples aren't real. The setup is. Sample project is on GitHub, linked at the bottom.

Giving AI the full picture

Project context is scattered across different documents, tools and people. Research lives in one place, product metrics in another, stakeholder feedback in Slack threads I missed. Every design session starts with manual context reassembly. So I built a memory bank out of it. Then I taught Claude Code to use it.

my-project/
  .claude/           ← skills live here
  data/              ← research synthesis & metrics (I started with this folder!)
  design/            ← per-feature folders (round-1/, round-2/, … for explorations + feedback)
  project-context/   ← frozen project details (PRD, goals, etc.)
  handoffs/          ← eng specs
  prototypes/        ← working HTML prototypes
  design-system/     ← tokens & components
  CLAUDE.md          ← project instructions
  MEMORY.md          ← persistent context index

CLAUDE.md customizes Claude Code for this project. MEMORY.md is the running index of all context, data, and decisions. Think of it as a table of contents that keeps evolving. When Claude needs information, this file tells it where to look.

design-system/ makes prototypes feel like the real product. My setup is simple: design tokens (spacing, color, typography) as CSS variables. The goal at this stage is validating flows and UX, not visual accuracy. I could wire up this project to my design system code, but setup felt time-consuming.

I store all project information as markdown. They're consistently formatted so AI can retrieve it better. Raw notes are fine going in. Claude can help shape them. Anything confidential, I obfuscate first.

I run Claude Code via Terminal in Cursor. Any IDE showing multiple files works (like VS Code). I need to see the files AI touches. Don't want any hallucinations creeping in!

The Terminal looks intimidating. But using Claude there feels like regular AI chat with more power. I can open a new Terminal tab and run another Claude instance. Using Claude Code via the desktop app could work too but I haven't tried it. Recently I've been using Warp to manage multiple agents and get notified when they're done. Pick an approach you're comfortable with!

Automating my process

Once the project had all its context, I noticed another problem. I kept re-explaining the same workflows: "Read the ticket, check research, give me three directions" every time. So I automated them with Skills.

Skills are documented workflows turned into single commands. Anthropic skills and others are worth using, but creating custom ones tuned to my needs worked best. Here's what I landed on:

explore: helps go through an entire design iteration. I give it a problem: a ticket, a brief, or statement and it kicks off an iteration, cross-referencing available data and generates code prototypes for each.
brainstorm: for working out which directions are worth pursuing
synthesize: takes new raw data and integrates it correctly into the project. Also helps connect new findings to existing data.
prototyping: builds self-contained code prototypes grounded in the design system.
design-partner: highly personalized to how I work. I use it to pressure-test a direction against my own standards and project goals.

Highly recommend taking the time to tweak these skills to your working style, especially design-partner.

Connecting to live data

As projects evolve, new context surfaces first in meetings or tools like Slack, Figma or Linear. I'd rather stay immersed in the problem. So I lean on MCPs (Model Context Protocol) to pull information from these tools. Setup takes time with authentication and permissions. But once running, it stays out of the way.

Linear: When the problem lives in a ticket, I point /explore at it so Claude can gather context, read the latest activity, and also help keep it updated.

Figma: Claude references mocks to generate accurate prototypes. Figma MCP writes to the canvas too which is useful. The more structured the Figma, the better it works. I've found great results giving Claude a well-defined, scoped section of mocks versus the entire file link.

Figma Console MCP: Lets my project learn the design system from Figma libraries instead of wiring up a codebase. Extracts richer layer data than a screenshot. If code extraction isn't an option, this helps get it from your Figma libraries.

Slack: Stakeholder feedback, new decisions, timeline shifts hit Slack before they hit any ticket. Teaching Claude where to look keeps it (and me) current.

All of these are optional. My project started with none of them. I wanted it working on its own first. MCPs came later, as I noticed patterns in my workflow worth automating. More connections means more things that can break so there's a balance.

In practice

One /explore run is the start, not the finish. Most problems take several iterations. I've noticed that the more clear I am, the fewer back and forth I have with AI.

AI surfaces directions I use as starting points. Those proposals are far from sharing or shipping. So I have it surface relevant data points. But I steer what it needs to build. I'll take over with Figma mocks if needed to help it along.

A typical session. Some commands are skills, some natural language. I talk to it like a collaborator. No re-explaining. It knows the project.

Where did I leave this project? What should I focus on next?

**/explore** the loading states problem

**/design-partner** evaluate the latest loading states solutions

**/synthesize** stakeholder feedback for revision 2: [raw feedback copy-pasted]

My latest iteration for loading states is complete. Post an update.
(it'll send a Slack message and Linear comment if MCP works)

Between commands is the actual design work. Sketching, reasoning, spec docs, forming a point of view before I bring Claude back in. This may even mean quick mocks in Figma. /design-partner pressure-tests my thinking against the problem.

Once I lock in directions, Claude builds them as code prototypes. Rough on purpose. To align on direction is the goal, not polish. Before anything goes to the team, I validate it against the original problem statement (/design-partner can help).

Note: I always check the AI's sources. It knows to pull only from existing project data but can still hallucinate. When it cites research to justify a decision, I verify the source.

Handoff

Once aligned on a prototype, I design Figma mocks for key moments in the flow. Then I write a spec describing the flow: the steps, with Figma frames for the key ones.

Writing out the solution is also context for AI. It becomes the anchor for everything else. Claude can use it to build a high-fidelity prototype, write a journey map, generate an implementation plan for code. It's also what stops it from hallucinating, especially with complex flows.

What changed

I stopped starting over. Every session picked up where the last one left off with decisions, dead ends, all of it. I could go from a well-defined problem to clickable prototypes fast. Context switching dropped. I could stay in the problem.

Code prototypes changed the feedback dynamic. Unlike static Figma mocks, they weren't polished and yet that helped. People stopped picking at visual details and started talking about UX. That's the conversation I want earlier. Bad ideas die faster too, before I've invested much.

I track decisions per round in the design/ folder. No more digging through Figma comment threads to remember why we made a call three weeks ago. Syncing stakeholders stopped feeling like project management. Claude reads the Linear tickets, Slack threads, and latest research. I don't manually summarize. It already knows.

The longer the project ran, the more useful it got. Early decisions became context for later ones.

Where this could go next

Prototyping with code components. Once I have a spec, rough prototype, and key Figma frames, Claude writes an implementation plan. I give that to my codebase and it builds a Storybook prototype using the design system. Real code that my engineers could use. I've had a fair amount of success with this. Claude Design might make it easier but haven't spent enough time with it yet.

Proactive context maintenance: Claude is already connected to Linear, Slack, and Figma. Right now I manually feed it updates. I've started with a /tidy skill for cleanup and maintenance, but the next step is surfacing a diff: "here's what's new since you were last here." New ticket comments, a Slack thread with an eng constraint, an updated Figma frame. The biggest tax in this setup is keeping context fresh. This would make it passive.

Post-ship feedback loop: The cycle ends at handoff. If I connected analytics, Claude could compare live performance against the original goals. "Bounce during load dropped from 38% to 22% after the receipt pattern shipped." That closes the loop. I'd know which design decisions worked without pulling dashboards.

Caveats

There's quite a few, I won't lie. But the benefits far outweigh the cons for me to even complain.

Upfront investment is real. Organizing project context takes time. I built it piece by piece. The structure is both powerful and fragile. Claude helps maintain it, but I must know what goes in. Incorrect or stale data meant hallucinated outputs.

It doesn't replace thinking. The project's greatest strength is recall and synthesis, not outsourced judgment. Claude does the synthesis work: retrieves the research, matches patterns, frames the initial tradeoffs. I do the design thinking. I've never shipped a direction without reshaping it because often times its suggestions can be quite terrible. But it does offer a good starting point.

Complex concepts need structured input. A 12-step prototype from a written prompt alone will create drift. Key states mocked in Figma plus a spec document keep AI's output anchored.

It amplifies blind spots. If my research only covers one persona, every recommendation cites that same source. It makes gaps obvious.

Context grows faster than it compresses. As a project runs longer, the memory bank grows: more rounds, more decisions, more data files. At some point there's too much for a session to hold cleanly. I manage it by archiving old rounds, keeping MEMORY.md lean, starting new chats often (/clear and /compact were my friends).

Prototype sharing feels rudimentary. The prototypes were interactive and fast to get feedback on. My team was super into it. But sharing a zip file isn't an elegant Figma link. No annotated comments or canvas sometimes made it tricky to gauge feedback via Slack or Linear comments.

Knowing when to take over. Sometimes it works flawlessly that my jaw drops. It one-shots my intent perfectly. But sometimes it won't get the simplest of things right, despite my constant prompts and prayers to the AI gods. That gets tiring. AI gets me 80% of the way. Then I jump to Figma to take it to completion. Otherwise, it's diminishing returns. It's also why I'm not chasing high-fidelity concepts with AI (yet).

Closing thoughts

At two months in (at the time of writing), I'm still finding the edges. But long enough to see it work well. Engineering and product were already moving faster. This is how I can keep pace where AI handles the recall, I handle the judgment.

I didn't need AI to crank out pretty UI. I needed it to hold more so I could think clearer. That's what this does, most of the time.

Starter kit

Try it yourself on GitHub: github.com/Suleiman19/ai-design-buddy

/sample has Beacon pre-loaded with fake data, research, and skills. Good place to explore before committing to your own setup.
Run /explore on result cards to see a full iteration kick off.
Starting fresh on your own project? Delete /sample first.

It's early and opinionated. Expect it to change.

Building something similar or approaching this differently? I'd love to hear about it! Reach out on LinkedIn.

Framer X For Design - 5 Reasons Why I Switched

Tue, 26 May 2020 00:00:00 GMT

As a developer turned designer, I have always been fascinated with ways to close the gap between design and development. Recently, I stumbled upon Framer X. After using it for quite a while, I’m convinced that it is a powerful new design tool that closes that gap considerably and encourages tighter collaboration.

NOTE
This is not a sponsored post. I haven't been paid by Framer to write this. All opinions are purely based on my personal experiences with the tool. Moreover, this isn't a hate post for other design tools (each one excels in its own right).

Design tools of the past

I have been an avid Sketch user for over 6 years now. However, for prototyping, I always found Framer JS more suited. Yes, the old Framer Classic that scared almost every designer (including me) which required writing code.

Now, at the time, for logic-based complex prototyping, this was the tool for the job. Framer JS used CoffeeScript, a preprocessor that was friendly and simpler to write so I braved and jumped right in.

However, despite that, it was so time-consuming to build something in Framer JS that it was my last resort for prototyping. It still didn’t replace my daily design tool yet.

Sometime later, along came Principle. A simple, timeline-based interaction design tool. Given its ease of use, I had quickly forgotten Framer.

Fast forward to 2019 and I didn’t see Framer JS around anymore. Instead, it was Framer X and everything about it seemed different.

What is Framer X?

Framer X is a smart interaction design tool for realistic prototypes.

Framer X is a complete overhaul with a low entry barrier for designers. Unlike previous versions, I could do everything I could I Sketch (and perhaps more!) without writing a single line of code. Designing and prototyping weren't two different modes. I found myself seamlessly doing both together. Moreover, there was a slew of features unheard of that highly piqued my curiosity. I had to use it myself to see what the hype was about.

If you are a designer who can code or a coder that can design, Framer X will be your very best friend.

John Traver | Framer X: to future or not to future

Game-Changing Framer X Features

In this article, I’ll show you a comparison between common tasks I’d do in Sketch which, trust me, is similar in almost every other major tool (yes, Figma and XD) and how Framer X handles the same. Hopefully, towards the end of this article, you’re as excited as I am to jump into this new hybrid tool.

So without further delay, here are some of the reasons why I switched to Framer X.

Responsive Design For Real

To clarify, responsive design in practice (as a designer) is the ability to create and set up on elements on canvas to resize in specific ways across different screen sizes.

Sketch mimics a simplified version of Xcode’s AutoLayout. This feature (of using constraint pins) is familiar across other tools too.

However, I find some quirks with this in Sketch.

For any element to be resizable, I need to MANUALLY setup every constraint! Moreover, oftentimes, I care about setting constraint values over the specific width or height of an element. For example, if I’m designing a list on iOS. I don’t care about the width of the list itself. What’s more important is that the list maintains a 20px (safe area guides) margins on either side. For that, I’ll have to recalculate the list’s width itself to get 20px margins on either side.

Now, Sketch experts might argue that I could use dummy rectangles, rulers or the Anima plugin to space without pixel calculation. That's workable, but not efficient.

Here's how Framer X does Responsive Design

One word — "automatic".

Based on how elements are positioned in your Artboard or “Frame” (no, it’s not a pun), Framer will automatically set up constraint pins. In other words, your mocks are responsive by default!

Notice how I didn't explicitly set any width for that rectangle. No manual math. Just set constraint values, Framer automatically pins them based on its position.

The automatic constraint pins are a HUGE time-saver, allowing me to design with speed.

If you look at how responsive design in front-end development, setting specific constraint values over specific element values is the norm. For example, when setting a fluid grid, you would declare the margins around each grid item, but let the screen width dictate the size of the grid item itself. Framer uses a similar approach that feels more familiar to use and powerful.

Frames over layers

I was confused with the concept of Frames vs Layers first. Traditionally, layers represent individual elements in our Artboards. You could also group them. But groups weren't layers themselves. This was my understanding with Sketch (no quarrels here). It was a nice way to organize and understand how to build mocks.

Things in Framer are different. While the Layers panel exists, each "layer" in Framer is actually a Frame (no pun intended). Figma folks may feel right at home here.

Each Frame is an empty container that can house other Frames or elements. You can drag and drop other elements inside this Frame. Doing so makes that Frame the automatic parent of those elements. In fact, your "Artboard" is also a Frame.

This is similar to div tags in HTML. Each <div/> can nest child elements. Furthermore, this parent div container’s properties can affect it’s children as well.

READ
CSS-Tricks clearly explains the CSS Box Model and how that applies to (web) design.

Initially, this skewed my mental model of how ‘layers’ worked and I struggled. However, over time, this felt natural and more flexible.

I couldn't figure out how to best explain why in words. So I made a video for you instead. In this video, I design a simple card in Sketch and then the same in Framer.

Watch on YouTube

Workflow differences in Sketch and Framer

Previously, I had to draw dummy, invisible rectangles to act as (fake) containers for my elements and then group them. This definitely was NOT ideal! Framer allows you to use Frames as containers for your elements which considerably reduces layer complexity.

Stacks

Stacks are what Flexbox is in web-development (CSS).

In Framer, Stacks are good for expressing truly fluid layouts. It can automate things such as distribution and alignment.

Learn more about Stacks from Framer

In Sketch, this functionality doesn’t 100% exist, or in any other tool for that matter. I can somewhat mimic the same with Sketch's Smart Layout or the Anima plugin, but it isn't truly "fluid".

However, the Stacks feature in Framer is much more powerful. You start by drawing a Stack and then throw elements inside it. Later, you can configure the Stack’s properties such as orientation, how items should be distributed, and spacing between individual items.

This feature opens up powerful possibilities for responsive layouts such as navigation bars, drawers, lists, and grids to name a few. All of these become very easy to make and closer to the real thing.

Prototyping in Framer X

Traditionally, I always found myself in two distinct modes:

Design - where I design all the mocks and its variants (states) for prototyping flow
Prototype - I take a pass at all my mocks and add in hotspots and links

In Framer, I am designing and prototyping in parallel. The experience here feels very seamless. You can build a click-through prototype in Framer without writing any code.

For things like drawers, modals, and more, I don't find myself redesigning (or copy-pasting) screens. I only design those elements I need for the transition.

LEARN MORE: Simple click-through prototyping in Framer X

Logic via code

Framer X allows you can take literally ANY element on the canvas and introduce behavior. Remember I mentioned that Framer X is React powered. Be it simple animations, complex interactions, or logic, it is possible.

Every Framer project is a Web project.

However, I’ll admit this involved me having to learn basic React. Luckily, Framer X uses TypeScript, which made writing JSX syntax MUCH easier.

If I want to do things like show a button click? No problem. Show an alert on button click? Sure!

Here’s a quick example of how I’d write some code to animate a button on hover and click. I simply have to write a function and then tell my button on canvas to use it.

This example barely scratches the surface. You can do complex scroll interactions, logic-based prototypes, pulling data via APIs, using real front-end components, and more. But I'm going to keep it simple for now. If you're interested, the Framer 101 Crash Course is the best place to start.

Designing for the future

It’s been well over a couple of months since I’ve started using Framer X. While it feels different from tools we're typically used to, I found Framer more dynamic and powerful. Framer’s tools allow me to communicate my work with high levels of fidelity that wasn’t possible before.

While those are great benefits, to avoid a biased opinion, it’s important to document its downsides.

Framer X Disadvantages

Framer's tools, while more intuitive have an initial learning curve
To take full advantage of Framer, you'll have to touch code (and learn React)
You can achieve extremely high fidelity with Framer - clearly define how much detail is needed in advance

To end on a more positive note, and to recap, here’s why Framer became my main, go-to design tool.

Framer X Advantages

Automatic Responsive Design
Frames and Stacks are powerful tools for responsive design
Prototyping feels natural and can be used interchangeably when designing (over being a different “mode”)
Intuitive prototyping without having to duplicate Artboards for UI changes/states
Use real, interactive components in design
Framer projects are web projects (you can literally Inspect Element your UI)
Ability to add logic with code

Not ready to switch yet?
No problem! Framer X allows you to copy-paste your design elements directly from Sketch/Figma. I did this for a good while until I was confident to fully switch.

READ
How to start using Sketch and Framer X — smashingmagazine.com

An Exciting Future Ahead

Framer X is an interesting and hybrid tool that sits at the intersection of design and development. If you are an engineer who can design or a designer who can code, I highly recommend giving Framer a try. Moreover, Framer is coming to the web this year, which has me excited about all the ways we could improve collaboration.

UPDATE
Framer Web is out and now includes a Free plan

What are your thoughts on the new Framer? Have you tried it already?

Build your UX Portfolio from Scratch – Choosing a Web Stack

Wed, 07 Aug 2019 00:00:00 GMT

Choosing to hand-code your UX portfolio can be an ambitious, yet daunting task. Your portfolio website is perhaps the most important avenue to display your experience, skills, and values as a designer.

With that said, you want to put your best foot forward. Having complete control in how you do this is what development (hand-coding) can offer albeit at the cost of time and increased effort.

A majority of that time could go into choosing the right set of tools for web development. Especially, when there’s a multitude of options to choose from that do similar things. It is important to choose tools that are not only easy to understand but speed up our workflow.

Even then, making a choice and then sticking with it can be hard, especially when you discover a blocker later down the road.

That’s what I’m here to help you with.

Welcome to Part 3 of the ‘Build your UX Portfolio from Scratch‘ series!

In this part, I’ll help you look at different available web technologies, their pros, and cons and finally help you decide the right toolset to develop your UX portfolio.

Developing your UX portfolio consumes considerable time and effort. But it grants you complete freedom and control over how you want to showcase yourself, making the trade-off worth it.

Previously in Part 2, we designed our UX portfolio by going through the entire design process. By this point, I assume you have a UX portfolio website design ready to go for development. If not, I strongly suggest reading Part 2 - It includes a lot of resources to inspire you and how to effectively design your portfolio.

New to the Build your UX portfolio series? Start with Part 1.

Build your UX Portfolio Series
This tutorial is broken up into several parts:

Part 1: Getting Started
Part 2: Design
Part 3: Choosing A Web Stack
Part 4: Setting Up Your System To Start Development (Coming Soon)
Part 5: Understanding Your Project Environment (Coming Soon)
Part 6: Getting Dirty With Code (Coming Soon)
Part 7: Optimizing Your Portfolio For Speed (Coming Soon)
Part 8: Launch your Website (Coming Soon)

Overview

Typically, I'd call this section 'Getting Started', but that's Part 1.

When starting to look for web tools, it helps to fully know exactly what you need in terms of features and functionality. Before we actually put our ‘research expertise’ to use on Google, remember this rule of thumb

Prefer popular tools that have a huge community behind it.

Why you ask?

Online help (Stack Overflow) when you’re stuck, not knowing how to do something
Strong tool development support with plans for the future
A low number of bugs (no bugs is near impossible) with workarounds
A large number of other tools that will work nicely with it, sometimes offering very easy plug and play options

So keep this in mind when you're trying to find something suitable for your needs.

With that said, what do we actually need?

Type of Tools Needed for your UX Portfolio

In a broad sense, we need 3 types of tools:

a Text Editor
a front-end (CSS) Web Framework
a Build System

Don’t panic if any of this doesn’t make sense to you. I’ll explain below what each one is, why we need them and a curated selection of each kind to choose from.

NOTE
None of the tools I recommend are promotions or sponsored content that I’m trying to sell to you. They are all my personal opinions which I say from experience.

1. Text Editor

We briefly looked into text editors in Part1 - Getting Started. Even so, I’ll briefly cover them here.

Text editors can help us code faster with powerful features such as:

auto-complete
syntax highlighting
useful find and replace features
extensibility (ability to add more features via plugins)

However, our focus on our UX portfolio website is going to be a text editor. Something lightweight and fast. Remember, nothing over the top!

Here are the 3 most popular ones.

Sublime Text 3
A sophisticated text-editor built for speed and extensibility

- Super fast to use
- free trial forever
- Plugins

Useful Shortcuts

Atom
Free, open-source text editor by GitHub

- Easy to use and great UI
- Packages
- GitHub integration

Useful Shortcuts

Visual Studio (VS)
A fast and powerful IDE by Microsoft

- powerful IDE
- great refactoring tools
- advanced features and complexity

While Visual Studio is popular, it is an IDE that might be overkill.

NOTE
Text Editors are NOT IDEs (Integrated Development Environment)! Both are two very different things. Text editors are more lightweight while IDEs are more robust including more powerful and complex features.

The Sublime Text VS Atom debate happens a lot around the internet. There isn’t anything that one has that the other doesn’t that could be a possible deal-breaker.

READ
IDEs VS Text Editors – When to use what?

I have used both extensively and can personally say that it all comes down to personal preference. I used Sublime Text before and recently have gravitated more towards Atom because I like the interface for managing my packages.

To build this specific iteration of my UX portfolio, I used Atom. For the previous iteration, I used Sublime Text. I can’t really say much for VS Code. While it’s powerful, I also find it fairly complex to use for a project of this simple scale and complexity.

If you have trouble deciding, here’s a comparison of all 3 which help give you perspective.

So go ahead, try and pick one which you like. I promise that your choice won’t be a hinderance for this tutorial.

2. Front-end Web Framework

To put it in very plain words, it is a CSS framework that’ll help you speed up your web development (front-end).

A good framework includes provides you with the following features:

A responsive grid with strong support for ‘mobile-first’ design
Collection of customizable components (buttons, forms, tabs, tables, etc) to use in your website
In-built functionality for adding interactivity
All in all, easy to use, extend and modify

Keeping that in mind, here are some popular frameworks.

Bootstrap 4

This is the most popular front-end component library for building responsive projects.

Get Bootstrap 4

UIkit

A modular, lightweight CSS framework with many useful components for small-scale projects.

Get UIkit

Materialize CSS

A CSS framework that's based on Google's Material Design

Get Materialize CSS

Skeleton

Extremely simple and lightweight responsive framework (just 200 lines of code).

Limited in functionality. Use with caution!

Get Skeleton

Some other frameworks worth looking into include:

Foundation
Most advanced responsive framework. Best suited for large-scale, complex enterprise-level projects.
**Semantic UI
**A framework designed with ease of use and natural naming of classes
Bulma
A (relatively new) modern, elegant, free, open-source framework that's quick to pick up
**Pure CSS
**A framework with a small footprint. Includes responsive CSS modules for quick use

Again, picking the right one here is more of personal preference. But keep this in mind when choosing a framework you like.

The more robust a framework is (lots of components, features, etc.), it comes with great support but larger will be the learning curve and complexity of use. While simpler, smaller frameworks can be quick to pick up and use, they can quickly become limiting and may not have everything you need and with lesser community support.

In plain words, by community support, I mean that when you get stuck at some point, you most likely could be on your own since Stack Overflow might not have an answer for you.

NOTE
Pick whatever you like. But take your time and think carefully on your choice because unlike Text Editors, swapping out CSS Frameworks can be a pain!

But don’t fret because, if you’re unsure of what to choose, pick Bootstrap.

RECOMMENDED FRAMEWORK
For this tutorial, I will be using Bootstrap 4, the most popular and versatile framework. It is the most safe option which is quick to use which offsets the slightly higher learning curve.

If you’re thinking ahead, you might worry about things like, Bootstrap is large and includes lots of things that I won’t use. That is true, but there are ways to fix that (relatively simple) which I will address in future parts.

3. Build System

A Build System tool is a task runner that can help automate tasks that you otherwise would do manually. With a little bit of setup, the pay off is huge in terms of speed and time gain.

A build system can manage many things, saving you from performing repetitive tasks manually. Some of them include:

dependency management
watch your files for changes to automatically update changes
combining multiple stylesheets, js into one
automatically minifying/compressing source files and images

Here are some of the popular build systems.

Gulp

A popular, simple build system (task runner) to automate and enhance your workflow

Get Gulp

Webpack

A popular bundler with powerful features.

Might require more complexity to configure!

Get Webpack

Browserify

A module-based bundler that allows you to use Node.JS bundles directly in the browser

Get Browserify

Gulp VS Webpack VS Browserify - which is better?

Some other tools include:

Grunt
A Javascript task runner
Bower
a package manager for the web

**Tl;DR
**Gulp is a task runner which is simple enough to configure and quick to get us up and running. I will be using Gulp, keeping in mind its speed and simplicity.

I've found Gulp easy to use, so if you’re using the same, then I assure you that you’re in safe hands!

Final Tools in your Arsenal

To recap, we looked at the 3 different kinds of tools we need. Then we did a deep dive at each type and saw various available options.

Then, for this tutorial series I mentioned that I will be using:

Atom as my text editor
Bootstrap as my front-end framework
Gulp for my build system

In this article, I hope I've given you an overview of the different kinds of tools we need and a taste of the different choices available in each.

While I could've simply said we're going to use these 3 tools right from the start. But I believe it's fair to lay out what's available to us, understand the options, analyze them and then make a meaningful choice.

Next Steps

Now that you have downloaded what you need, you're probably wondering "Now how the heck do I set everything up and actually begin coding my UX portfolio?"

That's exactly what I'm going to cover in the next part. In Part 4, I'll walk you through setting up all these tools to play nicely with each other and show you how to use them!

In the meantime, if you liked what you read, share this article with others who are developing their own UX portfolio. If you have any questions or thoughts, let me know in the comments below.

Lastly, don’t forget to subscribe below to know first when Part 4 is out!

Part 4: Configuring your Web Stack (Coming Soon…)

Build your UX Portfolio From Scratch – Design

Tue, 16 Jul 2019 00:00:00 GMT

Designing your own UX portfolio can give you an edge to stand out from the crowd. By choosing to design it yourself, it is an opportunity to showcase your brand and who you are.

By being original and unique, your portfolio will be memorable. So don't copy a theme or someone else's design. You don't want your UX portfolio to come off as a common template or worse, a rip-off.

Welcome to Part 2 of the 'Build your UX Portfolio from Scratch' series!

In this part, we'll look at how to approach the design phase. From brainstorming ideas on how might we design our portfolio to building high-fidelity screens and then preparing to handoff for development.

Previously in Part 1, I gave you an overview on what this series is going to be about. It covers a lot of things right from a website name to all the various tools we'll use from design to development. If you haven't read it yet, I highly encourage you to start with Part 1 first!

Design Process

It always helps to start with a plan or a road-map. To begin with, think of your portfolio as a design problem - Just as you'd tackle as any other design challenge.

But before we even decide on a design plan and anything else, ask yourself this.

Why do you need a Portfolio? Who are its Users?

TIP
You are not the user.

Do you need a portfolio to attract new clients? Or is it to help you land a new role? Think about it's use-case and who the target users are. For instance, if you need a portfolio to help you get a job, then the users might be recruiters and hiring managers.

Looking at it this way will help decide what want to show on your portfolio and how to present it.

Treat your UX Portfolio as a design problem

Yes, I'm asking you to UX your portfolio!

Asking yourself these questions early on will give you perspective. It will allow you to design with your target audience in mind.

READ
Considering the user of your UX portfolio – Sarah Doody, Inside Design by InVision

Here's the design process we're going to follow, right from hand-sketching and all the way to publishing our finished website.

This image could potentially be misleading since it appears to be linear. But design is never linear. Rather, it is iterative. So while you design your portfolio, you can iterate across these steps multiple times until you reach a design that is satisfactory (within reasonable time of course).

Quick Navigation

Brainstorm
1. Paper Sketching
Wireframing
Medium-fidelity
High-fidelity
1. Final Designs
Test for Feedback (Optional)
Development Handoff
Takeaways

Brainstorm - by finding inspiration

Whether this is the first time you're making your portfolio or not, you can always learn by learning from what other's have made.

Bestfolios has a great collection of UX portfolio examples. They are portfolios of designers in companies like Google, Facebook, Spotify and more!

If you're not sure on what to include in your portfolio yet, this can be a powerful starting point. Looking at how the industry approaches it can give you an idea on WHAT to include and HOW.

Inspiring collection of UX/UI portfolios - bestfolios.com

INSPIRATION
10 Student Portfolios Done Right – Bestfolios

Make note of patterns

Once, you've browsed through many portfolios, you'll start to notice a common pattern - A compelling hero section, focus on projects, and an about me page at the least.

While visually, there might be variations, here's what a common portfolio structure looks like.

Common Layout/Components in a UX Portfolio Website

Remember, this is YOUR portfolio. So while you look for inspiration, use it to nail the essentials down. But infuse it with your personality to make it unique to you!

Paper Sketching

Now that you've seen a couple of portfolio, you should have a pretty good idea on how you might want yours to look like. While that thought is fresh on your mind, put it down on paper.

Doesn't matter how it looks. Don't worry about fonts, colors and other visual specifics. Just dump everything that's on your mind onto a paper. Believe me, in this way, you'll be able to brainstorm over ideas MUCH faster.

NOTE
There can be a strong tendency to directly jump into code. Resisting that temptation allows you to be more open and flexible to ideas for your portfolio.

Paper sketching allows you to ideate at the speed of thought.

Here are some rough sketches I came up with on the things I wanted to do for my portfolio. Be sure to keep this handy. It works as a great reference point from designing to development!

Initial paper sketching to brainstorm ideas for my UX Portfolio.

Notice that I've also scribbled a lot of notes around my screens. They'll be a useful guide for the next design phase.

The focus here was on two key screens - the Home and About page. You might wonder, "What about the case studies?". While that is by far the most important, in this scenario, content and presentation overthrow the design of the page itself.

NOTE
For my case studies, I chose to write them on Medium as I was more concerned with content rather than the visual design of the page.

However, if you wish to keep your case studies in-house, I strongly encourage you to attempt brainstorming them too

If you're doing a redesign, make sure you only change those aspects of your portfolio that needs improvement. This could be something you've been wanting to improvise, or you've received feedback from users.

If you're unsure, look at your analytics data or previous user tests if any. I know this might be a little overkill. But testing is key to thoughtful design. I'll cover more on testing further in this article.

The paper sketches are a crucial starting point for your UX portfolio. Think of it as a visual map that will guide us in building our wireframes and high-fidelity. Next, we'll use this to build our wireframes.

Wireframing

A wireframe is a blueprint. A visual guide that represents the skeleton framework of a website

Wikipedia

By this point, you'd know the elements to include in your portfolio. Your rough paper sketches are a handy guide to what those are.

In wireframing, think about the skeleton or structure of your portfolio. All those elements you wish to include, think about how you want to place them and where.

Here are my wireframes. At this point, you could jump into a design software of your choice to design wireframes. For this entire tutorial series, I will be using Sketch (Mac-only). For Windows, the alternatives are Figma and Adobe XD. I've gone over this in Part 1.

Home

About

TIP
This is a good time to think about the portfolio copy such as the headline, subtitle, your about me page, etc. It doesn't have to be set in stone at this point, but at least, form a rough idea of what you want to say.

Continue to be flexible with ideation at this point. It allows your mind to be open to new ideas. You'll notice there are a few changes I've made to the design in the wireframes compared to the paper sketches.

Medium-Fidelity

Medium-Fidelity designs include the interactions & navigation possibilities of an application.

Definition from d-labs.com

Alright, I tried my best to get you a definition that makes sense. But turns out, I didn't understand the technical verbage here either. So let me try to explain what medium-fidelity means, in simple terms.

Medium-fidelity includes what your final UX portfolio contains such as layout elements, its navigation and text.

In other words, your navigation links, what your button is supposed to say, your headlines, subtitles, about me. All content needs to be finalized at this phase.

CAUTION
At this phase, do not, I repeat, DO NOT focus on colors, font styles or any other aspect of visual design

Medium-fidelity does NOT mean visual design. Focus on the structure of your UX portfolio. How does your design hold up with the final copy in place?

Keep your medium-fidelity monotone (grayscale). Doing so will keep your focus on structuring your portfolio rather than visual details such as colors and typography.

To design in medium-fidelity, you can use your existing wireframes to build upon. Leverage Symbols to upgrade the fidelity of your existing components.

The fact that you aren't worrying about visuals will allow you focus on the bigger picture. You won't be bothered with petty things such as "Should the button be rounded by 2 or 3px?" or "Should the spacing be 40 or 48px".

Here's how my medium fidelity designs look like.

Home

About

I know that some things could be improved here, such as spacing. But as I've previously said, the focus should be on layout structure, final copy and how that plays well with your design.

With that said, we now move on to the most fun and visual part of building your UX portfolio.

Design for High-Fidelity

High-fidelity designs appear and function as similar as possible to the actual product that will ship.

Nick Babich, Adobe Blog

This is the phase where you're going to be spending a bulk of your time. After all, it is designing how your UX portfolio will actually look like on the browser! Define the visual style - colors, typography, spacing, etc.

Before you let loose your creativity, keeping these tips in mind can make things easier.

3 Key things to remember

1. Create a styleguide to build faster

A simple styleguide for colors, typography and basic elements can help you design faster.

TIP
If you have a front-end framework you wish to use, they might have a Sketch styleguide for you to download. If they do, I highly encourage you to use that to jumpstart your design.

For my portfolio, I decided to use Bootstrap 4 (a very popular front-end web framework). Luckily they had a design system for Sketch. I quickly adapted that to my branding and jumpstarted my design. I'll cover more about front-end frameworks when we get into development.

Bootstrap 4 Design System
If you plan on using Bootstrap 4, you can grab the design kit Sketch file for free from sketchappresources.com.

2. Consistency is key

Your portfolio is your brand. Make sure it has one voice that echoes in unison across your whole site. Be it colors, type or even the content - keep it consistent.

3. Showcase who you are as a designer

While your portfolio is largely about your work (case studies), it also about demonstrating who you are as a designer and your beliefs.

So ensure your portfolio echoes your thoughts and beliefs in unison. For example, as a designer, I believe in clear, simple experiences that are minimally designed. Hence, my portfolio too is designed to reflect the same.

However, if I said that and then had a portfolio designed over the top with flash of colors and animation, that would be confusing right?

NOTE – **Don't aim for perfection
**Aiming for 'that perfect design' will waste a LOT of your time. graudally improve upon it. Don't get stuck trying to make it perfect (because there is no such thing).

Final Designs

Here's the final designs for my portfolio.

Home

About Me

If you're interested in getting the high-fidelity designs, you can download the Sketch file from below. It includes a simple styleguide with typography, colors and symbols defined.

Test for Feedback

Now that we're done designing our portfolio, we need to test to see if our design is actually usable by others.

I'd like to say that you could skip this section if you want. That's why I've called it optional. But then, I strongly urge you to do a bare minimum usability testing at the least.

TIP
Use Nielsen's 10 Heuristic principles to troubleshoot your UX portfolio design. Fix anything you can find.

I agree that robust user testing at this phase can be overkill. So from here, you could do two things, each with its own pros and cons.

Method

Pros

Cons

Perform User Testing Now

Easier to do now with a prototype
Can uncover usability issues early on

Can take time away from launching your portfolio

Get Feedback after launch

Issues uncovered can be more accurate

Implementing design changes in development can be hard/time consuming

TIP
Here's how you can conduct quick guerrilla user tests on your own.

If you're designing in Sketch, Adobe XD or Figma, either software lets you quickly transform your design into a prototype.

You can then share the prototype link which your users can access via any browser to test. Use this via link to test with people. Useful to gauge initial reactions from people. Even better if you've designed how your case studies will appear in your portfolio.

READ
Best UX Design Tools for Testing - Paul Boag

If you have the opportunity, test them with hiring managers and other designers you know. Gauge their reactions when they use your website (portfolio). Their feedback is rich information that you can use to further improve your portfolio.

If you have the luxury to do this, then I highly encourage you to do so. The portfolio designs of mine that I shared with you is the 5th iteration based on user feedback. Many of my design decisions are based off this.

Get Ready for Development Handoff

That was one long article but we're finally at the last step!

Once your portfolio design is complete (based on how many iterations it took you), the last and final step is handoff.

Remember what I said about perfection? There is no such thing! So don't spend time trying to get that 'perfect' design. You'll constantly keep getting new ideas so put it hard stop to it after a point.

What I'm trying to say is, the last step is preparing for development. So your design needs to be ready to go for this with no further design changes.

Since this is typically an individual project, you'll basically be handing it off to yourself (who is also the developer in this case).

Use Zeplin for your Design spec

Use a tool like Zeplin to import your portfolio designs. This is a much better way to reference your design specs rather than constantly looking at your Sketch file.

Zeplin.io

Zeplin is free upto one project. So go ahead and export your Sketch artboards to Zeplin. Sketch has a handy plugin that can do this for you.

READ
Learn from Zeplin on how to export from Sketch.

Thankfully, Zeplin isn't that complicated to use. By simply hovering over your designs, Zeplin gives you the specs on the right panel along with code!

With that, you're now ready to jump into development!

Recap

If you've made it this far, then please give yourself a pat on the back. That was definitely not easy for an article this long! Great job!

Let's quickly summarize what we did in this design phase.

First, we looked into what could be the design process for our UX portfolio.
We started brainstorming ideas for our portfolio by looking at some great portfolio examples from the industry.
Then, we identified patterns and sketched early ideas on what our portfolio might look like.
Next, we took our rough sketches and notes to build wireframes, focusing on layout and structure.
We then evolved our wireframes to medium-fidelity, fleshing out the website content and navigation.
Finally, we transformed our medium-fidelity to high-fidelity mockups by focusing on visual design
After completing our design, we looked into how might improve our portfolio design via heuristics or quick guerrilla usability testing.
Lastly, with our designs now complete, we exported them to Zeplin for development handoff.

Takeaways

Design is never finished. While that is true, this is our portfolio and there can be a tendency to endlessly iterate, trying to find that perfect design. It is important to be realistic and acknowledge that fact.

With that said, here are some last few pointers to keep in mind when you're in the design phase of your portfolio.

Design keeping your users in mind?
What do you want your users to takeaway from your portfolio?
Keep consistency with you as a brand and beliefs as a designer
Case studies are important – prioritize content over presentation
When possible - test and get feedback from your target audience

Next Steps

With all that said, we're now done with the design phase of building your UX portfolio. Cheers!

We've successfully exported our designs to Zeplin, ready to begin development. However, web development has an ocean of choices which can be overwhelming. But not to worry because that's exactly what I'll be covering in the next part.

In Part 3 of Build your UX Portfolio, I'll talk to you about the frameworks, languages and tools we'll be using (with choices) to develop your portfolio.

Be sure to subscribe below so you'll know when Part 3 is out!

Part 3: Choosing Web Technologies (Coming Soon...)

Build your UX Portfolio From Scratch – Getting Started

Mon, 01 Jul 2019 00:00:00 GMT

Our UX portfolio is a key piece of displaying our capabilities as a designer. Hence, it becomes essential to make one that can speak for you.

In this tutorial series, I will walk you through how I designed and developed my UX portfolio website. Sure, I could've named this article as 'How I Built My Portfolio' but I want to show you how YOU can do it too. It's easy, and you don't need to be a developer. Let me show you.

Fabricio Teixeira from the UX Collective clearly outlines the importance of a portfolio website.

There are those people who can design and also do development. Such hybrid individuals are known in the industry as UX Engineers. In fact, this entire blog is for such individuals!

UX Engineers weave together strong design aesthetics with technical know-how.

UX Engineer Role @Google

When you can leverage your talents from both domains. Why not use them to develop your own UX portfolio from scratch?

It is a powerful way to harness what you know to build a portfolio that's unique to you. The best part is that you and only you are in control of the whole thing.

**What to expect in this article?
**This will be an exhaustive, multi-part tutorial series. I will walk you through exactly how I designed and developed my portfolio from scratch. This includes my design process, development tools and how I launched the website. I did all this in one month and I'm no web development expert!

If you cannot code, don't worry. I am no web development expert and I got by. I'm here to walk you through it.

I will show you how to do all this and more. I will also be sharing tons of other resources so be sure to keep an eye out and save them.

There are 3 broad phases of building your UX Portfolio.
Over this multi-part tutorial, I'll take you through all these phases.

I'm a designer. Why do I have to code?

It offers many advantages for you and your UX portfolio (website).

Complete Control
Create a highly customized portfolio and make it unique to you
Not another clone
Templates are repetitive, which look like other portfolios on the internet
You own it
You and only you are in complete control of EVERY aspect of the website. Everything belongs to and is owned by you. Using third-party providers leaves you at their mercy since your entire portfolio is with them.
Freedom
Third-party portfolio builders can be restrictive, limiting appearance and functionality
Web development is not hard anymore
Various frameworks help ease and speed up the process
You learn!
A designer who knows how to code can create feasible solutions that respect technical challenges.

This is YOUR portfolio - make it your own!

Jessica Ivins beautifully explains with a real-life story about the advantages you have as a UX Designer who can code.

The intent of this tutorial series is to help you learn how to custom code your own portfolio from scratch. By the end, you will be able to rapidly develop, modify and maintain your portfolio with ease in the future.

Completely new to Web Development?
If you're completely new to web development and don't know HTML or CSS, W3schools is a great place to start by yourself.

Alternatively, Udemy has a great course for beginners.

Build your UX Portfolio Series
This tutorial is broken up into several parts:

**Part 1: Getting Started
**Part 2: Design
Part 3: Choosing A Web Stack (Coming Soon)
Part 4: Setting Up Your System To Start Development (Coming Soon)
Part 5: Understanding Your Project Environment (Coming Soon)
Part 6: Getting Dirty With Code (Coming Soon)
Part 7: Optimizing Your Portfolio For Speed (Coming Soon)
Part 8: Launch your Website (Coming Soon)

Getting Started

In part one of this article, I will give you an overview of everything that you need. It should help you prepare and know what to expect from the upcoming articles.

For experts who have their own UX portfolio wanting to redesign or developers, feel free to skip sections you already know. This article will cover certain sections exhaustively to help those who haven't done this before.

I will walk you through the entire process of how I made my portfolio from scratch. My hope is that you can learn from this, avoiding the pitfalls I made thereby saving you tons of time.

This is how my UX portfolio looks like.

My portfolio – iamsuleiman.com

My hope is that by the end of these tutorial series, you can create a portfolio like this or better.

Although it's not a complete visual overhaul, you'll be surprised to see the reworked internals. Now, I can easily redesign and add more content and functionality to my UX portfolio in the future. I want to help you do the same.

Quick Navigation

Getting Started
Tools Needed
1. Design Tools
2. Development
Domain Name, Hosting & Launch
1. Domain Name
2. Hosting
Wrap Up
Next Steps

Tools Needed to Build your UX Portfolio

For this tutorial series, we're going to be using a LOT of different tools and software. So before we begin, here's a heads up of what we need. Be sure to get them up and running before you start.

Design

Paper & Pencil
For ideation and early concepts.

Design Software
From wireframes to high-fidelity mock-ups of what our UX portfolio will look like.
Recommended - Sketch (Mac-only)
An Alternative - Adobe XD (Win & Mac), Figma (Free Web tool)

Zeplin (Highly recommended!)
Nice integration with Sketch & now, Adobe XD. It helps enable easy and quick hand-off from design to development. This can speed up your development greatly.

Prototyping (Optional)
Most UX portfolios are simple. They have a home and about page along with a few case study pages. Rarely are UX portfolios dense, with complex navigation that warrants a prototype.

Honestly, you can skip this step. But if you feel you need to see the bigger picture, use InVision or Marvel for prototyping. Again, I suggest skipping it. I did.

NOTE
I understand I'm deviating from a typical design process. But each phase is to serve a purpose. A simple, few-page UX portfolio is not so confusing that it warrants a prototype.

I talk more in-depth about design in Part 2.

Development

On a minimum level, you need a text editor and Node installed. But don't worry as I won't over complicate things at this stage and dump everything in this article.

The goal for this phase is not to demonstrate our developer prowess as designers (although you could if you want to). But rather, it is to build a UX portfolio quick and easy.

This is why we'll be using Bootstrap 4 to rapidly build our site and customize it to suit our needs. Then, we will take this a step ahead and automate some repeated web development tasks to speed up our workflow.

All this and more will be covered in Part 4.

Text Editors
Two really good text editors are Sublime Text 3 and Atom. I have extensively used both. It ultimately comes down to personal preference.

Sublime Text or Atom? Trouble deciding? This Reddit debate can help you decide.

In the end, whatever you choose, familiarize yourself with some handy shortcuts. You'll be faster and more efficient!

Sublime Text 3
Useful Shortcuts

Atom
12 Tips & Shortcuts

Domain Name, Hosting & Launch

Once we're done developing our UX portfolio, we need to launch it online. For that, we need a domain name and a hosting plan. If you haven't done this before, don't worry because it's much easier than you think. I'll walk you through this too, outlining some of the best and cost-effective options.

When your UX portfolio is ready, you need two things to launch.

Domain Name
Hosting

Start giving this a thought right from the start!

NOTE
Your portfolio could take a while to build. The last thing you want is to see the domain name you wanted is unavailable. Hence, if you have a good domain name in mind, go ahead and buy it first.

You don't need powerful hosting options for a UX portfolio website. Get something basic.

Now, a domain name and hosting are two very different things and each warrants a section of its own. But if you feel this might be too much of a hassle, just go with a hosting provider that also handles the domain name for you.

The Hosting section of this article covers this. Otherwise, if you want to get tied in fully by one provider, continue to read on.

Domain Name

But, I do urge for one thing. Get yourself a domain name. Now! Especially, if you don't have a portfolio of your own already. If you wait, you might not get the domain name you want. I got mine much before I even had a portfolio - iamsuleiman.com.

Where to buy domain names from?
Here are a few popular names from whom you can buy a domain name. Usually, everyone offers an introductory price for the 1st year. Don't just go by that though. You want to look at what you'll be paying every year after the first one.

Here are a few popular providers. This should give you a sense of how much hosting can cost. Usually, companies offer a highly discounted introductory price. So keep in mind the actual yearly costs after that.

Source

(1st year)

Renewal

NameCheap

$8.88

$10.98/yr

GoDaddy

$11.99

$17.99/yr

BlueHost

$11.99

$11.99/yr

HostGator

$12.95

$15/yr

1&1 IONOS

$15/yr

NOTE
None of these are affiliate links. If you buy from any of these providers, I don't make money from it. So you can be assured that my opinions aren't biased.

Personally, I bought my domain from 1&1 IONOS. I find their service very good and reliable. It is a great option if you don't want to pay too much upfront. Otherwise, NameCheap is a great alternative that saves you money in the long run.

Don't just go by the price. You might want to look into various other factors such as customer support, ease of use and more.

If you have trouble deciding, here are the 15 best domain name registrars in 2019. Many of these services provide hosting too. It should help you decide and pick one.

**But wait!
**Before buying a domain, read about hosting too. Certain hosting providers offer a free domain name (for the 1st year) when you buy from them.

Hosting

So what about hosting then? Consider hosting plans where they offer a free domain for the first year. Having your domain and hosting in one place simplifies a lot of the hosting process.

TIP
Consider a provider who offers both domain registration and hosting. This can save you the hassle of connecting both and money upfront.

Here's a little overview of the cheapest shared hosting plans by hosting providers.

Provider

Price (1yr)

Free Domain

Storage

SSL

Websites

InMotion

$7.46/mo

Yes

SSD

FREE

BlueHost

$4.95/mo

Yes

SSD

FREE

HostGator

$5.95/mo

Yes

Regular

FREE

iPage

$7.99/mo

Yes

Regular

Unlimited

TIP
Consider buying hosting for at least a year. The longer period you buy for, the lower is your $/month.

To help you decide, here are 7 hosting providers who offer a free domain.

If you’re a bit nerdy, you might want to see performance tests of some hosts. Hostingfacts.com has those results for 30 different providers.

Personally, I purchased hosting with InMotion Hosting. Their Business Plans may seem slightly pricier than other competitors. But the SSD storage and free SSL certificate were important for me.

NOTE
When a provider says unlimited. It doesn't actually mean unlimited. There will be a cap limit buried in the details so keep an eye out for that.

I tried to be brief as I can and yet, give you enough insight. Spend some time picking the right domain registrar and hosting provider for yourself.

Still, have trouble deciding? Check out the best web hosting companies for 2019 by HostingPill.

Part 8 will cover how to set everything up and launch your UX portfolio.

Wrap Up

I know this might've been a lot to digest. But I hope I've done my best to convey them to you simply.

By this point, if not hosting, get a domain name at least (if you haven't already).

If all the above was too much to take in for you, then no problem. I made an infographic that has condensed everything I just said above.

Download the free infographic on how to build your UX portfolio.

Download the FREE Infographic

Next Steps

In this article, I hope I have given you a fair overview of the 3 major phases of building our portfolio.

Design
Development
Hosting & Launch

If you know someone who wants to build a unique UX portfolio of their own, share this with them! If you have any questions or thoughts, I encourage you to comment below.

Don't forget to subscribe if you want to know when the next part comes out!

Read Part 2: Designing your UX Portfolio

Android Pagination Tutorial – Adding Swipe-to-Refresh

Mon, 22 Apr 2019 00:00:00 GMT

Pagination allows loading a long list of data in chunks. You see this in action in news feeds in social media apps, otherwise known as endless or infinite scrolling. In this tutorial, I will specifically show you how to handle pagination with Swipe-to-Refresh involved.

It took quite a while but finally, welcome to Part 5 of the Android Pagination Tutorial Series!

Previously in part 4, we looked at how to handle pagination when many View Types are involved.

Swipe-to-Refresh (as Android prefers to call it) or Pull To Refresh (as it is originally called) is a popular way of refreshing your data. But, when you have pagination in play, things can get a little tricky. In this tutorial, I will show you how to handle all those scenarios and implement swipe-to-refresh with pagination.

This article has been updated for AndroidX!

Android Pagination Series Overview –

Getting Started with RecyclerView
Pagination with APIs using Retrofit and Gson
Error Handling
Using Multiple RecyclerView Types
Adding Swipe-to-Refresh Support

NOTE
This is a continuation of the Pagination series. Hence this article (code included) assumes that you’ve read and implemented what was discussed in the previous parts.

If you’re new, I suggest starting with Part 1 — Implementing the Pagination logic. Otherwise, if you think you’re good, read on!

What is Swipe-to-Refresh?

The pull-to-refresh (or swipe-to-refresh) pattern lets a user pull down on a list of data using touch to retrieve more data.

– Pull to Refresh pattern as defined by Nick Babich

Swipe to Refresh animation. Source: Material Design guidelines

This pattern was first introduced by Loren Brichter in the Tweetie app (which was acquired by Twitter back in 2010). In fact, the design pattern became so popular that Twitter even holds a patent on it!

When to use it?

Swipe to Refresh is best to use this gesture with dynamic content that has frequent updates…

– Swipe to Refresh as defined in Material Design

Material Design has very detailed guidelines on Swipe to refresh, how to design for it and when to use it. I recommend everyone to read it.

Now what we know what Swipe to Refresh is and when to use it. Let’s get to actually implementing it.

Implementing Swipe-to-Refresh

To implement Swipe to Refresh, we need to do 3 things.

Add the SwipeRefreshLayout
Add support via a refresh menu action
Creating the refresh callback action

Once we’ve done these 3, we need to tie in our pagination callbacks with the Swipe to Refresh action. Let’s begin with the first step.

Add the `SwipeRefreshLayout`

Go to the MainActivity layout file, activity_main.xml and add the **SwipeRefreshLayout**.

You’ll have a RecyclerView layout that we’re using to handle the pagination. This RecyclerView now needs to be wrapped with a SwipeRefreshLayout. Look at the XML layout’s skeleton below for the code.

<FrameLayout>	
    <android.support.v4.widget.SwipeRefreshLayout
        android:id="@+id/main_swiperefresh"
        android:layout_width="match_parent"
        android:layout_height="match_parent">

        <androidx.recyclerview.widget.RecyclerView />

    </android.support.v4.widget.SwipeRefreshLayout>

    <ProgressBar />
</FrameLayout>

Add the Refresh Menu Item

From a design perspective, if you think about your app's users, a refresh action is needed on your Toolbar.

You should add a refresh action to your app's action bar to ensure that users who may not be able to perform a swipe gesture can still trigger a manual update.

– Android Developer Guidelines

Start by adding the refresh icon to your Activity's menu.xml file.

<menu>
    <item
        android:id="@+id/menu_refresh"
        android:title="@string/menu_refresh"
        app:showAsAction="never"/>
</menu>

Next, override the onOptionsItemSelected() method in your Activity.

@Override
public boolean onOptionsItemSelected(MenuItem item) {
 switch (item.getItemId()) {
  case R.id.menu_refresh:
   // Signal SwipeRefreshLayout to start the progress indicator
   swipeRefreshLayout.setRefreshing(true);
   doRefresh();
 }
 return super.onOptionsItemSelected(item);
}

Note that when the Swipe-to-Refresh action is triggered, you need to show that it's refreshing. That's what the loading indicator shows.

Swipe-to-Refresh. Image Credits - sapandiwakar.in

But also be sure to dismiss it when the refreshing is complete. You can do this by **swipeRefreshLayout.setRefreshing(false)**.

Note the doRefresh() method. This will handle our actual refresh logic which I will cover in the next step.

TIP
A good app is one that thinks about its diverse user base. Adding an explicit refresh action helps with accessibility, allowing people to see an action that they otherwise wouldn't.

So that's one for good UX design! Now that we have the UI controls in place, the last thing we need to do is create the Swipe-to-Refresh callback.

Now we've created a working Swipe-to-Refresh UI control. But, it doesn't do anything yet. Next, let's hook our Pagination to this.

Create the Refresh Callback Action

Before we get to the doRefresh() method, we've added the action via the Toolbar menu's refresh. But what about the actual Swipe-to-Refresh?

In other words, we need to listen when we swipe from the top. The same doRefresh() action will happen when we trigger Swipe-to-Refresh. We can do this via a simple listener.

In your Activity, add this code to its onCreate() method.

swipeRefreshLayout.setOnRefreshListener(this::doRefresh);

NOTE
The above code is simplified with Java 8 Lambdas for Android.

The doRefresh() method will handle the actual logic of refreshing via Swipe-to-Refresh.

private void doRefresh() {
 progressBar.setVisibility(View.VISIBLE);
 if (callTopRatedMoviesApi().isExecuted())
  callTopRatedMoviesApi().cancel();

 adapter.getMovies().clear();
 adapter.notifyDataSetChanged();
 loadFirstPage();
 swipeRefreshLayout.setRefreshing(false);
}

Here's what the doRefresh() method does.

First, remember to show the progress indicator. Clearing the adapter and making a fresh request can make the screen blank.

Then, check if any API's are being executed, these are the page load requests. If you recall, it is one single API call to which we pass the page number. This is done via the callTopRatedMoviesApi() method. Hence, we check if this API called is being executed and if yes, cancel it.

Next, we clear the list of existing data and notify the adapter of these changes. Then, we make a fresh request to the first page. Lastly, don't forget to setRefreshing(false).

Remember that the doRefresh() method will be triggered regardless of whether it is via a swipe or via refresh in the Toolbar.

The Problem with this Approach

Swipe-to-Refresh (going by its very definition), allows you to update (refresh) the existing data you have.

In pagination, the first page is loaded and presented by default. Page 2 and beyond loads as you keep scrolling down to the bottom of the list.

When you trigger a Swipe-to-Refresh, you request for page 1 again and load its fresh data. All other consecutive page data is removed and Pagination will begin fresh.

When to actually refresh?

While that's simple on paper, doing as I mentioned above is wrong. Think about it, constantly calling Swipe-to-Refresh keeps making a request for Page 1. But do we even know if Page 1 has updated or fresh data to display? If it is the same data, why are we making a network call for the same thing?

So how do we go about this? We use caching.

Use Caching

Caching allows us to store the data on memory and has an expiry (time) range associated with it. As long as the data hasn't expired, making a network call for that data will request the cache rather than the network.

When it has expired, the cache becomes stale. This time when a request is made, it is made from the network allowing fresh data to be displayed and the cache to be updated.

NOTE
As app developers, we need to be judicious with consuming data. We don't want to be spamming API calls that have no meaning. It wastes data and server resources.

So what do we need to do? With Swipe-to-Refresh or Pagination, there is no logic change. But, what we do need to do is modify Retrofit to support caching.

Modifying Retrofit to Support Caching

While this might be out of scope for this tutorial, it is essential to establish good practices. In this scenario, doing a Swipe-to-Refresh with pagination can abuse the network calls. Caching can help prevent this and encourage developers to build a performant app.

So firstly, we need to modify Retrofit to support caching in its network requests. To do this, open the MovieApi class. There are 3 things we need to do.

Declare cache
Define Interceptor to read cache
Add both to your Client Builder

1. Declare Cache

public class MovieApi {
 // 10MB Cache size
 private final static long CACHE_SIZE = 10 * 1024 * 1024;
 ...

 private static OkHttpClient buildClient(Context context) {
  ...
  // Create Cache
  Cache cache = new Cache(context.getCacheDir(), CACHE_SIZE);

  return new OkHttpClient
   .Builder()
   ...
   .cache(cache)
   .build();
 }
}

2. Define `Interceptor` to Read Cache

Next, define the Interceptor. This allows us to intercept the network requests we make and read their Cache-Control headers.

public class MovieApi {
 ...
 private static OkHttpClient buildClient(Context context) {
   // Build interceptor
   final Interceptor REWRITE_CACHE_CONTROL_INTERCEPTOR = chain -> {
    Response originalResponse = chain.proceed(chain.request());
    if (NetworkUtil.hasNetwork(context)) {
     int maxAge = 60; // read from cache for 1 minute
     return originalResponse.newBuilder()
      .header("Cache-Control", "public, max-age=" + maxAge)
      .build();
    } else {
     int maxStale = 60 * 60 * 24 * 28; // tolerate 4-weeks stale
     return originalResponse.newBuilder()
      .header("Cache-Control", "public, only-if-cached, max-stale=" + maxStale)
      .build();
    }
   };
   ...
  }
  ...
}

Finally, we must add this to our OkHttpClient.Builder. So it finally will look like this.

return new OkHttpClient
 .Builder()
 .addNetworkInterceptor(REWRITE_CACHE_CONTROL_INTERCEPTOR)
 .cache(cache)
 .build();

So we first, created our Cache and added it to the request builder. Next, we created an interceptor to read the Cache-Control headers from every request and added that to the request builder too.

Request from Network or Cache?

Now that we've modified Retrofit to support caching, how do we actually know if a specific request is from cache or not?

A simple if-else condition check for the Response will tell us.

if (response.raw().cacheResponse() != null) {
 //    Cache Response
} else {
 //    Network Response
}

You can read more about this on StackOverflow.

Tying it all with Swipe-to-Refresh

With this simple modification, you can use the above if-else to check where your data is coming from. You can log your network requests to check. The very first time you make a request, it'll be from the network. When a request is made again, it comes from the cache. The latter will continue to happen until the cache goes stale (expires).

Just a stepping point...

I don't want to digress too much from the goal of this tutorial, which is to implement Swipe-to-Refresh and support pagination.

However, we went beyond to use good design principles and implemented caching. Although this implementation works, it is very simple in its working and scope.

I highly encourage you to go beyond and fully test the caching mechanism.

For instance, let's look at the doRefresh() method again.

private void doRefresh() {
 progressBar.setVisibility(View.VISIBLE);
 if (callTopRatedMoviesApi().isExecuted())
  callTopRatedMoviesApi().cancel();

 adapter.getMovies().clear();
 adapter.notifyDataSetChanged();
 loadFirstPage();
 swipeRefreshLayout.setRefreshing(false);
}

This method currently refreshes the adapter with fresh data. By fresh I mean fetching from cache again if a network request was already made. In other words, you're clearing the Adapter and repopulating it with the SAME data. Wouldn't you agree that's wasted work?

A better way to do this is to NOT repopulate the data. Don't clear the data and load the first page again. Instead, you could make a short API call or check to see if there is any fresh data available in the server, if yes, then perform the actual swipe to refresh. Now you know there's fresh data available which will make the fetch meaningful.

TIP
A better approach is to not wait for the cache to expire. Rather check the server if there is fresh data available. If yes, then refresh the adapter with new data. Otherwise, don't bother doing the reload with Swipe-to-Refresh since it is the same data.

If you're interested in reading more about Caching with Retrofit, Midorks has a great Medium article on it.

Output

Now that we've done all that's needed to implement Swipe-to-Refresh for pagination, let's see how it looks like in action.

Project Available on GitHub

Get the Source Code

Wrapping up

In this tutorial, we looked at adding Swipe-to-Refresh support to Pagination. Again, the hardest part was implementing the Pagination logic, which we've done in Part 1. Swipe-to-Refresh was a simple add-on to that relatively.

Next, we also looked at implementing a simple caching mechanism by modifying Retrofit. This allowed us to not abuse network calls with Swipe-to-Refresh.

Lastly, if you've read the tutorial up to this point, this marks the end of the Pagination tutorial series. Congratulations on making through all five parts!

I hope you found this useful as I've enjoyed writing this for you.

Have I covered everything you need to know about adding Pagination in your apps? Or do you have any questions? Tell me in the comments below and I'll get back to you.

Lastly, if you loved reading this article, share it with others so they can learn too!

How To Design A Great Mobile App Intro By Learning From The Best

Mon, 02 Jul 2018 00:00:00 GMT

The App Intro or Product Tour is an introductory welcome experience for first-time users to your product. In this article, we will look at how to design great app intros by learning from the best mobile apps. The App Intro or Product Tour is the first part of your overall onboarding experience and hence, the most important. For the sake of this article, I will stick to calling it the App Intro. At first, I too was calling Intros as Onboarding but for the sake of brevity and not to mislead, I felt it would be best if the correct terms were used. Now the terms 'App Onboarding' and 'App Intro' might be used interchangeably sometimes. So it is best we clarify the difference between the two. In this article, let's begin by first clarifying the difference between the two terms. Next, we'll look at the problem that mobile apps typically face and how an app intro can help. Then, we will look at how app intros are designed by 3 popular mobile apps. We will then learn from these examples to design a mobile app intro of our own. Lastly, I will leave you with some brilliant resources to further learn from. So with that said, let’s dive in.

Onboarding VS App Intro

Instead of me trying to explain the difference to you in words, I hope the image below does a better job.

READ: Implement Material Design On-boarding in Android

What's evidently clear is that User Onboarding is NOT the same as the App Intro. They are two entirely different things. The App Intro only serves as an introduction or as a welcome to new users, giving them an overview of what the app is. The intro is simply a small part of the entire app's overall onboarding experience. User Onboarding

"User onboarding is the process of increasing the likelihood that new users become successful when adopting your product." — Samuel Hulick of UserOnboard.com

Want to learn more about onboarding? Chameleon has a great guide to onboarding flows with useful tips and examples. App Intro

The intro screen is a great way to showcase your app's greatest features. It is simply, one of the ways by which you can increase retention rates. The App Intro screen is a small part of the overall onboarding experience that you can build for your app.

Want more app intro inspiration? You can see 40+ example designs for mobile apps here. For the sake of this article, we’ll focus on just mobile app intros.

The problem with mobile apps

A good rule of thumb for creating mobile apps is to understand that your users are always on the go and hard-pressed for time. Hence it’s essential that we keep these constraints in mind. The purpose of apps is to be laser-focused on helping users do the one thing they need to do, really well and quickly.

Get users to be able to do what they want via your app, in the fastest way possible.

It is no secret that mobile apps have always struggled with retention. On average, mobile apps could lose 75% of their users in 3 months.

"Nobody cares about the thing you’ve designed unless you can get them past the beginning." — Julie Zhuo, Product Design VP, Facebook

Really Good Mobile App Intro Designs To Learn From

Now we know what an app intro is and it's importance in helping retention rates. Next, we'll look at 3 really good mobile app intros, do a breakdown of each and see why it works well. We will then learn from these 3 examples and see how to bring it all together for your app. In design, there never is a 'one size fits all' solution. So instead of trying to decide upon one approach, let's take a look at 3 best onboarding experiences on apps. Keep in mind that I am deliberately trying to be device agnostic. The goal is to look at how app intros have been designed so Android or iOS has no effect on this. The 3 apps that we'll look into are:

Evernote
Spotify
LinkedIn

1. Evernote

An extremely popular app for note-taking, to-do lists and much more.

2. Spotify

Spotify is a digital music service that gives you access to millions of songs.

Notice how Spotify breaks down its value proposition into simple, digestible chunks, displayed one at a time in a carousel.

3. LinkedIn

Linkedin is a professional networking service that includes recruiters, job seekers and alike.

Identifying what works

Remember there is no straightforward answer or a 'one size fits all' solutions. But I am sure that those who designed those app intros have a pretty solid understanding of that. So what we can do is learn from these designs. By looking at the three app intro designs, we can learn from them and identify common patterns. This will help us establish a foundation to build upon for our own apps. With that said, let's go through the common components that make up a good app intro.

The image above highlights the most common components of app intros. If you looked at all the app intro examples previously mentioned above, you can see the relation. Next, we will focus on each of these components individually and make note of the design choices each have taken and why that may be. This will further help us design our own app intros better.

1. Header Copy

Most headers include a distinct headline followed by a two-line text description. LinkedIn however, opted to not visually distinguish their copy keeping it simple. Note that each description uses a thoughtful choice of words that evokes clarity on what the app has to offer users.

Takeaways:

Clear heading and subheading (except for LinkedIn)
Distinct typography between heading and subheading
Short headlines and clear copy
Simple words used to indicate value proposition

2. Image

We've seen app intros using simple, full-blown imagery with great photography to videos. We've also seen delightful animations as well. Perhaps now, what we've come to increasingly see is custom illustrations like the one you see in Spotify. However, that's not to say that what's currently trending is the way to go. Look at the image choices used by Spotify. Notice the meaningful imagery used for 'Search'. A long road ahead tells that there's a lot to be discovered along the way. A beautiful representation for Search. unsplash.com provides brilliant photography that you can use for free. Be it photographs, UI components with animations or custom illustrations, they are all simply a design choice. You can already see the variety used here in these three apps. So pick one that goes with your brand or app's character. In other words, opt for a style that obeys your visual language that resonates across your app.

READ: Techniques to Display Text over Images

Personally, I like how Spotify uses clean illustrations to visually depict what it has to offer. From a technical standpoint, SVG illustrations are more light-weight than PNG images. But images can still be powerful to convey meaning or evoke emotion if the right one is used. Takeaways:

Distinct, simple illustrations that respect brand character (Evernote)
Using professional photography as a full-blown background image (Spotify)
Using pieces of the UI to 'educate' users on what to expect (LinkedIn)
Visual indicator for a swipe-able carousel that reveals more features of the app

3. CTA Button

The Call-to-Action (CTA) button for almost every app intro is to either create a new account or log in. A CTA present throughout the app intro implies something very important. You want your (first-time) users to know what your app has to offer. But you also don't want to force them to see through it all. You don't want your users to sit, swiping through multiple carousels before they can get to the signup screen. Then, the signup is another bunch of screens before they can actually get to use the app.

Don't force your users to see what you have to offer. If they're interested in knowing, they will go through it. Maybe they already know about your product. Don't forcefully re-educate them again. Allow them to skip to log in, signup or directly to the home screen. Remember that mobile users are impatient. We need to remember, respect that and let them get down to using your app, in the fastest way possible. Takeaways:

One simple button to 'Get Started', although it can be ambiguous (Evernote)
Clear buttons that respect both first-time and returning users to sign up or login respectively (Spotify)
Clever button design with clear visual distinction for emphasis on 'sign up' rather than 'sign in' (LinkedIn & Spotify)

Putting it all together - Design your own App Intro

Up till now, we've identified the three common components that make up a good app intro. Then we looked at how our three app approach and design these components. Next, we will harness all that we've learned and design an app intro of our own. Here's what I've designed. I also took some extra liberty to make a Dribbble shot because, why not?

Let me better explain the design choices here and how I copied *cough* drew inspiration from others.

Image: Opted for a minimal, clean SVG illustration that respects the brand color palette. In this way, it better fit with the minimal design I was going for, rather than an actual photograph. Also, I got this beautiful SVG illustration for free from unDraw.co.
Header Copy: Used a simple, clear font Source Sans Pro. Personally, I'm not a fan of using two different fonts. I rather stick with one and play around with font weights and colors for consistency. But use-cases can vary.
CTA Button: Primary action indicated by a bold, vivid button that gets most of the attention. The secondary action could've been a button too. But it could fight for attention with the primary action.

Going beyond a simple 'App Intro'

In this article, we've spoken extensively about how to design an app intro. But it doesn't just stop here and you should take it to the next level. Remember that the intro is just one part of the entire onboarding experience. Onboarding can be more personal and in-context. Moreover, to learn about great product onboarding, don't just restrict yourself to mobile apps. Amazing inspirations can be found on websites too. Look to how websites implement their onboarding and you'd be amazed to see what you can take away from there and implement in your own apps. A great starting point is the User Onboarding Teardowns by Samuel Hulick. There are detailed case studies where you can learn a lot from popular apps.

Key Takeaways

In this article, we saw how to design app intros by seeing how some of the best apps do it. We then identified that there are 3 main components that must be included in your app intro designs - the header copy, an image and a CTA. Lastly, remember that the app intro is only the beginning and a very small part of the overall onboarding journey. Apps need to deliver to their users fast! So get them familiar with your apps in the fastest way possible. Remember that mobile app users will not wait. Educate them early and educate them fast. More Resources: Mobile Onboarding inspiration gallery - mobile-patterns.com.

Android Pagination Tutorial—Handling Multiple View Types

Tue, 08 Aug 2017 00:00:00 GMT

Pagination is also known as endless or infinite scrolling. This is achieved using RecyclerView. In this tutorial, I’ll show you how to paginate when multiple View Types are involved.

Welcome to part 4 of the Android Pagination Tutorial Series!

Previously in part 3, we identified various scenarios in which errors can occur. Then, we saw how to handle these Pagination errors via code and present them to users.

RecyclerView is well known for supporting multiple view types. What if you wanted to do that and paginate the list, at the same time? Let’s look at just that, in this tutorial.

This article has been updated for AndroidX!

Android Pagination Series Overview

Getting Started with RecyclerView
Pagination with APIs using Retrofit and Gson
Error Handling
Using Multiple RecyclerView Types
Adding Swipe-to-Refresh Support

NOTE: This is a continuation of the Pagination series. Hence this article (code included) assumes that you’ve read and implemented what was discussed in the previous parts.

If you’re new, I strongly suggest you start with Part 1 — Implementing the Pagination logic. Otherwise, if you think you’re good, read on!

Supporting Multiple View Types in RecyclerView

Often, when you want to display a list, all the items aren’t the same. Commonly, your first item might be a hero image, followed by a list.

We all know too well that when multiple View Types are involved, the code tends to get verbose. Additionally, with Pagination in play, things are about to get ugly.

However, that doesn’t have to be the case. Code complexity should not scare you. Provided you spend little time organizing your codebase.

If you remember from the previous tutorials, we already have 2 view types in our RecyclerView.

The regular list item
Loading footer

But the loading footer is only temporary, it briefly appears until the next page loads. After that, it disappears.

So let’s go ahead and add a third View type — a Hero image as the first item in the list.

What we'll be creating

Creating the Hero ViewHolder

Adding a new View Type is a simple thing to do. If you’re familiar with RecyclerView, you should know this by now as well.

I strongly encourage you to create your own, without referencing this section. However, if you need help, I’ve got your back!

There’s no set way to go about it, but here are the steps:

Create XML layout for your new View
Update Item View Types
Create it’s ViewHolder in RecyclerView
Bind the View

Just 3 simple steps. Let’s start with 1.

1. Create XML Layout for new View Type

Create a new XML file res/layout/item_hero.xml.

As mentioned above, we will create a header for our list. Mine looks like this.

Hero Layout preview

Feel free to use your creativity to make a layout you like. But if you want to use mine, you can get the layout file from GitHub.

2. Update Item View Types

Once your layout is created, we need to tell RecyclerView about it. Open PaginationAdapter.java and add a flag for our new (header) view type.

public class PaginationAdapter extends RecyclerView.Adapter < RecyclerView.ViewHolder > {

 // View Types
 private static final int ITEM = 0;
 private static final int LOADING = 1;
 private static final int HERO = 2;
 ...
}

Next, we need to tell our Adapter about which View should be displayed when. You do this in the getItemViewType() method.

 @Override
 public int getItemViewType(int position) {
  if (position == 0) {
   return HERO;
  } else {
   return (position == movieResults.size() - 1 && isLoadingAdded) ?
    LOADING : ITEM;
  }
 }

3. Create ViewHolder in RecyclerView

Start by creating an inner class for your ViewHolder in PaginationAdapter.

/**
 * Header ViewHolder
 */
protected class HeroVH extends RecyclerView.ViewHolder {
 private TextView mMovieTitle;
 private TextView mMovieDesc;
 private TextView mYear;
 private ImageView mPosterImg;

 public HeroVH(View itemView) {
  super(itemView);
  // init views
  mMovieTitle = (TextView) itemView.findViewById(R.id.movie_title);
  mMovieDesc = (TextView) itemView.findViewById(R.id.movie_desc);
  mYear = (TextView) itemView.findViewById(R.id.movie_year);
  mPosterImg = (ImageView) itemView.findViewById(R.id.movie_poster);
 }
}

With the ViewHolder created, we need to inflate it in onCreateViewHolder().

@Override
public RecyclerView.ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
 RecyclerView.ViewHolder viewHolder = null;
 LayoutInflater inflater = LayoutInflater.from(parent.getContext());

 switch (viewType) {
  case HERO:
   View viewHero = inflater.inflate(R.layout.item_hero, parent, false);
   viewHolder = new HeroVH(viewHero);
   break;
   ...
 }
 return viewHolder;
}

4. Bind the View

Now that our header ViewHolder is created, it’s time to bind it. From the name, you would’ve known what I’m talking about. Yes, the onBindViewHolder() method!

@Override
public void onBindViewHolder(RecyclerView.ViewHolder holder, int position) {
 Result result = movieResults.get(position); // Movie

 switch (getItemViewType(position)) {

  case HERO:
   final HeroVH heroVh = (HeroVH) holder;

   heroVh.mMovieTitle.setText(result.getTitle());
   heroVh.mYear.setText(formatYearLabel(result));
   heroVh.mMovieDesc.setText(result.getOverview());

   loadImage(result.getBackdropPath())
    .into(heroVh.mPosterImg);
   break;
   ...
 }
}

// Bind method helpers

private String formatYearLabel(Result result) {
 return result.getReleaseDate().substring(0, 4) // we want the year only
  +
  " | " +
  result.getOriginalLanguage().toUpperCase();
}

private RequestBuilder < Drawable > loadImage(@NonNull String posterPath) {
 return GlideApp
  .with(context)
  .load(BASE_URL_IMG + posterPath)
  .centerCrop();
}

That’s all there is to it! That wasn’t as complex as you thought, was it? We already have 2 different View Types in play. We just added a third one.

The pagination logic wasn’t touched. So everything will work as it did, with the addition of a header View.

Don’t take my word though. Find out yourself with the output below!

Output — Final Result

Get the Source Code

View Project on GitHub

The key to implementing any successful feature comes down to the basics. It’s the foundation. In the case of Pagination, it came down to implementing the Pagination logic correctly. Once that was done, add-on features were relatively easy to add. Like multiple View Types!

I hope with this tutorial, you’ll be able to paginate lists with different View Types.

What do you plan to create? Does this cover your use-cases? Tell me in the comments below.

Lastly, if you loved reading this article, share it with others so they can learn too!

Use Empty States to your Advantage - Better User Retention

Tue, 25 Jul 2017 00:00:00 GMT

Empty States are often neglected and designed last. I don’t blame you though. After all, compared to the main screens, these aren’t important. Right?

Sadly, no. The worst that can happen is that users can uninstall your app after first use. Trust me, you don’t want that to happen.

Users who uninstall your app after first-use are most likely to never return.

Mostly, empty state screens are ignored until the app is done. Then, you realize that a particular screen could be empty at some time. So you just throw in a little error message like this and call it a day.

iOS Pages app — I'm not sure where it's asking me to tap...

This is NOT okay! Once users reach an empty state screen, they might not know what to do. Or they simply might move on to another screen, or worse, another app.

The gravity of the situation is worse than you think! Here’s a wake-up call.

The average app mostly loses its entire user base within a few months. - Andrew Chen (Growth at Uber, LinkedIn Influencer)

First, let’s clarify what an empty state is. Then, we’ll see why it must be given importance. Next, let’s find out when it can occur and how to tackle them. Finally, we’ll see how to design effective Empty States.

What are Empty States?

I’ll spare you the boring book definition here.

Empty State or zero-data state is what a user sees when there is no data to display on-screen.

Image credit: emptystat.es

Why Bother?

We need to make sure that users learn the purpose of a particular screen. If it’s a news app, and there is no news to display, tell them why.

Well, that might sound ironic. But what if the network call fails?

The reality is that 77% of users will uninstall your app in 3 days. Only the top 10-50 apps are able to break that and keep more users.

You might say these are extreme statistics but think again.

The difficulty of User Retention

Let me put that in perspective for you.

You use apps too right? Say you want to try out a news app. I’m sure you don’t download just one, but at least a couple of them.

Then, you give each app a try. You try to see which one is good. Finally, you keep what you like and you uninstall the rest.

Users try out a lot of apps but decide which ones they want to ‘stop using’ within the first 3-7 days - Ankit Jain, Google.

Get it? That might happen to your app as well. Hence you need to use everything at your disposal to keep your users.

Once they start using your app, do your best to make them stay. Empty States are the perfect opportunity to do so.

Use them to encourage interaction, reinforce your brand and increase user loyalty. I know such terms might sound cheesy. But if you use Empty States correctly, your app adoption rates will be much higher. In other words, that translates to lesser app uninstalls.

The best way to bend the retention curve is to target the first few days of usage, and in particular the first visit - Andrew Chen

When are most of the empty states visible? During the first few days of using the app.

Now you know what needs to be done. Let’s see when Empty States can occur and how to best design them.

Another user retention technique — Using Skeleton Screens make your app appear faster.

When can Empty States occur?

Now that we know about Empty States and its importance, let’s see when it can actually occur.

To put it simply, it occurs whenever there is an absence of data.

Yes, that’s just straight from the definition, but the exact scenarios are as follows:

for first-time users
when an error occurs

1. For first-time users

Empty States can serve as an onboarding for first-time users. Yes, you don’t have to do those forced carousel-like product tours!

Let’s take the example of the Google Keep Android app. It handles Empty States for first-time users in a unique way.

It displays ‘starter content’ to familiar users with its app. Typically, when you open a note-taking app, it will be empty. You don’t know how a bunch of notes will appear on-screen. You’ll have to create a couple of them to find out.

Instead, Google Keep does that for you. So although you don’t have any notes, Keep creates a few.

With this, first-time users are educated on 2 things:

how notes work within the app
learn about the app’s features

That’s pretty smart, right? It works extremely well for them. We’ll talk more about ‘starter content’ later into this article.

For apps like notes, email, bookmark managers and others, there is no content, to begin with! Users will have to start adding content manually to populate them. In such apps, having Empty States for first-time users is a sure shot.

But keep in mind that you have to think about individual screens rather than the entire app.

For example, a news app might show worldwide news by default on the home screen. So no worries there. Say the news app allows a bookmark feature. That screen would be empty unless users bookmark a news article. So that’s an Empty State too. How would you handle that? Think about it!

2. When an error occurs…

Now for some apps, even if you’re a new user, there will be some content to display. Say that the app makes an API call to fetch content, and for some reason, it fails.

When a new user opens your app and goes to the home screen, you don’t want that to happen. It appears very bad. Don’t show a generic error message.

That is just one scenario. This could happen to ANY screen. Make sure you handle that as well.

Tell users why it failed

This is perhaps the most important thing to remember. When you’re showing an Empty State in the event of an error, tell users what happened.

Make sure you tell users what the issue is, without going too technical. For example, let’s assume, your app’s servers overloaded and crashed due to traffic surge. If that’s the scenario, don’t get too technical and spam them with crash logs and error codes. That’s for your developers, not users! An appropriate error message could say “Our servers are currently busy”.

The Google Chrome browser balances information and detail very well. It even adds a bit of humor to it. It has a brilliant empty state that not only tells us what’s wrong. But also suggests how to fix the problem.

Here’s what Chrome achieves with this design.

A generic error message that everyone can understand
Suggests steps to resolve the error
An error code — for the tech savvy?
Download Page Later button— automatically download page for viewing when the internet is back on
T-Rex game— it’s actually a game you can play to kill time until your internet comes back

FUN FACT: Why Google Chrome shows a dinosaur when offline?

Here’s another example.

Desk Empty States by YiJing Z — Dribbble

Remember that not every scenario is the same. This would have already become evident to you. For example, for a retry page load, it makes sense to have a retry button. But what about an email app with an empty Spam screen?

Now that’s clear, we can see how to actually design it.

How to Design Empty States

To make blank slate useful, consider inserting quick tutorials, videos, help tips, call to action-elements, screenshot of the page when it is in “normal” stage – anything that helps the user and makes him happy with your app. — Patternry

Here is a couple of tips on how to design effective Empty States. Let’s go through them one at a time.

1. Be informative

When an empty state occurs, it is visible to the user. Tell them why they’re seeing this screen.

When a user sees an empty state, 2 things should be conveyed.

Purpose of the screen (what can I expect to see here?)
Why am I currently seeing an empty state?

Copy in design is very powerful. It effectively communicates what users need to know. The lesser the words used, the better.

If you read carefully, the copy answers both those questions above. It tells us:

What is this screen?
What’s the use of marking a file as a ‘favorite’?

2. Handle Failure States— Don’t scare your users

If it’s an error, tell them what went wrong. Take it a step further by suggesting how to resolve the error. Remember the Google Chrome example?

Here’s what you can do with Empty States for an error:

show a non-technical copy for error text
suggest possible steps to resolve the error (as simple and short as possible)
Don’t use technical jargon that can confuse users
Allow them to reload (retry loading a page)

Image credit: emptystat.es

3. Encourage Users to take action

A simple, yet highly-effective way to get users to interact, is to use a CTA (Call-to-Action).

A call-to-action (usually abbreviated as CTA) is an image or line of text that prompts your visitors, leads, and customers to take action. It is, quite literally, a "call" to take an "action.”— blog.hubspot.com

In other words, for our apps, CTAs are buttons. Big bold, attention hogging buttons. When a user sees a screen, the should immediately be able to see that CTA (button). That’s what makes it effective.

Material Design provides us a Floating Action Button. That’s a perfect candidate for a CTA!

Some examples would be a note-taking app. Prompt first-time users to add a new note by using a CTA button. Or a recipe app, where the CTA is to add a new recipe.

Marvel App - Project empty state by Murat Mutlu — Dribbble

Yet for some screens, there is simply nothing to do. Example, Gmail Spam screen.

4. Display Starter Content

Remember the Google Keep app? We spoke about it as an example for Empty States. That’s called Starter Content.

Evernote app — starter content for first-time users

With this, 2 goals can be achieved.

Help familiarize users with how notes work
Use these ‘starter content’ notes to to flaunt the app’s features

Consider Twitter, where every new user needs to follow few people first to get started. In this way, no first-time user’s home feed is going to be empty. This can also be seen as a way of Twitter reinforcing what it’s all about.

5. Stick to your brand— be consistent

You might have a lot of freedom when designing Empty States. But make sure you stick to your brand.

By that I mean, make sure you stick to your styleguide and color palette. The last thing you want is a screen that feels alien within your entire app.

Alright, this might not be a design tip that’s specific to Empty States. But even so, it is still important. It’s easy to get carried away!

For example, if your brand color is blue. For the sake of emphasis, don’t make your Empty State’s CTA button red! Agreed that you might want to emphasize an alert or danger. But don’t do it at the cost of inconsistency.

Course Dashboard by Shashank — MaterialUp

6. Use Humor

Sometimes, humor can play a big role in damping down the seriousness of an issue.

A great example of using humor in design is Mailchimp. They know how well to design it so that it engages the user.

Mailchimp — what users see after sending a campaign. Image credit: smashingmagazine.com

So before you use humor, make sure you it’s in the right context. For example, a good place to use it would be content not found screens (empty search results).

On the contrary, a bad place to use it would be in an error state. Say a failed task. It’s worse if the error was on your part.

Using humour is fun and is a welcome relief. But also think of scenarios when a customer comes to your site to complain, or they have a problem with your product or service. They may not be in the best mood and that humorous message could be a tipping point for a customer to leave permanently. — spotless.co.uk

Empty state concepts infused with personality by Tasnadi Otto — MaterialUp

7. Keep it simple

Arriving at the last design tip, this is the most important one to remember.

With all the tips mentioned above, it’s easy to include everything and go overboard! Don’t do that.

Remember that simple designs are always more effective.

Here’s a great empty state interaction. It’s lovely, but it’s also so fancy that if my app is simple and not animation-heavy. I wouldn’t attempt anything like this, just for an Empty State!

Empty State by Jordan Nelson — MaterialUp

An Empty State is supposed to be a lightweight screen. If there is an action to be performed, make sure it’s just one. Don’t offer many points of interaction on a single empty state! That’s just confusing.

Takeaway

To summarize everything, Empty States are an excellent opportunity to engage with users. It might seem insignificant in the larger picture. But even the smallest of things matter.

Attention to detail matters because when you show that you care about the small details, people trust you to care about the big ones. — Meg Robichaud (Shopify UX)

User retention with apps are already very hard. So use every chance you have to keep them. Because once they leave, it’s difficult to get them back.

Remember that no screen should be a dead-end for your users.

Wrap up

Keeping these simple design tips in mind will help you create effective Empty States:

Be informative — tell users why they’re seeing this screen
Handle failure — tell why the error occurred and suggest a fix
Use a CTA — encourage users to take action
Consider Starter Content — great way to familiarize users with your app
Be consistent — stick to your brand’s design guidelines
Use Humour — reduce the seriousness of an issue. Use carefully
Keep it simple — nothing over the top. Remember simple = effective.

I hope this article will help you design better, effective Empty States. Use them to your advantage for better user retention!

Lastly, if you need some design inspiration, these resources have you covered.

Resources for your inspiration —

Thanks for reading!

Customize Color with Styled Google Maps in Android

Tue, 04 Jul 2017 00:00:00 GMT

You can now style and customize your Google Maps colors and more. In this Android tutorial, let’s see how we can do that in our apps. Google Maps has added this ability across all platforms. This means regardless of whether you use Google Maps for Web, iOS or Android, you’ll be able to style them. By default, Google Maps looks like this.

We’re all used to this and by no means am I saying it looks bad. But say I want to display a map that corresponds to my brand color scheme.

Directions Module by David Rodriguez Now imagine if my only option was to display the default Google maps, with it's default colors. It wouldn't go well with the design, would it? The color scheme of the map won't be in harmony with the rest of the design. In other words, it sticks out, like a sore thumb. In such scenarios, we need a map that reflects our brand theme. Our brand color palette. This wasn’t possible before. But now, Google allows Styled maps. Using this, we can customize the map to look the way we want. This includes modifying colors, with a very high degree of control.

Getting Started

We’ll start by creating a new Android Studio project. Thankfully, we have pre-defined templates (for Activities) to start with. Activity templates were introduced in Android Studio 1.4. So when you create a new project, chose the ‘Google Maps Activity’ template.

Here are the project settings:

minSdkVersion - 14
targetSdkVersion - 26

Thanks to this, we don’t have to spend a lot of time configuring the Maps SDK and whatnot. I remember the first time I tried using Maps in Android (back in 2012). It took me well over an hour to simply display a Map! But you don’t have to worry anymore as we’ve come a long way from that!

Configuring Google Maps

Once the project has loaded, Android Studio will open the google_maps_api.xml file by default.

You’ll notice there is one step to follow to get your Google Maps API Key. Trust me, this is nothing compared to the amount of steps earlier! So follow the comments on the file. Don’t worry, I’ll still walk you through them. but you’ll have to grab the URL and keys from the google_maps_api.xml file’s comments.

1. Go to the URL provided - console.developers.google.com

You’ll land on a page like this.

Select ‘Create a Project’ from the dropdown and then hit the Continue button.

2. Create Google Maps API Key

In the next step (screen), click the ‘Create API Key’ button.

3. Get your generated API Key

Google now generated your Maps API key. So copy it and paste it in your XML file for the string name ‘google_maps_key’. Replace the ‘YOUR_KEY_HERE’ with your actual API key! You can optionally set up API Key restrictions if you want (see screenshot above). It’s fairly simple. Click restrictions and you’ll get a screen like this.

Choose ‘Key restriction’ as ‘Android Apps’ and hit Save button. Note that you don’t have to bother about the Package name and SHA-1 certificate fingerprint. You’ll realize that the fingerprint is same as the one in your Android Studio project comments. In other words, Google took care of that for you too. Sweet? Now let’s move on. With our API key in place, we’re finally ready to use Google Maps. But before we get to styling, let’s check if Maps itself works. So run your app and check it out. It’s always better to test every step of the way. Otherwise, you’ll never know what went wrong where. NOTE: Google Maps needs Google Play Services to work. So it’s safe to always run the app on a real device. Or, you can configure and use an AVD that includes Google APIs with Play Services. Here’s how Google Maps loads on my phone.

It works just fine. So let’s finally move on to styling it.

Using Styled Maps

Google Maps can load styling options via two different formats: 1 - JSON file You load the JSON file in the onMapReady() method.

@Override public void onMapReady(GoogleMap googleMap) { try { // Customise map styling via JSON file boolean success = googleMap.setMapStyle( MapStyleOptions.loadRawResourceStyle( this, R.raw.style_map_json));

    if (!success) {
        Log.e(TAG, "Style parsing failed.");
    }
} catch (Resources.NotFoundException e) {
    Log.e(TAG, "Can't find style. Error: ", e);
}

String resource Using a string resource works in a similar way.

@Override public void onMapReady(GoogleMap googleMap) { try { // Customise map styling via String resource boolean success = googleMap.setMapStyle(new MapStyleOptions(getResources() .getString(R.string.style_json)));

    if (!success) {
        Log.e(TAG, "Style parsing failed.");
    }
} catch (Resources.NotFoundException e) {
    Log.e(TAG, "Can't find style. Error: ", e);
}

Now we know how to load our Map styles. But how do we actually create our style? Let’s look at that next.

Creating a Color Theme for Google Maps

I’ll put it bluntly. There are two ways you can go about it. One, write a JSON file. Manually writing every property (do you even know them?). Or two, using the Map Styling Wizard. In other words, save yourself time and frustration. Go with the second option. Use the Styling Wizard. It’s a no-brainer. Seriously!

Google Maps Styling Wizard

For this part, you just play around with the Styling Wizard. Adjust the density of features depending on how much detail you want on the map. Then select a basic, pre-defined theme to work with. Finally, you can click on ‘MORE OPTIONS’ to alter the properties of each Map object. Trust me, there’s a LOT of things you can customize that it’s easy to get lost.

I’ve chosen very light, pastel-like colors for the map. These are colors mainly for the terrain, parks, water and highways. Once you’re done, click the FINISH button. Next, copy the JSON from the popup that appears.

Head over to your Android Studio project and create a new file under Project/app/src/main/res/raw/maps.style.json. This JSON file is where we’ll paste the JSON copied from the Maps Style Wizard. Now all that’s left is to tell Google Maps to load its style from this JSON file. Remember we spoke about how to do this in the onMapReady() method? Let me remind you again. Now that we have our JSON file ready, we can call it in like this. Open MapsActivity.java and go to the onMapReady() method. The template has this method already implemented for you. So with the default template existing, here’s how to load the Styled Map.

@Override public void onMapReady(GoogleMap googleMap) { mMap = googleMap; try { boolean success = mMap.setMapStyle( MapStyleOptions.loadRawResourceStyle( this, R.raw.maps_style));

    if (!success) {
        Log.e(TAG, "Style parsing failed.");
    }
} catch (Resources.NotFoundException e) {
    Log.e(TAG, "Can't find style. Error: ", e);
}
...

}

It’s actually just one line of code. The try catch block just makes it look verbose. With Styled Maps now loaded, run your app and check it.

Styled Maps - Output

Based on the colors I chose against a Grey- themed Google Map, mine looks like this.

I changed parks to purple color. Just so I visually know that Styled maps are working. I know it’s an ugly map. But I’m sure you can do better!

Wrap Up

In this Android tutorial, we saw how to Style our default-looking Google Maps. First, we created an Android Studio project, using the Maps Activity template. We then created an API key to use with Maps. Next, we used the Maps Styling Wizard to configure Google Maps to our liking. Then, we pasted the generated JSON over to our project. Finally, we told Google Maps to load its styling from that JSON file.

Where to from here?

That’s all there is to it! With Styled maps, it is now possible to customize Google Maps to be more relevant to your app color-scheme. No more out-of-place looking Maps. If used properly they can now blend well with your UI designs. How are you going to customize your map? I’m very interested to see what you’ll come up with. Show me in the comments below. Header Image Credits: Asar Morris

Android O Tutorial: Supporting Picture-in-Picture (PIP)

Thu, 22 Jun 2017 00:00:00 GMT

Picture in Picture or PIP is a feature famously seen on YouTube and Android TV apps. It minimizes your content (typically video), keeping it pinned to a corner while you carry out your other tasks. In other words, the video keeps playing in the corner, while you continue using the app.

What's Picture-in-Picture?

Picture-in-picture mode lets apps run a video activity in the pinned window while another activity continues in the background. - developer.android.com

Let me rephrase that for you. Open YouTube and watch a video. You'll notice you can minimize that video and continue to watch it whilst using the app.

Recently, even Facebook added it. You can minimize a video and continue watching it, while you're scrolling through your newsfeed. Sweet!

Until now, to implement such a feature, Android Developers like you and I had two options:

Write our own - won't come off pretty
DraggablePanel - works fine

Yep, I heard you. DraggablePanel was our only choice. While that was and is a fine library, I'd say there's a better option today.

Picture in Picture with Android O

When Android Nougat came, we saw PIP support for Android TV. It was only a matter of time when it came to mobile. Finally, in the next version, Android O added support for mobile too! In this article, I'll tell you how to enable support for mobile. Developers who have worked on Android TV with Nougat should feel right at home. But don't worry if you haven't. You'll be able to follow along just as easy.

Getting Started - Project Setup

To use all of Android O’s features properly, you need Android Studio 3.0 Preview. This works as a standalone install compared to your existing, stable Android Studio. If you already have all of that setup, then feel free to go ahead with this tutorial. If you haven’t setup Android Studio 3.0 Preview, I strongly recommend you go through the Android O: Getting Started article first. It covers how to setup Android Studio Preview to use API 26. Anyways, for your reference, here’s what we’ll be using:

Android Studio 3.0 Preview
Gradle version - 3.0.0-alpha4
compileSdkVersion - 26
buildToolsVersion - 26.0.0
Support Library Version - 26.0.0-beta2

You can use these to update your Gradle build accordingly. Lastly, make sure you’re using Google’s maven repository. Open your project-level build.gradle file.

buildscript { repositories { google() jcenter() } dependencies { classpath 'com.android.tools.build:gradle:3.0.0-alpha4' } }

allprojects { repositories { ** google()** jcenter() } } // ...

Adding PIP Support on Android

First, we need to create an Activity and declare that it supports picture-in-picture. So go ahead and create a new Activity. I call mine PipActivity.java. Next, open your AndroidManifest.xml. Here, we’ll declare that PipActivity supports Picture-in-Picture. We do so by using the supportsPictureInPicture attribute.

NOTE: Developers who have worked with Android Nougat for TV might notice that the resizeableActivity attribute is no longer required for PIP. However, keep in mind that if you set resizeableActivity to false, then the supportsPictureInPicture attribute is ignored.

Handling Activity Duplication and Recreation

Notice the launchMode attribute in the Manifest. Any guesses why it’s required? Avoiding Activity Duplication - Using Launch Modes

The Launch Mode singleTask tells Android that there should be only one instance of that Activity.

In other words, if I keep starting PipActivity, only one instance of it should open. There should never be any duplicates. This scenario is highly likely and is mandatory that you handle it. For example, take the YouTube app. You’re browsing through a playlist and you open a particular video. Then, if you enter PIP mode, you’re back to the playlist screen. Now, if you click the same video again, we want the existing video to enlarge back up. Or, if you click another video, we want PIP to maximize with the clicked video playing. We do not want another (PIP) screen to open. The singleTask Launch Mode handles this for us. Preventing Activity Recreation If you’re that daring person who wants to support PIP and orientation changes, then you’ll need one extra attribute. Add the configChanges attribute to your Manifest to prevent PipActivity from being recreated each time on orientation change. This will be extremely handy when your PiP includes a player (which will most likely be the scenario).

Starting Picture-in-Picture mode

Now that we’ve prepared our Activity, the next step is to trigger PIP mode. So to do that, we need to create a simple layout first. Open your Activity’s XML layout.

XML Layout

Honestly, I leave this to your imagination. But for the sake of this tutorial, I’m going to pretend we have a UI that includes a player.

The layout is very simple. Here’s the XML code for the same.

<ImageButton
    android:id="@+id/btn_minimize"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_gravity="top|start"
    android:layout_margin="@dimen/layout_margin"
    android:background="?selectableItemBackgroundBorderless"
    android:src="@drawable/ic_picture_in_picture_alt_black_24dp"
    android:tint="@android:color/white" />

<!--Other Player UI here-->

<!--Video details UI here-->

In short, we have a FrameLayout that would be our player. We also have a button that indicates switching to Picture in Picture mode. You can add that icon via a right click on res/drawable folder> New> Vector Asset. In this way, you can choose from the entire set of Google’s Material Design icons.

TIP: These icons that you import are by default, black in color. So make sure to tint vector icons for pre-Lollipop devices.

Triggering PIP

With the layout complete, it’s now time to start Picture-in-Picture. So to do that, head over to PipActivity. PiP is triggered when we click the button on the top-right. So we’ll write our entire logic inside that button’s click listener.

mBtnPip.setOnClickListener(view -> { if (android.os.Build.VERSION.SDK_INT >= 26) { //Trigger PiP mode try { Rational rational = new Rational(mFramePlayer.getWidth(), mFramePlayer.getHeight());

            PictureInPictureParams mParams =
                    new PictureInPictureParams.Builder()
                            .setAspectRatio(rational)
                            .build();

           ** enterPictureInPictureMode(mParams);**
        } catch (IllegalStateException e) {
            e.printStackTrace();
        }
    } else {
        Toast.makeText(PipActivity.this, "API 26 needed to perform PiP", Toast.LENGTH_SHORT).show();
    }
});

There are a couple of things going on here, so let’s tackle it one at a time. If you’ve seen the PIP animation, notice that the ‘ratio’ the player maintains when maximized and minimized, are the same. So it’s essential that we do the same. You can simply enter Picture-in-Picture mode using enterPictureInPictureMode(). But you can pass in some optional parameters if you wish. That’s what we’re doing here. We will maintain the ratio of our dummy player to be the same in PIP mode. For that, we need to pass a PictureInPictureParams object.

NOTE: I’m triggering PIP mode only for API 26 and above. Ideally, as a fallback, you must hide or disable this feature. For the sake of this tutorial, I’m displaying a Toast message.

Best Practices

Now that we’ve seen how to launch PIP, there are a couple of things to keep in mind.

Adapting UI to PIP mode

When in PIP mode, avoid displaying any UI controls except the video player.

When PipActivity enters PIP mode, we need to hide everything displayed except the video. So to do that, we need some way to know that we’re currently in PIP. We can detect when an Activity enters Picture-in-Picture using the onPictureInPictureModeChanged() method. In our case, the only UI control we need to hide is the PIP ImageButton on the top-left.

@Override public void onPictureInPictureModeChanged(boolean isInPictureInPictureMode) { super.onPictureInPictureModeChanged(isInPictureInPictureMode); if (!isInPictureInPictureMode) { mBtnPip.setVisibility(View.VISIBLE); } else { mBtnPip.setVisibility(View.GONE); } }

TIP: You can override onPictureInPictureModeChanged() either in your Activity or Fragment.

Updating PIP Content

Remember we discussed the importance of singleTask Launch Mode to avoid duplicate PIPs? I even used the YouTube app as an example. If you think carefully about that example, there’s one thing that we don’t know how to handle. When we’re in PIP, and we click on another content, we solved the duplication problem. But PIP must be updated with the content that we clicked. How can we do that? Use the onNewIntent() method to update your PIP with the new content data.

Managing Playback

Once our Activity goes into PIP mode, we need to ensure that the content playback continues.

NOTE: When you switch to PIP mode, Android considers that Activity to be in a paused state. Hence it calls that Activity’s onPause() method.

Forget PIP for a second. If your Activity goes into onPause(), then ideally, you’ll pause your playback too. But if you’re in PIP mode, make sure you don’t pause playback. Android’s given us a handy method isInPictureInPictureMode() that we can use to handle this.

@Override protected void onPause() { super.onPause();

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N
        && isInPictureInPictureMode()) {
    // Continue playback...
}
// Not in PIP & Activity is paused. Pause playback if required....

}

Output

Finally, we’ve done everything that’s needed to make Picture in Picture work. We’ve also made sure to handle its common scenarios. Let’s see how it works. Make sure you create an Android Emulator (AVD) that runs API 26 (Google Play System Image). Once you’ve done that, run your app. You should get a working PIP like this.

Wrap up

Picture-in-Picture was finally brought to Android Smartphones thanks to Android O. In this article, we briefly saw how to prepare Android Studio to use the latest Android O SDK (API 26). Then we learnt how to use PIP. Although PIP is generally used for video playing content, this tutorial excluded a guide for video playing. This was done to ensure the focus stays on Picture in Picture. SOURCE CODE: Sample working Project available on GitHub.

Where to from here?

Remember, there is no hard and fast rule that PIP must only be used for video playing content. Its usage is only restricted to your imagination. How will you use PIP in your app? Have any questions? Let me know in the comments below. Lastly, if you liked reading this, don’t forget to share (on the left). If you want updates on the next article, subscribe below.

Mega Guide to Android's Material Design Components

Tue, 30 May 2017 00:00:00 GMT

Material Components are a set of UI components that helps you build Android apps with Material Design.

In this post, I'll cover every Material Design component available to us. In addition to components, popular design patterns can be recreated as well. That too, quite easily. For example, the 'Collapsing App Bar on scroll' (Read as Flexible Space with Image Pattern).

Moreover, I'll tell you how to use each Material Component with links to detailed Android tutorials.

This article has been updated for AndroidX!

A Brief History

Material Design was introduced in 2014. At that time, there was little to no official support from Google for us Android Developers.

On one hand, we had Material Design in all its vibrancy, robust principles and eye-catching animations. On the other hand, we didn’t receive any official support on how to implement all of that.

But all that changed gradually over a year.

Support libraries steadily improved. AppCompat supported basic color theming. Even common widgets were ‘Materialized’. They were also made backward-compatible.

But Material Design wasn't just about a UI overhaul and vibrancy, was it?

Motion provides meaning. It respects and reinforces the user as the prime mover. Motion is meaningful and appropriate, serving to focus attention and maintain continuity…

– Material Design Principles

Material Components

Now, Android has modularized and put all their Material Design related offerings into a single resource. They call it Material Components. Here's their website.

material.io/components

For those who don't know, Material Components isn't another fancy new library. In fact, it's the same library which we're already familiar with, packaged in a different offering. Very smart on Google's part.

You might have already guessed what it is. For Android, it's nothing but the Design Support Library.

The Real Hero - Design Support Library

This gem beat every other library before it. Popular design patterns that took days and hundreds of lines of code were accomplished in a matter of minutes.

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 - android-developers.googleblog.com

Popular Material Design Components such as Snackbar, FAB, Navigation Drawer and more could be easily used. Moreover, patterns like Quick Return, Collapsing Headers were made possible, all through XML. All it takes is one line to enable the animation. That’s brilliance, at its finest!

You can start using Material Components by adding AndroidX and the Material Components library to your app/build.gradle file.

dependencies {
    …
    implementation 'androidx.appcompat:appcompat:1.1.0'
    implementation 'com.google.android.material:material:1.0.0'
}

Benefits:

1. Ease of use

All Material Components can be easily used just like any normal UI widget in Android. Moreover, as I mentioned above, performing on-scroll animations takes only one line of XML. You don't even have to touch Java.

I'll show you how to do all of this, later in this article.

2. Backward Compatibility

Remember how we all struggled with maintaining consistency using Material Design? I remember it, crystal clear. Doing anything Material, pre-Lollipop was a nightmare!

But the Design Support Library offers is compatible back to Android 2.1. Sweet!

Honestly, the only difference I see is the lack of elevation (depth) on pre-Lollipop. But there's a simple fix for that too. There's a way to show elevation shadows on pre-Lollipop.

3. Respects Material Design Guidelines

The library is officially by Google's Android team. All components strictly follow and respect Material Design guidelines. Each Material Component looks and behaves the way it's supposed to. So you don't have to worry about anything that may be amiss.

Also, you can easily tint your Material Component to match your brand color.

Material Components - Index

The Design Support Library gives us a many to use components. We can even style them to match our brand theme. Here's a list of all the Material components it offers for us Android developers to use.

You can treat this list as an index to navigate this entire article.

Important Classes

CoordinatorLayout
Behaviors

Android Material UI Components

Bottom Bar Navigation
Bottom Sheet
Floating Action Button (FAB)
Floating labels (for EditText)
Material Design Tabs
Navigation Drawer
Snackbar

Animations

Quick Return
Flexible Space with Image
Parallax Scrolling (header)

This post is a one stop destination for you to know about everything this library can do for you. Additionally, I’ll even tell you how to implement each feature.

Now that you have a glimpse of what we're going to cover, let's dive in.

Important Classes

Before we get to the Material Components, there are 2 fundamental classes you need to know. Without understanding these, it's difficult to learn how to use almost any Material Component.

1. CoordinatorLayout

CoordinatorLayout is a super-powered FrameLayout.

– Android docs

The CoordinatorLayout acts as a top-level parent layout. It helps 'coordinate' the behaviors of its child Views. One child Views can listen and react to changes based on another child View. The on-scroll animations that the library helps you perform, is because of the CoordinatorLayout.

To be specific, the CoordinatorLayout does this by using Behaviors. This brings us to our next point.

2. Behavior

Behavior enables interactions for child Views of CoordinatorLayout.

In other words, Behaviors allow you to intercept different events of a child View.

Want your FAB to shrink and grow? Want your Toolbar to scroll on and off-screen? All that is possible with Behaviors. Most of the interactions that you see in the Design Support, is made with Behaviors.

Android provides a few default Behaviors off the bat. You'll become familiar with them as you read this article. However, you can even write our own custom Behavior if you wish.

TIP
Ian Lake has a brilliant Medium write-up about Behaviors.

Or, if you want to create some amazing animation like the one above, Saúl Molinero has a great tutorial on Custom Behaviors.

Android Material UI Components

The Design Support library offers many UI components out of the box. While the Toolbar was introduced with the AppCompat Support Library, Design Support offers a wealth of Material Design components.

1. Bottom Bar Navigation

The newest addition to the Material Design guidelines is Bottom Navigation. Quite recently, it was added to the Design Support Library.

iOS devs would come to know this as the TabBar.

Bottom navigation bars make it easy to explore and switch between top-level views in a single tap.

Bottom Bar Navigation as seen on Instagram

To use Bottom Navigation, you use the BottomNavigationView class. Here's a quick code snippet you can drop into your layout.

<com.google.android.material.bottomnavigation.BottomNavigationView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_gravity="bottom"
        app:itemBackground="?attr/colorPrimary"
        app:itemIconTint="@drawable/selector_bottombar"
        app:itemTextColor="@drawable/selector_bottombar"
        app:menu="@menu/bottombar_menu"/>

On the surface, it looks very simple and limited in customization. For example, you can selectively display item text labels if you wish, change tint color and more. To give you a hint, all this is possible using 'State Selectors'.

READ
The Bottom Navigation tutorial for in-depth customization and more.

2. Bottom Sheet

Bottom Sheets slide up from the bottom of the screen to reveal more content.

Bottom Sheet as seen on Google Maps Android app

BottomSheet was added to Design Support Library in v23.2.0. It also included a whole new BottomSheetBehavior.

Simply add your Bottom Sheet directly within CoordinatorLayout.

<androidx.coordinatorlayout.widget.CoordinatorLayout>
 ...
  <androidx.core.widget.NestedScrollView
  app:behavior_peekHeight="312dp"
  app:layout_behavior="com.google.android.material.bottomsheet.BottomSheetBehavior" />
 ...
</androidx.coordinatorlayout.widget.CoordinatorLayout>

Additionally, you can make your Bottom Sheet react to on-scroll events. You can see such an example in the GIF above. The FAB contracts on expand, and grows (appears) on collapsing the bottom bar.

READ
The Android Bottom Sheet tutorial teaches you how to do all of this and more.

3. Floating Action Button (FAB)

A floating action button represents the primary action in an application.

The most important action that users will perform on a screen, must reside in a Floating Action Button (FAB). It represents a promoted action on-screen.

Material Design Floating Action Button. Image Credit: Android Developers Blog

Just like any other UI widget, you’d simply include it in your XML layout. Use the class FloatingActionButton.

<com.google.android.material.floatingactionbutton.FloatingActionButton
   android:src="@drawable/your_icon"
   app:rippleColor="@color/rippleColor" 
   app:fabSize="normal" />

Again, Materialdoc.com does a fine job of covering the FAB in detail. Paresh Mayani brilliantly explains how to use, style and customize it.

READ: Floating Action Button on materialdoc.com

If you’re using a FAB in your apps, keep the following in mind and use it carefully.

Chose your promoted action wisely
You may risk de-prioritising other onscreen actions
It may block your screen, as it is an overlay

4. Floating labels (for `EditText`)

When the user engages with the text input field, the floating inline labels move to float above the field.

Image Credit: materialdoc.com

Again, implementing this is simple. Just wrap your existing EditText with TextInputLayout.

<com.google.android.material.textfield.TextInputLayout android:layout_width="match_parent" android:layout_height="wrap_content">

</com.google.android.material.textfield.TextInputLayout>

To further style your Floating Labels, you can read Floating Labels on materialdoc.com.

5. Material Design Tabs

Tabs make it easy to explore and switch between different views.

Material Design Tabs

We’re all very familiar with Tabs. But the Design Support Library introduced a new TabLayout class which by default, styles your Tab in Material Design flavor.

<androidx.coordinatorlayout.widget.CoordinatorLayout>
    <com.google.android.material.appbar.AppBarLayout>

        <com.google.android.material.tabs.TabLayout
            android:layout_width="match_parent"
            android:layout_height="wrap_content" />

    </com.google.android.material.appbar.AppBarLayout>

    <android.support.v4.view.ViewPager
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        app:layout_behavior="@string/appbar_scrolling_view_behavior" />
</androidx.coordinatorlayout.widget.CoordinatorLayout>

READ
How to create Material Design Tabs with Android Design Support Library.

6. Navigation Drawer

The navigation drawer slides in from the left and contains the navigation destinations for your app.

In the early days, making a Navigation Drawer in Android took considerable effort. With Material Design things got even harder.

However, adding a Navigation Drawer now is a breeze. All your drawer items are loaded from a menu resource. The drawer header is a separate layout.xml. Honestly, it can’t get any easier than this.

<androidx.drawerlayout.widget.DrawerLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:fitsSystemWindows="true">

    <!-- your content layout -->

    <com.google.android.material.navigation.NavigationView
        android:layout_width="wrap_content"
        android:layout_height="match_parent"
        android:layout_gravity="start"
        android:fitsSystemWindows="true"
        app:headerLayout="@layout/drawer_header"
        app:menu="@menu/drawer" />

</androidx.drawerlayout.widget.DrawerLayout>

READ
Navigation Drawer with Design Support Library - Android Tutorial

7. Snackbar

A lightweight component that gives feedback to users. It optionally provides an action to users.

Here's a simple Snackbar.

Snackbar
.make(view, "Your message here",
Snackbar.LENGTH_SHORT) .show();

Note that "view" can be any View from your layout.

I know, you might say that if you remove the action, it's a Toast. I agree with you. But in one line, here's the difference.

Toasts are usually for important system related messages.

READ
How and when to use a Snackbar correctly.

Animations

1. Quick Return

The Toolbar scrolls off-screen with the rest of the scrollable content, but upon scrolling slightly up at any point, it scrolls back into view.

– Quick Return Animation Pattern

Quick Return is a useful pattern that provides more vertical space for your content.

They key to enabling this animation is as simple as adding this flag to your Toolbar.

app:layout_scrollFlags="scroll|enterAlways"

It is also possible to combine Quick Return with the Flexible Space pattern. Simply add this flag to get it working!

READ
Learn via a more detailed demonstration in the Android Quick Return tutorial.

2. Flexible Space with Image

A scrolling technique that supports an image header with a scrollable view below it. Upon scrolling, the ‘Flexible Space’ (image header) fades into a color. At the same time, it collapses into a Toolbar.

–- Material Design guidelines

Now it's obviously clear when you would want to use this pattern. It works best when you have a header image. You'll understand the Flexible Space pattern better via a GIF.

Note that in this GIF, the Toolbar doesn't always have to tint with the primary brand color. It also can take on the image's dominant color. You can fetch an image's dominant color, including a variety of other colors using the Palette API.

READ
How to create a collapsing toolbar animation, including Palette API.

3. Parallax Scrolling (header)

Parallax scrolling is where one element scrolls at a different speed compared to other elements.

In our case, we'll apply parallax scrolling to ImageView. So our ImageView will scroll at a different rate compared to CollapsingToolbar.

For a bit, head back to our Flexible Space pattern animation. Remember that I said it predominantly uses an ImageView for its header?

You just need one attribute to enable parallax scrolling on the ImageView.

app:layout_collapseMode="parallax"

If you want the parallax effect to be more profound, add a multiplier.

app:layout_collapseParallaxMultiplier="0.5"

ProGuard rules for Design Support Library

Lastly, don’t forget to add ProGuard rules. I’m sure the apps you build will go on to be production-ready. You’ll even upload it on the Play Store.

So when you’re generating your release build. Add these lines to your app/proguard-rules.pro file.

-dontwarn android.support.design.** -keep class android.support.design.** { *; } -keep interface android.support.design.** { *; } -keep public class android.support.design.R$* { *; }

TIP
If you’re using a lot of libraries, adding ProGuard rules can be hard. So here’s a useful collection of ProGuard snippets that will help you.

Key Takeaways

Being a user of Design Support library since its advent, I say this from experience. If you plan on building a Material Design Android app, this library is a must-have.

I hope this list was exhaustive and convincing enough for you. It's about time you made the jump to the Design Support Library.

Stop using external libraries that do the same thing. I’m not saying that they’re bad in any way. But I'd prefer using official implementation and reduce third-party dependency when possible.

How will you use Material Components in your Android app? Let me know in the comments below.

Android Architecture Components Tutorial - Room, LiveData and ViewModel

Tue, 23 May 2017 00:00:00 GMT

During the concluded Google I/O 2017, there were some amazing announcements about Android. Say hello to Android Architecture Components. For once, these are announcements that ease our lives as Android Developers.

Android Architecture Components

A new collection of libraries that help you design robust, testable, and maintainable apps. - developer.android.com

It helps us developers address two pain points:

Manage our UI components lifecycle
Persist data over configuration changes

In fact, these are the two biggest problems we Android Developers face. Period. Maintaining data over orientation changes and handling our objects with lifecycle is hard. That’s why, to avoid the hassle, you lock your apps in Portrait mode, don’t you? Don’t lie. Even I’ve done it. But don’t worry, Android Architecture Components will help alleviate both our fears. There are 3 main architecture components:

Room
LiveData
ViewModel

So first, let's find out what these components actually are. Then, we’ll learn how we can use them. We’ll even make a handy app that keeps track of what people borrow. This will help us learn better about how all these 3 components work together.

Room

Remember the amount of boilerplate code you had to write to create and manipulate even a very small database? You had to define the database structure, create an SQLiteHelper class etc. Room is a library that saves you all such trouble. Now you can query your data without having to deal with cursors or loaders. You can define your database by adding annotations in your Model class. Yes, it's that simple. If you’ve used third-party ORMs like Sugar, you’ll feel right at home here. In fact, from now on, I wouldn’t even want to use one. Room is that brilliant! Why would you want to use a third-party library, when the official Android libraries give you an equal, or if not, better solution.

Architecture

In this app, we will follow an architecture called MVVM - Model View ViewModel.

In MVVM, the ViewModel exposes the required data and interested parties can listen to it.

But you don't have to worry. We'll do a simple implementation for this article. You'll have no problem following. So in our case, the Activity will listen on the data and make changes in the UI.

Getting started

Create a new project in Android Studio. First, Add Google's maven repository to your project-level build.gradle file.

//... allprojects { repositories { jcenter() maven { url "https://maven.google.com" } } } //...

Next, add the following dependencies for Room in your app-level build.gradle file.

compile "android.arch.lifecycle:extensions:1.0.0" compile "android.arch.persistence.room:runtime:1.0.0" annotationProcessor "android.arch.lifecycle:compiler:1.0.0" annotationProcessor "android.arch.persistence.room:compiler:1.0.0"

Creating the Model

Create a class called BorrowModel.

import java.util.Date; @Entity public class BorrowModel {

@PrimaryKey(autoGenerate = true)
public int id;
private String itemName;
private String personName;
@TypeConverters(DateConverter.class)
private Date borrowDate;

public BorrowModel(String itemName, String personName, Date borrowDate) {
    this.itemName = itemName;
    this.personName = personName;
    this.borrowDate = borrowDate;
}

public String getItemName() {
    return itemName;
}

public String getPersonName() {
    return personName;
}

public Date getBorrowDate() {
    return borrowDate;
}

}

You might see an error at DateConverter.class. But don't panic, we'll create that next. So for now, pay attention to the Annotations used here. We use the @Entity annotation to tell Room to use the current class as a database table. Any attribute preceded by the @PrimaryKey annotation will serve as a primary key for the table. Here we use 'autoGenerate = true' so that the key is automatically generated every time an entry is made. SQL cannot store data types like Date by default. That's why we need a way to convert it into a compatible data type to store it in the database. We use the @TypeConverters to specify the converter for the borrowDate attribute. So to help us with this conversion, we'll create a class called DateConverter. NOTE: Make sure to import java.util.Date;

import java.util.Date; class DateConverter {

@TypeConverter
public static Date toDate(Long timestamp) {
    return timestamp == null ? null : new Date(timestamp);
}

@TypeConverter
public static Long toTimestamp(Date date) {
    return date == null ? null : date.getTime();
}

}

As you can see, the class just converts Date to Long and vice versa.

Data Access Object

Next up, we need to create a DAO - Data Access Object class. This class will be used to define all the queries we will perform on our database.

@Dao @TypeConverters(DateConverter.class) public interface BorrowModelDao {

@Query("select \* from BorrowModel")
LiveData<List<BorrowModel>> getAllBorrowedItems();

@Query("select \* from BorrowModel where id = :id")
BorrowModel getItembyId(String id);

@Insert(onConflict = REPLACE)
void addBorrow(BorrowModel borrowModel);

@Delete
void deleteBorrow(BorrowModel borrowModel);

}

We use @Dao to tell Room that this is a DAO class. We define our queries as strings and pass them as a parameter to @Query. Each @Query annotation is paired with a method. When the paired method is called, the query gets executed. Next, we use the @Insert annotation for methods that insert entries into the table. We can similarly use @Delete and @Update for deletion and update methods respectively. In case there are conflicts during such manipulation operations, we have to specify a conflict strategy too. In our example, we are using REPLACE. It means that the conflicting entry will be replaced by the current entry. Make sure you import REPLACE correctly using import static android.arch.persistence.room.OnConflictStrategy.REPLACE;

Creating the database

Now, all we need to do is create a RoomDatabase class. So create an abstract class called AppDatabase.

@Database(entities = {BorrowModel.class}, version = 1) public abstract class AppDatabase extends RoomDatabase {

private static AppDatabase INSTANCE;

public static AppDatabase getDatabase(Context context) {
    if (INSTANCE == null) {
        INSTANCE =
                Room.databaseBuilder(context.getApplicationContext(), AppDatabase.class, "borrow_db")
                        .build();
    }
    return INSTANCE;
}

public abstract BorrowModelDao itemAndPersonModel();

}

We annotate the class with @Database which takes two arguments:

An array of the Entity classes(the tables)
The database version which is just an integer.

This class is used to create the database and get an instance of it. We create the database using

Room.databaseBuilder(context.getApplicationContext(), AppDatabase.class, "borrow_db") .build();

The arguments are:

Context
Your database class
Name to given to the database

TIP: We have to create an abstract method for every DAO class that we create. This is really important. And that's it. Our database is ready to roll.

ViewModel

Earlier in the post, we mentioned ViewModel. ViewModels are entities that are free of the Activity/Fragment lifecycle. For example, they can retain their state/data even during an orientation change. ViewModels do not contain code related to the UI. This helps in the decoupling of our app components. In Room, the database instance should ideally be contained in a ViewModel rather than on the Activity/Fragment.

Create the AndroidViewModel

We create a ViewModel for our borrowed items.

public class BorrowedListViewModel extends AndroidViewModel {

private final LiveData<List<BorrowModel>> itemAndPersonList;

private AppDatabase appDatabase;

public BorrowedListViewModel(Application application) {
    super(application);

    appDatabase = AppDatabase.getDatabase(this.getApplication());

    itemAndPersonList = appDatabase.itemAndPersonModel().getAllBorrowedItems();
}

public LiveData<List<BorrowModel>> getItemAndPersonList() {
    return itemAndPersonList;
}

public void deleteItem(BorrowModel borrowModel) {
    new deleteAsyncTask(appDatabase).execute(borrowModel);
}

private static class deleteAsyncTask extends AsyncTask<BorrowModel, Void, Void> {

    private AppDatabase db;

    deleteAsyncTask(AppDatabase appDatabase) {
        db = appDatabase;
    }

    @Override
    protected Void doInBackground(final BorrowModel... params) {
        db.itemAndPersonModel().deleteBorrow(params\[0\]);
        return null;
    }

}

}

Every ViewModel class must extend the ViewModel class. If the ViewModel needs the application context, then it must extend the AndroidViewModel class. The ViewModel will contain all the data needed for our Activity. In our example, we are using something called LiveData.

LiveData is a wrapper that lets interested classes observe changes in the data inside the wrapper.

We wrap our list of borrowed items inside LiveData so that the Activity can observe changes in the data and update the UI. In our ViewModel, we first get an instance of our database using AppDatabase.getDatabase(this.getApplication()) First, we need to load the list of borrowed items from the database. For that, we should use the query we defined in the DAO class, getAllBorrowedItems(). Next, call the abstract method we created for DAO and then call the query method. Refer to this snippet in the BorrowedListViewModel class.

appDatabase.itemAndPersonModel().getAllBorrowedItems();

Now since we will be displaying a list of items, we need a RecyclerView. So first, let's create an adapter for the same.

public class RecyclerViewAdapter extends RecyclerView.Adapter<RecyclerViewAdapter.RecyclerViewHolder> {

private List<BorrowModel> borrowModelList;
private View.OnLongClickListener longClickListener;

public RecyclerViewAdapter(List<BorrowModel> borrowModelList, View.OnLongClickListener longClickListener) {
    this.borrowModelList = borrowModelList;
    this.longClickListener = longClickListener;
}

@Override
public RecyclerViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
    return new RecyclerViewHolder(LayoutInflater.from(parent.getContext())
            .inflate(R.layout.recycler_item, parent, false));
}

@Override
public void onBindViewHolder(final RecyclerViewHolder holder, int position) {
    BorrowModel borrowModel = borrowModelList.get(position);
    holder.itemTextView.setText(borrowModel.getItemName());
    holder.nameTextView.setText(borrowModel.getPersonName());
    holder.dateTextView.setText(borrowModel.getBorrowDate().toLocaleString().substring(0, 11));
    holder.itemView.setTag(borrowModel);
    holder.itemView.setOnLongClickListener(longClickListener);
}

@Override
public int getItemCount() {
    return borrowModelList.size();
}

public void addItems(List<BorrowModel> borrowModelList) {
    this.borrowModelList = borrowModelList;
    notifyDataSetChanged();
}

static class RecyclerViewHolder extends RecyclerView.ViewHolder {
    private TextView itemTextView;
    private TextView nameTextView;
    private TextView dateTextView;

    RecyclerViewHolder(View view) {
        super(view);
        itemTextView = (TextView) view.findViewById(R.id.itemTextView);
        nameTextView = (TextView) view.findViewById(R.id.nameTextView);
        dateTextView = (TextView) view.findViewById(R.id.dateTextView);
    }
}

}

Creating the Android LifecycleActivity

It's a pretty straightforward adapter. So I won't be getting into the details of it. But if you're interested in how RecyclerView works, this Android tutorial tells you how to create a RecyclerView.Adapter. Now create an Activity that extends LifecycleActivity to display a list of all the borrowed items.

LifecycleActivity is a class that provides us with the state of the lifecycle.

public class MainActivity extends LifecycleActivity implements View.OnLongClickListener {

private BorrowedListViewModel viewModel;
private RecyclerViewAdapter recyclerViewAdapter;
private RecyclerView recyclerView;

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    FloatingActionButton fab = (FloatingActionButton) findViewById(R.id.fab);
    fab.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View view) {
            startActivity(new Intent(MainActivity.this, AddActivity.class));
        }
    });

    recyclerView = (RecyclerView) findViewById(R.id.recyclerView);
    recyclerViewAdapter = new RecyclerViewAdapter(new ArrayList<BorrowModel>(), this);
    recyclerView.setLayoutManager(new LinearLayoutManager(this));

    recyclerView.setAdapter(recyclerViewAdapter);

    viewModel = ViewModelProviders.of(this).get(BorrowedListViewModel.class);

    viewModel.getItemAndPersonList().observe(MainActivity.this, new Observer<List<BorrowModel>>() {
        @Override
        public void onChanged(@Nullable List<BorrowModel> itemAndPeople) {
            recyclerViewAdapter.addItems(itemAndPeople);
        }
    });

}

@Override
public boolean onLongClick(View v) {
    BorrowModel borrowModel = (BorrowModel) v.getTag();
    viewModel.deleteItem(borrowModel);
    return true;
}

}

NOTE: Whenever we need to use ViewModels inside our Activity, the Activity must extend LifecycleActivity. Creating a ViewModel is simple.

viewModel = ViewModelProviders.of(this).get(BorrowedListViewModel.class);

The two parameters are:

Context
The ViewModel class

Now we need to make our Activity observe the changes in the ViewModel. So first, get a reference to the LiveData inside the ViewModel. Then, add an observe() method to the reference. The observe() method takes 2 parameters:

The owner of the Lifecycle. In our case, it is the Activity.
An Observer.

Whenever there is a change in the data, the onChanged() callback is executed and we get the new data. We can update the UI accordingly.

Simple Exercise - Create the 'Add Item Screen'

Now we have an Activity that can display a list of borrowed items. But how do we add items to the database? It's simple. You need to create an AddItemActivity. The entire procedure is exactly the same as before. But in this case, you need to call the addBorrow() DAO method and pass a Borrow object as a parameter. And that is it. Our app is ready. I encourage you to try this screen on your own. But in case you get stuck, you can refer to my files on GitHub.

Output

So go ahead and run your app. You should get an output similar to this.

The Android Architecture Components give us great advantage and relief. Hence, we don't have to worry about

lifecycle changes
memory leaks
data retention across configuration changes

If you recount, these are the biggest challenges faced by even veteran Android developers. Source Code: As always, the code from the post can be found on GitHub.

Wrap up

In the post, we got introduced to Android Architecture Components. Then, we learnt about Room and used it to create databases in a fast and easy way. Next, we also learnt how to make our UI respond to changes in data. Also, by using LiveData and ViewModels, we did not have to use a lot of callbacks. Additionally, we even learnt a bit about the MVVM architecture. We have barely scratched the surface in terms of what's possible with these new components. So I hope to discover more as I continue to tinker with Android Architecture Components. So are you going to use these components? Would you consider Room in any of your apps? Or maybe ViewModels to simplify your code? I'd love to hear your comments.

Horizontal Scrolling Lists in Mobile - Best Practices

Tue, 09 May 2017 00:00:00 GMT

Many Android and iOS apps have horizontal scrolling lists. Maybe it’s also combined inside a vertical list. But is it necessary? Even assuming it is, are you doing it right?

Horizontal lists are better-suited for mobile, as gestures are both horizontal and vertical.

Yet, people including you and me both, mostly vertical scrolling. I mean seriously, what’s the first natural thing you do, when you open an app? You scroll. Vertically. Okay, maybe you check your notifications, but even there, you scroll. Vertically. So how do you tell people that they can horizontal scroll too? Or rather, when should we use horizontal scrolling?

When to use Horizontal Lists

Horizontal lists work best when you want to display a subset of homogeneous content that’s part of a heterogeneous set.

Makes sense? Take the Play Store app for Android. Sure the Play Store is all about finding new apps. But for us to search better, apps need to be categorized right? For example, you can subcategorize apps into games, utility and social, to name a few. Hence each category of apps, can be in a horizontal list.

As you can see, Play Store gives us an assortment of apps. There's a bunch of 'Recommended' apps you can browse (horizontally). Then, there's a set of apps that are 'New+Updated'. So to go by the definition above, each subcategory of apps are in a horizontal list. These child lists are put into a (parent) vertical list. You can scroll vertically to find more such subcategories. Here’s another example.

Amazon Prime Video — Android App. Image Credits: pcadvisor.co.uk

Design Tips for Horizontal lists on Mobile

In the web, arrows show that there is a horizontal list of content you can scroll. This is typically a carousel. It uses a combination of arrows for navigation, dots for indication and scrollbars. These are indicators (affordances) that tell people how to navigate a carousel.

But how would you design horizontal lists on mobile? Mobile apps are touch based and support gestures. Would you still be using point and click mechanisms such as arrows? I’m sure not. Moreover, given mobile size constraints, using the same web paradigms makes little sense. Hence there must be a better way. Expect users to scroll the same way they would in a vertical list. Here are some design tips to keep in mind. They can help you make better and effective horizontal lists.

Show Visual Indicators

The design must leave a visual hint that a set of content is horizontally scrollable.

Assume you’re displaying a horizontal list of cards. You’d want the last card on the right, to peek out from the edge.

So for this particular device width, we can show two cards. To see the third card and beyond, we need to scroll horizontally. Notice the design teases a bit of the third card. Yes, the pink cards at the extreme ends that are partially hidden. This ‘tease’ provides a subtle hint that there’s more content. Since the flow of content is horizontal, it naturally indicates users in which direction to scroll. Hence, the user’s natural instinct is to scroll in that direction (horizontally).

Use a 'See More' Button

See More, See All, View All, View More, Show More ... Call the button what you want. Essentially, it should mean one thing:

A 'See More' button tells users there's more of where that came from. It's hints that there's more of similar content available.

Keep in mind, that each subcategory (horizontal list), is just a tease of what kind of content you can expect.

So when a user taps on "See More", you want to show them all that's there to show for that subcategory. For example, assume the user clicks the subcategory called "Top Action Games" in the Play Store app. Then the 'See All' screens shows all the best action games in that subcategory. Remember that vertical scrolling is the most natural and fastest.

Vertical scrolling increases the user's ability to skim through content

Hence, it makes sense to use a vertical grid in the See All screen.

Design for Responsiveness

Keep in mind that mobile app interfaces are responsive. So make sure that this subtle hint is always present. Otherwise, you might see a horizontal list that looks like a grid.

So tell me. From the UI above, can you tell that each subcategory is a horizontal list? Moreover, can you even tell if it's horizontally scrollable? I'm sure not. But you're not to blame. It's the design's fault. There is NO visual indication! Trust me, that’s not what you want people seeing. It looks just like a vertical grid. If it looks like that, then every user’s natural instinct is to scroll vertically.

Adapting Horizontal lists for Tablets

So how do you design horizontal scrolling lists on larger devices? Say tablets for example? You can convert your horizontal list into a grid with N items per row. The above UI design displays five items per row. With a see all button that indicates that a user can see more of this kind of content, on a new screen.

Hence, on mobile, it can be a scrollable horizontal list of say, ten cards. However on Tablets, you could have five or six, non-scrollable cards. Read: Getting Started with Material Design for Tablets - Android

Limit horizontal content on tablets

Tablets grant larger screen width. So it's wise to take advantage of large screen real-estate. But let's focus on just horizontal scrolling for a moment. It's perfectly fine on mobile. You show 3 contents by default. The rest is can be viewed by scrolling horizontally. This means that the additional content which is hidden, is optional. If users are interested, they can scroll to see more. Or if they're interested in seeing all of it, they can tap the 'See More' button. Now let's get back to Tablets. Your natural instinct would be to simply show more content horizontally. It totally makes sense to do so right? When large width is available, it's natural to make use of it. Right? No. Let me tell you why.

Giving a 'tease' of five to six contents is more than enough to tell people what to expect from a category. Remember that the user may scroll horizontally to see more. But they definitely will scroll vertically. Moreover, if they want to see everything a category has to offer, they can tap the See All button. Hence, it makes sense to just show a non-scrollable grid of 5-6 items per subcategory. Giving too many choices is a sign of increased cognitive load for users. That's not a good thing.

Every time you visit a website, a process of learning is initiated. Your brain has to learn how to use the site while keeping track of the reason you came there in the first place. The mental effort required during this time is called cognitive load. - Design Principles for Reducing Cognitive Load.

Alright, that may be in the context of a website. But it all the more holds true on mobile. Attention span on mobile is shorter than you think and an article by The Telegraph agrees too!

Snap Horizontal Scrolling

This is a technique that prevents freeform scrolling. Although not entirely. Here's a GIF that will explain it better.

Here, can you see horizontal scrolling is snapped? Whenever the user scrolls horizontally, the next item becomes slightly visible. This is a subtle hint that even after scrolling, there's more content available. Although this is hardly noticeable, its a great tip to keep in mind. It's a very subtle, yet powerful hint that indicates whether there is more content or not.

Indicate the starting and ending of a list

Agreed that when the scrolling stops, we know we’ve reached the end of the list. But unless we scroll, we don’t know right? Android uses a neat animation to denote the end of a list. But that’s only when the user scrolls. Which means the user finds out AFTER they have scrolled. Image Credits: Stack Overflow Would you expect your users to scroll to find out? Wouldn’t it be better if you could visually indicate that too? Use extra spacing to denote the end of a list. This is the extreme left and right.

Indicate Vertical Scrolling too

Assume your app supports both horizontal and vertical scrolling. We’ve already discussed leaving visual hints indicating horizontal scrolling. How do you indicate vertical scroll? Websites indicate a vertical scrollbar on the side. But what about mobile? Here’s a neat trick you can use, although not seen in many apps. Use a light faded scrim at the bottom.

Don’t confuse Tabs with Horizontal Lists

Let me put this one bluntly. Assume your app has Tabs and one of them includes a horizontally scrolling list. Say, something like this.

How do you switch between Tabs? You swipe. Horizontally. How do you scroll the list? Horizontally. Can you see that one gesture is used for two different actions? When used in Tabs, differentiate between horizontal scrolling and swiping. You don't want users to scroll to the end of a horizontal list, and then be taken to the next Tab. So what can we do? The easiest solution is to disable horizontal Tab swiping. The hardest solution is to rethink your navigation.

Horizontal List Alternative

The very purpose of a horizontal list is to show similar content that belongs to a particular category. Most apps who do this, display N scrollable items for a category. The remaining contents are hidden behind the SEE ALL button. So either way, you’re not showing ALL contents of a category. Assuming you display 10, users will have to tap ‘See All’ to view the remaining 50 plus whatever contents. If that’s what your horizontal list does, you don’t need a horizontal list at all.

Use a Grid instead

With no horizontal scrolling, users can now skim through your content faster. They just have to scroll in one direction. Vertically. We have already seen how Tablet designs adapt to this.

The second example is even better. Google Play Music app does it very well. It shows 4 contents of a playlist, collaged together. You can access other music in the playlist by directly tapping the thumbnail itself.

There are two advantages to this design decision:

you retain the user’s natural flow of consuming content
a user sees more initial content, than what a horizontal list shows

Speaking of the second point, you may argue that a horizontal list shows more. Okay, I agree. But you need to scroll to see that don’t you? The point of an alternative is for you to rethink. Do you really need those nested, horizontal scrolling lists? Users naturally scroll vertical by default. I say this multiple times because anything that breaks this flow, breaks the ability to skim quickly through content. So before you decide upon horizontal lists, it's worth weighing its negatives. Otherwise, before going with it, you can always try one of the methods above.

Tip for Android Devs.

Embedding a horizontally scrollable list in a vertical parent list is hard. In other words, nesting RecyclerView is easy to do, but difficult to get it right. But don’t sweat it. Nick Butcher has done this for Google’s I/O 2016 app and open-sourced it! It includes some neat performance tweaks too. You can see it on GitHub.

TL;DR If you want to display different categories of a content, consider using horizontal lists. However, don’t include it in screens that belong to Tabbed navigation.

Conclusion

Today, content-heavy apps use nested scrolling with horizontal lists. While that's not wrong, it's implementation must be right. Horizontal scrolling feels more intuitive on mobile due to gestures. But use it with caution, because it breaks our natural flow of consuming content. Which is reading vertically. So make sure you have good reason to include it in your app. Remember at the start of this article, we talked about Google’s Play Store app. We also saw why using a horizontal list is suitable in their scenario. As UI/ UX designers, it's our responsibility to ensure that we don't confuse users. After all, scrolling is the most fundamental and highly-used gesture on mobile!

Android Image Gallery App: Using Gestures and Transition

Tue, 25 Apr 2017 00:00:00 GMT

In this post, we'll look at creating a Material Design style, image Gallery app for Android. It will support image gestures like zoom, as well as shared element transitions. This is part two of the Create an Image Gallery App with Android Studio and Glide post. Previously, we created an Image Gallery app using Glide and Android Studio templates. If you're not familiar with the basics, I strongly recommend you read part one. It will give you a solid understanding of Glide and Layout Managers. One of the most commonly used apps on Android is the image gallery app. Have you ever wondered, how images are displayed in a continuous list? What about using gestures such as pinch zoom on images? In this post, we will learn how to implement exactly these. We will also take a dive into shared element transitions and learn how to use it for Fragments. We will also use a custom view called PhotoView which can be used in placed of the regular ImageView. I'll show you how awesome PhotoView is soon.

Creating the Image Gallery App

We will be using 2 popular libraries in our gallery.

Glide - powerful, yet simple to use image loading library by Square.Inc
PhotoView - flexible ImageView that supports gestures such as zoom and pan

So first, let's start by adding the above dependencies. Add the following lines to your app's build.gradle file.

repositories {
maven { url "https://jitpack.io" } } dependencies {
...
compile 'com.squareup.picasso:picasso:2.5.2'
compile 'com.github.chrisbanes:PhotoView:2.0.0' }

First off, we need to create a model class for our images.

public class ImageModel implements Parcelable {

private String name, url;

//TODO: Add your Getters and setters here. }

Next up, we need to create our Activity. The only one that we will be using in this Android tutorial. We will use Fragments to handle everything else. We will create an 'Empty Activity' using Android Studio. Let's call it MainActivity as per convention.

Utility class for Image loading

Before we go ahead and code, we'll create a utility class. This will provide us with the image data. We could keep this code inside an Activity too, but using a separate utility class helps keep our code clean.

public class Utils {

    static String IMGS\[\] = {
            "https://images.unsplash.com/photo-1444090542259-0af8fa96557e",
            "https://images.unsplash.com/photo-1439546743462-802cabef8e97",
            "https://images.unsplash.com/photo-1441155472722-d17942a2b76a",
            .
            //more image links
    };

    public static ArrayList<ImageModel> getData() {
        ArrayList<ImageModel> arrayList = new ArrayList<>();
        for (int i = 0; i < IMGS.length; i++) {
            ImageModel imageModel = new ImageModel();
            imageModel.setName("Image " + i);
            imageModel.setUrl(IMGS\[i\]);
            arrayList.add(imageModel);
        }
        return arrayList;
    }
}

Defining Click Interface for Gallery Images

To handle clicks on images in the gallery, we will create a simple interface. This will help listen to click events.

public interface GalleryItemClickListener {
    void onGalleryItemClickListener(int position, ImageModel imageModel, ImageView imageView);
}

Creating the Image Gallery Adapter

Next, we need to create an adapter that will handle the RecyclerView data and display it. RecyclerView offers powerful list and grid display options via LayoutManager. You can learn about RecyclerView's LayoutManager via the Staggered Grid article. So here's how we define our RecyclerView.Adapter. It's very basic. Almost like how every standard adapter would be.

public class GalleryAdapter extends RecyclerView.Adapter<GalleryAdapter.GalleryViewHolder> {

    private final GalleryItemClickListener galleryItemClickListener;
    private ArrayList<ImageModel> galleryList;

    public GalleryAdapter(ArrayList<ImageModel> galleryList, GalleryItemClickListener galleryItemClickListener) {
        this.galleryList = galleryList;
        this.galleryItemClickListener = galleryItemClickListener;
    }

    @Override
    public GalleryViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
        return new GalleryViewHolder(LayoutInflater.from(parent.getContext())
        .inflate(R.layout.gallery_item, parent, false));
    }

    @Override
    public void onBindViewHolder(final GalleryViewHolder holder, int position) {
        final ImageModel imageModel = galleryList.get(position);

        Glide.with(holder.galleryImageView.getContext()).
                load(imageModel.getUrl())
                .thumbnail(0.5f)
                .diskCacheStrategy(DiskCacheStrategy.ALL)
                .into(holder.galleryImageView);

        holder.galleryImageView.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                galleryItemClickListener.onGalleryItemClickListener(holder.getAdapterPosition(), imageModel, holder.galleryImageView);
            }
        });
    }

    @Override
    public int getItemCount() {
        return galleryList.size();
    }

    static class GalleryViewHolder extends RecyclerView.ViewHolder {
        private ImageView galleryImageView;

        GalleryViewHolder(View view) {
            super(view);
            galleryImageView = (ImageView) view.findViewById(R.id.galleryImage) ;
        }
    }
}

The layout of the RecyclerView items is as follows.

<ImageView xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/galleryImage"
android:layout_width="match_parent"
android:layout_height="128dp"
android:layout_margin="1dp"
android:adjustViewBounds="true"
android:scaleType="centerCrop" />

Nothing fancy till now. We have created a regular RecyclerView.Adapter. This uses an interface to handle click events. Then we use Glide to load the image into our ImageView. You can however save yourself trouble and NOT write RecyclerView.Adapter boilerplate code. Learn to use FastAdapter to write easier, smaller and faster RecyclerView Adapter code.

Using Fragments instead of Activities

Now that our Adapter is complete, we need to create a Fragment to hold our RecyclerView.

public class RecyclerViewFragment extends Fragment {

public static final String TAG = RecyclerViewFragment.class.getSimpleName();

public RecyclerViewFragment() {
}

public static RecyclerViewFragment newInstance() {
    return new RecyclerViewFragment();
}

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

}

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
                         Bundle savedInstanceState) {
    return inflater.inflate(R.layout.fragment_recycler_view, container, false);
}

@Override
public void onViewCreated(View view, @Nullable Bundle savedInstanceState) {
    super.onViewCreated(view, savedInstanceState);
    GalleryAdapter galleryAdapter = new GalleryAdapter(Utils.getData(),this);
    RecyclerView recyclerView = (RecyclerView) view.findViewById(R.id.recycler_view);
    GridLayoutManager gridLayoutManager = new GridLayoutManager(getContext(), 2);
    recyclerView.setLayoutManager(gridLayoutManager);
    recyclerView.setAdapter(galleryAdapter);
}

}

In the onViewCreated() method, we create our RecyclerView.Adapter (GalleryAdapter). Notice that Utils.getData() provides a list of images which we populated. Next, we create a GridLayoutManager which consists of two columns. Finally, we attach the adapter and LayoutManager to RecyclerView. Another type of GridLayoutManger is the StaggeredGridLayoutManager. The Pinterest Android app uses this and you can learn how to do it too. Here's the Fragment XML layout.

<android.support.v7.widget.RecyclerView
    android:id="@+id/recycler_view"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:clipToPadding="false" />

Now, let's launch the RecyclerViewFragment from our MainActivity.

public class MainActivity extends AppCompatActivity {

@Override
protected void onCreate(Bundle savedInstanceState) {

    getSupportFragmentManager()
            .beginTransaction()
            .add(R.id.content, RecyclerViewFragment.newInstance())
            .commit();
}

}

Our gallery view is ready. Now if you run the code, you should get something like this

Launching Full-screen Gallery Images

Now we will start implementing the view where can see the images in fullscreen. We will use a Fragment to display each image. Let's call this Fragment ImageDetailFragment.

public class ImageDetailFragment extends Fragment {

private static final String EXTRA_IMAGE = "image_item";

public ImageDetailFragment() {
    // Required empty public constructor
}

public static ImageDetailFragment newInstance(ImageModel image) {
    ImageDetailFragment fragment = new ImageDetailFragment();
    Bundle args = new Bundle();
    args.putParcelable(EXTRA_IMAGE, image);
    fragment.setArguments(args);
    return fragment;
}

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
}

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
                         Bundle savedInstanceState) {
    return inflater.inflate(R.layout.fragment_image_detail, container, false);
}

@Override
public void onViewCreated(View view, @Nullable Bundle savedInstanceState) {
    super.onViewCreated(view, savedInstanceState);

    final ImageModel image = getArguments().getParcelable(EXTRA_IMAGE);

    final PhotoView imageView = (PhotoView) view.findViewById(R.id.detail_image);
  
    Glide.with(getActivity())
            .load(image.getUrl())
            .asBitmap()
            .into(new SimpleTarget<Bitmap>() {
                @Override
                public void onResourceReady(Bitmap resource, GlideAnimation<? super Bitmap> glideAnimation) {
                    startPostponedEnterTransition();
                    imageView.setImageBitmap(resource);
                }
            });
}

}

The layout for fragment_image_detail.xml is as follows.

<com.github.chrisbanes.photoview.PhotoView xmlns:android="http://schemas.android.com/apk/res/android" android:id="@+id/detail_image" android:layout_width="match_parent" android:layout_height="wrap_content" android:adjustViewBounds="true" android:scaleType="fitCenter" />

Adding Gesture Support to ImageView

Here is where we make use of the awesome **PhotoView**.

PhotoView allows us to add like features pinch to zoom, double tap to zoom. We use PhotoView in place of ImageView and that's it. We'll have a functional ImageView that supports gestures. Pretty easy right?

A word of caution

Notice that we didn't load the image from URL into ImageView. The image is first downloaded as a Bitmap and then loaded into ImageView.

This is a restriction imposed when we use PhotoView along with Glide. But don't worry, it's a tiny workaround for an amazing result!

Swiping Images in Fragment - ViewPager

To get swipeable slides of images likes the one seen in galleries, we can use a **ViewPager**. It is a widget available in the Android Support Library. Just like we need an adapter for a RecyclerView, we need one for our ViewPager too. Let's name ours GalleryPagerAdapter.

public class GalleryPagerAdapter extends FragmentStatePagerAdapter {

private ArrayList<ImageModel> images;

public GalleryPagerAdapter(FragmentManager fm, ArrayList<ImageModel> images) {
    super(fm);
    this.images = images;
}

@Override
public Fragment getItem(int position) {
    ImageModel image = images.get(position);
    return ImageDetailFragment.newInstance(image);
}

@Override
public int getCount() {
    return images.size();
}

}

In the getItem() method, you can see that it returns an instance of ImageDetailFragment.

This is how ViewPager works. They contain a series of Fragments of the same type. That's what allows us to swipe across various slides (images in our case).

ViewPager creates 3 instances of the Fragment to display, every time we view a slide. One to the left of the current slide and one to the right. Such a mechanism ensures a smooth scroll between slides. The good news is that this is internally handled. So you don't have to worry about it.

Ideally, we use ViewPager along with Tabs. This tutorial can teach you how to use Android ViewPager with Material Design Tabs.

Now the final piece left for our image gallery app is the Fragment to handle the ViewPager. We will call it GalleryViewPagerFragment.

public class GalleryViewPagerFragment extends Fragment {

private static final String EXTRA_INITIAL_POS = "initial_pos";
private static final String EXTRA_IMAGES = "images";

public GalleryViewPagerFragment() {
}

public static GalleryViewPagerFragment newInstance(int current, ArrayList<ImageModel> images) {
    GalleryViewPagerFragment fragment = new GalleryViewPagerFragment();
    Bundle args = new Bundle();
    args.putInt(EXTRA_INITIAL_POS, current);
    args.putParcelableArrayList(EXTRA_IMAGES, images);
    fragment.setArguments(args);
    return fragment;
}

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
}

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
                         Bundle savedInstanceState) {
    // Inflate the layout for this fragment
    return inflater.inflate(R.layout.fragment_gallery_view_pager, container, false);
}

@Override
public void onViewCreated(View view, @Nullable Bundle savedInstanceState) {
    super.onViewCreated(view, savedInstanceState);

    int currentItem = getArguments().getInt(EXTRA_INITIAL_POS);
    ArrayList<ImageModel> images = getArguments().getParcelableArrayList(EXTRA_IMAGES);

    GalleryPagerAdapter galleryPagerAdapter = new GalleryPagerAdapter(getChildFragmentManager(), images);
    ViewPager viewPager = (ViewPager) view.findViewById(R.id.animal_view_pager);
    viewPager.setAdapter(galleryPagerAdapter);
    viewPager.setCurrentItem(currentItem);
}

}

In onViewCreated(), we create a ViewPager object. Then we set an instance of GalleryPagerAdapter as its Adapter.

Handling Clicks; Launching the Detail View

Now that all the required classes have been created, we have one tiny thing left. Yes, you guessed it right. We have to launch the ViewPager when an image in the gallery view is clicked. That's really simple. We need to use the onGalleryItemClickListener interface. So go ahead and implement that in RecyclerViewFragment.

public class RecyclerViewFragment extends Fragment implements GalleryItemClickListener{

public static final String TAG = RecyclerViewFragment.class.getSimpleName();

@Override
public void onGalleryItemClickListener(int position, ImageModel imageModel, ImageView imageView) {

    GalleryViewPagerFragment galleryViewPagerFragment = GalleryViewPagerFragment.newInstance(position, Utils.getData());

    getFragmentManager()
            .beginTransaction()
            .addToBackStack(TAG)
            .replace(R.id.content, galleryViewPagerFragment)
            .commit();
}

}

Since we're working with Fragments, the back press by default works for Activity only addToBackStack() remembers the Fragment we added. So now when we press the Back button, we go back to the gallery view, instead of exiting the app. That's it! You have now created a fully functional image gallery app. We saw how to display images from the internet using Glide. Additionally, we also added gesture capability such as zoom and pan using PhotoView.

Shared Element Transition

Lastly, don't forget that I promised animations. Material Design brought in a new type of transition called Shared Element Transition.

The transition focuses on content and its representation in the new activity. Such a transition makes the experience a lot more seamless.

A transition when two screens (Activities or Fragments) share one or more common views. But, it is available only on API level 21 and above. Remember this. You need to properly setup an Android project theme styles to use Material Design. Alternatively, you can use this free Material Design starter project. It has everything configured, so you can start building your app right away. So let's get started and add shared element transitions to our gallery app. The way shared element transitions work is that a shared view has a unique transition name. This allows the view to be shared during the transition. We add this transition name in the GalleryAdapter.

public class GalleryAdapter extends RecyclerView.Adapter<GalleryAdapter.GalleryViewHolder> {

@Override
public void onBindViewHolder(final GalleryViewHolder holder, int position) {
    final ImageModel imageModel = galleryList.get(position);

    // Set transition name same as the Image name
    ViewCompat.setTransitionName(holder.galleryImageView, imageModel.getName());

    holder.galleryImageView.setOnClickListener(new View.OnClickListener() {
        .
    });
}

}

We set the transition name as the image name. This ensures that the transition name is unique for all the images in the gallery.

When we call our ViewPager from the RecyclerView, we need to mention the shared View. In other words, the View being shared with the ViewPager. We do this by using the addSharedElement() method.

public class RecyclerViewFragment extends Fragment implements GalleryItemClickListener{

@Override
public void onGalleryItemClickListener(int position, ImageModel imageModel, ImageView imageView) {
    GalleryViewPagerFragment galleryViewPagerFragment = GalleryViewPagerFragment.newInstance(position, Utils.getData());

    getFragmentManager()
            .beginTransaction()
            .addSharedElement(imageView, ViewCompat.getTransitionName(imageView))
            .addToBackStack(TAG)
            .replace(R.id.content, galleryViewPagerFragment)
            .commit();
}

}

The addSharedElement() method takes a View and its transition name as parameters. So now we have told our FragmentManager about the transition. Next, we have to notify the ImageDetailFragment about the transition. We also need to include a parameter for the transition name.

public class ImageDetailFragment extends Fragment {

private static final String EXTRA_TRANSITION_NAME= "transition_name";

public static ImageDetailFragment newInstance(ImageModel image, String transitionName) {
    ImageDetailFragment fragment = new ImageDetailFragment();
    Bundle args = new Bundle();
    args.putParcelable(EXTRA_IMAGE, image);
    args.putString(EXTRA_TRANSITION_NAME, transitionName);
    fragment.setArguments(args);
    return fragment;
}

@Override
public void onViewCreated(View view, @Nullable Bundle savedInstanceState) {
    super.onViewCreated(view, savedInstanceState);

    String transitionName = getArguments().getString(EXTRA_TRANSITION_NAME);

    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
        imageView.setTransitionName(transitionName);
    }

    ...
}

}

That's it. Our shared element transition should work. But wait, there is a small glitch!

Achieving Smoother Transitions

If you run the app now, you will notice that we do not get any smooth transition. This is because it is overridden by the default Fragment transition. So we need a way to delay the enter transition for the Fragments. We can do so in the onCreate() methods of ImageDetailFragment and GalleryViewPagerFragment.

 @Override
 public void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);
     postponeEnterTransition();
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {       
        setSharedElementEnterTransition(
              TransitionInflater.from(getContext())
                    .inflateTransition(android.R.transition.move)
              );
    }
}

You will notice that there's an API level check. This is done to ensure backwards compatibility. Remember that Shared Element Transitions are available only in API level 21+. And finally, our app is ready!

The source code for the app is available on GitHub.

Wrap up

In this post, we learnt how to create a gallery view step by step. We also learnt about PhotoView and how to use it in our app to get some amazing gesture support. We implemented shared element transition between our two screens to give the feel of a continuous UI. Did you like PhotoView? Will you be using shared element transitions in your app? I would love to hear from you in the comments below.

Design Techniques to Display Text over Background Images

Tue, 11 Apr 2017 00:00:00 GMT

It's become popular to overlay text labels on background images. But the image could be anything. How does your user interface design accommodate that? Can text overlay remain readable always?

The last thing you'd want is your users straining to read such text. This is all the more important on mobile. Smaller screens and smaller text make it slightly harder to read.

But don't worry. There are a couple of design techniques you can follow to ensure that.

First, let me show you some design mockups that use text overlay.

Photography Portfolio by Winart Foster on Dribbble

Here's another.

Article Cards Alternate by Oliur on Dribbble

A good eye will immediately notice the problem with these two designs. Take the second one with the sea waves. If the wave foam was on the lower half of the image, would that text be readable?

Let me try to recreate that design for you.

Text with scrim overlay

How readable is the text now?

Alright, its not the same picture. But it's still ocean waves.

The background image is outright disturbing. But the image is not to blame. After all, when you decide to overlay text, you must be ready for ANY image. Which means, the image could be anything.

Good design is when we factor in all possible scenarios.

Now don't get me wrong. Those 2 designs are not bad in any way. In fact, I love the typography used in the second one. Both are well-designed interfaces by talented people. It's just that, some interface designs (mockups) are only for aesthetic purposes.

Anyone who translates them into a working project will immediately recognize what's wrong. The text displayed, does not account for its background images.

However these mockups are only examples. It assumes that whatever be the image, the text will be readable. But my design attempt just showed you that that's not the case.

The 2-in-1 problem with text overlay

Now we could say that this pattern became overly popular thanks to Card design. I mean, most of the card designs include an image, with text overlaid on top. Not to say that its bad, but there are two things that are largely not considered.

Trip detail card by Harsheen Kaur

When you overlay text on an image, you sacrifice two things:

Image clarity
Text readability

Readability is the ease with which a reader can understand a written text. It is a measure of how easily a reader can distinguish individual letters or characters from each other. - Wikipedia

Overlaying a text prevents viewing the image completely. Moreover, your text may not be readable.

The image can be anything

Now, most of the examples above are mockups. Which means those are ideal scenarios. The text matches perfectly against its background. Things can immediately go wrong if your using white text over a whitish or light image. The same holds true for black or darker tones.

Now we know the mess we’re getting ourselves into. So let’s look at what we can do about it.

Text Overlay Solutions

There are different approaches to making our overlay text readable. I want you to understand that these are different solutions to a single problem. There is no single solution answer.

Moreover, deciding on what to use ultimately boils down to your personal preference. Or you can even decide upon one, depending on what fits your brand style.

1. Using a Scrim

A Scrim is a semi-transparent gradient layer that helps Text appear more readable against backgrounds.

A scrim is a solid to a transparent gradient that sits behind a Text Label. So for instance, your text label could be a constant white. Then, your scrim would be a gradient going from, say 40% black to transparent.

I leave the opacity percentage to you. Again that’s a matter of personal taste.

But a 40% black to transparent works really well. It's not too evident and doesn’t disturb the image. It fades smoothly, giving the text label the contrast it needs, making it readable.

Scrim - gradient overlay

Recommended Scrim guidelines:

40% opacity
gradient settings
height: 50% of image height

These are not hard rules. But as you can see from the above design, these settings work well.

You can read about this in the Material Design Imagery guidelines.

Scrim gradient settings in Sketch

Advantages:

Most simple and common solution
Increases contrast for better text readability
A subtle design change which is hardly noticeable

Disadvantages:

Sharp gradients can break the image's appeal
Can block the image if visibility is too high

By far, using a scrim is the most popular solution for solving the text overlay issue with images.

But wait, don’t go yet! There are other solutions which might suit your taste better.

2. Overlay the entire image

Like the scrim solution, and instead of a gradient, you’d apply a full 40% black to the whole image.

That’s right. Maybe the image isn’t important to you. The text label is your priority. Or maybe the text covers the entire image’s size.

In such a situation, using a scrim doesn’t make sense. Since the scrim is a gradient, your text becomes unreadable half-way across.

So since the text covers the whole image, the solution is to darken the entire image.

In short, that's a 40% opacity black on the image.

Advantages:

Useful for large text (headings?) that covers the entire image
When text is your priority and not the image

Disadvantages:

Can obscure the entire image
Could sacrifice image visibility
Can diminish the background image as if it exists only for aesthetics

Here are some popular apps that use this approach:

Medium Series on Android

85000+ Status and Quotes 2017 Android App by Pratik Butani

3. Color Overlay

This is like an overlay. But instead of using black or white to darken or lighten the image, we use a different color.

Setting a color overlay on an image is the perfect way to neutralize a busy image. It blocks out all the different colors, making the image monotone.

Here is an example.

Usually, the color of choice is the brand color.

Playgong App by Deividas Graužinis

If you have trouble deciding color, check out Canva's Color Wheel Tool. It uses color theory and color combinations in design to help you find colors that look good together!

4. Soft gradients

Remember that to use this correctly, your text should have enough contrast.

Also, when you use gradients, don't use visually jarring colors. Chose colors that work together in harmony.

You can use web tools such as Coolors and Kuler by Adobe. These can help you generate color pairs that work well together.

Here's an example.

Web Agency by Mohammad Shohag

Advantages:

Better brand emphasis (if brand color used)
Single color tone allows room for better text contrast

Disadvantages:

Not suitable for pictures of people as it may not be recognizable

5. Semi-Transparent Image

This technique involves using a semi-transparent image against a solid color background. It helps ‘calm’ the noisy background, so the text can stand out.

The technique consists of 3 layers (from the bottom):

Bottom - solid color
Middle - semi-transparent image (40% opacity)
Top - Text layer

Advantages:

Softer image allows text to stand out
Makes image monotone, reducing image noise

Disadvantages:

Image may lose important details
Only suitable for images whose purpose is eye candy

6. Blur

Applying a Gaussian blur softens an image allowing text to become more readable.

Smoothing of images by reducing image noise and detail - Gaussian Blur

iOS folks will be familiar with this technique. iOS design principles use blur to denote depth. Whereas Android (Material Design) uses shadows to denote depth (elevation).

Here's a 16px blur on the left, and 4px blur on the right. Make sure you don't blur the image too much that the underlying image is completely unrecognizable!

Blur doesn't solve same text and image color problem

Advantages:

Helps reduce the ‘busyness’ in images
Softened images allow text to stand out

Disadvantages:

Completely sacrifices the image for text
Still doesn't solve same-color overlay issue
May not suit your product style. Using blur in a Material Design world?

7. Text Highlight

Here, we apply a background color to the text itself. This effect mimics the traditional way of highlighting text on paper.

Text with Highlighter effect

This technique works well when the design has minimal text and a spacious background.

Remember that the highlight color doesn't always have to be black. The example on the right borrows the dominant color from the image. This creates a higher sense of belonging with the image.

Advantages:

Good text clarity against any background image
Good contrast

Disadvantages:

Choice of highlight color may make text feel disconnected from image
Can completely block the underlying image

8. Go Grayscale

Alright, this is more of altering the image than the text. But we can still use it to achieve what we want.

By using a grayscale image.

Greyscale image filter

However, remember that greyscale includes colors from the brightest white to the darkest black. These alone, are on the polar ends of vibrancy. Hence you might want to consider toning down the image first. You can do so via a mix and match with any other techniques mentioned here.

For example, here's a grayscale image with text at the bottom. However, by default this wouldn't look good. So we add a scrim at the bottom.

Greyscale image with bottom Scrim combined

Notice how the scrim naturally blends very well with the image. The image is greyscale and our scrim is a black to transparent gradient. Hence the two techniques go hand-in-hand, quite well.

9. Playing with color and positioning

Sometimes, no matter what, the image remains the same. Say, for example, a category page will use a constant header image depicting its category.

In such a situation, you know what image to expect. You can use this information to design your text. This can be the font, size, color or even positioning the text.

Universitet Modules by Flatstudio

Notice the smart positioning of text, away from images. Also, the calm pastel background colors are not distracting. Both work in favor of allowing the text to stand out in addition to the graphic.

TL;DR - Use enough contrast

The state of being strikingly different from something else in close association. - Contrast

Did you notice? All the techniques discussed above are ways to increase text contrast. Contrast is what makes an element appear distinct from one another. There should be high contrast between text and image. It allows text to be readable.

There is also no need to sacrifice image visibility for text. Both can coexist together if we use the right technique. For instance, using a scrim allows text to be readable. At the same time, the image is visible as well.

As a general rule, using greyscale colors work well. Which means, white text against a dark background. Or black (dark grey) text against a light background always works best.

Conclusion

We looked at techniques that make text readable, without sacrificing the background image. Techniques such as the scrim are perfect examples of this. Or, using a color overlay can help reinforce your brand by using its primary color. This is especially useful when the image feels out of place in your design. Moreover, the blur technique is useful as well. But you will have to see if it aligns with your design style.

Remember that good design is thoughtful and knows how to balance aesthetic visuals with usability and clarity. It is not enough to let people use your app. It must be easy and pleasing to use.

You can even mix and match two techniques. Your imagination is the limit. Color overlay with scrim anyone?

So which technique are you going to use? Have I missed any popular method? I'd love to hear your thoughts. Let's talk in the comments below.

Android O Tutorial: Using Custom Font Resources

Thu, 30 Mar 2017 00:00:00 GMT

One of the new features in Android O is using Custom Font Resources. In this Android Tutorial, let’s see how to use them in our apps. The first Android O Developer Preview just dropped. There’s a lot for us developers to know about. One of the highlights in Android O is the ability to use custom font resources. In this article let’s look at using custom fonts in our apps. Before Android O, how difficult was it to use a custom font in our apps? We had two options:

Write a custom View
Use a library

Both options need considerable effort, for just a simple font. Extending your custom View in EVERY layout.xml, instead of TextView is tedious. Moreover, using a third-party library for something basic as text, can be a risky call. How many times have you admired a beautiful font, and wanted to use that in your app? But the sheer thought of integrating it, made you feel it's not worth it? Well, not anymore! Seeing Android O giving official support to custom fonts brought a big smile to my face. I hope it did to you as well.

Getting Started with Font Resources

Android O supports custom fonts via font resources. The magic lies in the app/res folder.

Creating the font folder is easy. It is like every other resource such as menu, values, drawable, etc. So right click the res folder and create a new font folder.

Now you’re ready to drop in your fonts. So go ahead and pick a font of your choice. Font Formats Android O supports both .otf (OpenType) and .ttf (TrueType) font formats. I’m going to create a simple page design. Like a book, where the heading is a large serif font.

Using Custom Font Resources in Android O

For this Android O tutorial, I’m going to pick my fonts from Google Fonts. They have a great collection, so definitely check that out! My two font choices are:

Here are the available font styles for Merriweather. I'm happy with just the regular font so I'll take that alone.

You can download the .otf or .ttf fonts of your choice and drop them in the res/fonts folder. Note: Keep in mind, that resource files should use lowercase alphabets and underscores. For example, the downloaded font was Merriweather-Regular.ttf. When you copy it to the res/fonts folder, rename it to merriweather_regular.ttf. Once you drop in your custom font files in the fonts folder, you can preview your fonts. Simply double-click on a font, and Android Studio previews the typeface. Neat right?

We're going to need two fonts. One for the heading, and one for the body text. Look closely at the design above. The headline uses a serif font, while the content body is a sans-serif. In other words, the heading will use Merriweather while the content body will use Lato. Remember, I encourage you to use whatever you like. Feel free to experiment. I'm just using a simple example to show you what's possible.

Using Custom Fonts via XML

Head over to your XML layout file. Let's skip the layout design and go straight to using our fonts.

<TextView
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:fontFamily="@font/merriweather_regular"/>

Here's my simple TextView. All you need to use a font is ONE attribute, and you're good to go. Its really that easy!

android:fontFamily="@font/merriweather_regular"

Custom Fonts via Java

You can assign a font programmatically too. First fetch the font typeface. Then set it to your TextView.

Typeface typefaceLato = getResources().getFont(R.font.lato_regular);
mTextIntro.setTypeface(typefaceLato);

Additionally, you can even specify a basic font style such has bold, italic or a combination of the two.

mTextIntro.setTypeface(typefaceLato, Typeface.BOLD_ITALIC);

There's something interesting to note here. If you're using a font family, you'll have the same font, with different weight. You know what I'm talking about. If you download a font and extract the .zip file, you'll get multiple font variations like this.

So for example, assume I'm using Merriweather-Regular. If Iset the typeface style to bold, Android will choose Merriweather-Bold from my font-family and display that. Now that I've dropped a hint about font family, you might be wondering what exactly it is. So let's talk about that next.

Using a font family

As we've seen above, what if you want to use the same font in its different styles? Alright, maybe you can get away using the default Typeface style of bold or italic. But what if you want a thinner font? Thin and italic? When you downloaded the .zip file from Google Fonts, did you notice there wasn't just a single font? There was a multitude of them. All varying in weight or thickness. You can group all these different fonts, and use them together as a font family.

Creating a Font Family

You can do this in 3 easy steps.

1 Right click the res/fonts folder and create a new 'Font resource file'.

Add an element for EVERY font variation you wish to include. Let's go back to the design we're trying to do. Font styles that are thin, thick and in italics would be nice. So let's add three. I only wish to vary fonts for the body content. So let's add 3 font variations for Lato.

<font-family xmlns:android="http://schemas.android.com/apk/res/android">
    <font
        android:font="@font/lato_light"
        android:fontStyle="normal"
        android:fontWeight="300"/>

    <font
        android:font="@font/lato_regular"
        android:fontStyle="normal"
        android:fontWeight="400"/>

    <font
        android:font="@font/lato_bold"
        android:fontStyle="normal"
        android:fontWeight="700"/>
</font-family>

If you're unsure about the fontWeight, a quick look at Google Fonts will clear your doubts.

After that, using a single font from a font family is the same. Just reference them via the font attribute

android:fontFamily="@font/lato_black"

Just remember to first add all your font variations to the font folder. Then create a 'Font resource file'. Then add an element per font variation. Finally, reference your font style just like a regular single font.

Customizing Font Styles for Readability

Using the fonts outright on a TextView does not guarantee good readability. Take a look for yourselves.

Seriously, that’s bad. It hardly readable. Keep in mind that a smartphone is a small device, compared to a desktop or tablet. This makes it harder to read the text. So if your app’s priority is for users to read content. Then its also your priority to make sure the content is easy to read. The key lies in playing around with two attributes:

letterSpacing
lineSpacingExtra

So with that in mind, here are my TextView elements in the layout.

...
<TextView
    style="@style/TextAppearance.AppCompat.Headline"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:fontFamily="@font/merriweather_regular" />

<TextView
    style="@style/TextAppearance.AppCompat.Subhead"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:lineSpacingExtra="4dp"
    android:letterSpacing="0.08" />

<TextView
    style="@style/TextAppearance.AppCompat.Body1"
    android:layout_width="match_parent"
    android:letterSpacing="0.04"
    android:layout_height="wrap_content"
    android:fontFamily="@font/lato_regular"
    android:lineSpacingExtra="4dp" />
...

With these extra attributes, font should now be easy to read. See the difference for yourself. Its better right?

If you have a hard time remembering the different attributes, use the 'Design' Pane in the XML Editor. The 'Properties' pane on the right, lists all available attributes that you can change.

Final Results

Here's how the app finally looks like.

Now take a breather here and notice how easily this was. We used 3 different custom fonts without breaking a sweat. Using a font of your choice is as simple as drag and drop! Then, all it took was a single attribute to reference the font file. I've used merriweather_regular for the large title heading. The following introduction text is like a quote. That uses lato_bold, with Typeface.ITALIC.

Typeface typefaceLato = getResources().getFont(R.font.lato_bold);
mTextIntro.setTypeface(typefaceLato, Typeface.ITALIC);

Yes, such a mix and match is also possible.

SOURCE CODE: Available on GitHub

Where to from here?

Using custom Font resources is just one of the new features in Android O. You can read about the other Android O features here. While using custom fonts is something basic, its good to know its finally added. Also, it's relative ease of use makes this feature adoptable by many Android Developers. So what's your take on custom fonts? How are you using it? Let me know in the comments. Also, I'll be covering other new Android O tutorials in future articles. So don't forget to subscribe below.

Android O Preview: What Developers Need to Know

Wed, 29 Mar 2017 00:00:00 GMT

The Android O SDK (API 26) dropped recently and the internet went nuts! The Developer Preview SDKs brought along many new features. But these new SDKs are the pre-final ones. It's that time of the year when Android Developers like you and me need to keep up with what's latest. I usually refrain from writing about Developer Previews, until a stable release arrives. But it's better we get to know what's new now. Rather than coping with changes in the future. So transitioning our apps to Android O will be smooth when the time comes.

Trying Android O with Android Studio EAP

Android Studio EAP (Canary Channel)

Credits: tools.android.com

In this post, we'll first see how to setup Android Studio Preview. We need this to try out the new Android O Developer Preview SDKs. Google I/O 2017 released Android Studio 3.0. They also released Android O RC2. Hence this updated article will be using them. But don’t worry as I’ll walk you through that as well. We’ll install Android Studio EAP in parallel to your existing Android Studio. So nothing will get affected. Next, we'll install the Android O Preview SDKs. This includes the Preview SDKs itself, Support Libraries and a System Image.

As you can see from the release schedule. We no longer have to use the preview SDKs. The beta SDKs for API 26 (Android O) has been released. We will be using that from now on. Before setting up everything, let's see what Android O has to offer.

Some of the biggest features in Android O are:

1. Picture-in-Picture (PIP) support for Android Mobile

PIP was first introduced in Android Nougat. It became famous by the floating video player in YouTube. Just add the attribute android:supportsPictureInPicture attribute in your tag in AndroidManifest.xml. But, back then it was limited to Android TV. With Android O, they've finally brought it to smartphones as well. Goodbye DraggablePanel?

Learn how to use Picture-in-Picture in this Android O tutorial.

2. Custom Font support

No need to use a library or write a custom View. Drop in your fonts to res/fonts folder. Then you can use them with a single attribute.

android:fontFamily="@font/Merriweather"

Finally we can start seeing apps with less of Roboto! You can read the full tutorial on how to use custom font resources.

3. Autofill Framework

Users can save time filling out forms by using autofill in their devices

Long story short. Are you familiar with auto-filling forms in your web browsers? Remembering your passwords and credit card information to autofill it when required. That’s available on Android now. Sweet?

4. Notification Channels

Notifications are great. Every Android release made it better. But honestly, notifications are a spam-fest on our phones right now.

Notification Channels provide a unified system to help users manage notifications

In short, Notification Channels let you group your notification into broad categories. You can change the behavior of these broad notification categories in your settings.

Other little, but noteworthy changes

Adaptive Icons

Adaptive icons can help you integrate better with device UI, which can display a variety of shapes across different device models.

Honestly, I don't get the point of this feature. It started with Nougat wanting to make every icon round. But now this.

ProgressDialog deprecated Developer docs suggest a good UX tip. To use an inline ProgressBar in an Activity, instead of this modal dialog. But, you can take it a step further by using a better Progress Indicator called Skeleton Screen. Text Justification Spreads the typography over the full width. You just need one line and you're good to go.

textView.setJustify(true);

Directional Attributes No more padding top, bottom, left and right. Just paddingHorizontal and paddingVertical. Save yourself from writing two extra lines.

Credits to Cryil Mottier

for this

OpenJDK Features for Android O Some of the newly added packages include java.time and java.nio.file. You can read the complete Android O API differences report here. Smart Sharing Android O learns your preference and suggests relevant apps depending on what you’re sharing. For example, if you want to share a photo, Android might suggest social media apps. Now we're fully aware of what Android O has to offer. Time for us Android Developers to start preparing our apps for Android O.

How to Develop for Android O right now?

To access the preview, you must first download to Android Studio 3.0 Preview.

A word of caution: Keep in mind, we're using an unstable IDE. So make sure to update your SDKs and IDE as soon as an update is available. The official Android developer documentation explains how to setup Android O. I highly recommend you follow their guide first. You can safely install Android Studio Preview in parallel to your existing, stable Android Studio. In short, nothing gets affected. Android Studio Preview will safely use your existing SDK path. NOTE: As of now, you must use Android Studio preview. Otherwise many of the new features simply will not work!

Android O SDK Download

Open SDK Manager and download the Android O SDK (API 26). Notice that these are the almost-final SDKs that you can expect in production. In other words, these include API changes that will carry forward from now on.

Android O DP2 Install Checklist

But just in case, here's a quick checklist of everything you need to do:

Download and install Android Studio 3.0 Preview
Next, install Android 7+ (O) - SDK Platform 26
Download a preview image for emulator (Google Play Intel x86 Atom System Image). This includes Google Play Services
Download and install SDK Build-Tools 26
Update your SDK Tools(26.0.2) and SDK Platform-Tools (26.0.0)
Create a new project targeting Android O Preview
Check app/build.gradle if correct targetSdkVersion and Support libraries are used
Create a new AVD targeting Android O
Test your app by running it on the new AVD

The setup might look exhausting. But trust me, it took hardly an hour to do all that. Once you're done with all that, you'll need to update your Gradle plugin as well. So first, replace the **distributionUrl** in your gradle-wrapper.properties file.

distributionUrl=https\\://services.gradle.org/distributions/gradle-4.0-rc-1-all.zip

This gives you the latest Gradle version that you need to be using for API 26. Otherwise your project will fail to compile. Finally, cross-check your app/build.gradle file with mine.

apply plugin: 'com.android.application'

android {
    compileSdkVersion 26
    buildToolsVersion "26.0.0"
    defaultConfig {
        applicationId "com.iamsuleiman.androido"
        minSdkVersion 14
        targetSdkVersion 26
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
    // To take advantage of cool Java 8 features, like Lambdas!
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}

ext {
    supportLibVersion = "26.0.0-beta2"
}

dependencies {
    compile fileTree(dir: 'libs', include: \['\*.jar'\])
    ...
    compile "com.android.support:appcompat-v7:${supportLibVersion}"
    compile "com.android.support:design:${supportLibVersion}"
    compile "com.android.support:recyclerview-v7:${supportLibVersion}"
    ...
}

If you're gradle file is looking like this, then you're all set to play with Android O. Moreover, developer.android.com does a good job of walking you through. It is fairly simple. But, if you get stuck anywhere, feel free to drop a comment here or send me a Tweet. I’ll be happy to help.

What’s next?

With Android Studio 3.0 Preview setup, and the new SDKs downloaded, you’re good to go. You can compile and test your apps against Android O and check if everything works smoothly. Also, you can use this time to make your apps take advantages of the new features. For example, expect the Autofill Framework and Notification Channels to be widely used. Even if you don’t want to support Android O right now, it's okay. You can test drive the new SDKs and see what it has to offer. So what did you like about Android O? Did you notice the new changes from the previous release? My particular favourite is downloadable custom fonts. What’s your favourite feature? Did I miss anything? Tell me in the comments below.

Introduction to Google's Awareness API

Tue, 14 Mar 2017 00:00:00 GMT

A while ago, Google announced something really interesting called the Awareness API. According to Google Developers - Android Awareness API bridges the physical world of users, and the digital world of Android to help you build more assistive and context-aware apps.

The last sentence can be a bit confusing. So here are some examples that will help you realise how powerful the Awareness API is:

Imagine you pass by a pharmacy and your phone reminds you that you have to buy medicines. Or as soon you enter your car, your phone automatically connects to the car's Bluetooth and your navigation app opens up in driver mode. Cool right? Awareness API makes this really easy.

Credits: Google

What does the Awareness API mean for us?

The Awareness API unifies 7 location and context signals in a single API.

Context is at the heart of the Awareness API

Let's take a quick look at the 7 context types offered by the Awareness API.

Time: Current local time
Location: Latitude and longitude
Place: Place, including place type
Activity: Detected user activity (walking, running, biking)
Beacons: Nearby beacons matching the specified namespace
Headphones: Are headphones plugged in?
Weather: Current weather conditions

Why use the Awareness API?

One API to rule them all You just need to add a single API and you are set. No headache of using tonnes of different APIs.
Battery and Data Friendly The API takes care of managing your battery life and data usage so that you can concentrate on features crucial to your app.
Better context data Raw signals are processed for improved quality. For example, advanced algorithms are used to determine the user's activity with a high level of accuracy.

Set up

Awareness API is a part of Google Play Services and was introduced in v9.2. Let's configure our project to use the Awareness API. Create a project on Google Developer Console

Go to the APIs Library and search for Awareness API. Then click on it and Enable it.

Next, go to Credentials > Create Credentials > API Key > Android Key. Enter the name of your project and click create. You will now be given an API key. Copy it down somewhere. Next, in your Android Studio project, add the following dependency in app/build.gradle.

dependencies {
    ...
    compile 'com.google.android.gms:play-services-awareness:10.2.0'
}

Add the following code to the <application/> tag of your AndroidManifest.xml.

Remember to replace "YOUR_KEY" with the API Key you obtained. That's it! You are now ready to use the awesome Awareness API.

Fences and Snapshots

The Awareness API provides two distinct APIs:

Fences: Helps detect changes in user's context, or when certain context conditions are met. For example, show a notification when the user reaches a certain location. Or even when the user starts walking or running.
Snapshot: Let's your app request information related to the user's current context. For example, what activity the user is currently engaged in.

In short, the Snapshot API helps you detect and identify changes in environment. Whereas the Fences API helps you react to those changes. In this post, lets keep things simple and go through the Snapshots API alone. We'll talk about the Fences API in the next post.

Snapshot API

Remember the 7 context types we discussed early? It's time to dive into some code now.

1. Time

We can get the local time by using Android's Time API. Hence there is no separate function for Time in the Awareness API. But since we are diving into code, here's how you can get the locale time.

Date date = new Date();
DateFormat dateFormat = DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL);
Log.d(TAG, dateFormat.format(date));

2. Location

Get the user's coordinates. Since we are dealing with locations, we will need to make sure our app has Location permission. Here is a quick recap on how to handle runtime permissions on Android Marshmallow and above.

Awareness.SnapshotApi
		.getLocation(googleApiClient)
       .setResultCallback(new ResultCallback() {
           @Override
           public void onResult(@NonNull LocationResult locationResult) {
               if (!locationResult.getStatus().isSuccess()) {
                   Log.e(TAG, "Unable to get location");
                   return;
               }
               Location location = locationResult.getLocation();
               Log.i(TAG, "Latitude: " + location.getLatitude() );
               Log.i(TAG, "Longitude: " + location.getLongitude() );
           }
       });

The getLocation() method has a callback that returns a LocationResult object. Then, we can use the LocationResult object to get the user's latitude and longitude. For that, we use the methods getLatitude() and getLongitude().

3. Places

Get places around user's location. The following example shows getting a list of possible places:

Awareness.SnapshotApi.getPlaces(mGoogleApiClient)
             .setResultCallback(new ResultCallback() {
                 @Override
                 public void onResult(@NonNull PlacesResult placesResult) {
                     if (!placesResult.getStatus().isSuccess()) {
                         Log.e(TAG, "Could not get places.");
                         return;
                     }
                     List placeLikelihoodList = placesResult.getPlaceLikelihoods();
                     // Show the top 5 possible location results.
                     for (int i = 0; i < 5; i++) {
                         PlaceLikelihood p = placeLikelihoodList.get(i);
                         Log.i(TAG, p.getPlace().getName().toString() + ", likelihood: " + p.getLikelihood());
                     }
                 }
             });

To use the SnapshotAPI.getPlcaes() method, you must:

Enable the Google Places API for Android in your Google Developers Console project.
Add the android.permission.ACCESS_FINE_LOCATION permission to AndroidManifest.xml.

In case you are developing for Android Marshmallow and above, make sure to handle the runtime permission for location.

4. Activity

Get the activity the user is currently busy in by using the getDetectedActivity() method. The getDetectedActivity() method requires com.google.android.gms.permission.ACTIVITY_RECOGNITION permission. Add this permission to AndroidManifest.xml.

Awareness.SnapshotApi.getDetectedActivity(mGoogleApiClient)
        .setResultCallback(new ResultCallback() {
            @Override
            public void onResult(@NonNull DetectedActivityResult detectedActivityResult) {
                if (!detectedActivityResult.getStatus().isSuccess()) {
                    Log.e(TAG, "Could not get the current activity.");
                    return;
                }
                ActivityRecognitionResult ar = detectedActivityResult.getActivityRecognitionResult();
                DetectedActivity probableActivity = ar.getMostProbableActivity();
                Log.i(TAG, probableActivity.toString());
            }
        });

DetectedActivityResult.getActivityRecognitionResult() returns an ActivityRecognitionResult. We can use the following functions to get various data related to the user's activity

getMostProbableActivity() to get only the most probable activity
hasResult() to detect whether an Intent contains an ActivityRecognitionResult
getActivityConfidence() to return the confidence value for a given activity type.
getProbableActivities() to get a list of recent activities ranked by probability.

5. Weather

We can use SnapshotApi.getWeather() to get the weather conditions of the user's current location. The SnapshotApi.getWeather() method requires the android.permission.ACCESS_FINE_LOCATION permission. Add this permission to AndroidManifest.xml.

Awareness.SnapshotApi.getWeather(mGoogleApiClient)
                .setResultCallback(new ResultCallback() {
                    @Override
                    public void onResult(@NonNull WeatherResult weatherResult) {
                        if (!weatherResult.getStatus().isSuccess()) {
                            Log.e(TAG, "Could not get weather.");
                            return;
                        }
                        Weather weather = weatherResult.getWeather();
                        Log.i(TAG, "Weather: " + weather);
                    }
                });

6. Headphone

We can use SnapshotApi.getHeadphoneState() to detect whether headphones are plugged into the device or not. It returns a HeadphoneStateResult. We can then call HeadphoneStateResult.getHeadphoneState() to get the headphone status.

Awareness.SnapshotApi.getHeadphoneState(mGoogleApiClient)
                .setResultCallback(new ResultCallback() {
                    @Override
                    public void onResult(@NonNull HeadphoneStateResult headphoneStateResult) {
                        if (!headphoneStateResult.getStatus().isSuccess()) {
                            Log.e(TAG, "Could not get headphone state.");
                            return;
                        }
                        HeadphoneState headphoneState = headphoneStateResult.getHeadphoneState();
                        if (headphoneState.getState() == HeadphoneState.PLUGGED_IN) {
                            Log.i(TAG, "Headphones are plugged in.\n");
                        } else {
                            Log.i(TAG, "Headphones are NOT plugged in.\n");
                        }
                    }
                });

7. Beacons

We can use getBeaconState() to get information about nearby beacons. To use the getBeaconState() method, we need to:

Add android.permission.ACCESS_FINE_LOCATION to AndroidManifest.xml.
Activate the 'Nearby Messages API' for the Google Developers Console project.

We need to declare all the possible attachment's namespaces and types in a TypeFilter.

private static final List BEACON_TYPE_FILTERS = Arrays.asList(
        BeaconState.TypeFilter.with(
                "my.beacon.namespace",
                "my-attachment-type"),
        BeaconState.TypeFilter.with(
                "my.other.namespace",
                "my-attachment-type"));

If your beacon's attachment namespaceType is my-sample-project/mydata , my.beacon.namespace would be my-sample-project while my-attachment-type would be mydata. Then, we can get the state of the beacon using the following code.

Awareness.SnapshotApi.getBeaconState(mGoogleApiClient, BEACON_TYPE_FILTERS)
                .setResultCallback(new ResultCallback() {
                    @Override
                    public void onResult(@NonNull BeaconStateResult beaconStateResult) {
                        if (!beaconStateResult.getStatus().isSuccess()) {
                            Log.e(TAG, "Could not get beacon state.");
                            return;
                        }
                        BeaconState beaconState = beaconStateResult.getBeaconState();
                        // Get info from the BeaconState.
                    }
                });

Wrap up

In this post, we learnt about the Awareness API and its advantages. We also took a dive into the various context types provided by the Snapshots API. We even looked into some sample code to use each Context Type. In the next post, we will learn about the Fences API while building a nice sample app. So what are your thoughts on the Awareness API? Will you use it anytime soon? I would love to hear from you in the comments. Header image credits: Google Awareness API

Stop Using Loading Spinner, There’s Something Better

Tue, 28 Feb 2017 00:00:00 GMT

Stop using those boring loading spinners in your user interfaces. Seriously. It's killing your apps' experience more than you know.

A loading spinner might be the solution to your content loading problems. But I’m here to tell you that it's not.

You might even use some of those fancy animated loading Spinners. But they’re not any better either.

By Tobias Ahlin on Dribbble

Why Loading Spinner doesn’t work

From a long time we’re following, or rather influenced by hard rules from design languages. I don’t blame you, though.

The key to wisdom is this - constant and frequent questioning, for by doubting we are led to question and by questioning we arrive at the truth. - Peter Abelard

Loading Spinner is one of the most used progress indicators in user interface design. But it has its own flaws which are generally overlooked.

Facebook using Loading Spinners for image and Pagination

After staring at too many Loading Spinners

No sign of progress

What does the loading spinner tell you? It denotes that content is currently loading. But does it say how much has loaded? Does it say how much remains to load?

No, it doesn’t.

Moreover, it's difficult to determine. If it could, we’d be using a progress bar right?

That period of uncertainty

By Chanpory Rith on Dribbble

How long did you spend looking at that? Were you expecting some content to load after some time? I’m sorry to disappoint.

Ok, let’s assume that GIF loading actually completed and some content displays. Ask yourselves these questions and give me an honest response. I’m sure you’ve stared at enough Loading Spinners to know.

When you looked at the Loading Spinner, did you know how much time remains to complete?
How much of the content has loaded?
How much remains to load?

We simply sit staring at a Loading Spinner. Hoping that it loads in time, with no answer to either of those 3 questions.

Moreover, network connections might be unstable. So we can never take for granted that content will always load fast.

Perceived to be slower than actual

Loading Spinners make loading appear slower.

It's like a clock, constantly ticking. It shows the time you’re wasting by staring at it. Like that GIF above, which I made you stare at.

http://gph.is/1MoI2wJ

What comes next is a surprise

Until everything has loaded, do you have any idea what to expect on screen? I bet you don’t. You might even get surprised once the UI and content display.

Now think about your users. Until everything has loaded, they have completely no idea what to expect on screen. I bet they’ll get surprised too.

This won’t be their fault. You didn’t tell them what to expect in the first place!

A ‘Surprise’ isn’t always a good thing

An unexpected or astonishing event, fact, etc. - Surprise

From the very definition of the word, a surprise indicates an ’unexpected’ event. People tend to have polarizing reactions to such events. This could either positive or negative.

Surprises don’t often tend to leave a positive impact on people. Unless it's their birthday. It depends upon how a person takes it. Thus, herein lies the problem.

Before

After

Take a good look at both the images. See the image on the right. Could you honestly predict the UI would finally look like that? I’m sure not.

Alright, the final UI is a low fidelity design. But you get the point.

I deliberately did not pull examples from existing apps. Because you and I both know what it will look like. With a known app, we’ve already seen the interface, even before its loaded.

Emotions affect our sense of time

Did you know? We humans can actually predict time. That too quite accurately.

But under an emotional influence, our sense of time is significantly clouded.

http://gph.is/1XcuFKh

We’ve all experienced this. Time seems to fly when you’re doing what you love. But if it's something you hate, time seems to drag. Even when you’re bored, staring at the clock waiting for your favorite show. Time moves even slower then.

The same holds true for our interfaces.

The point I’m trying to make is. Your content might not take much time to load. In fact, it might not be a big deal. But it may appear longer than it actually takes. It is just how people might perceive it, and there’s nothing we can do to change it.

But what we can do, is help change their perception. We can make our app appear faster than it actually is.

NOTE
Don’t get too carried away trying to fake it. Your interface needs a combination of real and perceived speed to succeed.

The Illusion of Alternatives

Typically, we have two options to denote loading content:

Finite progress bar - if we can determine load times
Loading Spinner (infinite loading progress) - if load times are unknown

But take a closer look at the choices again. Do you realise, there is no real choice here?

We can't use a finite progress bar because we cannot measure load times. Also, we already know that the Loading Spinner is no good.

A good progress indicator

A good progress indicator is one which obviously doesn’t have any of the negatives I mentioned above. But for a more optimistic tone, let me list them out.

gives immediate feedback
provides a sense of time ( how much has progressed, and how much is pending)
removes doubt (gradual progress reassures people that the app is working)

Some proof as backup

Some of you might not believe what I said. But trust me. If I was me, I wouldn’t believe what I said either. After all, where is the proof? Do loading indicators really harm? Who has experienced it?

Well, then consider yourself lucky. You get to learn from someone else’s mistakes. The iOS app Polar strongly suggests avoiding the Spinner.

Image credits: TechCrunch

Polar received a lot of complaints about their app being slow. This was because of the loading spinners they included in their app.

With progress indicators, we had made people watch the clock. As a result, time went slower and so did our app. We focused on the indicator and not the progress, that is making it clear you are advancing toward your goal not just waiting around.
– Polar

I guess I’ve rambled enough about why Loading Spinners are bad. The problem with Spinner lies in not providing a sense of progress. Though, we can remedy this.

How, you ask? The answer is 'Skeleton Screens'.

Skeleton Screens to the rescue

Unlike Loading Spinners, where the UI displays all at once. A skeleton screen helps load a user interface gradually, a little at a time.

This means that the barebones UI displays first. Then the loaded content is gradually populated on-screen.

“A skeleton screen is essentially a blank version of a page into which information is gradually loaded.”
– Luke Wroblewski

LinkedIn recently started using Skeleton Screens for loading

Skeleton screens shift the attention of users. It makes people focus on the progress, rather than the wait time.

Skeleton screens visually tells users what to expect from the interface. It gives them a heads up on what's going to come and creates a sense of gradual progress.

Most of all, it makes people perceive your site to be faster than it actually is. Remember that we are designing interfaces for use by real people. We need to give people the illusion of speed.

The more the system gives information about the waiting time the better the satisfaction of the user.
– How to Improve Perceived Waiting Time in HCI

Using a skeleton screen gives you the following benefits:

Helps people perceive your screen to load faster
Eliminates surprises
Gradual loading of UI - clear indication of progress
Shows exactly what's loaded and what’s yet to load

Gradual Progression

I know it's a fancy term. What it means is, loading your content gradually. Folks from web design and development know this as ‘Lazy-loading’.

Defer initialization of an object until the point at which it is needed.
– Lazy Loading

First, lay out the bare bones UI (Skeleton screen). Next load the text data. The user knows they’ve received the content. Finally lazy load the images. The user understands that most of the content has loaded. What’s left are the images.

In this way, you’ve given users:

a clear sense of progress
what to expect next
what’s left to expect

Notice how Instagram intelligently handles loading here.

Instagram loading - gradual progression

First, Instagram shows a loading spinner for a brief period. Next, it lays out the barebones UI. This is the skeleton screen or Placeholder UI. This indicates the place will content will eventually fill.

Also, notice that the text data has already populated the screen. Finally, in the third screenshot, the images are gradually loaded into place.

Here are some websites that use skeleton screens to show loading.

Skeleton Loading used in Facebook

Loading seen on Medium.com

You might argue that these websites use Loading Spinners. But notice how it is used. A Spinner alone is not displayed from start to finish. It is shown only for a brief period, followed by the Skeleton Screen.

TIP
If your load time is longer, you can briefly display a Loading Spinner, before Skeleton UI. This can buy your task some more time to complete.

Progressive Loading for Images

You can even apply gradual progression to image loading. For example, Medium and Google use progressive loading for their images.

Progressive Loading in Google Image Search

Progressive Image Loading in Medium

I’m sure you’ve seen either one of these. Maybe you didn’t know it had a proper name until now.

Here are the generic steps on progressive loading for images.

Display the skeleton screen
Load a very low quality (pixelated) version of the image (or prominent color)
Load the high-quality image in background
Fade in the high-quality image, replacing the previous low-quality one

Of course, what to display first varies. Medium chooses to use an extremely small pixelated image and applies a blur filter over it. Later it loads a higher quality image to replace it. Whereas Google displays the image’s prominent color first.

Note that you’ve not given then a clear indication of WHEN the task will complete. There is still no solid time estimate. But you have told that what has completed and what remains. That itself is clear sign of progress.

Skeleton Screens on Android and iOS

You might argue saying most of the skeleton screen examples are websites. So how do I do this on mobile? You’re absolutely right. Reading all this wouldn’t be worth it if I didn’t even give you hint on how to do this.

Facebook has written a library called Shimmer for both Android and iOS.

It works just like how Facebook using skeleton UI to load incoming content. The shimmer animation depicts that content is currently loading.

Shimmer by Facebook

You can use this library to display skeleton screens to denote loading in your apps.

Handling Failure with Skeleton Screens

There’s no guarantee that a request will always execute successfully. So we cannot assume that if a content loads gradually, it will eventually complete. Chances are, it might fail mid-way. The most common reasons include faulty, slow or no connectivity.

Assume you’ve started a request to load content. Next, the skeleton screen is also displayed. Then suddenly, your internet goes off. How would you handle this?

Typically, you must inform the user and allow them to retry.

No internet connection by Dima Karpushin on material.uplabs.com

Remember that giving feedback is good interaction design and positive user experience.

Empty states occur when an item’s content can’t be shown.

TIP
Consider using ‘ Empty States ’. It allows you to provide clear feedback with a ‘Call to Action’ (CTA) button.

Reminders Empty State by Salman Hossain Saif

Connectivity in Android and iOS

Here are a couple of resources that can help you handle connectivity.

Android

Use Snackbar to provide feedback with CTA button
Connectivity - network handling class

iOS - Swift

iOS Alerts - collection of alert libraries to chose from
Reachability - network handling

Wrapping Up

Apps are getting smart. People are starting to realize that the Loading Spinner is hurting their UX. It's about time you did too.

Skeleton screens provide incremental progress in loading your interface. Such incremental feedback gives better user experience, and reduces uncertainty. Moreover, people would be willing to wait a bit longer.

So what do you think about Skeleton screens? Is it a viable alternative to a Loading Spinner? Let me know in the comments below.

Android App shortcuts - How and When to use them

Tue, 21 Feb 2017 00:00:00 GMT

App Shortcuts were introduced Android Nougat 7.1. They allow you to access primary actions of your app directly from the launcher icon. You can also pin certain shortcuts to the launcher for faster access. Consider you have the Uber app and you want to book a ride home. You would normally open up the app and then book a cab with your Home as the destination. Instead of doing all this, wouldn't it be great if a there was a shortcut right in your launcher that does all this in once click? That's exactly where App Shortcuts come in. In this post, we will learn how to easily implement App Shortcuts.

App shortcuts give users quick, easy access to up to four of your app’s actions. Each action can also be added to the home screen.

Image credits: Google

Design Guidelines

Google Design Guidelines

Before we start coding, it is essential to know the design guidelines for App Shortcuts:

The shortcut icons should have a total dimension of 48dp x 48dp
The Live Area (where your icon will reside) should be 44dp x 44dp
The Live area should have a solid background colour fill of Material Grey 100 (or #F5F5F5)
The icon should have dimensions of 24dp x 24dp at the centre for the Live Area
Shadows should NOT be included
The icon colour has a strong contrast with Material Grey 100

You can read more about the guidelines here.

There are 2 types of App Shortcuts:

1. Static App Shortcuts

These are generated using XML and can be updated only when the app is updated. Static App Shortcuts should be only be used for actions that are constant and core to the app. For example, the Twitter app provides shortcuts to start a Search, make a new Tweet, send a new message, etc. These actions are essential to the app and are not affected by user behaviour. Hence it makes sense to implement them as Static shortcuts.

Twitter app shortcuts

Adding a Static Shortcut

In AndroidManifest.xml, we have to add some <meta-data> to the launcher Activity. In practice, any Activity with the intent filter set to action android.intent.action.MAIN and category android.intent.category.LAUNCHER can be used for app shortcuts. In my <meta-data> tag, I have specified the name as android.app.shortcuts and resource as @xml/shortcuts.

@xml/shortcuts is the file where we define our static shortcuts. In your res directory, create another resource directory called xml if there already isn't one. Inside that directory, create an XML file called shortcuts.xml with the following contents.

Each shortcut that you define should be enclosed in a <shortcut> tag.

Attributes explained

android:enabled Boolean to enable or disable the shortcut. If a shortcut is disabled, it will not show up in the list of shortcuts in the launcher.NOTE: If the disabled shortcut was previously pinned, it will be greyed out and clicking on it will display the message specified by the string in android:shortcutDisabledMessage
android:icon Icon resource to display corresponding to the App Shortcut
android:shortcutId Unique identifier that allows Android to recognise your shortcut
android:shortcutShortLabel Your App Shortcut's text. It should be within 10 characters. Otherwise, it will be ellipsised.
android:shortcutLongLabel Label that is displayed when the shortcut is pinned to the launcher. It should have a max length of 25 characters.

Every <shortcut> needs to have at least one <intent> tag that specifies what action is to be taken when a shortcut is clicked. You can have multiple <intent> tags in the same shortcut but Android will handle this by using the last <intent>. It places all the previous intents in the backstack. That's all you need to get static shortcuts running.

2. Dynamic App Shortcuts

Telegram app shortcuts

Dynamic shortcuts can be generated and destroyed at runtime. They are used for actions customised to the user's behaviour. For example, the Telegram app provides shortcuts to your most frequented chats.

Adding a Dynamic Shortcut

In order to add, remove or update dynamic shortcuts, we need to use the ShortcutManager class.

ShortcutManager shortcutManager = getSystemService(ShortcutManager.class);

Let's create our Intent that will be used by our shortcut.

Intent intent = new Intent(this, DynamicShortcutActivity.class);
intent.setAction(Intent.ACTION_VIEW);

To create a new shortcut, we have to use ShortcutInfo.

ShortcutInfo dynamicShortcut = new ShortcutInfo.Builder(this, "dyanmicShortcut")
                .setShortLabel("Dynamic")
                .setLongLabel("Open dynamic shortcut")
                .setIcon(Icon.createWithResource(this, R.drawable.ic_dynamic))
                .setIntent(intent)
                .setRank(0)
                .build();

Here dyanmicShortcut is the id given to the shortcut. The setRank() method is used to position the shortcut in the list, 0(zero) being the lowest positioned one. Now that we have our shortcut ready, we need to set it as a Dynamic Shortcut.

shortcutManager.setDynamicShortcuts(Collections.singletonList(dynamicShortcut));

The setDynamicShortcuts() method takes an Array. Since we have only shortcut, I have a created a Singleton List. Finally, add an <intent-filter> to the DynamicShortcutActivity in AndroidManifest.xml

That's it, we're done! Now our Dynamic Shortcut is ready to roll. Run your app and long press the app icon in the launcher. You should see something like this:

App shortcuts demo

Disabling a Shortcut

To disable a certain dynamic shortcut, we can use the disableShortcuts() method. It takes an array of shortcut ids as parameter

shortcutManager.disableShortcuts(Collections.singletonList(dynamicShortcut));

NOTE: You can have a maximum of 5 App Shortcut. The number of shortcuts should be chosen carefully. Attempting to use more than 5 will result in a crash. Not all launchers support app shortcuts. Make sure to test in on launchers that have App Shortcuts support (like Nova launcher).

When not to use App Shortcuts

App shortcuts should be used only for the most commonly used features of the app. Let us consider WhatsApp as an example. The ideal shortcuts for it would be the 'most frequent chats'. This is where the user spends the most time on the app. Hence it makes sense to include them in the shortcuts. But it should not be used for actions like creating a new group as it is not a core or frequently used feature. Using shortcuts for actions the user does not use that often beats the point of having shortcuts altogether.

Final Result

Source Code: View Project on GitHub

Quick Recap

In this post, we learnt

What App Shortcuts are
How are Static and Dynamic Shortcuts different
Implementation of both types of shortcuts
When to avoid using App Shortcuts and why

What do you think about App Shortcuts? Have you implemented them in your apps? I'd love to hear from you in the comments. Don't forget to subscribe for some awesome posts coming soon.

Using Bottom Navigation View - Android Design Support Library

Tue, 31 Jan 2017 00:00:00 GMT

This tutorial is now updated for AndroidX!

Android Bottom Bar (Bottom Navigation View) was officially added in Design Support Library v25. Bottom Bar was first introduced in the Material Design guidelines.

Initially, it was met with some reception. People had polarizing opinions on it. Even I, was on the negative spectrum of thought.The fact that it had existed on iOS for so long, now felt like a poor rip-off for Android.

However, usability studies say that Bottom Navigation trumps the Navigation Drawer. That’s when I felt its introduction was actually, well thought of.

But irrespective of our opinions, Bottom Navigation is here to stay. It is now officially supported in Android’s Design Support Library, as of version 25.0.0.

Bottom Navigation Bar - Getting Started

Bottom navigation bars make it easy to explore and switch between top-level views in a single tap. – material.io

Bottom Navigation in Google+ app

Bottom Navigation in Instagram Android app

Some of you might wonder why I’m writing another post on Bottom Navigation.

When Bottom Navigation was added to the Material Design spec, there was no official support for it. This paved way for (unofficial) third-party libraries.

Now I’m not saying those libraries are bad in any way. Those who know me, will know that I encourage using third-party libraries when possible.

READ
Easy Bottom Navigation Tutorial with a custom library

The above article includes:

Easy third-party implementation
when to use Bottom Navigation and the difference with Navigation Drawer
transition animations

However, if you want to use the official libraries (which are equally good, if not, better), read on below!

The Design Support Library is so popular, chances are that you’re already using it. Since it now includes BottomNavigationView, it might make little sense to rely on third-party.

Adding Dependencies

Start by adding the relevant support library dependencies.

dependencies { ... implementation 'androidx.appcompat:appcompat:1.1.0' implementation 'com.google.android.material:material:1.0.0' // Other Dependencies }

Adding BottomNavigationView to Layout

Now, add the Bottom Bar to your layout.xml.

<com.google.android.material.bottomnavigation.BottomNavigationView android:layout_width="match_parent" android:layout_height="wrap_content" android:layout_gravity="bottom" ** app:itemBackground="?attr/colorPrimary" ** app:itemIconTint="@drawable/selector_bottombar" app:itemTextColor="@drawable/selector_bottombar" app:menu="@menu/bottombar_menu"/>

I’ve taken the liberty to add some basic styling here. As you can see, we’re allowed to set a few basic color properties.

UX DESIGN TIP
Remember to keep your non-active tab items (icon+text) visible at all times so people know what they are, even when its not active.

Adding Bottom Navigation Items

Create a new bottombar_menu.xml under …res/menu/.

bottombar_menu.xml

 <item
    android:id="@+id/bottombaritem_calls"
    android:icon="@drawable/ic_call_24dp"
    android:title="Calls"
    app:showAsAction="ifRoom"/>

<item
    android:id="@+id/bottombaritem_recents"
    android:icon="@drawable/ic_query_builder_24dp"
    android:title="Recents"
    app:showAsAction="ifRoom"/>

<item
    android:id="@+id/bottombaritem_trips"
    android:icon="@drawable/ic_flight_24dp"
    android:title="Trips"
    app:showAsAction="ifRoom"/>

NOTE
It is recommended to have at least 3, and at most 5 items in Bottom Navigation.

Connecting Bottom Navigation in Activity.java

Head over to your Activity.java. Initialize your UI.

public class BottomBarActivity extends AppCompatActivity {

private BottomNavigationView bottomNavigationView;
...

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_bottom_bar);

    bottomNavigationView = findViewById(R.id.bottom_nav);

  ...
}

... }

Listen for Item clicks

We can listen and react to individual item clicks of Bottom Navigation. We do this using BottomNavigationView. setOnNavigationItemSelectedListener().

bottomNavigationView.setOnNavigationItemSelectedListener( new BottomNavigationView.OnNavigationItemSelectedListener() { @Override public boolean onNavigationItemSelected(@NonNull MenuItem item) { switch (item.getItemId()) { case R.id.action_bottombar_calls: // TODO return true; case R.id.action_bottombar_recents: // TODO return true; case R.id.action_bottombar_trips: // TODO return true; } return false; } });

Now we have a basic Bottom Navigation set up for our app. Why not run it and see how it looks?

Our Bottom Navigation seems to register clicks. But something seems off. Did you notice?

Our very first navigation item ‘Calls’ is selected by default alright.

But something doesn’t seem right

I don’t know about you, but I don’t see any state difference.

Meaning, visually, there’s hardly any difference between items that are resting, and the active item. In short, there is not enough visual contrast to differentiate the two.

Take a good look at our Bottom Navigation. Now see how it looks like on the Material Docs.

Image credit - material.io

Surely both don’t look the same!

Something has to be done about that. We can quickly take care of this by using XML selectors.

Bottom Navigation Styling - Selector States

Going by our XML, our Bottom Nav's background is colored. We want to light up our active item with 100% white and want the inactive ones dim. So let's say the inactive tab items are at 40% white. Here is the XML selectors for the same.

Create selector_bottombar_item.xml under …res/drawable/.

Modify your Activity’s BottomNavigationView widget to use this selector.

...
<com.google.android.material.bottomnavigation.BottomNavigationView android:id="@+id/bottom_nav" ... app:itemIconTint="@drawable/selector_bottombar" app:itemTextColor="@drawable/selector_bottombar" app:menu="@menu/bottombar_menu"/> ...

Run your app again.

Much better right?

Before moving onto the next section, why don’t you take a breather?

Creating Screens for Bottom Navigation Items

If you recall the guidelines, BottomNavigationView navigates between top-level views.

Think carefully, the top-level view(s) here would be the visible space above the Bottom Navigation.

This visible space must reflect the currently active Bottom Navigation Item.

So if the ‘Calls’ item is currently active (highlighted or selected) in our Bottom Navigation, then the visible space must show the Calls screen.

We can do this using Fragment.

Let’s hook up our BottomNavigationView with some Fragments.

Creating Fragments

For simplicity, I will use a single Fragment, with slight UI changes that denote each navigation item.

Create class BottomBarFragment.java. The only thing that I’ll be doing here is include a TextView. It will reflect the name of the current Bottom Navigation item.

public class BottomBarFragment extends Fragment { public static final String ARG_TITLE = "arg_title"; private TextView textView;

...

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
                         Bundle savedInstanceState) {
    View rootView = inflater.inflate(R.layout.fragment_bottom_bar, container, false);

    textView =  rootView.findViewById(R.id.fragment_bottom_bar_text_activetab);

    String title = getArguments().getString(ARG_TITLE, "");
    textView.setText(title);
  ...
    return rootView;
}

}

Layout Design
Here’s what I’ve created. Something simple enough where the TextView denotes the current active navigation item.

fragment_bottom_bar.xml

Modifying Activity layout to support Fragments

Go back to your Activity’s XML layout. We need a FrameLayout that will host our Fragment.

<FrameLayout
    android:id="@+id/frame_fragmentholder"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:layout_marginBottom="?attr/actionBarSize"/>

<com.google.android.material.bottomnavigation.BottomNavigationView />

Inflating Fragments

Go back to BottomBarActivity.java. We need to do 2 things.

1. Build a list of our Fragments. One for each Navigation item

Declare a List<BottomBarFragment> of Fragments that will hold all the Fragments for our Bottom Navigation.

private List fragments = new ArrayList<>(3);

We need a List of size 3 since our Bottom Navigation contains 3 items.

private void buildFragmentsList() { BottomBarFragment callsFragment = buildFragment("Calls"); BottomBarFragment recentsFragment = buildFragment("Recents"); BottomBarFragment tripsFragment = buildFragment("Trips");

    fragments.add(callsFragment);
    fragments.add(recentsFragment);
    fragments.add(tripsFragment);
}

Next, we’ll define the buildFragment() method. It’s job is to initialize each BottomBarFragment to hold the correct Bottom Navigation item title.

private BottomBarFragment buildFragment(String title) { BottomBarFragment fragment = new BottomBarFragment(); Bundle bundle = new Bundle(); bundle.putString(BottomBarFragment.ARG_TITLE, title); fragment.setArguments(bundle); return fragment; }

We now have a list of fragments that hold 3 BottomBarFragment. Each Fragment here holds its respective Bottom Navigation item title. The fragments in the List are in the same order as the Bottom Navigation items.

2. Inflate Fragment based on position

Lastly, we inflate the correct Fragment of the 3, into our FrameLayout.

Let’s write a generic method that handles the Fragment switching for us.

private void switchFragment(int pos, String tag) { getSupportFragmentManager() .beginTransaction() .replace(R.id.frame_fragmentholder, fragments.get(pos), tag) .commit(); }

There are 2 scenarios to handle:

a. App launch

We need to show a Fragment by default, when the app launches. This would obviously be the very first item in the Bottom Navigation, ‘Calls’ item.

Add this line in BottomBarActivity.onCreate().

// Set the 0th Fragment to be displayed by default. switchFragment(0, TAG_FRAGMENT_CALLS);

It would be wise to maintain constant tags to uniquely identify each Fragment (Bottom Navigation Item).

private static final String TAG_FRAGMENT_CALLS = "tag_frag_calls"; private static final String TAG_FRAGMENT_RECENTS = "tag_frag_recents"; private static final String TAG_FRAGMENT_TRIPS = "tag_frag_trips";

b. Bottom Navigation item clicks

When a Bottom Navigation item is clicked, the view is changed. In relative terms, we show the relevant BottomBarFragment.

Modify your BottomNavigationView item click listener as follows.

bottomNavigationView.setOnNavigationItemSelectedListener( new BottomNavigationView.OnNavigationItemSelectedListener() { @Override public boolean onNavigationItemSelected(@NonNull MenuItem item) { switch (item.getItemId()) { case R.id.action_bottombar_calls: switchFragment(0, TAG_FRAGMENT_CALLS); return true; case R.id.action_bottombar_recents: switchFragment(1, TAG_FRAGMENT_RECENTS); return true; case R.id.action_bottombar_trips: switchFragment(2, TAG_FRAGMENT_TRIPS); return true; } return false; } });

Here’s the complete BottomBarActivity.java for your reference.

public class BottomBarActivity extends AppCompatActivity { private static final String TAG_FRAGMENT_CALLS = "tag_frag_calls"; private static final String TAG_FRAGMENT_RECENTS = "tag_frag_recents"; private static final String TAG_FRAGMENT_TRIPS = "tag_frag_trips";

private BottomNavigationView bottomNavigationView;
/\*\*
 \* Maintains a list of Fragments for {@link BottomNavigationView}
 \*/
private List<BottomBarFragment> fragments = new ArrayList<>(3);

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_bottom_bar);

    bottomNavigationView = (BottomNavigationView) findViewById(R.id.bottom_nav);

    bottomNavigationView.setOnNavigationItemSelectedListener(
            new BottomNavigationView.OnNavigationItemSelectedListener() {
                @Override
                public boolean onNavigationItemSelected(@NonNull MenuItem item) {
                    switch (item.getItemId()) {
                        case R.id.action_bottombar_calls:
                            switchFragment(0, TAG_FRAGMENT_CALLS);
                            return true;
                        case R.id.action_bottombar_recents:
                            switchFragment(1, TAG_FRAGMENT_RECENTS);
                            return true;
                        case R.id.action_bottombar_trips:
                            switchFragment(2, TAG_FRAGMENT_TRIPS);
                            return true;
                    }
                    return false;
                }
            });

    buildFragmentsList();

    // Set the 0th Fragment to be displayed by default.
    switchFragment(0, TAG_FRAGMENT_CALLS);

}

private void switchFragment(int pos, String tag) {
    getSupportFragmentManager()
            .beginTransaction()
            .replace(R.id.frame_fragmentholder, fragments.get(pos), tag)
            .commit();
}

private void buildFragmentsList() {
    BottomBarFragment callsFragment = buildFragment("Calls");
    BottomBarFragment recentsFragment = buildFragment("Recents");
    BottomBarFragment tripsFragment = buildFragment("Trips");

    fragments.add(callsFragment);
    fragments.add(recentsFragment);
    fragments.add(tripsFragment);
}

private BottomBarFragment buildFragment(String title) {
    BottomBarFragment fragment = new BottomBarFragment();
    Bundle bundle = new Bundle();
    bundle.putString(BottomBarFragment.ARG_TITLE, title);
    fragment.setArguments(bundle);
    return fragment;
}

}

Conclusion

Wow, that took longer than expected! Now with everything done, go ahead and run the app.

If your app looks similar to that, give yourselves a pat on the back.

Congratulations! We’ve successfully added Bottom Navigation to our apps.

Source Code:

View Project on GitHub

Quick Recap

In this article, we set up a BottomNavigationView and reacted to item clicks. Then we looked into styling options with XML selectors. Finally, we saw how to set up navigation between Fragments using the Bottom Navigation Items.

Now all that’s left is for you to decide what content goes into each Fragment. I am sure you will create something great. Good luck with that!

Is there anything you’d like to add to this article? Let me know in the comments.

If you liked reading this article, share it to your social network.

Material Design Snackbar in Android - How and When to Use

Tue, 24 Jan 2017 00:00:00 GMT

Snackbar was introduced in Material Design. It is available via the Design Support Library. Code-wise, it is similar to a Toast.

In this article, we’ll first clear the confusion around using Snackbar and Toast. Next, we’ll look at implementation and customizing.

But before that, let’s clarify what exactly a Snackbar is.

Already know what it is? Jump straight to the code.

What is Snackbar?

A lightweight component that gives feedback to users. It optionally provides an action to users.

Behavior

Snackbars are displayed at the bottom of the screen. It stays there for the specified interval. Or, you can dismiss it by swiping.

However, there arises a confusion with our ‘ol pal, the Toast.

Snackbar VS Toast Confusion

The addition of a Snackbar created ambiguity. When do we use it and when to use Toast?

Its important that we know what to use when. So before moving on to actual code implementation, let’s clear the confusion.

The Difference

Snackbar

Contain a single line of text directly related to the operation performed. They may contain a text action, but no icons.

Lightweight feedback about an operation
Optionally includes a single action
Can optionally stay on-screen permanently, until swiped off screen

Toast

A simple Toast

Primarily used for system messaging. They also display at the bottom of the screen, but may not be swiped off-screen.

System-level messaging
No user action can be performed
Can only stay on screen temporarily. Cannot be swiped

Moving forward

Now that we’re clear about difference between the two, we can start implementing.

First, we’ll look at using a simple usage, right off the bat. Next I’ll tell you how to include a primary action. Then we’ll learn how to style it. Finally, we’ll go over its do’s and don'ts.

Usage

Displaying is relatively simple. In fact, it is similar to how you would write a Toast. We use the class android.support.design.widget.Snackbar .

Snackbar  
    .make(view, "Your message here",               
                Snackbar.LENGTH_SHORT)
    .show();

The view (1st parameter) doesn’t have to be your parent layout. It can be any View.

TIP
Ideally, Snackbar works best if your parent layout is a CoordinatorLayout. This ensures that it plays nice with other UI elements (such as FAB). More on that later.

Next, the duration for displaying (3rd parameter), can be any of the following:

LENGTH_INDEFINITE
LENGTH_LONG
LENGTH_SHORT

I hope the duration types above are self-explanatory.

LENGTH_INDEFINITE will show the Snackbar for and indefinite period of time. But you can dismiss it by swiping.

Finally, don’t forget to call Snackbar.show() .

NOTE
For Snackbar to work, your Activity must inherit from (extend) AppCompatActivity. Otherwise, consider a third-party alternative.

Adding a Primary Action

As stated in the Material Design spec, we can optionally include an action.

Adding a user action is relatively simple. Simply modify your existing call as follows.

Snackbar  
    .make(view, "Your message here",               
                Snackbar.LENGTH_SHORT)
    .setAction("YourAction", new View.OnClickListener() {
                    @Override
                    public void onClick(View v) {
                        // TODO: Your Action
                    }
                });
    .show()

Ideal use-cases for a primary action include:

UNDO - for deleted message, archive, etc
CONNECT - to enable internet if disconnected
RETRY - an action that failed (e.g. API call)

NOTE
Do not include an action for DISMISS. This is of no use. Just auto-dismiss your Snackbar by setting a short duration. Or it can simply be swiped away.

Styling

Default properties

The Snackbar class follows the Builder pattern which allows for easy styling.

Action Text color

snackbar.setActionTextColor(
      ContextCompat.getColor(
          context, R.color.yourColor)
      );

To style properties such as text colors, you’ll have to fetch the View first.

View snackbarView = snackbar.getView();

Then get the TextView from it.

TextView textView = (TextView) snackbarView.findViewById(
       android.support.design.R.id.snackbar_text);

// For multi-line text, limit max line count.
textView.setMaxLines(3);

 // Snackbar text color (not action button)
 textView.setTextColor(yourColor);

Background color

First, you’ll need a reference. Then apply all your style properties and finally call snackbar.show().

snackbarView.setBackgroundColor(yourColor);

Playing nice with Floating Action Button

Have you seen this behavior before?

The FAB translates up, giving space for the Snackbar to rise from the bottom.

This is the ideal, recommended behavior. Because the last thing we want is the FAB overlap!

So to avoid that, just keep one thing in mind.

Your parent layout (root layout) must be a CoordinatorLayout. It ensures that the correct Behavior is applied to its child Views. In other words, it ensures that UI elements ‘behave’ or ‘coordinate’ correctly.

Here’s an example of how such an XML layout would look like.

<androidx.coordinatorlayout.widget.CoordinatorLayout  
        android:layout_width="match_parent"
        android:layout_height="match_parent">

    <com.google.android.material.floatingactionbutton.FloatingActionButton
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_gravity="end|bottom"
            android:src="@drawable/ic_your_icon"/>

</androidx.coordinatorlayout.widget.CoordinatorLayout>

Creating a Custom Layout

With v25.1.0 of Android Design Support Library, creating a custom layout is now possible.

That’s right, I’m talking about creating an XML layout of your own.

We can do this in 4 simple steps.

1. Create XML layout

Now I’m going to leave this to you. Let loose your imagination!

As for me, I’ll just roll in a simple layout this time.

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
              xmlns:tools="http://schemas.android.com/tools"
              android:layout_width="match_parent"
              android:layout_height="wrap_content"
              android:background="#efefef"
              android:gravity="center_vertical"
              android:orientation="horizontal"
              android:paddingBottom="16dp"
              android:paddingTop="16dp">

    <TextView
        android:id="@+id/snackbar_text"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_weight="75"
        android:ellipsize="end"
        android:maxLines="3"
        android:paddingLeft="16dp"
        android:paddingRight="16dp"
        android:textAppearance="@style/TextAppearance.Design.Snackbar.Message"
        tools:text="This is a custom Snackbar text"/>

    <Button
        android:id="@+id/snackbar_btn"
        style="@style/Widget.AppCompat.Button.Borderless"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_marginEnd="24dp"
        android:layout_marginLeft="24dp"
        android:layout_marginRight="24dp"
        android:layout_marginStart="24dp"
        android:layout_weight="25"
        android:text="Action"
        android:textColor="@color/colorAccent"/>

</LinearLayout>

Custom layout

Custom layout- Blueprint

2. Create a Custom class

Create a CustomSnackbar final class that extends BaseTransientBottomBar.

Next, create an inner, static class ContentViewCallback. Implement the BaseTransientBottomBar.ContentViewCallback interface.

public class CustomSnackbar 
        extends BaseTransientBottomBar<CustomSnackbar> {
    
    ...
    
     private static class ContentViewCallback
            implements BaseTransientBottomBar.ContentViewCallback {

     // view inflated from custom layout
        private View view;

        public ContentViewCallback(View view) {
            this.view = view;
        }

        @Override
        public void animateContentIn(int delay, int duration) {
            // TODO: handle enter animation
        }

        @Override
        public void animateContentOut(int delay, int duration) {
            // TODO: handle exit animation
        }
    }
   ... 
}

Now, our main layout is inflated and taken care of. Next is handling the TextView and action Button.

But keep in mind that a typical Snackbar has this. Moreover, since my custom layout has a Text and Button too, I’m adding functionality to it.

So if you don’t have either of those Views, then skip ahead to point 4.

3. Inflate Custom View

Create a static method make(ViewGroup parent, int duration), similar to the original Snackbar.make() method.

Here, we will inflate our custom layout, using the parent ViewGroup.

public static CustomSnackbar make(ViewGroup parent, int duration) {
       // inflate custom layout
       LayoutInflater inflater = LayoutInflater.from(parent.getContext());
       View view = inflater.inflate(R.layout.custom_snackbar, parent, false);

       // create with custom view
       ContentViewCallback callback= new ContentViewCallback(view);
       CustomSnackbar customSnackbar = new CustomSnackbar(parent, view, callback);

       customSnackbar.setDuration(duration);

       return customSnackbar;
   }

4. Display it

Finally, you can display your CustomSnackbar, just like you would with a regular Snackbar.

CustomSnackbar customSnackbar = CustomSnackbar.make(rootView, CustomSnackbar.LENGTH_SHORT);
       customSnackbar.setText("Your message here");
       customSnackbar.setAction("Action", new View.OnClickListener() {
           @Override
           public void onClick(View v) {
               // TODO: handle click here
           }
       });
       customSnackbar.show();

CustomSnackbar.java

Here’s the complete code for the CustomSnackbar class.

public final class CustomSnackbar
        extends BaseTransientBottomBar<CustomSnackbar> {

    protected CustomSnackbar(@NonNull ViewGroup parent, @NonNull View content, @NonNull ContentViewCallback contentViewCallback) {
        super(parent, content, contentViewCallback);
    }

    public static CustomSnackbar make(ViewGroup parent, int duration) {
        // inflate custom layout
        LayoutInflater inflater = LayoutInflater.from(parent.getContext());
        View view = inflater.inflate(R.layout.custom_snackbar, parent, false);

        // create with custom view
        ContentViewCallback callback= new ContentViewCallback(view);
        CustomSnackbar customSnackbar = new CustomSnackbar(parent, view, callback);
        customSnackbar.setDuration(duration);

        return customSnackbar;
    }

    private static class ContentViewCallback
            implements BaseTransientBottomBar.ContentViewCallback {

        // view inflated from custom layout
        private View view;

        public ContentViewCallback(View view) {this.view = view;}

        @Override
        public void animateContentIn(int delay, int duration) {// TODO: handle enter animation}

        @Override
        public void animateContentOut(int delay, int duration) {// TODO: handle exit animation}
    }
}

Do’s and Don'ts

Knowing how to use Snackbar is essential. But knowing when to use it is important as well. So before we call this a wrap, let's look at some do's and don'ts.

keep the text content short
Allow undoable actions to be undone (delete, archive, etc.)
display feedback results for user actions
style it to match your design

Don’t

include icons
perform core functionality via the action button
display multiple instances
display important system information or errors
overlap or block the FAB (Floating Action Button)
animate or reposition

Conclusion

The Snackbar is comparatively a tiny component in the Material Design spec. Hence it is easily prone to misunderstanding and misuse.

Giving users feedback is important. Effectively using it is key to your app.

Quick Recap

First, we clarified the difference between a Snackbar and Toast. Then we even discussed when to use what.

Next, we looked into using a simple implementation and went onto adding actions. From there, we looked into styling and customization options.

Additionally, we saw that even a custom layout can be used. Finally, we reinforced key guidelines.

Where to from here?

This is just one of the many new additions to Material Design.

The Design Support Library is making life easy for Android Developers to use Material Design. Are you using it?

Recommended Read:

I hope this article instilled a complete understanding about Snackbar.

Lastly, I’d like to hear your thoughts. Have anything to add to this? Or have I missed out anything? Drop ‘em in the comments below.

If you liked reading this article, share it on social media!

Android Pagination: Error Handling

Mon, 09 Jan 2017 00:00:00 GMT

Endless or Infinite scrolling is called pagination. You do this in Android using RecyclerView. However, there are a few critical error scenarios to handle.

This is the third post in the Android Pagination article series.

In the previous article, (Android Pagination: Using APIs with Retrofit and Gson), we fetched real API data in Pagination. We used themoviedb.org for our data source. Additionally, Retrofit was used for networking, Glide for image loading and Gson for JSON parsing.

However, when networking is involved, one simply cannot ignore the various errors that occur. A good app intelligently handles all errors. This article aimed towards that.

This article has been updated for AndroidX!

Pagination Series Overview

Android Pagination Tutorial: Getting Started
Using APIs with Retrofit and Gson
Error Handling
Using Multiple RecyclerView Types
Adding Swipe-to-Refresh Support

Unlike one-off API calls, which involve one request to display data on-screen, Pagination is different.

Those who’ve followed my Pagination post series, know that the first-page call happens separately. This means error handling for page 1 will be different than that for page 2 and beyond.

Pagination involves 2 crucial error handling scenarios. Let's deal with both.

Pagination Error Handling for Page 1

For pagination, page 1 is our one-off API call.

Now if the API call fails here, the screen will be empty with nothing to display. So unless you have cached data as a backup, you have nothing to show.

One-off loading content

So what can we do? Use the entire screen to tell people what went wrong.

Ideally, stick to a crisp one or two liner about the error. Nothing too technical. Also, don’t forget to include a ‘Call-to-Action’ (CTA) button.

Mostly, the CTA would and should be a retry button.

Here’s how I’ve modified my existing screen to accommodate an error layout:

activity_main.xml layout skeleton

<FrameLayout>
    <androidx.recyclerview.widget.RecyclerView />
    <ProgressBar/>
    <include layout="@layout/error_layout"/>
</FrameLayout>

error_layout.xml

<merge
       android:layout_width="match_parent"
       android:layout_height="match_parent">

    <LinearLayout
        android:id="@+id/error_layout"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center"
        android:orientation="vertical"
        android:visibility="gone"
        tools:visibility="visible">

        <!--Displays a generic error message-->
        <TextView
            style="@style/TextAppearance.AppCompat.Subhead"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="@string/error_msg"/>

  <!--Displays a reason for the error—>
        <TextView
            android:id="@+id/error_txt_cause"
            style="@style/TextAppearance.AppCompat.Caption"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_gravity="center"
            android:layout_marginTop="@dimen/activity_margin_quarter"
            tools:text="The server took too long to respond."/>

        <!—CTA— prompting user to retry failed request>
        <Button
            android:id="@+id/error_btn_retry"
            style="@style/Widget.AppCompat.Button.Borderless"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_gravity="center_horizontal"
            android:layout_marginTop="@dimen/activity_margin_content"
            android:text="@string/btn_retry"
            android:textColor="@color/colorPrimary"/>

    </LinearLayout>
</merge>

One-off API call error layout

Use humor to reduce the seriousness of the error

While this is the bare minimum, use the available screen estate effectively. Use this opportunity to display an image associated with the error. Even better if you can use a short GIF to go with it.

Some examples from material.uplabs.com:

Google Playbook – Error Animation by Ben Breckler

Error Screen by Amit Nanda

Remember, adding a bit of humor goes a long way. But this may offend a few, so use it sparingly.

Handling Failure

Once the call fails, we must do three things:

Hide the ProgressBar (loading indicator)
Display error layout
Show the appropriate error message

We can handle all of this by writing a convenient method showErrorView(Throwable t) called in onFailure() of our API call.

callTopRatedMoviesApi().enqueue(new Callback < TopRatedMovies > () {
 @Override
 public void onResponse(Call < TopRatedMovies > call, Response < TopRatedMovies > response) {
  hideErrorView();
  // TODO: handle data
 }

 @Override
 public void onFailure(Call < TopRatedMovies > call, Throwable t) {
  t.printStackTrace();
  showErrorView(t);
 }
});

private void showErrorView(Throwable throwable) {
 if (errorLayout.getVisibility() == View.GONE) {
  errorLayout.setVisibility(View.VISIBLE);
  progressBar.setVisibility(View.GONE);

  // display appropriate error message
  // Handling 3 generic fail cases.
  if (!isNetworkConnected()) {
   txtError.setText(R.string.error_msg_no_internet);
  } else {
   if (throwable instanceof TimeoutException) {
    txtError.setText(R.string.error_msg_timeout);
   } else {
    txtError.setText(R.string.error_msg_unknown);
   }
  }
 }
}

showErrorView() takes a Throwable parameter, that can be used to know what the error is.

Notice our error layout has a retry button. This is our CTA which effectively allows retrying the failed request. So hopefully our screen will have something to show now.

Next, let’s add a click listener.

btnRetry.setOnClickListener(new View.OnClickListener() {
   @Override
   public void onClick(View view {
     loadFirstPage();
   }
});

The button allows users to retry the first request if it failed.

Let’s run through a quick recap of what we just did. We:

modified our activity_main.xml layout to include an error view
displayed error view whenever the one-off API call failed
used onFailure() to display an appropriate error message
allowed users to retry the request after failure, via a CTA (Retry Button)

Pagination Error Handling for Page 2 and above

As mentioned earlier, errors for Page 2 and above will be handled differently. Initially, when expecting a page to load, a ProgressBar (loading indicator) is display at the footer.

If the API successfully returns a response, then we remove our ProgressBar and append the new data. However, for some reason, if that fails, we need to handle it.

Similar to page 1, we need to do two things:

Hide the footer ProgressBar and show an error (in the footer) instead
Tell the user what went wrong
Allow them to retry

While the steps to perform remain the same, the key difference lies in executing this and displaying it to the user.

Open item_progress.xml. We need to add an error layout to this.

<FrameLayout android:layout_width="match_parent"
             android:layout_height="wrap_content">

    <ProgressBar
        android:id="@+id/loadmore_progress"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center"/>

    <LinearLayout
        android:id="@+id/loadmore_errorlayout"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:background="?attr/selectableItemBackground"
        android:clickable="true"
        android:orientation="horizontal"
        android:paddingBottom="@dimen/activity_margin"
        android:paddingTop="@dimen/activity_margin"
        android:visibility="gone">

        <ImageButton
            android:id="@+id/loadmore_retry"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_gravity="center"
            android:layout_marginLeft="@dimen/activity_margin_content"
            android:layout_marginStart="@dimen/activity_margin_content"
            android:background="@drawable/rety_selector"
            android:padding="@dimen/activity_margin_half"
            android:src="@drawable/ic_refresh_black_24dp"
            android:tint="@color/placeholder_grey"
            android:tintMode="src_in"
            tools:targetApi="lollipop"/>

        <LinearLayout
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            android:layout_marginEnd="@dimen/activity_margin_content"
            android:layout_marginLeft="@dimen/activity_margin"
            android:layout_marginRight="@dimen/activity_margin_content"
            android:layout_marginStart="@dimen/activity_margin"
            android:gravity="center_vertical"
            android:orientation="vertical">

            <TextView
                android:id="@+id/loadmore_errortxt"
                style="@style/Base.TextAppearance.AppCompat.Body1"
                android:layout_width="match_parent"
                android:layout_height="wrap_content" />

            <TextView
                style="@style/Base.TextAppearance.AppCompat.Caption"
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:text="@string/tap_to_reload"/>

        </LinearLayout>
    </LinearLayout>
</FrameLayout>

(Footer) Progress layout with retry UI

Notice that our design now does two things. It:

allows a user to retry
tells them what went wrong

Listening to Retry button clicks

Go to PaginationAdapter.java. Let’s add the click action for the retry button.

protected class LoadingVH extends RecyclerView.ViewHolder implements View.OnClickListener {
 private ProgressBar mProgressBar;
 private ImageButton mRetryBtn;
 private TextView mErrorTxt;
 private LinearLayout mErrorLayout;

 public LoadingVH(View itemView) {
  super(itemView);

  …
  mErrorTxt = (TextView) itemView.findViewById(R.id.loadmore_errortxt);
  mErrorLayout = (LinearLayout) itemView.findViewById(R.id.loadmore_errorlayout);

  mRetryBtn.setOnClickListener(this);
  mErrorLayout.setOnClickListener(this);
 }

 @Override
 public void onClick(View view) {
  switch (view.getId()) {
   case R.id.loadmore_retry:
   case R.id.loadmore_errorlayout:
    showRetry(false, null);
    mCallback.retryPageLoad();
    break;
  }
 }
}

Notice that mCallback.retryPageLoad() is a listener which MainActivity will implement.

public interface PaginationAdapterCallback {
 void retryPageLoad();
}

Head back to MainActivity.java and implement the PaginationAdapterCallback interface. Then, go to the loadNextPage() method and make the following changes:

private void loadNextPage() {
 callTopRatedMoviesApi().enqueue(new Callback < TopRatedMovies > () {
  @Override
  public void onResponse(Call < TopRatedMovies > call,
   Response < TopRatedMovies > response) {
   adapter.removeLoadingFooter();
   isLoading = false;…
  }

  @Override
  public void onFailure(Call < TopRatedMovies > call, Throwable t) {
   adapter.showRetry(true, fetchErrorMessage(t));
  }
 });
}

Add the showRetry() method in PaginationAdapter.java.

public void showRetry(boolean show, @Nullable String errorMsg) {
 retryPageLoad = show;
 notifyItemChanged(movieResults.size() - 1);

 if (errorMsg != null) this.errorMsg = errorMsg;
}

adapter.showRetry() is responsible for changing the footer ProgressBar into a retry button. It additionally displays an error message saying what went wrong.

Displaying an error message matters

Typically, apps tend to show a retry button on failure. They miss out on telling us what exactly went wrong. The reason for failure could be anything. Does the user have a network issue? Or did the server fail to respond?

Most importantly, the error message tells us on whose side the issue is.

Here is how Instagram and DailyHunt (NewsHunt) handle pagination errors:

Pagination error handling in Instagram

DailyHunt pagination error handling

Take a good look at both these examples. Which one do you think did a better job of telling you what went wrong? That's right, Dailyhunt. The app clearly tells us what the issue is. Also, it tells us what to do, to rectify it. Finally, the error footer is clickable, allowing us to retry that failed request.

While Instagram certainly does have a clean design, simply showing a retry option doesn't really tell us the problem.

Finally, with everything done, let's go ahead and run our app.

Final Results

Watch on YouTube

We've now successfully handled both use cases. Page 1 is a separate call compared to the rest of the pages.

When page 1 fails, we don't have any content to show the user. This leaves the entire screen blank. We handled this by smartly using the available screen estate. An appropriate error message was displayed. Additionally, we allowed users to retry the failed request.

We then followed a similar approach to handle page 2 and beyond. In addition, to display a retry button in the footer, we displayed the reason for failure as well. Finally, we inferred from 2 famous apps about how they handled a similar scenario.

View Source Code on GitHub

Some key takeaways:

Pagination primarily has 2 error cases to be handled
Errors can be unavoidable, but we can take steps to handle them
Tell users what exactly went wrong, but don't get too technical
Be forgiving with errors (consider using humor) and allow users to retry requests

I hope this post helped make your paginated apps error-prepared.

As always, I'd like to hear what you think. Tell me if I covered all the use cases. Did I miss out on anything? Drop 'em in the comments below.

I’m happy you took the time to read this. All I need for you is to help me spread the word!

Android Pagination: Using APIs with Retrofit and Gson

Tue, 22 Nov 2016 00:00:00 GMT

Let's look at Android Pagination with RecyclerView, using real data from an API. This will give us a better understanding of Pagination. First, we'll look at what API to use. Next, we will set up a networking library (Retrofit) that will help us perform these API calls.

This is the second post in a series of Android Pagination articles. In the previous, Android Pagination Tutorial: Getting Started article, we learned about Pagination and implemented its logic. We created dummy content to populate our RecyclerView.Adapter.

This article has been updated for AndroidX!

Pagination Series Overview

Android Pagination Tutorial: Getting Started
Using APIs with Retrofit and Gson
Error Handling
Using Multiple RecyclerView Types
Adding Swipe-to-Refresh Support

In this post, we will look at fetching data from an API, as a real-time scenario. This will give us a better understanding of Android Pagination. First, we'll look at what API to use. Next, we will set up a networking library (Retrofit) that will help us perform these API calls.

For a real-world scenario, we'll need real content from an API. For that, let's go with themoviedb.org(TMDb). A popular, user-maintained database for movies and TV shows.

The Movie DB API

themoviedb.org

We need an API key before we can start using their APIs. So go ahead and sign up.

Next, login in and go to your account. Generate an API key from there. Be advised, there's a fairly long form you need to fill. The API is free, so the least we can do is fill a form. So do swift of that, and get your key.
After that, either go through their documentation for in-depth usage. Otherwise, for the scope of this tutorial, we'll simply make a request to find 'top rated movies'. You could use a URL of your own choice, or follow along with me.

API Call for Top Rated Movies

Here's the shortest URL we need:

_https://api.themoviedb.org/3/movie/top_rated?api_key=YOUR_API_KEY&language=en-US&page=1_

Just remember to replace YOUR_API_KEY with your actual API key!

JSON Response for Top Rated Movies

{ "page": 1, "results": [ { "poster_path": "\/9O7gLzmreU0nGkIB6K3BsJbzvNv.jpg", "adult": false, "overview": "Framed in the 1940s for the double murder of his wife and her lover, upstanding banker...", "release_date": "1994-09-10", "genre_ids": [ 18, 80 ], "id": 278, "original_title": "The Shawshank Redemption", "original_language": "en", "title": "The Shawshank Redemption", "backdrop_path": "\/xBKGJQsAIeweesB79KC89FpBrVr.jpg", "popularity": 8.522754, "vote_count": 5493, "video": false, "vote_average": 8.34 }, … // Other result (movie) objects ], "total_results": 4341, "total_pages": 218 }

Notice the page attribute in the response. It starts at 1. We also get a nice response that tells us the total_pages is 218. That means we can Pagination 218 times in total, with about 20 content per page! However, we don't need that much, so for this tutorial, let's stick to 5 pages in total?

TIP:
I recommend using Postman when dealing with APIs. It gives you a clear idea of how to construct proper API requests. Also, the formatted JSON response is handy too.

Before we begin, we'll need to decide upon a networking library (and image loading library too, if you wish). Dealing with text and media in APIs is pretty common, so I'll assume we need both. These libraries will do most of the heavy-lifting, allowing us to focus on the app itself.

Tech Stack:

Gson - library to convert Java Objects into their JSON representation and back
Retrofit - HTTP client for Android
Glide - image loading and caching library for Android; handy for smooth scrolling

You might be familiar with Retrofit and Gson. They're a powerful combination, often preferred when dealing with APIs. The CodePath guides is a perfect place to start for the uninitiated:

However, not to worry if you're unfamiliar with them. I'll be going over the basics. Just enough to get your app working!

Also Read: Create an Image Gallery Android App with Sugar ORM and Glide.

Getting Started

Start by adding Gson, Retrofit, and Glide to your app/build.gradle.

ext {
    retrofit = '2.6.1'
    axAppcompat = '1.0.2'
    axOthers = '1.0.0'
    glide = '4.9.0'
    supportLib= '28.0.0'
}

  /*
        TODO: remove temporary fix for Glide compiler issue
        https://github.com/bumptech/glide/issues/3185
      */

    // Temporary fix begin
    implementation "com.android.support:support-annotations:${supportLib}"
    annotationProcessor "com.android.support:support-annotations:${supportLib}"
    // Temporary fix end

    implementation "com.squareup.retrofit2:retrofit:${retrofit}"
    implementation "com.squareup.retrofit2:converter-gson:${retrofit}"
    implementation ("com.github.bumptech.glide:glide:$glide") {
        exclude group: "com.android.support"
    }
    annotationProcessor "com.github.bumptech.glide:compiler:$glide"

NOTE
You might notice that I've added Android's Support libraries while I'm also using AndroidX. This is a temporary workaround that's needed because currently, Glide's annotation processor has only partial support for AndroidX. In other words, this won't break anything since I've tested it for you. Simply copy paste these dependencies and you should be good.

Additionally, we need a Gson converter for Retrofit. It allows serializing JSON responses to model classes using Gson, automagically! This allows us to work with data, via models. So, no more manual JSON parsing!

Don't forget to add internet permissions in AndroidManifest.xml!

<uses-permission android:name="android.permission.INTERNET"/>

Note:
This is not a tutorial about using Retrofit. However, I will go through the bare minimum that’s required to set up Retrofit and use it.

Preparing Model Classes with Gson

We need to create model classes that mirror our API response. While you can take your time to manually create this, I want to automate it. We already know how our API response looks like. So let's auto-generate our model classes and save ourselves time.

Head over to http://www.jsonschema2pojo.org and paste your API response. Set the parameters on the right as follows:

Set the (project) package name and parent model class name (ideally should be the name of the API call, i.e. TopRatedMovies)
Set Source Type as JSON
Set Annotation Style as GSON

Finally, hit Zip to generate the class files and download them. Or, you can get the files directly from me. :)

Let's take a quick breather here. Did you just see what we did? We auto-generated all the model classes we need to handle a particular API response. Just how amazing is that!?

Either way, you'll end up with two model classes. Parent model TopRatedMovies and the other model is automatically named Result. Notice how each model's property is annotated to its JSON response attribute. Gson uses these annotations to map the JSON values to its respective model properties.

With this done, we can proceed to set up Retrofit.

Modifying PaginationAdapter

Compare the API response with our model classes. Each movie object in the array is Result.java, and the entire response is TopRaterMovies.java.

Also, consecutive page requests indicate multiple TopRatedMovies model. This implies that our RecyclerView.Adapter must use List<TopRatedMovies>. So go ahead and modify PaginationAdapter to use the same.

Updated PaginationAdapter can be found here.

Note:
Delete the Movie.java model class as its no longer needed.

Configuring Retrofit

Create a class MovieApi.java. This will be responsible for configuring the Retrofit client. Next, create an interface called MovieService. We will define all our API calls here. Retrofit uses Annotations to define API calls.

Open MovieApi.java. We'll now configure the Retrofit client.

public class MovieApi {
 private static Retrofit retrofit = null;

 public static Retrofit getClient(Context context) {
  if (retrofit == null) {
   retrofit = new Retrofit.Builder()
    .addConverterFactory(GsonConverterFactory.create())
    .baseUrl("https://api.themoviedb.org/3/")
    .build();
  }
  return retrofit;
 }
}

Note:
Remember that the base URL must always end with a forward trailing slash.

Now, head over to MovieService.java. We will define our top-rated movies API call here.

// Declare all your API calls here
public interface MovieService {

 @GET("top_rated")
 Call < TopRatedMovies > getTopRatedMovies(
  @Query("api_key") String apiKey,
  @Query("language") String language,
  @Query("page") int pageIndex
 );
}

Making API Calls with Retrofit

Go to MainActivity. If you remember from Part 1 of the Android Pagination tutorial, there is a method called loadFirstPage(). We were loading dummy data here at first. Scrap those lines off. Now we're going to perform the API request here. We'll start by requesting for the very first page, i.e. page 1.

...
@Override
protected void onCreate(Bundle savedInstanceState) {
 …
 //init service and load data
 MovieService movieService = MovieApi.getClient().create(MovieService.class); //1
 loadFirstPage();
}
/**
 * Performs a Retrofit call to the top rated movies API.
 */
private Call < TopRatedMovies > callTopRatedMoviesApi() { //2
 return movieService.getTopRatedMovies(
  getString(R.string.my_api_key),
  "en_US",
  currentPage
 );
}
/*
 * Extracts List<Result> from response
 */
private List < Result > fetchResults(Response < TopRatedMovies > response) { //3
 TopRatedMovies topRatedMovies = response.body();
 return topRatedMovies.getResults();
}
private void loadFirstPage() {
 callTopRatedMoviesApi().enqueue(new Callback < TopRatedMovies > () { //4
  @Override
  public void onResponse(Call < TopRatedMovies > call, Response < TopRatedMovies > response) {

   List < Result > results = fetchResults(response); //5
   progressBar.setVisibility(View.GONE);
   adapter.addAll(results);

   if (currentPage <= TOTAL_PAGES) adapter.addLoadingFooter();
   else isLastPage = true;
  }

  @Override
  public void onFailure(Call < TopRatedMovies > call, Throwable t) {
   // handle error
  }
 });
}
private void loadNextPage() {
  callTopRatedMoviesApi().enqueue(new Callback < TopRatedMovies > () { //6
   @Override
   public void onResponse(Call < TopRatedMovies > call, Response < TopRatedMovies > response) {
    adapter.removeLoadingFooter();
    isLoading = false;

    List < Result > results = fetchResults(response);
    adapter.addAll(results);

    if (currentPage != TOTAL_PAGES) adapter.addLoadingFooter();
    else isLastPage = true;
   }

   @Override
   public void onFailure(Call < TopRatedMovies > call, Throwable t) {
    // handle failure
   }
  });
 }
 ...

Here are crucial snippets of an updated MainActivity.java. Let's go over what each of the commented steps means.

Start by initializing MovieService object with a Retrofit instance. Look at getClient() method in MovieApi.java, you'll notice that it builds a configured Retrofit instance.
callTopRatedMoviesApi() returns the Retrofit API call since we'll be reusing the same. The method parameters passed here are query parameters for the API's URL.
Another helper method that extracts the list of results (movies) from the API response.
Attach an API callback using enqueue() to handle the response.
Notice how the callback returns Response<TopRatedMovies> and not a generic JSON String. This is the magic of Gson. It serialized the entire response into TopRatedMovies. However, what we actually need is a list of movies gives by List<Results> from TopRatedMovies class.
We use the same API call for loading the next page too. mCurrentPage is incremented by PaginationScrollListener, so the API loads the indicated page number

If you noticed back in the API response, Pagination starts from page 1. There is no index zero. Hence change PAGE_START = 1. Additionally, the response includes other useful information such as up to how many pages we can paginate.

Updating PaginationAdapter to display API data

Now, we have a working API call with a response, so head over to PaginationAdapter. First, we start by updating our helper methods. If you can recall, we had defined the following methods in Part 1:

void add(Result r)
void addAll(List<Result> moveResults)
void remove(Result r) 
void clear()
boolean isEmpty()
void addLoadingFooter()
void removeLoadingFooter()
Result getItem(int position)

NOTE
We don't use the Movie model class anymore. Instead our 'Movie' object is now replaced by Result.java. So update your methods accordingly!

Next, our list of data will now become a List<Result> object. So change that in your adapter as well, if you haven't.

With that done, the last step is to update onBindViewHolder() with our new data.

@Override
public void onBindViewHolder(RecyclerView.ViewHolder holder, int position) {

 Result result = movieResults.get(position); // Movie

 switch (getItemViewType(position)) {
  case ITEM:
   final MovieVH movieVH = (MovieVH) holder;

   movieVH.mMovieTitle.setText(result.getTitle());

   movieVH.mYear.setText(
    result.getReleaseDate().substring(0, 4) // we want the year alone
    +
    " | " +
    result.getOriginalLanguage().toUpperCase()
   );

   movieVH.mMovieDesc.setText(result.getOverview());

   // Using Glide to handle image loading.
   Glide
    .with(context)
    .load(BASE_URL_IMG + result.getPosterPath())
    .listener(new RequestListener < String, GlideDrawable > () {
     @Override
     public boolean onException(Exception e, String model, Target < GlideDrawable > target, boolean isFirstResource) {
      // handle failure
      movieVH.mProgress.setVisibility(View.GONE);
      return false;
     }

     @Override
     public boolean onResourceReady(GlideDrawable resource, String model, Target < GlideDrawable > target, boolean isFromMemoryCache, boolean isFirstResource) {
      // image ready, hide progress now
      movieVH.mProgress.setVisibility(View.GONE);
      return false; // return false if you want Glide to handle everything else.
     }
    })
    .diskCacheStrategy(DiskCacheStrategy.ALL) // cache both original & resized image
    .centerCrop()
    .crossFade()
    .into(movieVH.mPosterImg);

   break;

  case LOADING:
   //                Do nothing
   break;
 }
}

TIP
Don't forget to update your ViewHolder item layout accordingly. For example, here's how I've modified mine to display the new data. However I'm sure you can come up with something better!

Adapter item layout

BONUS - Automatically Log Network Calls

With Retrofit, it might be a little difficult to manually log network responses. Since Gson maps it to our model classes, getting back the JSON is difficult. As trying to deserialize an already serialized response, defeats the purpose of using Gson in the first place. So what can we do?

Retrofit plays nicely with OkHttp, an efficient HTTP client for Android and Java. By using Interceptors, OkHttp allows us to 'intervene' between network calls and perform our desired action.

Interceptors are a powerful mechanism that can monitor, rewrite, and retry calls - OkHttp Wiki

A popular use case for Intercepters would be to append our API key as a query parameter to every request. This sure beats manually passing it as a method parameter to each request.

Coming back to automatic logging, we will be using the very same Interceptor to get our job done.

Add the following library to your app/build.gradle:

implementation 'com.squareup.okhttp3:logging-interceptor:4.0.1'

Next, open MovieApi.java and modify the getClient() method as follows:

// builds OkHttpClient with logging Interceptor  
 private static OkHttpClient buildClient() {
  return new OkHttpClient
   .Builder()
   .addInterceptor(new HttpLoggingInterceptor().setLevel(HttpLoggingInterceptor.Level.BODY))
   .build();
 }
 public static Retrofit getClient() {
  if (retrofit == null) {
   retrofit = new Retrofit.Builder()
    .client(buildClient())
    .addConverterFactory(GsonConverterFactory.create())
    .baseUrl("https://api.themoviedb.org/3/")
    .build();
  }
  return retrofit;
 }

The highlighted line emphasizes how the custom client is attached to the Retrofit builder. You can use the buildClient() method to add yet another Interceptor if you wish.

Run your app now and you'll observe that your network activity is now automatically logged. You can even find the raw JSON response there. Cheers!

The complete project with auto logging is available in commit "auto logging network calls".You can see the source code that contains auto-logging network calls.

Output

Now that we've done everything needed, go ahead and run your app. Here's how the output should look like:

Note:
You might notice duplicated contents at the end and the beginning of consecutive pages. Eg: The movie 'Empire Strikes Back', might appear twice. This occurs twice in the paginated response and is no cause for alarm.

Project Available on GitHub

View the entire project source code.

In this post, we were able to take Pagination and apply it to a real-world example using an API. We used Retrofit to handle our networking, Gson to maintain our model classes and auto-parse JSON results. We also used Glide to make image handling a breeze. Next, we updated our existing code to reflect the new API.

However, with network and API calls in play, we cannot ignore the scenario of an API call failing. Nor can we ignore when our mobile data or Wi-Fi stops working. Error handling becomes imperative in such cases.

In Part 3, I'll show you how to deal with such cases.

Pagination Android Tutorial with RecyclerView: Getting Started

Tue, 01 Nov 2016 00:00:00 GMT

Pagination (Endless Scrolling or Infinite Scrolling) is a feature common in content-heavy apps. It breaks down a list of content into equal smaller pieces, loaded one at a time.

This is the first post in a series of Pagination articles. The series covers how to implement Pagination with RecyclerView, handle adapter changes with new data, error handling and more.

This article has been updated for AndroidX!

Pagination Series Overview

Pagination Android Tutorial: Getting Started
Using APIs with Retrofit and Gson
Error Handling
Using Multiple RecyclerView Types
Adding Swipe-to-Refresh Support

The What, Why and When of Pagination

Pagination is the process of dividing a document into discrete pages, either electronic pages or printed pages. - Wikipedia

Already know what Pagination is? Jump straight to the code section!

What we're going to do, relates to this definition. Loading the next set of data (next page), by specifying its index (page number).

What is Pagination?

Users of Facebook, Twitter or Instagram will know what I'm talking about. After all, we've spent countless hours scrolling through them haven't we? They just don't seem to end!

Twitter Profile Tweets list

Why Pagination?

From a developer's perspective, how would you load all of that content? It is not possible to make a call for such huge content at one go. We'll have to request them in parts, or 'pages'.

Pagination allows the user to see the latest content with little wait time. As we load the next 'page' by the time users scroll to the bottom, more content is loaded and available.

When to use Pagination?

I'm sure you have a pretty good idea by now on when to use it. If you have a ton of content that takes too long to load. This can be either from a local database or an API call. Then it makes sense to use Pagination. If you're pulling from a database, request data in batches (say 20 per request). The same also holds true for an API call.

With that out of the way, I'm sure you'd want to see some Android code with Pagination in action. So without further delay, let's get straight to it!

Getting Started

As we all know, Pagination has been around for quite some time. This opens it up to various approaches on how exactly to do it.

Here are some solutions you might have come across:

Endless Scrolling with AdapterView and RecyclerView - guides.codepath.com
How to implement an endless list with RecyclerView - stackoverflow.com

But these don’t tell you how to show or hide a footer loading progress (ProgressBar). You also would have resorted to an Android Pagination library on GitHub:

Usually, I’d suggest one of the above, but this time I won't. That's because we can roll our own scroll listener. This would be simpler instead. Sometimes it's better to be in control of our feature, especially when third party solutions refuse to work the way you want.

Android Pagination with RecyclerView

Custom OnScrollListener

public abstract class PaginationScrollListener extends RecyclerView.OnScrollListener {

 LinearLayoutManager layoutManager;

 public PaginationScrollListener(LinearLayoutManager layoutManager) {
  this.layoutManager = layoutManager;
 }

 @Override
 public void onScrolled(RecyclerView recyclerView, int dx, int dy) {
  super.onScrolled(recyclerView, dx, dy);

  int visibleItemCount = layoutManager.getChildCount();
  int totalItemCount = layoutManager.getItemCount();
  int firstVisibleItemPosition = layoutManager.findFirstVisibleItemPosition();

  if (!isLoading() && !isLastPage()) {
   if ((visibleItemCount + firstVisibleItemPosition) >=
    totalItemCount && firstVisibleItemPosition >= 0) {
    loadMoreItems();
   }
  }
 }

 protected abstract void loadMoreItems();
 public abstract int getTotalPageCount();
 public abstract boolean isLastPage();
 public abstract boolean isLoading();
}

Copy over this class. To enable Pagination, we must detect the user reaching the end of the list (RecyclerView). PaginationScrollListener allows us to do so.

NOTE:
The onScrolled() logic is the most important piece of your entire Pagination logic. So make sure you're doing it right. The key snippet which contains the Pagination logic is as follows.

if (!isLoading() && !isLastPage()) {
 if ((visibleItemCount + firstVisibleItemPosition) >=
  totalItemCount && firstVisibleItemPosition >= 0) {
  loadMoreItems();
 }
}

Layout Setup

Create a layout with RecyclerView and a ProgressBar (for indicating load of initial content).

// activity_main.xml skeleton layout

<FrameLayout> 
    <androidx.recyclerview.widget.RecyclerView /> 
    <ProgressBar android:layout_gravity="center”/> 
</FrameLayout>

Creating RecyclerView.Adapter

First, create class PaginationAdapter extending RecyclerView.Adapter, and then create two RecyclerView.ViewHolder.

class ContentVH (main content item)
class LoadingVH (footer ProgressBar used for Pagination)

I will be going through the essentials of the adapter, as creating a regular RecyclerView.Adapter is quite common by now.

public class PaginationAdapter extends RecyclerView.Adapter < RecyclerView.ViewHolder > {

 // flag for footer ProgressBar (i.e. last item of list)
 private boolean isLoadingAdded = false;
 ...
 @Override
 public int getItemCount() {
  return movies == null ? 0 : movies.size();
 }
 @Override
 public int getItemViewType(int position) {
  return (position == movies.size() - 1 && isLoadingAdded) ? LOADING : ITEM;
 }
 ...
}

For our example, let's assume we want to display a list of movies.

NOTE
List<Movies> (your data) must reside in the RecyclerView.Adapter class only. You can access it via Getter Setters.

Adapter Helper Methods

Add the following methods to PaginationAdapter. They will be useful for added data fetched via Pagination.

public void add(Movie mc) {
 movies.add(mc);
 notifyItemInserted(movies.size() - 1);
}

public void addAll(List < Movie > mcList) {
 for (Movie mc: mcList) {
  add(mc);
 }
}

public void remove(Movie city) {
 int position = movies.indexOf(city);
 if (position > -1) {
  movies.remove(position);
  notifyItemRemoved(position);
 }
}

public void clear() {
 isLoadingAdded = false;
 while (getItemCount() > 0) {
  remove(getItem(0));
 }
}

public boolean isEmpty() {
 return getItemCount() == 0;
}

public void addLoadingFooter() {
 isLoadingAdded = true;
 add(new Movie());
}

public void removeLoadingFooter() {
 isLoadingAdded = false;

 int position = movies.size() - 1;
 Movie item = getItem(position);
 if (item != null) {
  movies.remove(position);
  notifyItemRemoved(position);
 }
}

public Movie getItem(int position) {
 return movies.get(position);
}

That is all for the adapter. Complete PaginationAdapter code is available here, just in case.

Preparing RecyclerView

// Setup Layout Manager
linearLayoutManager = new LinearLayoutManager(this, RecyclerView.VERTICAL, false);
recyclerView.setLayoutManager(linearLayoutManager);
recyclerView.setItemAnimator(new DefaultItemAnimator());

// Setup Adapter
PaginationAdapter adapter = new PaginationAdapter(this);
recyclerView.setAdapter(adapter);

Upon careful inspection, Pagination works in this flow:

Display loading progress (ProgressDialog) on the empty screen while fetching initial data
Hide ProgressDialog and display data
Detect user scroll to the end of the list
Show ProgressDialog at footer while fetching next page data
Remove footer ProgressDialog and display fetched data
Repeat Steps 3, 4 & 5 until all pages have loaded

Notice that the setup for certain steps is already in place. Loading initial data (page 0) will handle Step 1 and 2. PaginationListener will handle Step 3 and 6. PaginationAdapter helper methods will handle Step 4 and 5.

The following code setup will show you how all this will tie together.

Activity Setup

Here's the entire MainActivity.java. It should give you a clear understanding of how everything ties together.

Be sure to note the variables here. As each plays a key part in the Pagination logic. Also, remember that TOTAL_PAGES will be determined by how many pages your API has. Usually, this will be included in the paginated response.

 public class MainActivity extends AppCompatActivity {

 PaginationAdapter adapter;
 LinearLayoutManager linearLayoutManager;
 RecyclerView rv;
 ProgressBar progressBar;

 // Index from which pagination should start (0 is 1st page in our case)
 private static final int PAGE_START = 0;

 // Indicates if footer ProgressBar is shown (i.e. next page is loading)
 private boolean isLoading = false;

 // If current page is the last page (Pagination will stop after this page load)
 private boolean isLastPage = false;

 // total no. of pages to load. Initial load is page 0, after which 2 more pages will load.
 private int TOTAL_PAGES = 3;

 // indicates the current page which Pagination is fetching.
 private int currentPage = PAGE_START;

 @Override
 protected void onCreate(Bundle savedInstanceState) {
   super.onCreate(savedInstanceState);
   setContentView(R.layout.activity_main);
   ...

   // init views

   adapter = new PaginationAdapter(this);

   linearLayoutManager = new LinearLayoutManager(this, RecyclerView.VERTICAL, false);
   rv.setLayoutManager(linearLayoutManager);
   rv.setAdapter(adapter);

   rv.addOnScrollListener(new PaginationScrollListener(linearLayoutManager) {
    @Override
    protected void loadMoreItems() {
     isLoading = true;
     //Increment page index to load the next one
     currentPage += 1;
     loadNextPage();
    }

    @Override
    public int getTotalPageCount() {
     return TOTAL_PAGES;
    }

    @Override
    public boolean isLastPage() {
     return isLastPage;
    }

    @Override
    public boolean isLoading() {
     return isLoading;
    }
   });
   loadFirstPage();
  }
  ...
}

Loading Initial Data

Here’s how we’ll be using that method to perform the initial load (i.e. 1st-page request):

private void loadFirstPage() {
 // fetching dummy data
 List < Movie > movies = Movie.createMovies(adapter.getItemCount());
 progressBar.setVisibility(View.GONE);
 adapter.addAll(movies);

 if (currentPage <= TOTAL_PAGES) adapter.addLoadingFooter();
 else isLastPage = true;
}

We can even mimic network delay, using a Handler.

// mocking 1 second network delay
new Handler().postDelayed(new Runnable() {
 @Override
 public void run() {
  loadFirstPage();
 }
}, 1000);

Once we load the initial request and get data, hide the ProgressBar. Next, the fetched data is added to the adapter and notified. The addAll() helper method in PaginationAdapter accomplishes this.

NOTE
The initial data to be loaded is the 1st page (0th index). This must be a separate call, as the remaining pages are handled differently.

Using PaginationScrollListener

Notice how PaginationScrollListener uses our Activity defined flags. It needs the LayoutManager supplied to RecyclerView to count and compare the number of items it has. This is more accurate to know how many items are actually in layout, rather than counting the List. But for now, its constructor only supports LinearLayoutManager.

Once initial data has loaded, its time to listen to scroll changes and trigger the next page.

private void loadNextPage() {
 List < Movie > movies = Movie.createMovies(adapter.getItemCount()); // 1
 adapter.removeLoadingFooter(); // 2
 isLoading = false; // 3
 adapter.addAll(movies); // 4
 if (currentPage != TOTAL_PAGES) adapter.addLoadingFooter(); // 5
 else isLastPage = true;
}

Now let's look at the steps we take to load page 2. This remains the same for all pages beyond this.

Get data (response) from API
Remove footer ProgressBar to make way for new data
Indicate that the next page is currently not loading (using isLoading)
Add your new data to the adapter
Check if this is the last page. If not, add back the footer ProgressBar

Final Output

As per our code setup, we create 10 dummy content per page load. The number of times Pagination will happen is 3 (TOTAL_PAGE). Add that with the initial page load, and you're looking at 40 items in total.

Go ahead and run the app.

Pagination result GIF

Download Source Code from GitHub

For Scroll listener, refer to this updated class - PaginationScrollListener.

Great job there! We now have a working Android app with a RecyclerView that supports Pagination.

What's next?

In this article, we learned the logic behind paginating our data. However, this is just some dummy data. In the real world, we get data from an API. So with network calls in play, how would you paginate?

You can read about this in Part 2 - Pagination with real data via APIs using Retrofit.

So how are you going to Paginate your apps? Do you think this approach is good? Or do you have something better in mind? Drop 'em in the comments below.

Material Design Onboarding in Android- Quickstart (Tap Target)

Mon, 29 Aug 2016 00:00:00 GMT

There are 3 Material Design Onboarding models in Android. In this tutorial, we'll learn about using the Quickstart model using TapTarget library. This is part of the updated Material Design guidelines for apps. There are 3 types of Material Design onboarding models:

Self-Select Display a series of choices allowing users to customize their app experience
Quickstart Let users start using your app immediately and highlight actions they can take.
Top User Benefits Display the top 3 features of your app with a carousel.

Self-Select, Quickstart, & Top User Benefits (Left to Right) - material.google.com

Which Material Design Onboarding model to use?

The ‘Quickstart' model only serves you best when your app is something people are already familiar with. Like a chat, email, or camera app.

Provide value and encourage return visits by introducing users to new features and functionality at contextually relevant moments. - Feature Discovery (material.google.com)

However, if your app is something groundbreaking and new. If it has new features people don’t know how to use or aren’t familiar with. Then the ‘Top User Benefits’ model is the best choice. If you’re app’s home feed is built based on user choices. Like how most social networks build your newsfeed the first time you join. Then for cases like these, you have the ‘Self-Select’ model. The table below can help decide which model best fits your Material Design app:

Source: material.google.com

NOTE: While onboarding is a crucial part of your app’s experience, your major focus must be on the app itself. As there is no use having an amazing onboarding experience, with a mediocre app. This increases user expectation, only to disappoint them later.

Quickstart Onboarding with Tap Target

Get the demo App here.

A feature discovery prompt focuses user attention on a specific UI element. - Tap target

Now that you know what the Tap Target effect looks like, let’s get to using it. Luckily, there’s a handy library called Material TapTarget Prompt by Samuel Wall. So let’s use it to make quick work of this. Let’s start by adding the dependency. First, add the jcenter repository in your project level build.gradle file.

repositories {
   jcenter()
}

Next, add the library dependency to your app level build.gradle file.

dependencies { 
    compile 'uk.co.samuelwall:material-tap-target-prompt:1.1.4' 
    ... 
}

Finally, decide upon which View must show the Tap Target.

new MaterialTapTargetPrompt.Builder(YourActivity.this)
        .setTarget(findViewById(R.id.yourView))
        .setPrimaryText("Here is an interesting feature")
        .setSecondaryText("Tap here and you will be surprised")
        .setOnHidePromptListener(new MaterialTapTargetPrompt.OnHidePromptListener()
        {
            @Override
            public void onHidePrompt(MotionEvent event, boolean tappedTarget)
            {
                //TODO: Store in SharedPrefs so you don't show this prompt again.
            }

            @Override
            public void onHidePromptComplete()
            {
            }
        })
        .show();

Use Tap Target sparingly

Use Tap Target to only highlight the most important features. It helps direct users to an action you want them to take. For example, take the Gmail Android app. Its primary action is to compose new email, which is prioritized with a Floating Action Button. Hence the FAB here, is a perfect case for Tap Target. READ ALSO:

Keep in mind that 'Quickstart' must only be used ONCE per feature. Introduce features to users one by one, gradually over time. This will involve you storing a SharedPreference, once Tap Target has been displayed for a feature. You can always allow users to reset this via your app's Settings screen.

Customization

Here are a few Builder methods for the MaterialTapTargetPrompt class:

Animation Interpolators-

setAnimationInterpolator(new FastOutSlowInInterpolator())

Change highlighted icon (useful for color inversion when showing TapTarget)-
```
setIcon(R.drawable.ic_your_icon)
```
Theming- Some properties you can define for styling TapTarget in values/styles.xml- - focalRadius - backgroundColour - focalColour - primaryText - secondaryText - focalRadius - primaryTextSize - secondaryTextSize

Remember that Quickstart will highlight a feature only ONCE. Also, it reveals each feature gradually over time as a user uses the app. The time span could be a week or so. Once a feature is highlighted, Tap Target is not displayed for it again. SAMPLE APP: Available on GitHub.

We are already familiar with the 'Top User Benefits’ model. Its the App intro sliders made with ViewPager. READ: Onboarding with Android ViewPager: The Google Way The Quickstart model for Material Design onboarding is the fastest way to get users familiarize with your app. It uses Tap Target helps encourage user action. Quickstart takes users straight into your app. Then, on the way it sprinkles little tips and suggestions with how and what to use. This model in my opinion, is the best by far. Because mobile users do NOT like to wait! So which Material Design Onboarding model are you using in your Android app? Let me know in the comments, or subscribe below for more updates!

Header image: Onboarding screens by Murat Gürsoy

DayNight Theme Android Tutorial with Example

Mon, 08 Aug 2016 00:00:00 GMT

The DayNight Theme was added to AppCompat with the realease of Support Library v23.2.0. We can reference the theme using Theme.AppCompat.DayNight. DayNight theme allows to switch between light(day) and dark(night) themes, based on the time. Keep in mind that it supports API 14+. Any lower and it defaults to the Light theme. If you remember, this is just one of the goodies released by this support library version. Another great addition was Bottom Sheets, which you can read about here.

The Old Days

Supporting both Light and Dark themes is pretty popular. It is desirable for any app that focuses on reading. Doing so requires maintaining two independent themes that inherit from:

Theme.AppCompat.Light
Theme.AppCompat

Then, you would set the correct Theme in every Activity’s onCreate(), before super().

Night mode as seen on Newslet

app

setTheme(isDarkTheme? R.style.MyDarkTheme : R.style.MyLightTheme);

isDarkTheme is a boolean to check if Dark Theme must be enabled. Ideally, you want users to set this via Settings (SharedPreferences). This is how apps would handle theme switching before, but let’s look at a better alternative.

Using the DayNight Theme

Start by changing your parent theme in values/styles.xml. You can inherit from any of the following themes:


<!--Your theme declarations-->

Next, you have to tell our app to take advantage of this. Those familiar with switching themes before DayNight, will feel right at home. We set the theme, immediately in the Activity’s onCreate().

@Override
protected void onCreate(Bundle savedInstanceState) {

    AppCompatDelegate.setDefaultNightMode(
            AppCompatDelegate.MODE_NIGHT_AUTO);

    super.onCreate(savedInstanceState);
...
}

This little method tells your Activity to use the DayNight theme. Notice that we do not use setTheme() anymore. AppCompatDelegate takes care of this.

Wait. What’s AppCompatDelegate?

In short, AppCompatDelegate helps bring Material Design goodness to pre Lollipop Android versions.

It represents a delegate which you can use to extend AppCompat's support to any Activity. - developer.android.com

The AppCompat support libraries make this possible. That is why our Activities must extend from AppCompatActivity and NOT from Activity. This medium post tells you how to use AppCompat goodness when not extending from AppCompatActivity.

Let’s get back to the DayNight theme. You would have noticed one more thing in this method call.

AppCompatDelegate.setDefaultNightMode(
 AppCompatDelegate.MODE_NIGHT_AUTO);

That’s right, you may wonder what MODE_NIGHT_AUTO is. The curious one would’ve immediately done a Cmd/Ctrl + Click to read its source. Let me highlight all available modes, so we can be clear what each one’s for.

MODE_NIGHT_AUTO - The app switches to night theme based on the time. It makes use of location APIs (if necessary permissions granted) for accuracy. Otherwise falls back to using system time.
MODE_NIGHT_FOLLOW_SYSTEM - This is more of an app-wide setting for night mode. Uses the system Night Mode setting to determine if it is night or not.
MODE_NIGHT_NO - Tells the app to never use night mode, regardless of time / location.
MODE_NIGHT_YES - Tells app to use night mode always, regardless of time / location.

MODE_NIGHT_YES can be used to test Night Theme. This is useful when its not actually night yet. You won't have to wait the whole day to test it!

Taking Control of DayNight theme

Now that you know how to use the DayNight theme, its time to customize it. Android allows us to override resources specific to Day or Night themes. You can do this using the -night resource qualifier, appended to our resource folder names. For instance, I want to change my colors for the night theme. I can do so by creating a new resource, specific for that: res/values-night/colors.xml. Then I can simply override the colors for them here. But for the sake of depth, let’s see how we can override the Night Theme itself. Create res/values-night/styles.xml. Here we will override the Night Theme.


 <item name="colorPrimary">@color/colorPrimaryNight</item>
 <item name="colorPrimaryDark">@color/colorPrimaryDarkNight</item>
 <item name="colorAccent">@color/colorAccentNight</item>
 <item name="android:windowBackground">@color/bg_dark</item>

With this setup, we’re overriding Night Theme and specifying a new color scheme for it. You can even specify Night Theme specific drawables.

Setting DayNight for a single `Activity`

You can also apply Activity specific theme using this code snippet. Use it prior to calling super() in onCreate().

getDelegate().setLocalNightMode(mode);

Setting DayNight theme for entire app

Set this in your Application class onCreate(). This applies app-wide DayNight theme, depending on mode.

AppCompatDelegate.setDefaultNightMode(mode);

NOTE: When referencing resources, always use from AppCompat (your theme). This ensures the correct theme attributes are applied. This ensures the DayNight theme is applied correctly and avoid weird UI issues. Such as black text against a dark background in Night mode. ;)

Result

I've applied the DayNight Theme to an existing app. Let's see how it looks.

You'll notice that I've completely changed the Material Design color palette for Night Theme. This is purely for demonstration purposes. Always remember to completely test both themes across both post and pre Lollipop Android versions. Despite our best attempts to maintain seamless UI, there always might be some issues. No harm in testing :) ALSO READ: Bottom Navigation Bar Android Tutorial

Things to keep in mind

Do not use MODE_NIGHT_FOLLOW_SYSTEM by default. As this is system dependent, set to false initially
MODE_NIGHT_FOLLOW_SYSTEM can be changed using setLocalNightMode(int). Allow the user to control this via settings, via Preferences
Calling AppCompatDelegate.setDefaultNightMode(mode) must be done BEFORE calling super() in Activity onCreate(). Otherwise you must recreate() the Activity for the set theme to take effect
Always reference resources and styles from the inherited theme. For example, you must reference primary color in styles as ?attr/colorPrimary and NOT @color/colorPrimary. This ensures correct themed resources are used. It applies to all theme resources. It also eliminates UI inconsistencies, such as non-readable text.

SOURCE CODE: GitHub

Quick Recap

Let's quickly review what we did.

Make our parent theme extend from any one of Theme.AppCompat.DayNight
Tell our Activity(s) to set DayNight theme depending on the MODE_NIGHT flags
Override night specific theme resources using -night qualifier for folders.
Make sure to reference theme related attributes via styles.
Remember to call recreate() if theme is changed after Activity creation.

Many apps allow switching between Light and Dark themes. But with no official support from Android, we maintained two separate themes. With DayNight theme, we can inherit from one base style that covers both themes. We can even override night theme and specify different resources. However, using two different themes is a matter of choice for users. Some like to use the Dark Theme when possible. So its a good idea to provide an option for the same. How do you adapt your UI's to the DayNight theme? Drop 'em in the comments below. Also don't forget to subscribe for latest posts and tips.

Implement Parcelable to Bundle your POJOs

Sun, 26 Jun 2016 00:00:00 GMT

Every Android Developer is familiar with passing data via a Bundle or Intent.

In doing so, you would have wanted to pass your entire POJO (Plain Old Java Object) class,or List<Bean>. But Intent or Bundle don't allow that right off the bat. The key lies in your Beans implementing Parcelable.

public class YourModel implements Parcelable {

    // properties
    String name, url;

    public YourModel() { }

     // Getter Setters here

    // Parcelable methods
    protected YourModel(Parcel in) {
        name = in.readString();
        url = in.readString();
        // other properties
    }

    public static final Creator CREATOR = new Creator() {
        @Override
        public YourModel createFromParcel(Parcel in) {
            return new YourModel(in);
        }

        @Override
        public YourModel[] newArray(int size) {
            return new YourModel[size];
        }
    };

    @Override
    public int describeContents() {
        return 0;
    }

    @Override
    public void writeToParcel(Parcel dest, int flags) {
        dest.writeString(name);
        dest.writeString(url);
        // other properties
    }
}

After that, you simply pass your model class data like this:

Passing via Intent

intent.putParcelableArrayListExtra("listofmodels", (ArrayList) yourModels);

List of YourModel

intent.putExtra("singlemodel", (Parcelable) yourModel);

Single YourModel object

Passing YourModel via a Bundle

bundle.putParcelableArrayList("listofmodels", (ArrayList) yourModels);

List of YourModel

bundle.putParcelable("singlemodel", yourModel);

Single YourModel object

PRO-TIP: You can alternatively implement Serializable to achieve a similar result!

USEFUL RESOURCES:

Parceler library by John Ericksen
Difference between Parcelable and Serializable

RecyclerView Adapter in Android, made Fast and Easy

Tue, 07 Jun 2016 00:00:00 GMT

Every time we think of creating a RecyclerView, we dread the amount of code that must go into the adapter. Also, if that adapter has many ViewHolders, then god save us! Also, I haven't even mentioned click listeners, drag and drop and other fancy stuff. If you've freaked out already about the effort needed for all that, then this post is for you. Of course, we all are familiar with the RecyclerView.Adapter boilerplate code. But writing the same code setup again and again is a waste of time. Surely there must be a better way?

Say hello to FastAdapter!

The bullet proof, fast and easy to use adapter library, which minimizes developing time to a fraction... - Mike Penz

FastAdapter is made by Mike Penz. The developer of popular libraries such as MaterialDrawer and AboutLibraries. FastAdapter reduces your time spent on Adapter code. Moreover, it offers a lot of features so it wouldn't limit your app in any way. With tons of features offered, consider replacing your 'regular' RecyclerView Adapters with FastAdapter. Click listeners, Multi-selection, filtering, drag and drop, headers and much more. You name it, you got it!

Getting Started

Start using FastAdapter by adding the following dependencies:

compile('com.mikepenz:fastadapter:1.5.2@aar') {
        transitive = true
    }
compile 'com.mikepenz:fastadapter-extensions:1.5.1@aar'

Creating the Model class

Let's say we're creating an app about the types of Mango (which happens to be my favourite fruit). So I name my model class simply, Mango.

public class Mango {

    private String name, description, imageUrl;

    public Mango() { }

    public Mango(String name, String description, String imageUrl) {
        this.name = name;
        this.description = description;
        this.imageUrl = imageUrl;
    }

    // Your variable Getter Setters here
}

Implementing the Adapter

FastAdapter makes use of your model class to create the RecyclerView.Adapter and RecyclerView.ViewHolder. Extend your model with AbstractItem<Item, Item.ViewHolder> and implement its methods:

getType() - return a unique ID (of your parent layout)
getLayoutRes() - return your XML layout resource
bindView() - RecyclerView's onBindViewHolder() method

public class Mango extends AbstractItem {

    private String name, imageUrl, description;

    public Mango() { }

    public Mango(String name, String imageUrl) {
        this.name = name;
        this.imageUrl = imageUrl;
    }

     // Your Getter Setters here
     
    // Fast Adapter methods
    @Override
    public int getType() { return R.id.item_card; }

    @Override
    public int getLayoutRes() { return R.layout.list_item; }

    @Override
    public void bindView(ViewHolder holder) {
        super.bindView(holder);
    }

    // Manually create the ViewHolder class
    protected static class ViewHolder extends RecyclerView.ViewHolder {
  
        //TODO: Declare your UI widgets here

        public ViewHolder(View itemView) {
            super(itemView);
            //TODO: init UI
        }
    }
}

Marrying FastAdapter to RecyclerView

With that in place, you can finally attach FastAdapter to your RecyclerView:

recyclerView.setLayoutManager(new LinearLayoutManager(context, LinearLayoutManager.VERTICAL, false));

FastItemAdapter fastAdapter = new FastItemAdapter<>();
recyclerView.setAdapter(fastAdapter);

// Fetch your data here
List mangoes = loadMangoes();

fastAdapter.add(mangoes);

That is all we need to do! If we run our app now, we'd get a RecyclerView populated with a list of mangoes. So instead of reviewing what we just did. Let's what what we did NOT do for our adapter:

create an exclusive class for RecyclerView.Adapter
inflate an item layout
bother with getItemCount()

So I'm sure you'll believe me now. FastAdapter did quick work of creating a list. But surely you want to do more than just display a list? Here is where FastAdapter shines.

Feature List

Let's see how some popular RecyclerView features are done with FastAdapter. Use the below index to navigate.

Click listener
Filtering data with Search
Drag and drop
Multi-select with CAB (Contextual Action Bar) and Undo action
Adding Header view (multiple ViewHolders)
Infinite (endless) scrolling

1. Click Listener

Enable withSelectable for FastAdapter, and then set its click listener.

fastAdapter.withSelectable(true);

fastAdapter.withOnClickListener(new FastAdapter.OnClickListener() {
            @Override
            public boolean onClick(View v, IAdapter adapter, Mango item, int position) {
               // Handle click here
                return true;
            }
        });

2. Filtering data with Search

If our app uses a SearchView, and we want to filter our adapter data based on its results. FastAdapter has provision for that too.

// Call this in your Search listener
fastAdapter.filter("yourSearchTerm");

fastAdapter.withFilterPredicate(new IItemAdapter.Predicate() {
            @Override
            public boolean filter(Mango item, CharSequence constraint) {
                return item.getName().startsWith(String.valueOf(constraint));
            }
});

Note the filter(Mango item, CharSequence constraint) method. Return true means remove those items from the adapter, and retain those items which return false. If you're using SearchView, call filter() in its onQueryTextSubmit(String s) and onQueryTextChange(String s) methods.

3. Drag and Drop

Start by creating an instance of SimpleDragCallback (courtesy of FastAdapter). Next, use it to initialize an ItemTouchHelper. Finally attach the ItemTouchHelper to RecyclerView.

SimpleDragCallback dragCallback = new SimpleDragCallback(this);
ItemTouchHelper touchHelper = new ItemTouchHelper(dragCallback);
touchHelper.attachToRecyclerView(recyclerView);

Implement the ItemTouchCallback interface in your Activity. It implements the itemTouchOnMove() method. Add the following code to it.

@Override
   public boolean itemTouchOnMove(int oldPosition, int newPosition) {
       Collections.swap(fastAdapter.getAdapterItems(), oldPosition, newPosition); // change position
       fastAdapter.notifyAdapterItemMoved(oldPosition, newPosition);
       return true;
   }

4. Multi-Select with CAB (Contextual Action Bar) and Undo action

Start by creating an inner class ActionBarCallBack for your Activity, and implement ActionMode.Callback.

private class ActionBarCallBack implements ActionMode.Callback {
        @Override
        public boolean onCreateActionMode(ActionMode mode, Menu menu) { return true; }

        @Override
        public boolean onPrepareActionMode(ActionMode mode, Menu menu) { return false; }

        @Override
        public boolean onActionItemClicked(ActionMode mode, MenuItem item) {
            mode.finish();
            return true;
        }

        @Override
        public void onDestroyActionMode(ActionMode mode) { }
    }

Initialize an ActionModeHelper (by FastAdapter).

fastAdapter.setHasStableIds(true);
fastAdapter.withSelectable(true);
fastAdapter.withMultiSelect(true);
fastAdapter.withSelectOnLongClick(true);

actionModeHelper = new ActionModeHelper(fastAdapter, R.menu.cab, new ActionBarCallBack());

Regular onClick methods are used for other actions, such as for detail navigation. Hence FastAdapter provides a preClick and preLongClick listener for handling CAB.

fastAdapter.withOnPreClickListener(new FastAdapter.OnClickListener() {
            @Override
            public boolean onClick(View v, IAdapter adapter, Mango item, int position) {
                Boolean res = actionModeHelper.onClick(item);
                return res != null ? res : false;
            }
});

fastAdapter.withOnPreLongClickListener(new FastAdapter.OnLongClickListener() {
            @Override
            public boolean onLongClick(View v, IAdapter adapter, Mango item, int position) {
                ActionMode actionMode = actionModeHelper.onLongClick(MainActivity.this, position);
                if (actionMode != null) {
                    // Set CAB background color
                   findViewById(R.id.action_mode_bar).setBackgroundColor(Color.GRAY);
                }
                return actionMode != null;
            }
});

Note that we do not consume preClick if Action Mode is not enabled. If that's the case, we return false. This allows us the regular onClick method to be handled. If you're also using withOnClickListener(), don't forget to return false. Lastly, enable windowActionModeOverlay in your AppTheme, found in values/styles.xml.

true

Multi-select and CAB (Contextual Action Bar)

Undo Action

Deleting multi-selection items in CAB mode, works in conjunction with UndoHelper. This helper class will allow us to perform deletion on the multi-selected items.

UndoHelper undoHelper = new UndoHelper(fastAdapter, new UndoHelper.UndoListener() {
            @Override
            public void commitRemove(Set positions, ArrayList> removed) {
                Log.d("remove", "removed: " + removed.size());
            }
        });

For this interface implementation, we log the removed items count. UndoHelper.UndoListener is also useful to know the positions of the removed items. Remember the inner class ActionBarCallBack that we created? Modify its onActionItemClicked() method to this:

@Override
public boolean onActionItemClicked(ActionMode mode, MenuItem item) {
    undoHelper.remove(findViewById(android.R.id.content), "Item removed", "Undo", Snackbar.LENGTH_LONG, fastAdapter.getSelections());
    mode.finish();
    return true;
}

We have just called the UndoHelper's remove() method. This essentially removes the multi-selected items. Upon removal, it displays a SnackBar notifying us on success. It also gives us a prompt to undo the last removal, if we want to.

5. Adding Header View (multiple ViewHolders)

You could modify the existing Mango model for this. But for the sake of code cleanliness, let's maintain a new model class for our Header view.

public class Header extends AbstractItem {

    String title;

    public Header(String title) {
        this.title = title;
    }

     // Your getter setters here

    // AbstractItem methods
    @Override
    public int getType() {
        return R.id.header_text;
    }

    @Override
    public int getLayoutRes() {
        return R.layout.header_item;
    }

    @Override
    public void bindView(ViewHolder holder) {
        super.bindView(holder);

        holder.textView.setText(title);
    }

    protected static class ViewHolder extends RecyclerView.ViewHolder {
        @BindView(R.id.header_text) TextView textView;

        public ViewHolder(View itemView) {
            super(itemView);
            ButterKnife.bind(this, itemView);
        }
    }
}

Nothing fancy here. The Header model supports displaying a simple TextView. Start by initializing your Adapter variables:

FastItemAdapter fastAdapter = new FastItemAdapter<>();
fastAdapter.setHasStableIds(true);
fastAdapter.withSelectable(true);

HeaderAdapter

If you recall from earlier, we initialized our FastAdapter like this:

FastItemAdapter fastAdapter = new FastItemAdapter<>();

Note that now, we don't explicitly mention the type. This allows our FastAdapter to hold data from both Mango and Header models. Alternatively, you can initialize a generic type FastAdapter:

FastItemAdapter fastAdapter = new FastItemAdapter<>();

IItem is the base type for your Model classes. So if you initialize like this, remember to cast your models to IItem when adding data.

Setting the adapter

This is slightly different from last time. We set both, headerAdapter and fastAdapter to our RecyclerView using the wrap(FastAdapter) method.

recyclerView.setAdapter(headerAdapter.wrap(fastAdapter));

If you wish to have a third, different type of ViewHolder, its possible with an additional wrap() method.

recyclerView.setAdapter(thirdAdapter.wrap(headerAdapter.wrap(fastAdapter)));

Adding data All data is added to FastAdapter. For this example, I want one Header view at the top, and another in the middle. In an ideal scenario, you will have different subsets of data with header titles for each of them. So for my case, I add my data like this:

 int half = mangoes.size() / 2;

fastAdapter.add(0, new Header("First half").withIdentifier(1));
fastAdapter.add(1, mangoes.subList(0, half));
fastAdapter.add(half + 1, new Header("Second half").withIdentifier(2));
fastAdapter.add(half + 2, mangoes.subList(0, half));

I already have my list of mangoes. So I add half of them under the first header, and the other half under the second. The above code snippet demonstrates that. Note the increments to the half integer. The position is incremented like you would for any List.

Manipulating with different ViewHolders

Our FastAdapter now supports and holds data of different View types. So how do we manipulate stuff? Like handle clicks, and all the fancy stuff mentioned above? In short, the answer is to use instanceof. As an example, I'll show you how to modify FastAdapter's click listener:

fastAdapter.withOnClickListener(new FastAdapter.OnClickListener() {
            @Override
            public boolean onClick(View v, IAdapter adapter, IItem item, int position) {

                if (item instanceof Mango) {
                   // Do your thing!
                } else if (item instanceof Header) {
                   // Header clicks usually don't do anything. Ignore if you like.
                }
                return true;
            }
});

Notice the difference here? When we did the same click listener earlier, the onClick() passed us a Mango item. But since FastAdapter now is generic, it passes us an IItem (base class) object.

6. Infinite (endless) scrolling

This feature is used by almost all social networking apps. They load N number of posts first. After you reach the end of it, they show a loading indicator and then load N more. This is known as endless scrolling or pagination. The key to doing this lies in RecyclerView's addOnScrollListener() method. But we both know, inside the listener is where the real hardship is. For this, FastAdapter saves us with EndlessRecyclerOnScrollListener(). First, let us create a FooterAdapter. We need this to display a loading ProgressBar at the end of our list.

FooterAdapter footerAdapter = new FooterAdapter<>();

Note that ProgressItem is provided by FastAdapter's extensions. It is not part of the core library. So let's safely use both core and extension libraries shall we? After all, they are very useful!

recyclerView.addOnScrollListener(new EndlessRecyclerOnScrollListener() {
            @Override
            public void onLoadMore(int currentPage) {
                footerAdapter.clear();
                footerAdapter.add(new ProgressItem().withEnabled(false));

                // Load your items here and add it to FastAdapter
                fastAdapter.add(newMangoes);
            }
});

Really, that's all there is to do infinite scrolling. It's that easy! See the results for yourself.

Alternatively, if you want to implement Pagination with a regular RecyclerView.Adapter, then read Android Pagination with RecyclerView.

Wrapping it up

Wow, I think this was the longest post ever! I applaud your patience and perseverance for getting to the end of this post. RecyclerView's magic resides in its Adapter. FastAdapter knows this and simplifies it. It is more than just a convenience library. If you do a lot of Adapter manipulations, then having FastAdapter in your arsenal is an absolute must! RESOURCES:

mikepenz/FastAdapter library on GitHub (library and samples)

SOURCE CODE: Relevant code snippets of mine, for this post can be found on my GitHub Gist here. FastAdapter let's you do almost anything you would with an ordinary RecyclerView. Just, more easier and faster. I'm going to start using FastAdapter for my existing and future projects. What about you? Let me know in the comments below!

Prepare your apps for Multi-Window in Android N

Tue, 17 May 2016 00:00:00 GMT

Android 7 Nougat introduced Multi-Window, a new feature that enables multi-tasking. In this post, let's make or Android apps Multi-Window compatible. Android Nougat brings in a host of improvements and changes. Many of you already know what's new in Android N. So if we developers want to support the latest Android version, there's more work cut out for us.

Android N Multi-Window from developer.android.com

Why bother?

It might be alright to ignore supporting Multi-Window. But what Ian Lake said, should change your mind.

Keep in mind that multi-window is enabled by default - even if you don't target Android N, your app will be available in multi-window mode*. Start thinking about it now! * With the exception of apps with a fixed orientation or the immersive flag set in the manifest. - source

I hope that convinced you that Multi-Window in Android N is important. Let's get started. We'll create a simple list detail app using RecyclerView. Then enable Multi-Window on one Activity. Finally see how we can handle it. For this tutorial, I'm creating a list of the Avengers.

Creating an Android Nougat app

Android Nougat 7.1 has just released, so let's jump straight to using that. Make sure you've downloaded the following via Android SDK Manager:

SDK Build Tools & Platform Tools (v 25)
Android 7.1.1 (API 25)
Latest Support Libraries

Here's how my project's app/build.gradle looks like:

android {
    compileSdkVersion 25
    buildToolsVersion "25.0.0"

    defaultConfig {
        minSdkVersion 16
        targetSdkVersion 25
        ...
    }
 ...
}

dependencies {
    compile 'com.android.support:appcompat-v7:25.0.0'
    ...
}

Enabling Multi-Window in Android N

Add a layout tag under your activity tag in AndroidManifest.xml. Add in these layout attributes:

... 

            
            ...

...

There are a few things to note here:

android:resizeableActivity="true" tells Android that your app supports Multi-Window
default Height & Width are the dimensions the app takes by default, when entering Multi-Window
minHeight and minWidth are the smallest dimensions the app can be resized to
android:gravity dictates the initial position of the app in freeform mode

220dp is the minimum dimensions for an app. So make your app layout compatible from that breakpoint onwards. NOTE: While 220dp is the lowest size possible, you can set any minimum dimension in the Manifest file, as mentioned above.

Wait, now what's Freeform Mode?

In addition to Multi-Window in Android N, Tablets have Freeform mode. Similar to opening multiple windows on your desktop OS. Maybe a GIF will help you better understand.

GIF from Lifehacker But let's just focus on Multi-Window for now. By adding <layout /> inside <activity /> in your Manifest, I could say we're pretty much done. That is all that's needed to enable Multi-Window.But I'm sure you're not here for JUST that? Apart from resizing, the layout needs to adapt to size changes.

Making an adaptive UI

You must be wondering, "What needs to be done, to make my UI adaptive?". Well there's nothing new you have to do. If you think hard enough, you'll realise the solution already resides within Android. Yes, its Android's resource directory! Those familiar with designing adaptive UI for tablets will feel right at home. READ ALSO: Material Design for Tablets If not, I strongly recommend you read the above post, for an up-to-date primer on designing adaptive Android layouts. So let's see an example first. Here I have a list of the original Marvel Avengers team.

Looking good on the left, but in Multi-Window mode? Not much. The cards are huge for such a tiny window. Let's make each card's height smaller, so we can view more in a smaller window. Also, did you notice? Android automatically resized the Toolbar's title in Multi-Window. TIP: How to launch Multi-Window in Android Nougat Long-press the Recents button. Or from the Recents screen, long-press + drag a window onto the highlighted area. Create res>values-h500dp folder. Those familiar with the 'smallest-width' concept for creating layouts will immediately recognize that it works the same way for height. NOTE: This ideally works on the smallest-width concept. However, smallest-height sh400dp doesn't seem to work, and gives a compile error (weird)! However, if anyone can clarify this for me, it would be great! Create dimens.xml under values-h500dp folder. Doing so tells Android that "Hey, if my app's height is greater or equal to 500dp, use the values-h500dp folder, otherwise go for the regular res/values folder". I want my card's height to be smaller on Multi-Window. So here's how I define it's value: values-h500dp/dimens.xml

96dp

values/dimens.xml

80dp

In this way, if my app's height will be greater or equal to 500dp, card will be 96dp tall. If its lesser than 500dp in height, the card will be 80dp tall. Similarly, you can adapt your UI by providing alternate dimensions under the appropriate values folder. Here's the result of how the list adapts in Multi-Window:

Looking good on landscape too!

Listening to Multi-Window changes

Use the method isInMultiWindowMode() in your Activity, to determine if your app is in Multi-Window. Note that our Activity's lifecycle is not altered. When you alternate between the 2 apps in Multi-Window, your app pauses and resumes accordingly. SOURCE CODE: Available on GitHub

Things to remember

Make sure you're handling configuration changes properly using onSavedInstanceState()
Don't entirely change the UI, so users can avoid relearning the interface
Handle both portrait and landscape changes
Make the UI adapt from a minimum size of 220dp and up

Multi-Window in Android N highly encourages multi-tasking. Expect to see a lot of apps use this feature. Are you adapting your apps to Multi-Window? How have you modified your layouts? Drop 'em in the comments or subscribe below for future posts!

People API Android Tutorial - Part 1

Tue, 19 Apr 2016 00:00:00 GMT

Imagine having access to your contacts including data about them and their connections, via a single API? Combine the Contacts API and Google+ API and we have the People API. You can read the announcement on Google Developers Blog. Never was a fan of the Contacts API in Android, so I'm glad this came into picture. In this two-part post, we'll look at using the People API.

The People API lets you list authenticated users' Contacts and retrieve profile information for authenticated users and their contacts.

Part 1 of this post covers how to create a project via Google API Console. Then we'll see how to configure it, enable the People API and make it ready for access via our Android app. If you feel you're already familiar with all this, jump ahead to part 2 of the People API Android Tutorial. Part 2 is where all this is put into action in code. However, I suggest you at least skim through this.

Two Different People API

Let's clear some misconceptions first. First, there's the Google+ People API. Those who have used Google+ library in Android, would be familiar. Now that is not the same as this, which is what I'm talking about. Not the Google+ version. The difference in simple words is: People API (new)

Denotes your Google contacts
Your Contacts and Google+ data through one API.

Google+ People API

Denotes Google+ users
Only Google+ related data

You can refer the links above, just in case I haven't convinced you enough. Ok, I'm saying API too much. Let's get started?

Create a new project

Head over to https://console.developers.google.com and create a new project.

Next, enable the People API.

Once you enable the People API, you'd see that little warning about credentials. It authenticates our app to make API calls. So let's do that next.

Adding Credentials

Use Android's debug certificate for signing. Here's the command:

keytool -exportcert -alias androiddebugkey -keystore $HOME/.android/debug.keystore -list -v

$HOME/.android/debug.keystore is the default path on Mac. For windows, the debug.keystore can be found in your Android SDK folder.

Successfully executing this will print your SHA-1 fingerprint key. You need it for generating credentials for an Android client. After configuring your credentials you will be prompted to download them as a JSON file. You don't have to download it.

It's important that credentials are created for Android, and OAuth Client ID for web. Once you've created credentials for Android, do the same for web. You'll need your web's Client ID and Client Secret in the future. It might appear strange to add credentials for a Web client, for an Android app. It appears that we need credentials for BOTH Web and Android clients for it to work. However, within our Android app we'll only use keys from the Web client. Sound's weird right? Well that's how it works. Really hope Google would simply this in the future. So this is how my Credentials section in the API Manager is looking right now:

If yours looks similar to this, then you're good to go. You can name both your clients anything you want. I've stuck to the default names.

Enable Play Services for Android

To successfully link the People API and Play Services on our Android device, we'll be using Google Sign-in. Doing so, allows us to authenticate our requests which the API requires. Start by enabling Play Services for your newly created project.

Hit that huge blue button to proceed. In the next step, enable Google Sign-In. Remember that SHA-1 fingerprint we got in the previous step? Add that same key here. Finally, generate your configuration file, google-services.json and download it. It includes all the credential details you generated in the previous step. Neat!

Let's take a breather here. Why did we do all this? I just want to use the People API. Is all this needed? If you're asking anything like these questions, here's the long story short. Using any of Google's API services requires authentication (OAuth). It basically involves an exchange of a token which validates against the requests you make. The Play Services are specific to Android OS. They have a super easy API client library to use. This is possible with the Play Services SDK installed by default on your Android device. Some of the Google APIs come along with Play Services, such as Google+, Analytics and Maps. Here's the list of APIs bundled with Play Services. All the other Google APIs can be found here. What we're doing is, using Play Services to Sign-in. Then obtain a token from here and access a Google API (People API). We're going to integrate the two. Here's how both the mechanisms work:

I hope that was clear enough for you. A more detailed explanation of integrating the two, can be found in the Android developer's blog post. You can ignore the code snippets there. It'll be covered in Part 2 of this post.

Great! Now we have a ready project created in Google API Console. We've created credentials for both Android and Web clients, and enabled Play Services with Google Sign-in. With all the needed configuration in place, we're ready to integrate this into our Android app. Head over to part 2!

People API Android Tutorial – Part 2

Tue, 19 Apr 2016 00:00:00 GMT

Let's look at using the People API in our Android app. We will see how it allows us to pull data from contacts, as well as data from their G+ profiles. All through the People API alone.

Recap

Part 1 covered configuring a project via the Google API Console. We created credentials for Android and Web client. Next, we enabled Play Services for our project and downloaded a configuration file for the same. In part 2, we'll look at its implementation.

Preparing your App

Start by adding these to your Android app's Gradle dependencies:

repositories {
    mavenCentral()
}

dependencies {
    ...
    compile 'com.google.android.gms:play-services-plus:8.4.0'
    compile 'com.google.android.gms:play-services-auth:8.4.0'
    compile 'com.google.api-client:google-api-client:1.21.0'
    //  People API
    compile 'com.google.apis:google-api-services-people:v1-rev2-1.21.0'
}

Don't forget to add an Internet permission in your AndroidManifest.xml file.

Client ID and Secret

Take a look at your Web Client credentials in your Google API Console. You will notice a Client ID and Client Secret. Keep in mind we need these from the Web client, not Android. For the sake of this tutorial and complexity, I will simply add the Web Client's Client ID and Secret to my strings.xml file. Feel free to do the same, but remember that google-services.json file you downloaded in Part 1? Preferably, you must to add the file to your Android Studio project. Then JSON parse that file contents and fetch your keys from that.

Adding Google Sign in

Next, we'll add a Google Sign in. By signing in, we can obtain a valid access token from our registered Google account. In turn, this token will help us access the People API. Start by adding the Sign in button widget in your XML layout:

When we perform a sign in, we need to tell Play Services, what APIs and Scopes we're requesting.

GoogleSignInOptions

Notice the Scopes I'm requesting here. With the People API, for the sake of demonstration I'm happy with two.

GoogleSignInOptions signInOptions = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
             // The serverClientId is an OAuth 2.0 web client ID
             .requestServerAuthCode(getString(R.string.clientID))
             .requestEmail()
             .requestScopes(new Scope(Scopes.PLUS_LOGIN),
                     new Scope(PeopleScopes.CONTACTS_READONLY),
                     new Scope(PeopleScopes.USER_PHONENUMBERS_READ))
             .build();

GoogleApiClient

Next we build an instance of the GoogleApiClient. This helps handling whether Play Services exists on our app and handles it accordingly.

// To connect with Google Play Services and Sign In
        mGoogleApiClient = new GoogleApiClient.Builder(this)
                .enableAutoManage(this, this)
                .addOnConnectionFailedListener(this)
                .addConnectionCallbacks(this)
                .addApi(Auth.GOOGLE_SIGN_IN_API, signInOptions)
                .build();

While you're at it, you can implement the GoogleApiClient.OnConnectionFailedListener and GoogleApiClient.ConnectionCallbacks interfaces. They're pretty handy! We won't take any chances with whether the needed APIs are available or not. So let's add a safety check if the connection fails. This code snippet fetches the error message and displays it in a dialog.

@Override
public void onConnectionFailed(@NonNull ConnectionResult connectionResult) {
    GoogleApiAvailability mGoogleApiAvailability = GoogleApiAvailability.getInstance();
    Dialog dialog = mGoogleApiAvailability.getErrorDialog(this, connectionResult.getErrorCode(), RC_API_CHECK);
    dialog.show();
}

Enable your API Client connection in the onStart() method.

@Override
  protected void onStart() {
      super.onStart();
      mGoogleApiClient.connect();
  }

Google Sign-in Click Listener

Lastly, we define the on-click action for our Google Sign In button.

@Override
   public void onClick(View v) {
       switch (v.getId()) {
           case R.id.main_googlesigninbtn:
               getIdToken();
               break;
       }
   }

   private void getIdToken() {
       // Shows an account picker to let the user choose a Google account from the device.
       // If the GoogleSignInOptions only asks for IDToken and/or profile and/or email then no
       // consent screen will be shown here.
       Intent signInIntent = Auth.GoogleSignInApi.getSignInIntent(mGoogleApiClient);
       startActivityForResult(signInIntent, RC_INTENT);
   }

Note RC_INTENT here. It's simply a request code, used to recognize the results returned from the sign-in. We can handle this in onActivityResult().

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    super.onActivityResult(requestCode, resultCode, data);

    switch (requestCode) {
        case RC_INTENT:
            GoogleSignInResult result = Auth.GoogleSignInApi.getSignInResultFromIntent(data);

            if (result.isSuccess()) {
                GoogleSignInAccount acct = result.getSignInAccount();
                Log.d(TAG, "onActivityResult:GET_TOKEN:success:" + result.getStatus().isSuccess());
                // This is what we need to exchange with the server.
                new PeoplesAsync().execute(acct.getServerAuthCode());

            } else {
                Log.d(TAG, result.getStatus().toString() + "\nmsg: " + result.getStatus().getStatusMessage());
            }
            break;
    }
}

We can verify the success of the sign-in using GoogleSignInResult. Use the result to fetch the server auth code. We now have what we need to authenticate our calls to the People API.

Finally, People API

I can't believe it took us one and a half posts to get to the actual thing! So without wasting time, let's start implementing this. Here's 3 things we need to do:

Exchange the server auth code we got for a token response
Create a credential using the response
Use the credentials to obtain an instance of People API

Simple? The code snippet below demonstrates this.

public static People setUp(Context context, String serverAuthCode) throws IOException {
       HttpTransport httpTransport = new NetHttpTransport();
       JacksonFactory jsonFactory = JacksonFactory.getDefaultInstance();

       // Redirect URL for web based applications.
       // Can be empty too.
       String redirectUrl = "urn:ietf:wg:oauth:2.0:oob";

       // STEP 1
       GoogleTokenResponse tokenResponse = new GoogleAuthorizationCodeTokenRequest(
               httpTransport,
               jsonFactory,
               context.getString(R.string.clientID),
               context.getString(R.string.clientSecret),
               serverAuthCode,
               redirectUrl).execute();

       // STEP 2
       GoogleCredential credential = new GoogleCredential.Builder()
               .setClientSecrets(context.getString(R.string.clientID), context.getString(R.string.clientSecret))
               .setTransport(httpTransport)
               .setJsonFactory(jsonFactory)
               .build();

       credential.setFromTokenResponse(tokenResponse);
 
       // STEP 3
       return new People.Builder(httpTransport, jsonFactory, credential)
               .setApplicationName(APPLICATION_NAME)
               .build();
   }

Pass in the server auth code you obtained from the sign-in result in the previous step. Again, notice how I'm referencing my Client ID and Client Secret here. They are simply strings. But you must JSON parse them from the google-services.json file. NOTE: Use the Client ID and Secret of your Web client and NOT Android Client!

Calling it in

With the above setUp() method done, we just need to call it.

People peopleService = setUp(MainActivity.this, serverAuthCode);

ListConnectionsResponse response = peopleService.people().connections()
                                   .list("people/me")
                        .setRequestMaskIncludeField("person.names,person.emailAddresses,person.phoneNumbers")
                                   .execute();

List connections = response.getConnections();

We're pretty much done! We now have a list of our connections, and we get get a lot of information from that. You would have noticed I requested Scopes for contacts and their phone numbers during Sign-in. So let's see an example for fetching phone numbers. NOTE: Use must the setRequestMaskIncludeField() method to specify which data fields you want to request. Omitting this 'ideally' means the API will return ALL data sets under the sun. But that doesn't happen, and is a known issue. Check this SO post for more. Here's the full list of People API scopes. Once you fetch the connections into a list, simply iterate through it to fetch data.

for (Person person : connections) {
    if (!person.isEmpty()) {
       List phoneNumbers = person.getPhoneNumbers();

       if (phoneNumbers != null)
          for (PhoneNumber phoneNumber : phoneNumbers)
               Log.d(TAG, "phone: " + phoneNumber.getValue());

Hope the code there is self-explanatory. Fetching the phone numbers from a person, is yet another list. So we simply iterate down another level to fetch the phone numbers. Simple as that. If you want the email IDs, it is person.getEmailAddresses(). You'd be surprised to know the rich data that the People API allows you to access. Here's the complete list for your reference. Just keep in mind good UX and wrap all these calls in an AsyncTask. Show a progress indicator if it takes too long to load.

Final Output

Here's a little demo of how the API works.

Ideally upon first launch, the app will display an account picker and then request permissions. Of course I'm only displaying the name from the People API. But I'm printing the rest to the logs. You can check out the source code for this on GitHub.

Wrapping it up

That's it for this two-part post on the People API. Hope you've got a good feel about how powerful the API can be. In fact Google plans to completely replace the Contacts API with People API in the near future. So now's a really good time to migrate! Plus, you can even query one's Google+ related data from this API. While configuration might seem to be a handful, the long-term usefulness of the API far outweighs it. So what do you think? Know anything important I might have missed? Any cool features it has, that I'm not aware of? Drop 'em in the comments below!

Bottom Navigation Bar Android Tutorial

Tue, 22 Mar 2016 00:00:00 GMT

One of the newest additions to the Material Design is the Bottom Navigation Bar. Its like the TabBar you see on iOS, and similar in functionality too.

Android Bottom Navigation

Facebook iOS App

Before getting to the tutorial, let's get to know what Bottom Navigation is. Also let's narrow down on the best scenarios to use it.

What is Bottom Navigation?

Bottom navigation bars make it easy to explore and switch between top-level views in a single tap. - Material Design spec

This helps developers opt for Bottom Navigation, instead of a Navigation Drawer.

If you have about four top-level navigation items, its ideal to use Bottom Navigation. Otherwise, go for a Navigation Drawer. We don’t want the Bottom Navigation looking too crowded now, do we?

This was already common for iOS apps. But now, a lot of Android apps have started adapting this. To name a few, the YouTube app recently made the switch.

Bottom Navigation was recently adopted by the Android Youtube app

When to use?

A Bottom Navigation is best used when you have three to five top-level navigation items of similar importance.

Until now, the default, go-to navigation solution is the Navigation Drawer. Would you agree?

Grab all your screens, throw them in the Navigation Drawer and we're done. I don't blame you. Once upon a time, I was guilty of the same.

For just 4 navigation screens, would you use an entire Navigation Drawer for it? Besides, that huge side menu is hidden away by a tiny hamburger menu.

Think of the benefits a Bottom Navigation provides:

always visible - its omnipresent no matter which of the 4 screens you visit
simpler - lesser the options, easier to remember

So given all that, in such a scenario, a Bottom Navigation will serve you the best.

A simpler way to look at it –

If all that seems too complex, then just keep the number of navigation screens in mind.

2 screens - Tabs
3 to 5 screens - Bottom Navigation
5 and above - Navigation Drawer

Easy enough? Now let's move on.

Getting Started

I must admit the Bottom Navigation looks pretty cool. I noticed Aurelien Hubert has a fancy Bottom Navigation library. So let’s use that for this tutorial.

NOTE
Android Design Support Library provides a Bottom Navigation Bar too. But compared to this one, what we can do with it is currently limited. Hence, to know what all is possible with the Bottom Bar, we’ll go with Hubert’s library.

However, if you want to use the Design Support Library instead, this tutorial’s got you covered.

But seriously, read this first. This one’s got all the bells and whistles!

First, start by adding the library’s dependency to your **app/**build.gradle file.

dependencies { compile 'com.aurelhubert:ahbottomnavigation:0.1.3' }

NOTE
I hope your app supports minSdk >14. If not, make sure you do, because this library supports 14 and above only. Seriously, why are you supporting 0.99% of the (ancient) devices!?

Adding Bottom Navigation to Layout

Make sure your parent layout is a CoordinatorLayout. This ensures the Bottom Navigation behaves correctly with Snackbar and FAB.

<android.support.design.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools" android:id="@+id/coordinator" android:layout_width="match_parent" android:layout_height="match_parent">

<android.support.design.widget.AppBarLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <android.support.v7.widget.Toolbar
        android:id="@+id/toolbar"
        android:layout_width="match_parent"
        android:layout_height="?attr/actionBarSize"
        android:background="?attr/colorPrimary"/>

</android.support.design.widget.AppBarLayout>

<FrameLayout
    android:id="@+id/frame"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:layout_behavior="@string/appbar_scrolling_view_behavior"
    tools:background="#EFEFEF"/>

<com.aurelhubert.ahbottomnavigation.AHBottomNavigation
    android:id="@+id/bottom_navigation"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:layout_gravity="bottom"/>

</android.support.design.widget.CoordinatorLayout>

The FrameLayout with ID @+id/frame is the placeholder UI to load our Fragment.

Moving onto Java

Each Bottom Navigation bar item denotes a different color. For demonstration purposes, each item click will change the Fragment’s view color. But ideally, you’ll want to load a different Fragment for each item.

Initializing and using the Bottom Navigation is easy as one two three. I ain’t even kidding. See for yourself!

1. Create your Items

There are different constructors you can use to define your Bottom Navigation items.

At the least, you must provide a title and icon. In other words, a String and Drawable.

Both parameters can be hardcoded Strings. But for the sake of good practice, lets reference both from XML resources.

AHBottomNavigationItem item1 = new AHBottomNavigationItem(R.string.bottomnav_title_0, R.drawable.ic_map_24dp);

2. Add Bottom Navigation items

Once you’ve defined the number of items, its time to add them to the Bottom Navigation.

Use the following method to do so.

bottomNavigation.addItem(item1);

3. Set Listener

Finally, you need to listen to item clicks. So add the following to your Fragment.

bottomNavigation.setOnTabSelectedListener(new AHBottomNavigation.OnTabSelectedListener() { @Override public void onTabSelected(int position, boolean wasSelected) { fragment.updateColor(Color.parseColor(colors[position])); } });

I have a tiny card layout centered in my Fragment layout. Depending on the item click, I change its color.

Also, don’t forget to set your default item. This item depicts the default (home) screen which people will see.

// Setting the very 1st item as home screen.
bottomNavigation.setCurrentItem(0);

Ideally, you’d want to change the Fragment here. The same way when creating a Navigation Drawer in Android.

Styling Bottom Navigation

Off the bat, the library provides considerable styling options. But after recent updates, there has been a lot more.

Some of these additions include notification badges and coordinating behaviors. It also includes on-scroll Quick Return pattern.

Its all that one could ever want with the Bottom Navigation. This library is much more feature-rich than what Android Design Support Library offers. So if you want more customization options and more control, you know what to use.

Before we get to that, here’s a heads-up. We’ll be using and referencing a lot of colors. Normally, we reference colors in Android like this:

ContextCompat.getColor(context, R.id.yourcolor);

Now I’m no fan of writing such a lengthy line for fetching a simple color resource.

So I’ll write a simple method that shortens what I have to type.

private int fetchColor(@ColorRes int color) { return ContextCompat.getColor(this, color); }

Great! From now on I don’t have to write long lines. This simple method call will do to fetch my color resource.

TIP
Hiding the complexities of a system by providing a simpler interface is known as the Facade Design Pattern.

With that out of the way, let’s look at implementing all the possible styling options.

Simple Theming

At the most basic level, the Bottom Navigation requires these attributes:

Default background color
Accent color - highlights active items
Inactive color - (you guessed it!) color for inactive items

bottomNavigation.setDefaultBackgroundColor(Color.WHITE); bottomNavigation.setAccentColor(fetchColor(R.color.yourAccentColor)); bottomNavigation.setInactiveColor(fetchColor(R.color.yourInactiveColor));

With such basic styling, you can expect your Bottom Navigation to look like this.

Bottom Navigation with basic styling

Color Ripple Effects

You can take styling a step further by using a color ripple.

Yes, I’m talking about this.

Bottom Navigation with Color Ripple

The good news is that its easy to enable a colored ripple.

// Enables color Reveal effect bottomNavigation.setColored(true); // Colors for selected (active) and non-selected items (in color reveal mode). bottomNavigation.setColoredModeColors(Color.WHITE, fetchColor(R.color.bottomtab_item_resting));

setColoredModeColors() defines the colors for items when using color ripple.

Text Labels

Here’s what the Material Design documentation tells us. If Bottom Navigation has:

3 items - display icon and text always for all items
4-5 items - display text for active icon only and hide for inactive views

Now, you might have a good guess on what I’m going to say next.

“This is what the Material Design guidelines suggest, so let’s do just that”.

But this time I won’t. I disagree, and so should you. I’ll tell you why.

The Material Design guidelines aren’t always right

Whether you have 3 or 5 items in your Bottom Navigation, always show text labels!

By doing so, you’ll avoid the mystery meat navigation problem that plagues Material Design.

Buttons or links that don’t explain to you what they do. Instead, you have to click on them to find out

Mystery Meat Navigation

I’m sure we’ve all been victims of this at some point at least. We click on a button assuming it to do something, only for it to do something else entirely!

So do yourselves, and your users a favor. Always, show text labels for your Bottom Navigation icons.

bottomNavigation.setTitleState(AHBottomNavigation.TitleState.ALWAYS_SHOW);

I did my part to give good UX. What about you?

Translucent Bottom Navigation

First, you create an app Theme that supports translucent navigation.

...

Next, in your AndroidManifest.xml, apply this Theme to your Bottom Navigation Activity.

... ...

Finally, the last step is to add one simple line to YourActivity.java.

bottomNavigation.setTranslucentNavigationEnabled(true);

NOTE
Disable Instant Run if you observe weird UI glitches. I've disabled mine by default.

Behaviors

The library allows on-scroll animation for the Bottom Navigation Bar. It also supports a Translucent Theme for the same.

'Quick Return' Animation

A View can scroll off-screen with the content and return when the user reverse scrolls.

Quick Return

Hide on scroll - Quick Return

This is a popular Animation pattern that helps maximize screen estate while scrolling. Usually the Quick Return animation pattern is used for Toolbars.

The good new is, this library allows us to enable the same for Bottom Navigation. You just have to add this simple line.

bottomNavigation.setBehaviorTranslationEnabled(true);

Translucent Navigation with Quick Return

Now you might get ambitious and want to combine both. A translucent Bottom Navigation and Quick Return pattern.

While I applaud your bravery, there’s a small hiccup in making both work together. You already might have set up a Translucent Navigation.

But once you enable Quick Return, you might notice the scroll not behaving as expected. The Toolbar might appear clipped. No amount of fitsSystemWindows will help.

Toolbar clipping with Translucent bar + quick return

That’s the hiccup I’m talking about.

But don’t worry. I’ll tell you how to fix this. Its not perfect, but it gets the job done.

All you have to do is alter your AppBarLayout. Add a View as a child to your AppBarLayout, above the Toolbar View.. This View should have a height equal to the StatusBar, which is 24dp.

<android.support.design.widget.CoordinatorLayout > <android.support.design.widget.AppBarLayout>

  <LinearLayout
  android:orientation="vertical">
     <View
    android:layout_width="match_parent"
       	android:layout_height="@dimen/statusBarSize" />

   	   <android.support.v7.widget.Toolbar
        	android:id="@+id/toolbar"
       	android:layout_width="match_parent"
       	android:layout_height="?attr/actionBarSize"
       	android:background="?attr/colorPrimary"/>
</LinearLayout>

</android.support.design.widget.AppBarLayout>

<FrameLayout
    android:id="@+id/frame"
    app:layout_behavior="@string/appbar_scrolling_view_behavior"/>

<com.aurelhubert.ahbottomnavigation.AHBottomNavigation
    android:id="@+id/bottom_navigation"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:layout_gravity="bottom"/>

</android.support.design.widget.CoordinatorLayout>

TIP
AppBarLayout is a vertical LinearLayout that determines scrolling behavior of its child Views.

Translucent bar with quick return

Notification Badge

This again is simple. For the sake of demonstration, I’ll show you by creating a dummy notification.

Show notification

Let’s say I want to show a notification count of 1, for the last item. We can use the library's AHNotification class for this.

private void createFakeNotification() { new Handler().postDelayed(new Runnable() { @Override public void run() { AHNotification notification = new AHNotification.Builder() .setText("1") .setBackgroundColor(Color.YELLOW) .setTextColor(Color.BLACK) .build(); // Adding notification to last item.

           bottomNavigation.setNotification(notification, bottomNavigation.getItemsCount() - 1);

           notificationVisible = true;
       }
   }, 1000);

}

The Builder allows us to customize the text, its color and the background. Then, remember to set that notification to the Bottom Navigation item.

Notification Badge

Remove notification

In the above code snippet, I used a boolean notificationVisible. It tells us whether the notification badge is currently visible or not.

A notification must be removed or dismissed once we tap the respective item. We can do this in 2 simple steps:

detect the item click via OnTabSelectedListener
check if notification is visible and remove it

bottomNavigation.setOnTabSelectedListener(new AHBottomNavigation.OnTabSelectedListener() { @Override public boolean onTabSelected(int position, boolean wasSelected) {

    //TODO: update Fragment here

         // remove notification badge
   int lastItemPos = bottomNavigation.getItemsCount() - 1;
         if (notificationVisible && position == lastItemPos)
             bottomNavigation.setNotification(new AHNotification(), lastItemPos);

         return true;
     }
 });

To remove a notification, we set an EMPTY notification for that item. That is all there is to it.

Dismissing notification badge

Managing Bottom Navigation with Fragments

It’s pretty obvious by now that each Bottom Bar’s item manages a Fragment.

To put it in other words, you could say it’s similar to Material Tabs with a ViewPager. Except you can’t swipe.

Maintaining Fragments with ViewPager

Now that we’ve decided on using a ViewPager to handle our Fragments, we need to write an Adapter.

For that, we have two choices:

Now, depending on your use case, choosing between the two can make all the difference. But I’ll spare you all the rambling and state it simply.

Using a **FragmentStatePagerAdapter** is more useful when there are a large number of pages. It holds on to much less memory associated with each visited page.

Okay, our Bottom Navigation has three items, but it can go up to five. So considering the extreme scenario, we can have five resource-heavy Fragments. So you can do your app a favour and use a **FragmentStatePagerAdapter**.

But if you’re interested in knowing in depth, this SO post has all the answers.

Creating the ViewPager Adapter

There’s a ‘smart’ implementation of FragmentStatePagerAdapter that allows us to access already existing Fragments from the Adapter. So go ahead and grab it from this GitHub gist.

Next, to actually use this, we need to create our Adapter that extends SmartFragmentStatePagerAdapter. So let’s call it BottomBarAdapter.

public class BottomBarAdapter extends SmartFragmentStatePagerAdapter { private final List fragments = new ArrayList<>();

public BottomBarAdapter(FragmentManager fragmentManager) {
    super(fragmentManager);
}

// Our custom method that populates this Adapter with Fragments public void addFragments(Fragment fragment) { fragments.add(fragment); } @Override public Fragment getItem(int position) { return fragments.get(position); }

@Override
public int getCount() {
    return fragments.size();
}

}

Nothing fancy here. Just note the List<Fragment> that our Adapter uses here.

NOTE
In future if you want to fetch a particular Fragment, you can do it using **pagerAdapter.getRegisteredFragment(position)**.

Now that our Adapter is ready, we need to connect it to the ViewPager. But wait. Not so fast!

There is one tiny change we need to do to the ViewPager. Swiping must be disabled.

Disable swiping on ViewPager

The easiest way is to create a custom ViewPager. So let’s create a new class extending ViewPager. I call it NoSwipePager, for the lack of a better name.

public class NoSwipePager extends ViewPager { private boolean enabled;

public NoSwipePager(Context context, AttributeSet attrs) { super(context, attrs); this.enabled = true; }

@Override public boolean onTouchEvent(MotionEvent event) { if (this.enabled) { return super.onTouchEvent(event); } return false; }

@Override public boolean onInterceptTouchEvent(MotionEvent event) { if (this.enabled) { return super.onInterceptTouchEvent(event); } return false; }

public void setPagingEnabled(boolean enabled) { this.enabled = enabled; } }

NOTE
Make sure you reference NoSwipePager in your XML layout instead of a regular ViewPager.

Once, you initialize your ViewPager in Activity, you need to explicitly disable swiping. You can do it with a single line.

viewPager.setPagingEnabled(false);

With the previous step, our Adapter and ViewPager is now ready to roll. The final step is to create our Fragments, then pass them to the Adapter and finally connect the Adapter with ViewPager.

Connecting ViewPager with PagerAdapter

Let’s create a simple Fragment called DummyFragment. It accepts one argument “color”. Using a different color will tell us which Fragmentinstance is shown when we use the Bottom Navigation.

Once your Fragment is ready, let’s get to completing our ViewPager.

1. Set up ViewPager

// init UI viewPager.setPagingEnabled(false);

2. Initialize PagerAdapter

pagerAdapter = new BottomBarAdapter(getSupportFragmentManager());

3. Create Fragments and add them to Adapter

Bundle bundle = new Bundle(); bundle.putInt("color", color);

DummyFragment fragment = new DummyFragment(); fragment.setArguments(bundle);

pagerAdapter.addFragments(fragment);

4. Finally, set the **ViewPager** Adapter

viewPager.setAdapter(pagerAdapter);

Handling Click Events

Hang in there, we’re almost done!

Since we disabled ViewPager swiping, the only way to switch Fragments is by clicking the Bottom Navigation Items. So we need to manually handle those click events!

Don’t worry, it’s dead simple. See for yourself!

bottomNavigation.setOnTabSelectedListener(new AHBottomNavigation.OnTabSelectedListener() { @Override public boolean onTabSelected(int position, boolean wasSelected) {

             **if (!wasSelected)**
                 **viewPager.setCurrentItem(position);**

return true; } });

The click listener provides us a useful boolean that tells us if the current click is happening on an already selected item. So we simply need to change the Fragment when this is NOT the case.

That’s all there is to it.

Output

Just to give you a visual on how all that code works, here’s a GIF of everything put together.

Where to, from here?

The Bottom Navigation is the newest entry in Material Design. It pushes us to rethink our navigation structures.

At first, it might be confusing. But I hope this post has helped clear the air.

SOURCE CODE:
Available on GitHub.

Other Options

Bottom Navigation Bar by roughike
Clearly its the more popular one. But this library seems to work just as fine, so there’s no cause for alarm.
Official Bottom Navigation by Design Support Library
However, it is very limited in options in terms of styling and customization.

Wrap Up

So what do you think about Bottom Navigation? It is very common in iOS but I’m excited to see how we’re going to use it in Android.

A lot of Android apps have already adopted it (Instagram, Google+ and Quora to name a few). What about you? Let me know in the comments below.

Bottom Sheet with Android Design Support Library

Thu, 17 Mar 2016 00:00:00 GMT

Version 23.2 of the Android Support library is a huge update. The Design Support Library made Material Design easy. The new update made it a step easier by adding my personal favorite, Bottom Sheet! In this post, we'll look into making just that.

What's a Bottom Sheet?

A Bottom Sheet is a sheet of material that slides up from the bottom edge of the screen. Displayed only as a result of a user-initiated action, and can be swiped up to reveal additional content. It can be a temporary modal surface or a persistent structural element of an app. - Material Design Spec

Here are some examples:

We'll be making the exact Bottom Sheet on the right (excluding the map).

Getting Started

Start off by updating your support libraries to 23.2.0.

dependencies {
    compile fileTree(include: ['*.jar'], dir: 'libs')
    compile 'com.android.support:appcompat-v7:23.2.0'
    compile 'com.android.support:design:23.2.0'
    ...
}

Also, for this tutorial I’m using:

Build Tools v 23.0.2
Android Studio 1.5.1
Gradle (Build Tools) 1.5.0

If you aren’t familiar with the Design Support Library, now is the time to do so. Read these Design Support Library tutorials:

Adding a Bottom Sheet via XML

For those familiar, we include our scrollable view within CoordinatorLayout, below AppBarLayout in XML. To include a Bottom Sheet, we add it below our scrollable view. NOTE: The Bottom Sheet does not use any special tag. It is just a NestedScrollView using a Behavior.

For the sake of clarity, you might want to include the Bottom Sheet XML via a separate file. To keep it simple, I've only included the XML's hierarchy. But here's my complete layout. Note the layout_behavior attribute for the NestedScrollView. It refers to the BottomSheetBehavior provided by the Design Support Library. In this way, we’re telling CoordinatorLayout we want NestedScrollView to behave like a Bottom Sheet. By default, only a part of the Bottom Sheet is visible. We drag to expand, and continue scrolling. Use behavior_peekHeight to define how much of the Bottom Sheet you want visible. Yep, that's all you pretty much need to get Bottom Sheet working. Just pure XML. This is what the Design Support Library has been about. Easy Material Design. So far, here's what we got.

But I'm sure we're not here for just that? What if you want to listen to state changes? The folks at Android figured you'd want to. So they provided a set of neat flags. Sweet!

Listening to Bottom Sheet state changes

If you read the official blog post about 23.2, you'd notice the Google Maps Bottom Sheet. The Floating Action Button there, caught my eye. Its a perfect UI element to demonstrate the callbacks.

Action Plan

Here's what we're going to do. Let the Floating Action Button (FAB), be visible when the Bottom Sheet is resting (not expanded). It becomes invisible once the Bottom Sheet expands. We'll handle FAB's visiblity with a neat grow / shrink animation.

Grow / Shrink Animation

These animations are defined in XML. You can get the animations from here. Then simply reference these animations in your Activity like this:

Animation growAnimation = AnimationUtils.loadAnimation(this, R.anim.grow);
Animation shrinkAnimation = AnimationUtils.loadAnimation(this, R.anim.shrink);

Listening to State Changes

Now, onto the real deal. First, reference the Bottom Sheet from your CoordinatorLayout.

CoordinatorLayout coordinatorLayout = (CoordinatorLayout) findViewById(R.id.coordinator);
View bottomSheet = coordinatorLayout.findViewById(R.id.bottom_sheet);

BottomSheetBehavior behavior = BottomSheetBehavior.from(bottomSheet);

Don't forget to reference your FAB. Notice that we've also referenced the BottomSheet's Behavior. This is needed to set the callback. Attach a BottomSheetCallback() to your behavior object. It provides 2 methods to override:

onStateChanged()
onSlide()

onStateChanged()

There are 5 flags in total:

STATE_DRAGGING: intermediate state while the user is dragging the bottom sheet up or down
STATE_COLLAPSED: default state
STATE_EXPANDED: fully expanded state of the bottom sheet.
STATE_HIDDEN: allows users to swipe down on the bottom sheet to completely hide it. Disabled by default
STATE_SETTLING: brief time between when the View is released and settling into its final position

Only the first 3, among 5 is what we need. Your onStateChanged() method will look like this:

behavior.setBottomSheetCallback(new BottomSheetBehavior.BottomSheetCallback() {
          @Override
          public void onStateChanged(@NonNull View bottomSheet, int newState) {

              switch (newState) {
                  case BottomSheetBehavior.STATE_DRAGGING:
                      if (showFAB)
                          fab.startAnimation(shrinkAnimation);
                      break;

                  case BottomSheetBehavior.STATE_COLLAPSED:
                      showFAB = true;
                      fab.setVisibility(View.VISIBLE);
                      fab.startAnimation(growAnimation);
                      break;

                  case BottomSheetBehavior.STATE_EXPANDED:
                      showFAB = false;
                      break;
              }
          }
        ...
      });

While the Bottom Sheet is dragged, we want to shrink the FAB. STATE_COLLAPSED is the default resting position of the bottom sheet. This is where we want our FAB to appear with a grow animation. showFAB is a Boolean that tracks if the FAB needs to be shown or not while dragged. ALTERNATE APPROACH: Here's another way to do the FAB animation. Adjust the rate of growing / shrinking depending on the rate of the Bottom Sheet's drag. Grow if you drag down, shrink if you drag up. I leave that for you to try. With all this in place, lets see how our Bottom Sheet looks now.

Final Output

Our Bottom Sheet sure does have some life now doesn't it? With the help of its callbacks, we were also able to do this nice little grow / shrink animation. The new Android Support Library 23.2 is a nice update, with Bottom Sheets added to it, just made it better. SOURCE CODE: GitHub What designs did you come up with? Drop 'em in the comments below. Or share the post if you liked it!

Android SQLite Database Tutorial with Sugar ORM

Mon, 22 Feb 2016 00:00:00 GMT

SQLite database is one way to store your app’s data locally in Android. In this Android SQLite Database tutorial, I’m here to show you an easier way to it. Using Sugar ORM.

Insanely easy way to work with Android Databases. - Sugar ORM

Here are other storage options you could check out. Typically using SQLite in Android required a lot of boilerplate code, which took considerable time. But with Sugar ORM, all you need is a model (bean) class and you’re good to go. Taking the example of a note app similar to Google Keep, we’ll see how to:

Add a new note (save)
Delete note
Modify

Setting up Sugar ORM

Add this under your build.gradle dependencies block:

compile 'com.github.satyan:sugar:1.4'

Modify your AndroidManifest.xml as follows:

…

Designing Entities

A model (bean) class which extends SugarRecord is all you need. Sugar ORM will use the information in this class to automatically create a table. Awesome right? Since ours is a note app, the entity will simple be Note.

public class Note extends SugarRecord {

String title, note;
    long time;
    // Default constructor is important!
    public Note() {
    }

public Note(String title, String note, long time) {
        this.title = title;
        this.note = note;
        this.time = time;
    }
 …
// Getter setters here
}

The UI

For the scope of this tutorial, I will simple show you how my UI will look like. Let’s concentrate on how Sugar ORM works instead. There are just 2 screens:

Nothing complex here. Those are simple list detail views. I made quick work of it with the Design Support Library. If you’re unfamiliar with that, then these tutorials can help. READ ALSO:

I setup a StaggeredGridLayout for my RecyclerView, akin to Google Keep.

StaggeredGridLayoutManager gridLayoutManager =
        new StaggeredGridLayoutManager(2, StaggeredGridLayoutManager.VERTICAL);
gridLayoutManager.setGapStrategy(StaggeredGridLayoutManager.GAP_HANDLING_MOVE_ITEMS_BETWEEN_SPANS);
recyclerView.setLayoutManager(gridLayoutManager);

Now let’s move on to how we can easily perform basic database functions.

CRUD made easy with Sugar ORM

Create

Note note = new Note(title, desc, time);
note.save();

Update

Note note = Note.findById(Note.class, id);
note.title = “updated title here";
note.save();

Delete

Note note = Note.findById(Note.class, id);
note.delete();

Listing all notes

List notes = Note.listAll(Note.class);

Let’s take a small breather here. Were we able to do CRUD operations, in just one line each? That’s amazing!

Queries

What is SQL if you can’t use queries? Sugar has got you covered there too! There are 2 ways to do this. Let’s take an example to compare the two.

Raw Query

List notes = Note.findWithQuery(Note.class, "Select * from Note where name = ?", "mynote");

Query Builder

Select.from(Note.class)
.where(Condition.prop("title").eq("mynote"),
Condition.prop("description").eq("notedesc"))
.list();

From this point on, I highly encourage you to build a simple notes app on your own. Use this post and the link to Sugar's docs for reference. However, if you think you need help, don't worry, read on below.

Sugar ORM in our Notes app

Now that we have the basics done, let's see how Sugar ORM can help us make a simple Notes app. With most of the boilerplate code out of the way, this should be a snap. We've already seen how to add a note above. We do this in the AddNoteActivity.java class. Pretty simple.

Updating Notes

We can use the same Activity to update the existing note. We do this by passing an Intent from MainActivity.java. Here's the snippet:

List notes = Note.find(Note.class, "title = ?", title);
                 if (notes.size() > 0) {

                     Note note = notes.get(0);
                     note.title = newTitle;
                     note.note = newDesc;
                     note.time = newTime;

                     note.save();
                 }
              finish();

First fetch the Note from the database. I'm finding it based on the title, but ideally you'd do it using an ID of sorts. I simply update that note object with my new data and save, successfully updating it.

Making RecyclerView play nice with Sugar

Everything ultimately boils down to how your RecyclerView can display and update the notes. Make it play nice with the changes you do. Let's see how we can update our RecyclerView depending on changes such as deleting, adding and modifying a note. We initially display all notes saved via Sugar simply like this in your onCreate():

 notes = Note.listAll(Note.class);

adapter = new NotesAdapter(MainActivity.this, notes);
recyclerView.setAdapter(adapter);

Update RecylerView after creating a note

We return to MainActivit****y using finish(), after creating a new note in AddNoteActivity. So what get's triggered upon return? onResume(). So this is where we refresh our RecyclerView.

final long newCount = Note.count(Note.class);

    if (newCount > initialCount) {
        // A note is added

        // Just load the last added note (new)
        Note note = Note.last(Note.class);
        notes.add(note);
        adapter.notifyItemInserted((int) newCount);

        initialCount = newCount;
    }

Since the newly created note would be the last item added, we simply fetch that and notify our adapter of the same.

Deleting a note

I'm using Swipe to Dismiss to achieve this. Here's the logic:

final int position = viewHolder.getAdapterPosition();
               final Note note = notes.get(viewHolder.getAdapterPosition());
               notes.remove(viewHolder.getAdapterPosition());
               adapter.notifyItemRemoved(position);

               note.delete();
               initialCount -= 1;

               Snackbar.make(recyclerView, "Note deleted", Snackbar.LENGTH_SHORT)
                       .setAction("UNDO", new View.OnClickListener() {
                           @Override
                           public void onClick(View v) {

                               note.save();
                               notes.add(position, note);
                               adapter.notifyItemInserted(position);
                               initialCount += 1;

                           }
                       })
                       .show();

Observe that we take care of notifying our adapter here too, after an item is deleted via a swipe to dismiss. READ ALSO: Swipe to Dismiss for RecyclerView with ItemTouchHelper

Output

Now let's see Sugar work its magic. Watch on YouTube As you can see, Sugar ORM for Android really took away a lot of boilerplate code needed to start using SQLite in our apps. We took an example of a Note app as our use case, and this Android SQLite Database tutorial showed us how easy we can use databases thanks to Sugar ORM. As always, here's the source code link: GitHub What did you make with Sugar ORM? Drop 'em in the comments below, or subscribe for more tutorials like this!

Swipe to Dismiss for RecyclerView with ItemTouchHelper

Thu, 21 Jan 2016 00:00:00 GMT

A hidden gem in Android Support Library, is the built in Swipe to Dismiss functionality. Using the ItemTouchHelper class, we can add this to a RecyclerView.

Create a SimpleCallback

ItemTouchHelper.SimpleCallback simpleCallback = new ItemTouchHelper.SimpleCallback(0, ItemTouchHelper.LEFT | ItemTouchHelper.RIGHT) {

        @Override
        public boolean onMove(RecyclerView recyclerView, RecyclerView.ViewHolder viewHolder, RecyclerView.ViewHolder target) {
            return false;
        }

        @Override
        public void onSwiped(RecyclerView.ViewHolder viewHolder, int direction) {
            //Remove swiped item from list and notify the RecyclerView
        }
    };

The onSwiped() method is where you should remove the item. Don't forget to notify your RecyclerView! 2. Finally, create an ItemTouchHelper instance and attach it to RecyclerView.

ItemTouchHelper itemTouchHelper = new ItemTouchHelper(simpleCallback);
itemTouchHelper.attachToRecyclerView(recyclerView);

Onboarding with Android ViewPager: The Google Way

Wed, 16 Dec 2015 00:00:00 GMT

In this tutorial, learn to create an onboarding experience for your apps with Android ViewPager. Similar to the product tour app intro in Google Drive app. When you launch an app for the first time, you see the onboarding experience. It displays slides, highlighting features about the app with vibrant imagery. Let's make one for our app, the way Google does for theirs.

The 'Onboarding Experience'

Its also known as App Intro or Product Tour. Call it what you want, but its what every user sees when opening a new app. Also, every other app includes it. Google too. This type of Onboarding is known as Top User Benefits model, as noted in the Material Design spec.

Display a brief autoplay carousel (or animatic) highlighting up to three benefits of using the app. - material.google.com

When to use it?

According to specs, use it when your app uses new features or major changes. DO NOT use it to highlight common features your users expect your app to have. In short, avoid anything that is trivial. Because its is called 'Top User Benefits' for a reason ;)

We will replicate the Product Tour seen on the Google Drive Android App.

Upon first look, it may appear the background transitions color when the slide changes. But look closer and you'll will notice the drag changes color. In this tutorial we will:

create an onboarding experience for our app with ViewPager
control color transition while swiping
display these slides when launching app for the first time

Getting Started

Add the support libraries to your build.gradle file:

dependencies {
    compile 'com.android.support:appcompat-v7:23.1.1'
    compile 'com.android.support:design:23.1.1'
    ...
}

Here's what I'm using:

Android Studio 1.5.1
Build Tools v23.0.2
Support Libraries v23.1.1
Gradle 1.5.0

Let's use the updated App templates provided by Android Studio, to jumpstart this tutorial. Right click your package > New > Activity > Tabbed Activity. Then, set the Navigation Style to Swipe Views (ViewPager).

READ ALSO:

Tabbed Activity Template

I must say, this template did half the setup work for us. Brilliant! First, lets see what we have:

Our Activity (I called it PagerActivity)
SectionsPagerAdapter (ViewPager Adapter. Handles the slides)
PlaceholderFragment (responsible for each slide's layout)

So with all this in place, let's tweak it to our needs. Open your Activity layout.xml and do the following:

Remove the Toolbar
Add the button bar (which controls the ViewPager)

The button bar is what you noticed below the onboarding screen.

Layout:

Button Bar

Skip Button
Circle pager indicator (we're rolling our own here)
Next/ Finish Button

I wrapped all of this within a FrameLayout and added it to my Activity layout XML.

Fragment

Here's the layout breakdown for the ViewPager Fragment.

With the layout in place, lets get the onboarding to work with the ViewPager.

Controlling color with ViewPager

The pager adapter is already tied to the ViewPager, so thats one less to worry about. As we swipe through, the color updates itself. In other words, the distance offset by the swipe determines the amount of color to change. We will have 3 simple slides, with a set color for each.

int color1 = ContextCompat.getColor(this, R.color.cyan);
int color2 = ContextCompat.getColor(this, R.color.orange); 
int color3 = ContextCompat.getColor(this, R.color.green); 

int[] colorList = new int[]{color1, color2, color3};

We can detect changes to the ViewPager using the OnPageChangeListener; the meat of this tutorial.

mViewPager.addOnPageChangeListener(new ViewPager.OnPageChangeListener() {
     @Override
     public void onPageScrolled(int position, float positionOffset, int positionOffsetPixels) {
         
         /*
         color update
          */
         int colorUpdate = (Integer) evaluator.evaluate(positionOffset, colorList[position], colorList[position == 2 ? position : position + 1]);
         mViewPager.setBackgroundColor(colorUpdate);         
     }

     @Override
     public void onPageSelected(int position) {

         page = position;
         updateIndicators(page);

         switch (position) {
             case 0:
                 mViewPager.setBackgroundColor(color1);
                 break;
             case 1:
                 mViewPager.setBackgroundColor(color2);
                 break;
             case 2:
                 mViewPager.setBackgroundColor(color3);
                 break;
         }

         mNextBtn.setVisibility(position == 2 ? View.GONE : View.VISIBLE);
         mFinishBtn.setVisibility(position == 2 ? View.VISIBLE : View.GONE)
     }

     @Override
     public void onPageScrollStateChanged(int state) {

     }
 });

We've created a ArgbEvaluator object to update the color. The transition happens from the previous slide's color, to the next slide's color. The updateIndicators() method as you guessed, updates the pager indicators by toggling two drawables.

void updateIndicators(int position) {
      for (int i = 0; i < indicators.length; i++) {
          indicators[i].setBackgroundResource(
                  i == position ? R.drawable.indicator_selected : R.drawable.indicator_unselected
          );
      }
  }

NOTE: colorList[position == 2 ? position : position + 1] indicates that if the position is at the last slide, don't increment. Array size basics (goes from zero to (n-1). Otherwise this gives us an ArrayIndexOutOfBoundsException. The page variable helps track the ViewPager's current page position. Remember to increment this in your Next button's click listener! onPageSelected() method is where we handle setting the background color for each slide. Finally check if we're on the last slide and make the finish button visible.

Updating the Indicators

I toggle between two simple drawables for the pager indicators. indicator_selected.xml

indicator_unselected.xml

Calling it in

The onboarding screen is best called when the app is launched for the first time. This helps in making the user aware of what this app has to offer. However, from the second launch onwards, the app loads the home screen. We can achieve the same via a simple boolean SharedPreference. Alternatively, if your app introduces major changes in an update, highlighting them with onboarding screens is a good approach. Here are 2 handy utility methods for reading and saving a SharedPreference:

public static String readSharedSetting(Context ctx, String settingName, String defaultValue) {
      SharedPreferences sharedPref = ctx.getSharedPreferences(PREFERENCES_FILE, Context.MODE_PRIVATE);
      return sharedPref.getString(settingName, defaultValue);
  }

  public static void saveSharedSetting(Context ctx, String settingName, String settingValue) {
      SharedPreferences sharedPref = ctx.getSharedPreferences(PREFERENCES_FILE, Context.MODE_PRIVATE);
      SharedPreferences.Editor editor = sharedPref.edit();
      editor.putString(settingName, settingValue);
      editor.apply();
  }

Trigger first time launch

Check the SharedPreference before you set your Activity's layout. Then launch the onboarding if needed.

isUserFirstTime = Boolean.valueOf(Utils.readSharedSetting(MainActivity.this, PREF_USER_FIRST_TIME, "true"));

       Intent introIntent = new Intent(MainActivity.this, PagerActivity.class);
       introIntent.putExtra(PREF_USER_FIRST_TIME, isUserFirstTime);

       if (isUserFirstTime) 
           startActivity(introIntent);

Finally, to make the app know the onboarding is complete, we update this preference to false. Do this in your Finish button's click listener (The one we make visible on the last slide!).

mFinishBtn.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {

            finish();
            //  update 1st time pref
            Utils.saveSharedSetting(PagerActivity.this, MainActivity.PREF_USER_FIRST_TIME, "false");

        }
    });

APP INTRO LIBRARY: If you want a more simpler solution, or don't want deal with all this yourself, here's a library alternative by Paolo Rotolo. KOTLIN ALTERNATIVE: For all the Kotlin lovers out there, here's a library by Edgar Fernandes based on this post. Taking it Further If you're not satisfied with such a 'simplistic' implementation. Or if you want to take it to the next level. Say with added animations and PageTransformers, there's a brilliant post on Medium by Michell Bak that will help.

Final Output

Phew! That was quite some work. But hey, the new Activity templates in Android Studio took care of half the work, didn't it? We just modified the layout to our liking and made the ViewPager do a nice color transition. Here's the result: Watch on YouTube READ ALSO: How to make the Status Bar transparent SOURCE CODE: GitHub. That's a wrap for this post. We created a nice onboarding experience for our app's first time users. Used the ViewPager's scroll listeners to create a nice color transition on swipe. We even used a little SharedPreferences to display this screen for the first launch. My 'images' don't quite match with the ones you see on the Drive app. But I'm sure you can come up with something better! Drop 'em in the comments below.

Runtime Permissions - Android Marshmallow Tutorial

Thu, 26 Nov 2015 00:00:00 GMT

Runtime Permissions is a new permission model introduced in Android Marshmallow 6.0. Users are able to grant permissions during the app's runtime, rather than during app install. Let's look at leveraging the new runtime permissions for Android Marshmallow.

The Runtime Permission Model

As always, lets first see what good it does. The new permission model allows users to take control of permissions and decide what to grant when. This can be controlled from the App Info > App permissions section.

Good for users, not for developers

In pre Marshmallow, all permissions had to be granted during install time. An app at any point of time had access to ALL permissions it requested. The user had no choice but to accept them. But that has changed now. Runtime permissions give users control over the sensitive information they provide. They chose which apps can access what, and when they cannot. While this is good news for users, for a developer, it is not. Earlier we simply declared permissions in AndroidManifest.xml and we were on our way. But now apart from that, we need to check every time for a permission related task. Such as requesting the camera, calendar, contacts and so on. In addition, if the user denies the request permission, we need to handle that too. Phew! That's a lot of checking. You may wonder, "If I'm using the new permission model, what about pre Marshmallow devices?". Thankfully, implementing this gracefully falls back to the previous permission model on older devices. Great! That's one less to worry about.

Guidelines

Runtime permissions add a new dimension to your app's user experience. As an Android developer, you need to know WHEN and HOW to ask users for one, without annoying them. Design patterns for runtime permissions.

Getting Started

If there's one way to lessen our worries, its using a library. Like this one. The Permission Helper library will help us implement runtime permissions a whole lot easier! Start by adding the library to your apps' build.gradle file:

compile 'com.github.k0shk0sh:PermissionHelper:1.0.7'

Normal and Dangerous Permissions

That's how Android's permissions are categorized into two groups. The full list is here.

_C_over areas where your app needs to access data or resources outside the app's sandbox, but where there's very little risk to the user's privacy - Normal Permissions Dangerous permissions cover areas where the app wants data or resources that involve the user's private information - Dangerous Permissions

Android will automatically grant access for Normal Permissions. So runtime permissions really come into play for the Dangerous Permissions.

Requesting Runtime Permissions

I'm going to request the 'dangerous' permission of reading the calendar. So for reference sake, I declare it like this:

final String PERMISSION = Manifest.permission.READ_CALENDAR;

Let's bring the library's magic into play. Implement OnPermissionCallback in your Activity. You'll get the following methods:

onPermissionGranted() - permission requested, and successfully granted by user
onPermissionDeclined() - permission requested, but declined by user
onPermissionPreGranted() - requested permission is already granted (allowed via app permissions screen)
onPermissionNeedExplanation() - requested permission was denied, tell the user why you need it
onPermissionReallyDeclined() - requested permission was denied, and future requests were denied too. ( Can only be allowed from Settings now)
onNoPermissionNeeded() - fallback method for pre Marshmallow devices (older permissions model)

Firstly, initialize your PermissionsHelper:

permissionHelper = PermissionHelper.getInstance(this);

Then request your permission, say in your button's OnClickListener.

permissionHelper.setForceAccepting(false).request(PERMISSION);

setForceAccepting() helps ensure that the request doesn't force the user to grant permission. Next, override the Activity's onRequestPermissionsResult() method.

@Override
   public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
       permissionHelper.onRequestPermissionsResult(requestCode, permissions, grantResults);

   }

Handling Requested Permission

After requesting the permission, we need to handle:

Permission grant
Permission denial

1. Permission Grant

Override the Activity's onRequestPermissionsResult()

@Override
    public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {

        permissionHelper.onRequestPermissionsResult(requestCode, permissions, grantResults);

    }

If the user granted permission, then onPermissionGranted**()** is used, otherwise onPermissionDeclined() is called. In the user flow diagram, you can see that a denied permission can be requested again. If requested again, this time a system dialog doesn't appear. But the permission will be added to your app's Permissions screen, from where you can manually enable disable requested permissions.

So if you want to request a denied permission, use the onPermissionNeedExplanation() method. Use this to tell the user WHY you need that permission. I do it with a simple dialog explaining why.

AlertDialog dialog = new AlertDialog.Builder(this)
          .setTitle(title)
          .setMessage(message)
          .setPositiveButton("Request", new DialogInterface.OnClickListener() {
              @Override
              public void onClick(DialogInterface dialog, int which) {

                  permissionHelper.requestAfterExplanation(permission);

              }
          })
          .create();

  dialog.show();

Finally, if you're requesting for a permission that is already granted, then the onPermissionPreGranted() method comes really handy.

2. Permission Denial

Now what if the user denied permission? You need to handle that too. Since I'm requesting to read the calendar, if the user refuses to grant my request, I need a contingency plan. You can handle denial with the onPermissionDeclined() method. See the system dialog above, on the right? If the user checks 'Never ask again', then that permission can ONLY be enabled via the app's permissions screen found here:

You can handle this condition using the onPermissionReallyDeclined() method.

Fallback

Like I mentioned earlier. Devices running pre Marshmallow reverts to using the older permission model. This is automatically managed, since permissions are defined in AndroidManifest.xml. One less worry for us. Cheers!

Final Output

With everything in it's place, let's finally run our app and watch Runtime Permissions in action! In my demo, I've printed logs to a TextView. This way, you can see which methods are called when. Watch on YouTube

Source code on GitHub.

That's all for this post. I hope runtime permissions with Android Marshmallow is clear now. Especially thanks to the Permission Helper library. If this post helped you handle runtime permissions like a pro, considering sharing so others can benefit too. Cheers!

Google Chrome Custom Tabs Android Tutorial

Mon, 16 Nov 2015 00:00:00 GMT

Android Marshmallow introduced Chrome Custom Tabs. This allows us to load Web URLs natively from within our app. It leads to a more faster experience, with customizable options making Chrome Custom Tabs more akin to our app's branding. It's been a while since Android Marshmallow is out, along with a slew of new features for both users and developers. I feel now's the right time to start updating our apps, so existing Android Marshmallow users can take advantage of what's in store.

Android Marshmallow Chrome Custom Tabs are blazing fast! I mean just look at that speed. This is amazing progress. I remember how I dread clicking on an external link in Facebook, Twitter or Feedly. I used to cringe each time a Chrome browser opens slowly. You see, I’m no fan of mobile web browsing. But this will change that. Allowing UI customization and loading web content from WITHIN your app. This is something I’m looking forward to.

When to use it?

If your app redirects your users to third- party content, or URLs outside your domain, you need to use Chrome Custom Tabs. Here's why:

Native in-app loading experience
Chrome Custom Tabs load nearly twice as fast as WebView
Allows UI customization for Toolbar, bringing it closer to your branding
'Pre-warming' of browser in the background, allows for faster load times
Shared Cookie jar with Chrome

Frankly I've seen a couple of code samples, by Google and one on Medium.com, but those are fairly complex involving a lot of custom classes and helpers for the fallback. So I've decided NOT to go that way. Instead I'll show you a simple, straightforward way to achieve this. Because for developers, using a new feature must ease a task, not add to our burden. So let's get started with the Custom Chrome Tabs Android Tutorial.

Chrome Custom Tabs Library

Start by adding this line to your build.gradle file:

dependencies {
    compile 'com.android.support:customtabs:23.1.0'
}

I'm using Android Studio 1.4 and the updated Blank Activity template. This gives me a layout complete with a FAB and content holder, without having me to worry about initial setup. For my activity_main.xml, I've kept nothing but a FAB, which upon click will load my web URL in a Chrome Custom Tab. Also Read:

Fallback? No problem!

You may wonder about a fallback from Chrome Custom Tabs to WebView? Incase the user doesn't have Chrome. Let me clear a few things here.

Chrome Custom Tabs works with Chrome 45 & above
It is not exclusive to Android Marshmallow. (Just that it was introduced along with it!)

The good news is, we just need to worry about launching the Chrome Custom Tab. The support library takes care of the fallback for us. Which means, if the user doesn't have Chrome, it will load the same in a WebView. Neat!

Pre-Warming Chrome Custom Tab

I know Chrome Custom Tabs are fast. But when there's an option to make it faster, then why not? Pre-warming allows us to tell Chrome to warm up its browser, and initialize itself. We also tell it the URL which the user is likely to open. So since we'll do all this beforehand, when the user actually clicks a URL, launching Chrome Custom Tabs, they get a near instantaneous experience. Users hate to wait, so I strongly recommend you take advantage of pre-warming.

Custom Tabs Service Connection

To take advantage of pre-warming, we need to bind the CustomTabsService and initialize the CustomtabsClient in it's callback.

mCustomTabsServiceConnection = new CustomTabsServiceConnection() {
          @Override
          public void onCustomTabsServiceConnected(ComponentName componentName, CustomTabsClient customTabsClient) {

              //Pre-warming
              mClient = customTabsClient;
              mClient.warmup(0L);
              mCustomTabsSession = mClient.newSession(null);
          }

          @Override
          public void onServiceDisconnected(ComponentName name) {
              mClient = null;
          }
      };

After this, we bind the Service.

CustomTabsClient.bindCustomTabsService(MainActivity.this, CUSTOM_TAB_PACKAGE_NAME, mCustomTabsServiceConnection);

CUSTOM_TAB_PACKAGE_NAME is Chrome's package name. Which is "com.android.chrome". Note that in order to make pre-warming fully effective, make sure you to do this well in advance, giving considerable time between pre-warming and actually launching the URL.

Custom Tabs Intent Builder

With pre-warming done, next is to define a few launch options for Chrome Custom Tab. We do this using the CustomTabsIntent Builder.

customTabsIntent = new CustomTabsIntent.Builder(mCustomTabsSession)
              .setToolbarColor(ContextCompat.getColor(this, R.color.colorPrimary))
              .setShowTitle(true)
              .build();

There are a lot of customization options available with the Builder. I suggest you take your time, and define what you need. I've set the basics, my primary brand color and displayed the URL title. You can also define Chrome's enter and exit animations with setExitAnimations() & setStartAnimations() respectively. If you play around with the Builder, you will find options to set Action buttons, a Close button and even entire Menus. But let's keep it simple for now and process with the bare essentials.

Launching Chrome

Finally with every setup done, we're set to actually tell Chrome to load our URL. You can do so with this:

customTabsIntent.launchUrl(MainActivity.this, Uri.parse(URL));

Where URL is the String for any website. I've set it to my blog of course "https://blog.iamsuleiman.com/". Since I want my FAB to load Chrome Custom Tabs on click, I add the above line inside its onClick listener. As suggested earlier, I strongly suggest you pre-warm Chrome at the earliest to give it enough time to initialize. Given possible network slowdowns and other issues, it needs some time. That is all! Simply run your app and watch Chrome Custom Tabs in action! Watch on YouTube My test device runs Android Lollipop 5.1.1. Alternatively, you can even try it on an emulator (which does not have Chrome). It will switch to a WebView! Thats how the support library handles the fallback in Chrome's absence. SOURCE CODE: Available on GitHub.

Barely Scratched the Surface

Chrome Custom Tabs is a brilliant addition to the Android arsenal. Handling third party URLs has been bugging us from a long time now! It's finally great to see an elegant solution to this. However, there is a LOT more flexibility which Chrome Custom Tabs allow. I've only included essentials to get you started. Reducing the learning curve. But if you want to know everything that's under the hood, developer.chrome.com has you covered for reference.

Hope the tutorial helped you implement Chrome Custom Tabs easily. If you liked it, do considering sharing & subscribing. Cheers!

How to create an Image Gallery App with Glide - Android Tutorial

Mon, 26 Oct 2015 00:00:00 GMT

Let’s look at how fast we can create a simple image gallery app in Android using Glide. An image loading and caching library which takes care of almost everything for us.

Glide is a fast and efficient open source media management and image loading framework for Android that wraps media decoding, memory and disk caching, and resource pooling into a simple and easy to use interface.

We’ll be creating an image gallery app, pretty common for Android app development. We will use Glide to handle image loading and caching. Then load these images in fullscreen upon tap. This will use a ViewPager allowing us to swipe between images. After updating to Android Studio 1.4, I’m glad that they’ve updated the default app templates as well. We will be using this to make quick work of the app. Let’s get started.

Fire up Android Studio 1.4 and create a new app.

Minimum SDK: API 14 Android 4.0
Choose the ‘Blank Activity’ template and next, hit Finish//img on the right
Remove the Floating Action Button (FAB) from your layout and Activity
Include Glide in your build.gradle file: compile 'com.github.bumptech.glide:glide:3.6.1'
Add Android Support v4 library, since Glide depends on it

NOTE: I'm using grade version 1.4.0-beta3.

MainActivity

This simply consists of a RecyclerView, its adapter, item layout and its POJO model class.

Android Image Gallery Layout

As expected, Android Studio has already added a skeleton layout for us (courtesy of the Design Support Library). You should be pretty familiar with the Design Support library by now, so I’m just mentioning the layout skeleton here.

If you don’t know what the Design Support library is, I strongly suggest you do. You can get started here. It covers the basics. While its not really required for this tutorial, you’d be surprised at how the library lets you create popular design patterns with ease.

Image Gallery Item Layout

This is the layout for EACH item the RecyclerView will hold. Since ours is an Android image gallery app, it will be a grid layout with each item being a square holding the image.

Layout Item Model

Being familiar with RecyclerViews should tell you that it needs an Adapter and a custom layout. Also to bridge the layout and its data we will create a model POJO class ImageModel. This will contain getter setters for our data. For our image gallery app, just the image URL, and title will suffice.

public class ImageModel {

    String name, url;

    public ImageModel() {
    }
    // Getters & Setters here
 
}

QUICK TIP: To automatically generate getter setters, place your cursor on the variable you want to generate for. Hit Ctrl+Space, from the Generate popup, select Getter and Setter.

Layout Adapter

Adapter’s aren’t something that need a tutorial and I’m sure you’ve done this a hundred times yourselves, so go ahead and add that for me will ya? Here’s mine, just in incase ;-)

Using Glide to Load Images into Adapter

In the onBindViewHolder method is essentially where we ‘bind’ our data to each layout item, based on position. We’ll use Glide to load our images for us into the ImageView.

Glide.with(context).load(data.get(position).getUrl())
                   .thumbnail(0.5f)
                   .crossFade()
                   .diskCacheStrategy(DiskCacheStrategy.ALL)
                   .into(((MyItemHolder) holder).mImg);

The Glide API, is seriously fun to use. It shares a striking resemblance to Picasso, so Picasso users will feel right at home with Glide. Every Glide call starts with the with() method providing a context.

load() - provide the URL for Glide to load
thumbnail() - provide the size multiplier for thumbnail size
crossFade() - for a smoothly fading in the loading image into ImageView 4. diskCacheStrategy(ALL) - saves the source and result data (images) into cache. AKA faster loading, but larger cache. Alternatively use DiskCacheStrategy.RESULT 5. into(targetView) - this the layout ‘into’ which the image must be loaded.

Also, you can specify a placeholder and error layout for your ImageView with Glide, using the placeholder() and error() methods respectively.

Putting the Adapter Together

So far, you should have a RecyclerView, a RecyclerView adapter using the list_item.xml and the list model POJO class. With all this in check, lets head over to MainActivity.java and connect them together. NOTE: For this tutorial, I’m storing 10 image URLs in an array. I'm just going to use a regular boring Grid layout here. But if you're up for something more interesting like the StaggeredGridLayout (like in Pinterest), read Create a Pinterest Style Masonry Layout.

public class MainActivity extends AppCompatActivity {
…
ArrayList data = new ArrayList<>();
public static String IMGS[] = {
// Your image URLs here
};

@Override 
protected void onCreate(Bundle savedInstanceState) {
…
for (int i = 0; i < IMGS.length; i++) {
//	Adding images & title to POJO class and storing in Array (our data)
ImageModel imageModel = new ImageModel();
imageModel.setName("Image " + i);
imageModel.setUrl(IMGS[i]);
data.add(imageModel);
}
…
mRecyclerView = (RecyclerView) findViewById(R.id.list);
mRecyclerView.setLayoutManager(new GridLayoutManager(this, 3));
mRecyclerView.setHasFixedSize(true); // Helps improve performance

mAdapter = new GalleryAdapter(MainActivity.this, data);
mRecyclerView.setAdapter(mAdapter);
…
}
}

Go ahead, run your app now, you should get a nice grid getting populated with images loaded from the internet (courtesy of Glide). You can see how Glide loads in a low resolution image first and then transitions a higher quality one.

Give yourself a pat on the back for coming this far. Next, we’ll implement the Detail view; the fullscreen gallery complete with swiping between images.

Detail Activity

You needn’t alter anything in the DetailActivity’s layout so instead open your fragment_detail.xml layout. Simply throw in an ImageView and we’re done.

Android Studio ViewPager Template

Again, Android Studio 1.4 makes this easy for us with a prebuilt template we can use. Right click package > New > Activity > Tabbed Activity. In the dialog, make sure Navigation Style is set to Swipe Views (ViewPager). My Activity name is DetailActivity. Here’s the Activity structure for your reference:

public class DetailActivity extends AppCompatActivity {
…
@Override 
protected void onCreate(Bundle savedInstanceState) {
…
}

/**
* A FragmentPagerAdapter that returns a fragment corresponding to 
* one of the sections/tabs/pages.
*/
public class SectionsPagerAdapter extends FragmentPagerAdapter {
…
}

/**
* A placeholder fragment containing a simple view.
*/
public static class PlaceholderFragment extends Fragment {
…
@Override 
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View rootView = inflater.inflate(R.layout.fragment_detail, container, false);
…
return rootView;
}
}
}

Frankly, 80% of the setup process is already done. You have a Fragment setup, the ViewPager and its adapter as well. Everything is defined. All you need to do is point your data to it.

Passing ArrayList Data between Activities

Yes we’re aware of passing data between Activities using Intents and Bundles. But what if we want to pass an ArrayList holding a custom object? Like in our case ArrayList ? Simple. Make the class imageModel implement Parcelable. Now some of you may use Serializable, but here’s why its a bad idea. With this done, we can now pass this ArrayList via an Intent. So head back to MainActivity.java, add a click listener for your RecyclerView trigger the DetailActivity.

mRecyclerView.addOnItemTouchListener(new RecyclerItemClickListener(this,
        new RecyclerItemClickListener.OnItemClickListener() {

@Override 
public void onItemClick(View view, int position) {

Intent intent = new Intent(MainActivity.this, DetailActivity.class);
intent.putParcelableArrayListExtra("data", data);
intent.putExtra("pos", position);
startActivity(intent);

}
}));

I’ve declared my data variable like this: ArrayList data = new ArrayList<>(); NOTE: If you’re having trouble rolling in your own click listener for RecyclerView. You can just use this one instead as a more loosely coupled solution. Now you can retrieve your data in DetailActivity.java like this:

data = getIntent().getParcelableArrayListExtra("data");
pos = getIntent().getIntExtra("pos", 0);

Remember that in a typical gallery app, the Toolbar (ActionBar) will change name according to the image’s title. So upon launching this Activity, there must be an initial title. You can add one like this: setTitle(data.get(pos).getName()); Every time the ViewPager is swiped, the new image’s title must be updated. Do that using the ViewPager’s addOnPageChangeListener() method.

mViewPager.addOnPageChangeListener(new ViewPager.OnPageChangeListener() {
 	…
@Override 
public void onPageSelected(int position) {
setTitle(data.get(position).getName());
}
…
});

Passing Data to ViewPager Adapter

This can simply be done by passing your ArrayList data as a parameter to the SectionsPageAdapter. With this you can modify the adapter as such:

public SectionsPagerAdapter(FragmentManager fm, ArrayList data) {
    super(fm);
    this.data = data;
}

@Override 
public Fragment getItem(int position) {
return PlaceholderFragment.newInstance(position, data.get(position).getName(), data.get(position).getUrl());
}

@Override 
public int getCount() {
return data.size();
}

@Override 
public CharSequence getPageTitle(int position) {
return data.get(position).getName();
}

Now for the last step. Fetching the information passed in the PlaceHolderFragment’s newInstance() and using it to load the image in its layout.

Sending Data to Fragment using setArguments()

Android Studio gives me a warning saying passing data to Fragments via its constructor is a bad idea. So I’m going to trust that and use the setArguments() method for the same.

@Override 
public void setArguments(Bundle args) {
    super.setArguments(args);
    this.pos = args.getInt(ARG_SECTION_NUMBER);
    this.name = args.getString(ARG_IMG_TITLE);
    this.url = args.getString(ARG_IMG_URL);
}

public static PlaceholderFragment newInstance(int sectionNumber, String name, String url) {
PlaceholderFragment fragment = new PlaceholderFragment();
Bundle args = new Bundle();
args.putInt(ARG_SECTION_NUMBER, sectionNumber);
args.putString(ARG_IMG_TITLE, name);
args.putString(ARG_IMG_URL, url);
fragment.setArguments(args);
return fragment;
}

Note that the arguments passed in newInstance() is bundled and passed into the setArguments() method. This is the way of passing data to Fragments. In the setArguments() method, we can retrieve that data and handle them. So lastly, all that’s left is to let Glide work its magic in our Fragment’s ImageView.

ImageView imageView = (ImageView) rootView.findViewById(R.id.detail_image);

Glide.with(getActivity()).load(url).into(imageView);

That’s a wrap! Run your app and take a look. Your grid should now detect taps and load into fullscreen. Watch on YouTube For this tutorial, we focused on creating a simple gallery. However, we haven't looked into things like image gestures such as zoom and pan. Also, it would be nice if there were screen transition animations. Yes, Material Design animations. Part 2 of the image gallery tutorial covers transitions and gesture. No gallery app is without gestures, so it's definitely worth a read. Picasso VS Glide Picasso and Glide are very similar in terms of API, but Glide wins hands down in terms of pure speed. But the downside is slightly reduced image quality. Glide also has GIF support, which is another win over Picasso. You can view their comparison breakdown here.

We've seen how to rapidly create an Android image gallery app using Android Studio 1.4 Activity templates. Also handle images like a breeze using the Glide library. However I've barely scratched the surface in terms of Glide's potential. So you can take a look at there full feature set here. GitHub (Source code) Hope this serves as a foundation for your Android gallery apps.

Using Vector Assets for Icons in Android Studio 1.4

Tue, 06 Oct 2015 00:00:00 GMT

Since Android Studio 1.4, we can use Vector Assets which was earlier restricted to Lollipop alone. This is more efficient since one drawable which requires multiple instances saved in different density folders will now be replaced by just ONE single vector asset inside res/drawable/ You need to use Gradle 1.4 for this.

Add 'com.android.tools.build:gradle:1.5.0' to your build.gradle file dependencies.
Add a vector asset by right-clicking res/drawable/ > New > Vector Asset. Android Studio provides a built-in viewer for you to pick your drawable.
Reference your icon like you usually do. Eg: android:icon="@drawable/ic_help_24dp"

NOTE: Since the icons are black, you may want to tint your ActionBar icons white. You can do so by reference the icon like this: menu.getItem(index).getIcon() and then use DrawableCompat to tint.

Parallax Scrolling Tabs with Android Design Support Library

Tue, 15 Sep 2015 00:00:00 GMT

Material Design has seen the rise in on-scroll animations in Android apps. Certain designs include a parallax scroll effect with a header images, along with Tabs. In this post, we'll look at just that. Parallax scrolling is a popular pattern. Previously we've seen such examples with the Flexible Space with Image and Quick Return pattern. In this post, we'll look at making parallax scrolling Tabs using Android Design Support Library. Parallax scrolling has been very popular in web design and now in app development as well. I've seen quite a few people wanting to implement this and I wanted to provide a solution without using a third party library. So here it is. Creating Parallax Scrolling on Android is nothing but the Flexible Space with Image pattern, with an added TabLayout.

Parallax Scrolling Tabs in Android

Have you read the android tutorial for creating the Flexible Space with Image Pattern? If you have, then you would immediately recognise that all this needs is a TabLayout. For those who haven't read it, don't worry. I'll walk you through everything in this article. But wait, hold your horses! I just threw in the TabLayout and this is what I got.

Unlike the typical Material Design Tabs attached to the Toolbar, Tabs here are transparent. Here is the layout. So clearly, the plug and play doesn't work. It looks like some tweaks are required. So before I straight away paste the entire code here, let's look at the layout skeleton.

<android.support.design.widget.CoordinatorLayout> <android.support.design.widget.AppBarLayout>

  <android.support.design.widget.CollapsingToolbarLayout>
     <ImageView />
     <android.support.v7.widget.Toolbar />
     <android.support.design.widget.TabLayout />
  </android.support.design.widget.CollapsingToolbarLayout>

</android.support.design.widget.AppBarLayout> </android.support.design.widget.CoordinatorLayout>

The CollapsingToolbarLayout is like a super FrameLayout. So take note of the ordering of elements inside. Whatever element you place last, is what appears on the top. This positioning is important to get the parallax scrolling to work. So now that you have an idea of the layout structure, behold the full XML layout code!

<?xml version="1.0" encoding="utf-8"?>
<android.support.design.widget.CoordinatorLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:id="@+id/htab_maincontent"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:fitsSystemWindows="true">

    <android.support.design.widget.AppBarLayout
        android:id="@+id/htab_appbar"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:background="?attr/colorPrimary"
        android:fitsSystemWindows="true"
        android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar">

        <android.support.design.widget.CollapsingToolbarLayout
            android:id="@+id/htab_collapse_toolbar"
            android:layout_width="match_parent"
            android:layout_height="256dp"
            android:fitsSystemWindows="true"
            app:contentScrim="?attr/colorPrimary"
            app:layout_scrollFlags="scroll|exitUntilCollapsed|snap"
            app:titleEnabled="false">

            <ImageView
                android:id="@+id/htab_header"
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                android:background="@drawable/header"
                android:fitsSystemWindows="true"
                android:scaleType="centerCrop"
                app:layout_collapseMode="parallax"/>

            <View
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                android:alpha="0.3"
                android:background="@android:color/black"
                android:fitsSystemWindows="true"/>

            <android.support.v7.widget.Toolbar
                android:id="@+id/htab_toolbar"
                android:layout_width="match_parent"
                android:layout_height="?attr/actionBarSize"
                android:layout_gravity="top"
                android:layout_marginBottom="48dp"
                app:layout_collapseMode="pin"
                app:popupTheme="@style/ThemeOverlay.AppCompat.Light"/>

            <android.support.design.widget.TabLayout
                android:id="@+id/htab_tabs"
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:layout_gravity="bottom"
                app:tabIndicatorColor="@android:color/white"
                app:tabSelectedTextColor="@android:color/white"
                app:tabTextColor="@color/white_70"/>

        </android.support.design.widget.CollapsingToolbarLayout>

    </android.support.design.widget.AppBarLayout>

    <android.support.v4.view.ViewPager
        android:id="@+id/htab_viewpager"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        app:layout_behavior="@string/appbar_scrolling_view_behavior"/>

</android.support.design.widget.CoordinatorLayout>

Layout Breakdown

Some of the attributes here make the parallax scroll work. So let me walk you through them. 21. The total height that we want our collapsible header View to have. 25. This is not the Flexible Space with Image pattern. We don't want the Toolbar title to collapse. We want it fixed. So disable the title. 34. The flag that triggers the parallax effect upon scrolling. 36 - 41 Scrim that makes Tab text more readable against the busy header background. 47. Remember that CollapsingToolbarLayout is an extension of FrameLayout. So this attribute ensures the Toolbar stays on top. 48. TabLayout by default has a height of 48dp. Telling our Toolbar to have a bottom margin of the same, avoids the overlap issue I showed you above. 49. Makes sure the Toolbar consistently is pinned to the top. Otherwise when you start scrolling, the Toolbar scrolls off screen. 56. Ensures the TabLayout sticks to the bottom of the header.

Setting up ViewPager in Activity.java

In case you forgot, the Tabs need a ViewPager to work with, so let's take care of that in our Activity.java. Let's start by creating a dummy Fragment. For the sake of displaying some content, the Fragment will display a RecyclerView. Additionally, it's background color will change depending on it's position in the ViewPager.

public static class DummyFragment extends Fragment {
     
      public DummyFragment() {
      }

      @Override
      public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
          View view = inflater.inflate(R.layout.dummy_fragment, container, false);
          ...
          RecyclerView recyclerView = (RecyclerView) view.findViewById(R.id.dummyfrag_scrollableview);

          LinearLayoutManager linearLayoutManager = new LinearLayoutManager(getActivity().getBaseContext());
          recyclerView.setLayoutManager(linearLayoutManager);

          SimpleRecyclerAdapter adapter = new SimpleRecyclerAdapter(list);
          recyclerView.setAdapter(adapter);
          ...
          return view;
      }
  }

Note that DummyFragment is just a placeholder which I'm using with a different background color for each of my Tabs. You on the other hand must define a Fragment accordingly for each of your Tabs.

ViewPager Adapter

A minimal Adapter for our ViewPager. (To hold 3 Fragments)

static class ViewPagerAdapter extends FragmentPagerAdapter {
        private final List mmFragmentTitleList FragmentList = new ArrayList<>();
        private final List = new ArrayList<>();

        public ViewPagerAdapter(FragmentManager manager) {
            super(manager);
        }

        @Override
        public Fragment getItem(int position) {
            return mFragmentList.get(position);
        }

        @Override
        public int getCount() {
            return mFragmentList.size();
        }

        public void addFrag(Fragment fragment, String title) {
            mFragmentList.add(fragment);
            mFragmentTitleList.add(title);
        }

        @Override
        public CharSequence getPageTitle(int position) {
            return mFragmentTitleList.get(position);
        }
    }

Hooking up ViewPager with TabLayout

Finally we'll attach the ViewPager to our TabLayout in the Activity's onCreate() method.

... 
TabLayout tabLayout = (TabLayout) findViewById(R.id.htab_tabs);
        tabLayout.setupWithViewPager(viewPager);

 tabLayout.setOnTabSelectedListener(new TabLayout.OnTabSelectedListener() {
            @Override
            public void onTabSelected(TabLayout.Tab tab) {

                viewPager.setCurrentItem(tab.getPosition());

                switch (tab.getPosition()) {
                    case 0:
                        showToast("One");
                        break;
                    case 1:
                        showToast("Two");
                        ...
                  }
               }

  private void setupViewPager(ViewPager viewPager) {
        ViewPagerAdapter adapter = new ViewPagerAdapter(getSupportFragmentManager());
        adapter.addFrag(new DummyFragment(getResources().getColor(R.color.accent_material_light)), "CAT");
        adapter.addFrag(new DummyFragment(getResources().getColor(R.color.ripple_material_light)), "DOG");
        adapter.addFrag(new DummyFragment(getResources().getColor(R.color.button_material_dark)), "MOUSE");
        viewPager.setAdapter(adapter);
    }
...

The setupViewPager() method simply initializes my Fragment and adds them to the ViewPager. Nothing out of the ordinary here. The Material Design Tabs post does the same thing, which is why this has minimal explanation. However if you get stuck anywhere, below is a link to the source code (GitHub) which you can refer to :)

Dynamic Tab color with Palette API

The color you see the Toolbar + TabLayout take, is picked from the header image. Courtesy of the Palette API. Using this, we'll set colors for the Toolbar, TabLayout and Status Bar. This is easily done by the following code snippet:

try { Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.header); Palette.from(bitmap).generate(new Palette.PaletteAsyncListener() { @SuppressWarnings("ResourceType") @Override public void onGenerated(Palette palette) {

        int vibrantColor = palette.getVibrantColor(R.color.primary_500);
        int vibrantDarkColor = palette.getDarkVibrantColor(R.color.primary_700);
        collapsingToolbarLayout.setContentScrimColor(vibrantColor);
        collapsingToolbarLayout.setStatusBarScrimColor(vibrantDarkColor);
    }
});

} catch (Exception e) { // if Bitmap fetch fails, fallback to primary colors Log.e(TAG, "onCreate: failed to create bitmap from background", e.fillInStackTrace()); collapsingToolbarLayout.setContentScrimColor( ContextCompat.getColor(this, R.color.primary_500) ); collapsingToolbarLayout.setStatusBarScrimColor( ContextCompat.getColor(this, R.color.primary_700) ); }

Notice that the actual Palette API calls reside in the try block. But it is good practice to always handle the fail case. Here, the Palette API can fail if we're unable to get a Bitmap. So as a fallback, we resort to using our app's primary colors.

Final Output

With everything in place, run your app and scroll down and watch that beautiful parallax scrolling.

We have a neat TabLayout that plays nice with our Toolbar. Our header image scrolls nicely and fades into our image's primary vibrant color. As you can see this is a neat pattern in use which many of you would have seen. A perfect use case for this would be in apps that have categories (sub divisions) like the Play Store app, and also require a neat header image (Master Detail being the perfect example). SOURCE CODE: Find the source code for this project on GitHub. Alternate Library: If you're not satisfied with the parallax scrolling the Design Support Library provides, or desire a greater degree of control and flexibility, you can use MaterialViewPager by florent37 on GitHub. Do share the post if you liked it! Cheers.

Material Design for Tablets

Tue, 08 Sep 2015 00:00:00 GMT

So far we've seen use cases for popular design patterns restricted to a handset only. Now let's look at applying Material Design for Tablets in Android app development. New to Material Design? Get started with Android Material Design for pre Lollipop first. Let's begin with the project setup so our app can handle different screen sizes, and fire up a layout accordingly. A fitting example to showcase the best tablet design would be the Navigation Drawer pattern. It's pretty famous and can be seen on almost any mobile app. On mobiles, you swipe right or tap the Hamburger menu to open it. While on tablet, it usually stays opened (Master Detail flow). Like a two pane layout. Let's look at making such a template for your tablet app.

Material Design Tablet Metrics

This doesn't involve you doing anything 'special'. You just need to create appropriate folders for your tablet resources, and add relevant files. That is key.

Layout for Tablet Design

Here's the breakdown which shows the folders you need to have under res/ folder. Keep in mind the default folder for layouts is res/layout and for values its res/values. We're going to create alternate resources for tablets that will override these defaults. I'll try my best to keep it simple and not over-complicate.

The folders work on a concept of smallest width (sw). The key takeaway here is that layouts above 600dp is tablet, with 600dp and 720dp being 7 inch and 10 inch tablets respectively. For alternative landscape configurations, append -land to the folder name. For values folder it follows the same concept. This is the bare minimum and enough for most cases. However, if you're the curious one like me, here's the full breakdown. I strongly suggest that you follow that link whenever making your folder structure for a hybrid tablet app. Simply because the Material Design specs are the updated guidelines and NOT this. So given that you've understood everything that went on above, for this post, we need a layout for phone, and an alternate for tablet. Given that, we will need a res/layout and res/layout-sw-600dp folders. Tablets are best used in landscape so while you can go ahead and use the layout-sw-600dp folder if you want, but the two pane layout is ideal for landscape, so I'm going with the layout-sw-600dp-land folder.

Dimensions

Also note that the dimension values that you specify, you must define its alternate dimension values in the res/values/dimens.xml folder. Remember to use the correct values folder for tablets. Example, the default activity margins are 16dp for mobile, and 24dp for 7 inch to 9 inch tablets. So I would define a dimension like this: PHONE: res/values/dimens.xml: <dimen name="activity_margin">16dp</dimen> TABLET: res/values-sw600dp/dimens.xml: <dimen name="activity_margin">24dp</dimen> Note how both dimension values have the same name, while residing in different res/values folder. Android will take care of accessing the correct folder. In this case, it takes 16dp until a device's width is 599dp. Anything 600dp and beyond in width will take 24dp.

Enough of me rambling, let's dive into making our tablet app. Basically, we'll create 2 layouts, one for phone and another for tablet that reside in different layout folders. Then in our Activity class, we'll check which layout is in use and setup accordingly. Yep, it takes twice the effort my friend. That's why we use Fragments ;)

Phone Layout

Start by defining your res/layout/activity_main.xml Since I mentioned we'll be doing a two pane layout, for phones that very layout is our regular Navigation Drawer. I'm implementing a Material Navigation Drawer with the help of the Design Support Library.

To learn more about NavigationView or Navigation Drawer, read Easy Navigation Drawer with Design Support Library.

Tablet Layout

Now for res/layout-sw600dp-land/activity_main.xml Optionally, if you want the regular phone landscape to have this layout as well, then you can include this layout in res/layout-land/ instead.

The thing to notice here is, the ID for NavigationView and FrameLayout (which inflates Fragment) are the same. The only thing different, is the Drawer layout in res/layout/activity_main.xml. Hence we will use this difference to identify whether its a tablet or phone layout. Remember that the Android framework will automatically choose the correct layout. So we just need to check which one it is and react accordingly. This, we will handle in Java.

Handling Both Layouts in Activity

The crux of the Activity is this:

  if (findViewById(R.id.drawer) != null) {
            mTwoPane = false;
            // Handle Phone layout setup here
        } else {
            mTwoPane = true;
            // Handle Tablet setup here
}

We find any one ID that's unique to either layout (phone or tablet). Here, the Drawer exists only in for the phone layout, hence we check if a view containing that ID is inflated. So if the layout holding the Drawer is inflated, it means its a phone. Otherwise its tablet. We use this simple if condition to check the type of device and initialize accordingly, using a Boolean 'mTwoPane' to keep track of the changes. Alternatively you can fetch the device width and handle changes, but I find this solution more elegant.

public class MainActivity extends AppCompatActivity {
    ...

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        setUpToolbar();

        if (findViewById(R.id.drawer) != null) {
//            Phone layout
            mTwoPane = false;

            setUpNavDrawer();
            ...
        } else {
//            Tablet layout
            mTwoPane = true;
            ...
            }
        }
        // Initialize & handle views here common to both Phone & Tablet
        mNavigationView = (NavigationView) findViewById(R.id.nav_view);
        // Inflate the common Fragment here @+id/main_content_area (FrameLayout)
        ...
    }

Hope the comments are self explanatory. Anything specific to phone or tablet is handled in their respective if or else statements. What is common to both is handled outside them.

Final Output

Finally after a lot of folder creations and alternate resource files, we're ready to run our tablet app.

Source Code: Available on GitHub.

Wrap Up

I hope this post provided needed insights for you to get started on Material Design for Tablets. I've used a pretty common use case- a two pane layout with the Navigation Drawer, covering small (600dp) and large (720dp) tablet versions. We've seen how we can define alternate resource files in our folder structure which lets Android pick the right one depending on screen size. We also saw how to handle different layouts in our code and react accordingly. Designing for Android tablet opens up a whole new dimension for us designers to play more freely on a larger screen. Remember that a good app is one that intelligently makes use of available space, yet retaining familiarity. Hoping to see you come up with awesome layout designs. Do show them off in the comments below.

Overlap a Transparent Status Bar

Mon, 24 Aug 2015 00:00:00 GMT

There's a lot going on about making your Status Bar transparent for your Activities. But most of the time, its easier said than done and if android:fitsSystemWindows = "true" doesn't work for you, then there is another way. Add this before your setContentView()

  if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
            getWindow().getDecorView().setSystemUiVisibility(
                    View.SYSTEM_UI_FLAG_LAYOUT_STABLE
                            | View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN);
            getWindow().setStatusBarColor(getResources().getColor(R.color.black_trans80,null));

}

Remember that a transparent Status Bar works only on Lollipop and above. For Android KitKat 4.4 it is translucent. Android Jelly Bean 4.2 and below, it remains black and there's nothing you can do about that. The Status Bar color here could be anything, but as per norms it must be 20% opacity black. NOTE: Don't forget to add a 24dp padding to your Toolbar top, since it will now be under the Status Bar.

Create Gmail Style List in Android

Thu, 13 Aug 2015 00:00:00 GMT

I'm sure all of you would have noticed the list style in the Gmail app for Android. The placeholder for a person's photo is their first letter accented with a nice color. In fact even the stock Contacts app and the new Inbox by Gmail has a similar style.

Gmail

Lollipop Stock Contacts App

This is a pretty neat way of handling the absence of a profile picture, instead of a mundane grey placeholder. This helps add more vibrancy to our app, giving it more 'pop' and life. Let's look at how to make a Gmail style list using the TextDrawable library, as it makes it easy to mimic such a style. The reason for using this library is that apart from the prime function we seek, it offers flexibility and customization as well. The idea is to use this as a placeholder for a person's profile picture. For example if you take WhatsApp, you have a grayed contact icon which is rather dull. If the user had a profile picture, that would replace the grey icon instead. That's the same thing we're going to fix here, except instead of that boring grayed icon, we'll add a randomly generated color for our placeholder along with the 1st letter of the list item (as seen above).

Setup

As advertised, the library is lightweight and you can start using it simply by adding these lines to your build.gradle file.

repositories {
    maven {
        url 'http://dl.bintray.com/amulyakhare/maven'
    }
}

dependencies {
    compile 'com.amulyakhare:com.amulyakhare.textdrawable:1.0.1'
    ...
}

Layout

As always, we'll start with the MainActivity's layout, which is nothing but a RecyclerView. So let's jump ahead to our list item's layout.

Modifying the Adapter

Now I won't be going into creating an adapter for our list. You can find tons of posts about that like this one. Moreover, as an Android developer, you must be both familiar and comfortable in creating an adapter for your RecyclerView by now. So instead of that, I'll show you how to modify our RecyclerView's adapter so we can get those different colors. Be sure to reference your ImageView (gmailitem_letter) in your RecyclerView ViewHolder like this:

class GmailVH extends RecyclerView.ViewHolder {
        ImageView letter;
        ...

        public GmailVH(View itemView) {
            super(itemView);
            letter = (ImageView) itemView.findViewById(R.id.gmailitem_letter);
            ...
        }
    }

onBindViewHolder()

Called by RecyclerView to display the data at the specified position.

This is where we'll create a TextDrawable, generate a random color for it and set it to our ImageView. To generate a random color, use ColorGenerator generator = ColorGenerator.MATERIAL;

 @Override
    public void onBindViewHolder(GmailVH gmailVH, int i) {
        ...
//        Get the first letter of list item
        letter = String.valueOf(dataList.get(i).charAt(0));

//        Create a new TextDrawable for our image's background
        TextDrawable drawable = TextDrawable.builder()
                .buildRound(letter, generator.getRandomColor());

        gmailVH.letter.setImageDrawable(drawable);
    }

I hope along with the comments, the above code snippet was self explanatory. For each list item for position int i, we will be generating a random color for each list item. If you want instead of randomly generating colors, you can generate based on a key value like this:

int color = generator.getColor("urawesome@gmail.com")

Finally, don't forget to set your adapter! Here's the entire adapter code if you need it, otherwise feel free to scroll past it.

public class GmailAdapter extends RecyclerView.Adapter {
    List dataList;
    String letter;
    Context context;
    ColorGenerator generator = ColorGenerator.MATERIAL;

    public GmailAdapter(Context context, List dataList) {
        this.context = context;
        this.dataList = dataList;
    }

    @Override
    public GmailVH onCreateViewHolder(ViewGroup viewGroup, int i) {
        View view = LayoutInflater.from(viewGroup.getContext()).inflate(R.layout.gmail_list_item, viewGroup, false);
        return new GmailVH(view);
    }

    @Override
    public void onBindViewHolder(GmailVH gmailVH, int i) {
        gmailVH.title.setText(dataList.get(i));
        letter = String.valueOf(dataList.get(i).charAt(0));

        TextDrawable drawable = TextDrawable.builder()
                .buildRound(letter, generator.getRandomColor());

        gmailVH.letter.setImageDrawable(drawable);
    }

    @Override
    public int getItemCount() {
        return dataList == null ? 0 : dataList.size();
    }

    class GmailVH extends RecyclerView.ViewHolder {
        TextView title;
        ImageView letter;

        public GmailVH(View itemView) {
            super(itemView);
            letter = (ImageView) itemView.findViewById(R.id.gmailitem_letter);
            title = (TextView) itemView.findViewById(R.id.gmailitem_title);
        }
    }

}

Final Output

Here's how its finally going to look like. Pretty neat eh?

As always you can check out the code sample over at GitHub. If you have a profile picture, you can easily handle that as well. Simple don't generate a TextDrawable, instead pass that image as the background for the ImageView. As you can see the library helped us give our RecyclerView a facelift. That's not all, the library has additional functionality which you can explore and add to your app as needed. Even the need for handling the entire list of colors is not needed, which is why this library is great for creating a Gmail style list. Hoping to see you put it to good use. Cheers!

My Experience with the Moto G 3rd Gen

Wed, 05 Aug 2015 00:00:00 GMT

I was looking to get a new phone for a while and wasn't sure what to get. I heard rumors about the Moto G 3rd gen (Moto G3), and decided to wait. The wait was worth it. This is not a typical speculative review, but rather my hands-on experience, a week after buying and using the phone myself. :-) I bought the Moto G 3rd Gen 16GB internal, 2GB RAM variant, in black. I'd suggest you go for the same too as there's not much you could do with the 8GB variant given there's only about 3.2GB free space remaining for you to play around with.

Build & Design

One can say Motorola has played it safe with the build here. Last year's model was pretty solid, and they've improved upon that. The front speaker grille are less obtrusive and suit the phone's design well. The back design is what I love. It sports a diagonally ribbed texture, along with a centered camera and two-tone flash, housed in a metallic strip. I particularly like this texture, including the power button. The strip accents the back very well, along with Motorola's logo. The overall back texture is a welcome addition, making me more confident while holding the phone.

Water Resistance

Motorola even made the Moto G water resistant with a IPX7 rating. On paper it says the phone can withstand upto 1 feet for 30 minutes. However, its not designed to be used while underwater. Watch on YouTube The important thing to note here is, only original Motorola back cases will help with water resistance, provided the back is sealed properly. Not to worry as when you power on the phone first time, it will walk you through all this. I haven't personally tried this myself. Didn't want to subject my phone to such cruelty on day one. However, you're welcome to try it ;-) Overall the phone doesn't look cheap in any way. The build is solid and the phone feels firm to hold.

Display

I don't ask for much in terms of display here. Motorola stuck with the Moto G2's display, going at 5-inch HD (720x1280p) display (entire specs here). I'm satisfied with this. The display is good, though not too sharp as full-HD displays. Nothing to complain here. In fact this would only do good for the battery. Motorola's added an on screen display (notification) feature, which in my opinion is pretty neat. You can view all your notifications, and control your music without having to unlock your phone, each and every time. Neat! Touch response is excellent. I carry out my daily tasks such as email, texting, social media, light gaming with my Wi-Fi on the whole time. No hiccups or lag whatsoever. You might want to keep a screen guard ready for your new Moto G3. I know it comes with Corning Gorilla Glass, but you can never be too safe. Moreover, you'll get a screen cover like this: Naturally you might want to replace that ASAP.

Software

No bloatware. Stock Android. Moto apps.

That said it all. I'm happy to see my homescreen free of useless apps. Motorola's set of installed apps improve upon the already brilliant user experience. There are 3 features bundled into the Moto app:

Assist

helps tailor your phones audio settings depending on what you're doing or where you are. For instance if you're in a meeting, it can silent all calls. If you wish your favourite contacts can still get to you on the second ring.

Action

Two neat gestures, a double karate chop for torch and twist twice to open the Camera.

You can even twist twice, to switch back and forth between the front and rear camera. The good news is these gestures work as said, quite well.

Display

The screen wakes to display notifications, that you can view without unlocking your phone. You can tailor this by picking which apps you don't need a notification and so on.

Camera

13MP rear, 5MP front camera. Fast shutter. Need I say more?

Motorola has steadily been working on the camera. The G had 5MP, G2 had 8MP and G3 has 13. Motorola says the G3 uses the same camera module used in Nexus 6. While that sounds good on paper, that's not the case really. Images snapped under well-lit conditions (daylight) are brilliant, while low light images are decent, they tend to suffer from noise. Especially if you prefer taking a snap without flash, like me. However, the two-tone flash built in is good. The shutter is very fast even if you turn on HDR, that's great news, complemented with a top-notch and clean camera UI, that makes taking photos with the Moto G3 a breeze. Here are some random shots I've taken (under various conditions) for you to judge.

Battery

Moto G3 packs a 2470 mAh battery.

Personally I felt this was low, but I was wrong. The phone lasts remarkably well. I use this throughout the day with Wi-Fi on the entire time, browsing, emails, various social media, gaming and taking lots of photos. End of the day I have about 30% left. Oh, and did I mention I charged it the previous night? To me, that's good enough.

Verdict

What I learn from all this is that "Hardware specs aren't everything in a phone". The phone is snappy, performs great. No signs of lag whatsoever. Good camera (fast shutter). Water resistance is a welcome addition. Butter smooth, bloat-free Android Lollipop. Need I say more?

Pros:

Lag-free experience
Solid phone design
Water resistant
Customizable via Moto Maker

Cons:

Good camera, but not great
No fast charging

Should you buy it?

For India, you can buy Moto G (3rd Gen) from Flipkart. They did a damn good job of delivering it. Or purchase one from Amazon.If you're looking for a budget phone, look no further. The Moto G 3rd Gen is an all round performer. Whatever it does, it does well. Motorola shows others, this is how you make a budget phone! It does it in style and shows what's possible at this price range. When Motorola launched this phone, their slogan was "Choose the phone that's always there for you", and I'd support that. Even the cons mentioned above is no deal-breaker, that's just me nitpicking. I chose this phone over the Zenfone 2, Galaxy J5, K3 Note and Mi 4i. I don't regret my decision one bit. If you want a phone that performs, has a quick camera, is bloat-free, will last and gives timely updates, then Moto G 3rd Gen is the phone for you.

Make an Android Splash Screen (Launch Screen)

Fri, 31 Jul 2015 00:00:00 GMT

The launch screen (or splash screen if you prefer), is the first thing your user's going to see. In other words, it is a user's first experience of your application. In this post I'll show you how to create a branded launch screen / splash screen for your Android apps.

This is where you must do your best to impress the user. Use some flashy graphics, vibrant imagery along with a neat logo. Not trying to be harsh, but if you slack off here, he's probably not going to return.

Here are a few examples to inspire you.

Why use a Launch / Splash Screen?

The launch screen is a user’s first experience of your application.

You can take this opportunity to briefly provide brand exposure, as a welcome screen. However, I suggest you have a more useful purpose than JUST this.

If your app is heavily dependent on data that would take a while to load, say you're downloading images from a database, loading a URL or fetching information from a server. Without this your initial UI will look empty and increase it's perceived loading time.

Such situations are a perfect for a launch screen. Use this opportunity to load data in the background. So while your launch screen is being displayed, a background task will be fetching the required data for your app.

Types of Launch Screens

The launch screen as mentioned by Material Design has two types:

Branded Launch - provide momentary brand exposure, freeing the UI to focus on content
Placeholder UI - for apps that have very short load times, or don’t have a strong branding need

You can read more about these here.

Now I'll show you how to make a branded launch screen, and how to use this opportunity to carry out your background tasks.

Branded Launch Screen

Create a new Blank Activity named LaunchScreenActivity and set this to be the Launch Activity. Check the AndroidManifest.xml and it should be like this:

...

           <category android:name="android.intent.category.LAUNCHER" />
       </intent-filter>
   </activity>

...

Layout

This is where we'll design our actual launch screen. This could entirely be an image, or you could do the layout using Android's native XML as well. For this demo, I'll simply use a nice Material Design wallpaper of my choice, followed by a centered title.

Here's the layout structure for reference:

<FrameLayout 
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="@color/blue_grey" >

      <ImageView
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:background="@drawable/splash_img" />

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_gravity="center"
        android:orientation="vertical">

        <TextView
            android:text="Material Design" />

        <TextView
            android:text="Sample App" />
    </LinearLayout>

</FrameLayout>

layout.xml preview

Once you're done making your awesome launch screen, head over to your Activity.

Launch Screen Activity

Remember I mentioned about carrying out a background task while displaying the launch screen to users? This is where we're going to do that.

public class LaunchScreenActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        ...
        new BackgroundTask().execute();
        ...
    }

Note the BackgroundTask(). This is an AsyncTask which you will use to carry out your background tasks. However, I will simply use a timer, which upon a 3 second completion will go to your app's home activity.

Background AsyncTask

private class BackgroundTask extends AsyncTask {
        Intent intent;

        @Override
        protected void onPreExecute() {
            super.onPreExecute();

            intent = new Intent(LaunchScreenActivity.this, MainActivity.class);
        }

        @Override
        protected Object doInBackground(Object[] params) {

            /*  Use this method to load background
            * data that your app needs. */

            try {
                Thread.sleep(SPLASH_TIME);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

            return null;
        }

        @Override
        protected void onPostExecute(Object o) {
            super.onPostExecute(o);
//            Pass your loaded data here using Intent

//            intent.putExtra("data_key", "");
            startActivity(intent);
            finish();
        }
    }

Note the 3 methods here. The onPreExecute() must be used for initialization. To prepare whatever you need to carry out your task. The doInBackground() is where the actual background task will be carried out. The meat of the task happens here. Finally, use the onPostExecute() method to carry out whatever needs to be done AFTER our task is complete.

In our case, we will use onPostExecute to send the user to our app's home screen (Activity). Use this chance to pass the fetched data via an Intent.

Yep, that's pretty much it! However do note that in my case, I am simply using a 3 second timer, which upon expiring takes the user to the home screen. You should do something more useful here.

Also, if your background tasks may take longer to execute, consider adding a ProgressBar or Spinner to indicate some sort of progress to the user. Otherwise they may be staring at your launch screen for quite a while not knowing what's going on. Visual feedback is important!

Anyway, here's the demo.

Watch on YouTube

As always, here a link to GitHub for code sample.

A launch screen is a recent addition in Google's Material Design arsenal for Android apps. While its certainly not new, with major app brands doing this for a long time. Only now do we have some official confirmation about this being a valid design pattern.

While my two minute launch screen design is far from amazing, it only serves the purpose of a demo. I believe you could come up with something much better. Drop 'em in the comments below!

Pinterest Masonry Layout (Staggered Grid)

Mon, 27 Jul 2015 00:00:00 GMT

If you have used the Pinterest app or their website, you would have noticed a rather creative grid layout. That is a Masonry Layout.

It works by placing elements in optimal position based on available vertical space, sort of like a mason fitting stones in a wall.

Thankfully, we won't be needing any external library for this as Android's native RecyclerView makes implementing a Pinterest masonry layout simply by changing the RecyclerView's Layout Manager. This is quite popular in web design as well. Let's look at implementing this in Android.

Start by adding the require Gradle dependencies.

dependencies {
    compile 'com.android.support:appcompat-v7:22.2.1'
    compile 'com.android.support:recyclerview-v7:22.2.1'
}

Masonry Layout - Tile

Now for each tile I will use a simple LinearLayout, however you could alternatively use a Card view.

Nothing fancy up there. Just an ImageView and a TextView for a title. This is the layout for each of our tile. Now this is akin to each list item in your typical ListView. I am purposely skipping our MainActivity's layout since its just a RecyclerView. We'll skip that and head onto creating our adapter and hooking it up to our RecyclerView.

Adapter

If you're familiar with custom ListView in the past, you should be aware of a ViewHolder. This is basically the layout for EACH item in our list.

 class MasonryView extends RecyclerView.ViewHolder {
        ImageView imageView;
        TextView textView;

        public MasonryView(View itemView) {

            imageView = (ImageView) itemView.findViewById(R.id.img);
            textView = (TextView) itemView.findViewById(R.id.img_name);

        }
    }

Now we need to create our RecyclerView's adapter and tell it to use this ViewHolder of ours.

public class MasonryAdapter extends RecyclerView.Adapter {
    private Context context;

    int[] imgList = {R.drawable.two, R.drawable.one, R.drawable.three, R.drawable.four,
            R.drawable.five, R.drawable.six, R.drawable.seven, R.drawable.eight,
            R.drawable.nine, R.drawable.ten};

    String[] nameList = {"One", "Two", "Three", "Four", "Five", "Six",
            "Seven", "Eight", "Nine", "Ten"};

    public MasonryAdapter(Context context) {
        this.context = context;
    }

    @Override
    public MasonryView onCreateViewHolder(ViewGroup parent, int viewType) {
        View layoutView = LayoutInflater.from(parent.getContext()).inflate(R.layout.grid_item, parent, false);
        MasonryView masonryView = new MasonryView(layoutView);
        return masonryView;
    }

    @Override
    public void onBindViewHolder(MasonryView holder, int position) {
        holder.imageView.setImageResource(imgList[position]);
        holder.textView.setText(nameList[position]);
    }

    @Override
    public int getItemCount() {
        return nameList.length;
    }
}

Nothing much to explain here, except that its our regular RecyclerView adapter. Nothing out of the ordinary, I'm pretty sure everyone's familiar with this by now. To populate my Staggered Grid, I'm simply using 10 random images loaded from my drawable folder, named one to ten.

Attaching the Adapter

With all that set, all that is needed is to attach this created adapter of ours to our RecyclerView. Note that the key here is the LayoutManager. This helps determine the layout of our RecyclerView. It could be a regular list, a uniform grid, or a staggered grid (which is what we what). This can further be defined to be scrollable either horizontally or vertically.

mRecyclerView.setLayoutManager(new StaggeredGridLayoutManager(2, StaggeredGridLayoutManager.VERTICAL));

        MasonryAdapter adapter = new MasonryAdapter(this);
        mRecyclerView.setAdapter(adapter);

Here, the parameters for the StaggeredGridLayoutManager is the number of columns and orientation respectively. That's all that's needed to be done. Nothing fancy or out of the ordinary here. If you're quite familiar with RecyclerView, you would realize that the only thing that needs to be changed is the LayoutManager that should be used is a StaggeredGridLayoutManager.

Staggered Grid Spacing Fix

Great so its done. Before you run along and test your app, let me stop you right there and ask you to include a tiny fix. The issue is that, while I was building my sample, I noticed that setting a margin on my LinearLayout didn't seem to work. There was no spacing between my tiles which made the entire list appear joined. This obviously is not what we want. So here's a quick fix. Create a new class that extends RecyclerView.ItemDecoration that helps add spacing around each tile. You might remember that ItemDecoration helps add things like a list divider for each row item.

public class SpacesItemDecoration extends RecyclerView.ItemDecoration {
    private final int mSpace;

    public SpacesItemDecoration(int space) {
        this.mSpace = space;
    }

    @Override
    public void getItemOffsets(Rect outRect, View view, RecyclerView parent, RecyclerView.State state) {
        outRect.left = mSpace;
        outRect.right = mSpace;
        outRect.bottom = mSpace;

        // Add top margin only for the first item to avoid double space between items
        if (parent.getChildAdapterPosition(view) == 0)
            outRect.top = mSpace;
    }
}

Now just tell our RecyclerView to add this ItemDivider simply:

SpacesItemDecoration decoration = new SpacesItemDecoration(16);
mRecyclerView.addItemDecoration(decoration);

Feel free to add any value you wish for SpacesItemDecoration. That value determines the amount of spacing.

Final Results

I'm not going to stop you from running the app now, so go ahead and run it!

As always, here's the GitHub link for the source code.

RecyclerView is pretty powerful as you can see. We were able to create a Pinterest masonry layout using a StaggeredGridLayoutManager. It is more flexible that the previous ListView (which I still see a few people using) and strongly suggest you migrate to its better alternative. Its brilliant how just by changing the LayoutManager, we were able the change the face of a regular RecyclerView to come up with something creative.

Top 10 Material Design Libraries for Android

Mon, 20 Jul 2015 00:00:00 GMT

Material Design is all the rage now. Here are top 10 libraries you need to provide a complete Material Design experience across all apps, pre Lollipop as well. These are in no order of priority.

1. Android Design Support Library

Provides APIs to support adding material design components and patterns to your apps. It adds support for various material design components and patterns such as navigation drawers, floating action buttons (FAB), snackbars, and tabs.

This library has come a long way from its initial release. It provides a ton of useful stuff that would otherwise take time to do. Animations like quick return can be done just by XML alone. I encourage devs to give this one a go before resorting to another external library for the same. The good news is that everything that this library provides is pre Lollipop compatible. Here are some of the Material Design components the library provides:

Navigation Drawer
Floating Action Button
Toolbar (Flexible Space with Image Pattern, Quick Return, etc)
Material Design Tabs
Bottom Sheets

You can get started by adding this to your build.gradle's dependency: com.android.support:design:23.2.0 You can check out the developer's blog for an intro. ALSO READ:

2. Circular Reveal

Reveal animations provide users visual continuity when you show or hide a group of UI elements.

This was introduced in Lollipop and is specific to that too. But this library allows us to have the same animation ported to previous Android versions too. Neat! The advantage is the syntax and methods are exactly the same. So you can get started right away. My post on this should show you how it works. LIBRARY: Circular Reveal by ozodrukh ALSO READ:

Create a Reveal Effect in Android (like WhatsApp)

3. Floating Action Button (Expandable)

Floating action buttons are used for a promoted action.

While the Design Support Library does provide you a Floating Action Button (FAB), this one deserves a mention for it's expand and collapse ability. You might have noticed this in the Google Keep app. So if you need that expand ability on your FAB, this is the go to library. It's can be easily customized and should get you up in a couple of minutes at most. LIBRARY: Android Floating Action Button by futuresimple

4. Material Navigation Drawer

Yes we got this too, but here's the difference.

Maybe you're not satisfied with the Design Support. You want more, like the one on the right? Full control over the nav links, include a button or a switch there? Then this library by mikepenz is for you. It includes full drawer customization. Includes sections, header with images, account switcher and dark/ light themes too. LIBRARY: Material Drawer by mikepenz

5. Ripple Effect Backport

Touch feedback in material design provides an instantaneous visual confirmation at the point of contact when users interact with UI elements. The default touch feedback animations for buttons use the new RippleDrawable class, which transitions between different states with a ripple effect.

What would Material Design be without this neat effect? This too has been exclusive for Lollipop and above. Thanks to this library, we can do a similar effect on pre Lollipop versions. LIBRARY: Ripple Effect by traex

6. Lollipop Transitions Backport

Transitions since Lollipop have been overhauled, and I must say that they are brilliant. The shared transitions and the way each element loads into each new Activity is amazing. Unfortunately this yet again was Lollipop only, but the GitHub user andkulikov has backported the Transitions API from Kitkat and Lollipop for API 2.2 above. LIBRARY: Transitions Everywhere by andkulikov

7. Bottom Navigation Bar

Bottom navigation bars make it easy to explore and switch between top-level views in a single tap.

A relative new addition to Material Design's arsenal. Akin to the TabLayout seen on iOS. This type of navigation is very popular on iOS apps. In Android, it works as a regular Bottom Bar on mobile. Switches to a side navigation on Tablets. This is really neat, and I'm excited to see how developers put it to good use. Its ideal for apps that have only three to four navigation screens. Makes sense to use Bottom Navigation, instead of a Navigation Drawer then. LIBRARY:

8. Super RecyclerView

While not a direct feature of Material Design, RecyclerView is replacing ListView, as something more versatile and powerful. Super RecyclerView is RecyclerView on steroids. As stated by the creator "This is an attempt to make RecyclerView easier to use." It has a lot of features you might otherwise spend quite a while making. Some of them are:

Swipe to Refresh (Google style)
Swipe to Dismiss
Infinite Scrolling
Sticky Header

LIBRARY: Super RecyclerView by Malinskiy

9. Circular Image View

A circular image is very popular and Material Design has pushed this even further. But doing this in Android was never that straightforward. Thankfully, many libraries have made this dead simple to implement, yet versatile in nature. Such a library is one very popular library that has good draw performance as well. LIBRARY: Circle Image View by hdodenhof

10. Material Shadows

Shadows help define elevation of views. This is fundamental in the concept of Material Design. Sadly Lollipop uses a separate Render Thread to handle the UI, making such visuals not possible on pre Lollipop. However, GitHub user h6ah4i has managed to mimic this for API 9+ by using a 9-patch shadow image to replicate the feel of elevation for varying depths. LIBRARY: Android Material Shadow Nine patch by h6ah4i

These are MY top 10 Material Design libraries for enhancing the experience for my users. The recent Design Support Library by Android has added a LOT of features for our apps. But there are a lot of third party libraries which have made development a breeze. Like the ones above. So what are your favorite Material Design libraries? Did I miss anything? Let me know in the comments below.

Circular Reveal Effect like WhatsApp in Android

Fri, 17 Jul 2015 00:00:00 GMT

While sending a photo through WhatsApp, I noticed the 'Attach' button performs a neat Circular Reveal effect. My phone being JellyBean, I was surprised to see a Lollipop only transition. Thanks to a neat library, we can mimic the exact same thing for pre Lollipop too.

The Reveal Effect

Touch feedback in material design provides an instantaneous visual confirmation at the point of contact when users interact with UI elements.

The Reveal Effect uses the RippleDrawable class to achieve this. So visually, you can tell that it is similar to the Ripple effect. The only difference being that a Ripple is a touch feedback denoted by a color spreading from a point of contact, while the Reveal effect does the same animation, but for displaying a view.

WhatsApp's Version

Here's how it looks on WhatsApp, after their Material Design upgrade.

This is exactly what we're going to create. If you still don't get what I'm talking about then scroll down to the end of the post.

Setup

The issue is, this animation as said before is intended for Lollipop and above ONLY. There is no support library to help us out here. So no version below Lollipop can perform this.

However, there is a neat library that's managed to backport this for us. We will be using the same, for our purpose. The good thing about the library is that, the methods are exactly the same, which is convenient. Though one must be careful about the imports.

Circular Reveal Library

We'll start by including the library in our build.gradle file. Add the repository first, and then the dependency.

repositories { maven { url "https://jitpack.io" } }

dependencies { compile 'com.github.ozodrukh:CircularReveal:1.1.0' }

Layout

Let's create a layout similar to that of WhatsApp's Attach option.

Here's the layout skeleton if you're interested. Honestly this layout could be any layout that you want to reveal using this effect, even entire screen transitions could be done.

<io.codetail.widget.RevealFrameLayout android:layout_width="match_parent" android:layout_height="wrap_content">

       <LinearLayout
           android:id="@+id/reveal_items"
           android:layout_width="match_parent"
           android:layout_height="wrap_content"
           android:orientation="horizontal"  >

           <LinearLayout
               android:layout_width="0dp"
               android:layout_height="wrap_content"
               android:layout_weight="1"
               android:gravity="center"
               android:orientation="vertical">

               <ImageButton
                   android:layout_width="70dp"
                   android:layout_height="70dp"
                   android:background="@drawable/icon_camera" />

               <TextView
                   android:layout_width="wrap_content"
                   android:layout_height="wrap_content"
                   android:layout_marginTop="16dp"
                   android:text="Gallery" />
           </LinearLayout>

           <!-- Other 2 icons here-->
           
       </LinearLayout>

   </io.codetail.widget.RevealFrameLayout>

Note the RevealFrameLayout widget. This comes from the library we imported. This is nothing but a FrameLayout. To perform the animation, we will reference the immediate child layout of this frame. While that child (here being the LinearLayout) with id reveal_items will animate, it's shape will be clipped by the outer RevealFrameLayout.

Performing the Reveal Effect

Head over to your Activity.java and lets get that animation working. The animation will be toggled when we tap the Attach (clip) button. The contents of the RevealFrameLayout will be displayed, and hidden alternatively.

Remember I said we need to reference the immediate child of the RevealFrameLayout.

LinearLayout mRevealView = (LinearLayout) findViewById(R.id.reveal_items); mRevealView.setVisibility(View.INVISIBLE);

The view will be inivisible as by default it remains hidden, only presenting itself when we tap Attach.

Our Attach button will be in our Toolbar, included using a menu resource.

... ...

The meat of the action takes place in the onOptionsItemSelected() method. Here is where the Toolbar (ActionBar) menu item's click actions are defined.

public boolean onOptionsItemSelected(MenuItem item) {

switch (item.getItemId()) { case R.id.action_clip: // handle animation here return true;
}

 return super.onOptionsItemSelected(item);

}

Animation Prerequisites

To perform the animation, two parameters are needed:

X, Y coordinates to start the animation from
Radius of the circular reveal

WhatsApp performs the Reveal effect from the top right.

int cx = (mRevealView.getLeft() + mRevealView.getRight()); int cy = mRevealView.getTop();

If you need it from the center, then just change cy to this instead: int cy = (mRevealView.getTop() + mRevealView.getBottom())/2;

The radius can be obtained using this method:

int radius = Math.max(mRevealView.getWidth(), mRevealView.getHeight());

ViewAnimationUtils

Now we can finally initiate the reveal effect.

SupportAnimator animator = ViewAnimationUtils.createCircularReveal(mRevealView, cx, cy, 0, radius); animator.setInterpolator(new AccelerateDecelerateInterpolator()); animator.setDuration(400);

SupportAnimator animator_reverse = animator.reverse();

NOTE: Be very careful of the imports here. ViewAnimationUtils is imported from from the external library, and NOT the default android.view.ViewAnimationUtils import.

animator will be used for revealing the view on tap, while animator_reverse in essense reverses the animation for hiding back the view when tapped again.

Animation Toggle

We will use a simple boolean hidden to handle the toggling.

if (hidden) { mRevealView.setVisibility(View.VISIBLE); animator.start(); hidden = false;

          } else {

              animator_reverse.addListener(new SupportAnimator.AnimatorListener() {
              
                  @Override
                  public void onAnimationEnd() {
                      mRevealView.setVisibility(View.INVISIBLE);
                      hidden = true;
                  }
                  ...
              });

              animator_reverse.start();
          }

Note that we need to make the view visible before we being the reveal effect. While this simply works, its not the same for the reverse effect. The library's SupportAnimator provides a method reverse() to reverse the animation. We cannot just set the view invisible before starting the animation. The animation performed will never be visible.

For this we will use the AnimatorListener. Once the reverse animation ends, the convenient onAnimationEnd() method will allow us to hide the view.

Be sure to update the boolean hidden accordingly in the if and else cases.

Lollipop Fix

Strangely, this doesn't seem to work on Lollipop 5.0.1 and above. As in, the transition itself doesn't work. A simple workaround for this would be to use Android's native ViewAnimationUtils for devices Lollipop and above.

Simply wrap the code you just wrote like this.

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP) { // Your previously written code } else { // Same code here but import ViewAnimationUtils from android.view.ViewAnimationUtils Animator anim = android.view.ViewAnimationUtils.createCircularReveal(mRevealView, cx, cy, 0, radius); ... }

Hope the comments there were self explanatory. There's no need for the support animator as well. You can look at my code here, just in case.

That's it. While this post, for the most part was just my explaining, the actual implementation itself is pretty simply and straightforward once you do it yourself. The Circular Reveal library by ozodrukh is brilliant and works nicely.

Here's the final output and it looks amazing.

As always, here's the link to my Git for code reference.

You can get creative with which views your using, be it a simple view or an entire screen transition itself! I simply used WhatsApp's Attach button as an example.

Show me what you can come up with and drop em in the comments below.

Design App Mockups with Adobe Illustrator & InVision

Wed, 08 Jul 2015 00:00:00 GMT

Designing app mockups allow us to quickly visualize how our app might ultimately look like. In this article tutorial, let's learn how to do this really quick with Adobe Illustrator and InVision. I will also tell you the benefits of doing this and guide you every step of the way. While I say this blog is about Android app development and design, my series of recent posts were hardly anything about the latter. Adobe Illustrator along with InVision are two powerful tools when used together. Before we jump ahead to the softwares, let's discuss about why we need app mockups in the first place?

Why Design App Mockups?

To develop any app, what is required first is a visual idea of the end product. A mockup. Note that although this article talks about app mockups. You could do static mockups for any digital product/software. So why do a mockup when you could spend that time building the actual thing? Good question.

A mockup, is a model of a design, used for demonstration and design evaluation. It is used by designers mainly to acquire feedback from users. Mock-ups address the idea captured in a popular engineering one-liner: You can fix it now on the drafting board with an eraser or you can fix it later on the construction site with a sledge hammer. - Wikipedia

Note the last line quoted above. It implies that making corrections early on is easier and less costly, rather than having to rework on your actual designs later on into development. Long story short, you save time and frustration, if you pay attention to things now. Also, if you didn't understand any of that, a mockup is simply a static image design of what an app screen will exactly look like. Here's an example of a app mockup that I made.

Getting to know the tools

Now that we're clear on what an app mockup actually is, let's look at the tools we need. As I've previously mentioned above, the two software that we're going to use are:

Adobe Illustrator
InVision App

Adobe Illustrator

A professional software for graphic design. It specializes in Vector Graphics and is the industry standard.

If you don't have the software, you can grab a free-trial of Adobe Illustrator CC 2018. Yeah, I know that today there's a better tool out there *cough* Sketch *cough* that's more well-suited (and fancy). Maybe I'll cover that in another tutorial, but for now, let's focus on Illustrator. Once you have Illustrator set up, keep in mind that it is a fairly complex software. But I will show you how to use it easily and design app mockups fast! Just to note, you do not require extensive knowledge of Illustrator. But I do recommend a getting started video at the LEAST just to familiarize yourself with the workflow. However, not to be alarmed as we'll just be doing simple drag and drop. If you're interested in learning Adobe Illustrator, I'd suggest you check out this course by Udemy. It provides free Adobe Illustrator classes.

UI Kits to design app mockups, faster

There are many available resources to accelerate our workflow such as UI kits specifically for mobile, be it Android or iOS. I'll be using a free UI Kit for Google Material Design. I strongly suggest you use one so you can simply drag and drop UI components instead of designing them from scratch. Grab the UI kit here. Exploring the Material Design UI Kit Once you've downloaded the UI kit, let's take a look at what it has to offer. Inside the UI kit you downloaded, there will be 3 files under the 'master' folder:

the actual kit
the individual UI elements
Typography styles

You can notice the UI kit is quite exhaustive, and that's only half of what I could screenshot. As a bonus, the 'resources' folder also includes the entire 'Roboto' font and the complete Material Design color palette. Neat!

InVision App

A prototyping tool that helps you put your designs together and add interactivity to it. It helps you understand how your products will behave and also serves as a deliverable to developers.

InVision is free to start so go ahead and sign up! We will be using InVision to finally put together our mockups and bring our prototype to life. But more on that later.

Designing App Mockups with Adobe Illustrator

I will suggest using Adobe Illustrator for mockups. Now many of you may say why not Adobe Photoshop, but read this discussion on DesignerNews as to why Illustrator is better suited for UI design. Now, let's get down to actually designing our app mockup screens.

Document & Grid Setup

Start by creating a New Document in Adobe Illustrator. We won't be going with a preset but rather creating one of our own. So use the following settings to create a new document.

Width: 360 px
Height: 640 px
Advanced> Raster Effects: Screen (72 ppi)

Now we'll setup a grid for our work, so our elements can align perfectly. Go to Edit > Preferences > Guides & Grid

Gridline every: 64 px
Subdivisions: 8

Don't fret seeing this as a troublesome process. You can save this as a template so you can jump start your work from the next time.

Process

Create two new Global Color Swatches in your color palette, one named 'primary' and the other 'accent'. Those familiar with how color works in Material Design should instantly be able to recognize what I just did there. As the name goes, those two are primary and accent colors that will be global to our app design. In other words, those are our brand colors. One primary and one secondary. We do this so that we can swap out the default colors with our brand colors in the Material Design UI kit. Helpful Reading: Color Psychology - What do different colors mean? Now open the UI Kit files that you just downloaded. Drag and drop whatever components you need to swiftly build your app mockups. The beauty here is, when you drag and drop the desired elements onto your Artboard, you will be asked whether to 'Merge Swatches'. Hit that option and watch as the objects take on your document's primary and accent colors. Great!

From now on the process is the same, rinse and repeat. Drag your required elements from your UI kit over to your document

Metrics

The width of each grid column is 8px. This is the baseline grid used in Material Design metrics for design. So if you plan on making a FAB (Floating Action Button- see below), that would be 56 px (8 x 7 ). While the guidelines mention in dp (for apps), you can continue to use px in your designs. So if you see, the grid helps us scale well. The UI kit would have elements in the right dimensions anyway.

Final Results - Output

Now once you're done with your screens, save them via File > Save for Web. Now its called 'Save for Web' for a reason so I strongly suggest you use this option. You can save as either a JPEG or PNG. Deliberately save at medium quality so your mockups will load fast on a browser. Alternately you can scale it at a decent 1280x720 and save but I'd caution against pushing further than that.

App Structure

Now that we have all our screens together, the purpose of a mockup is to mimic a 'feel' of the end product. I know its not the real thing, but it should be close enough. So to mimic that realism we need to have a screen flow to logically show how our app will behave and navigate upon certain action. Now keep in mind that being a mockup, focus on the primary actions first. So for my caller app, I'm going to focus on this simple screen flow. Home screen (Contact List) -> Contact profile screen -> Calling screen Yes, I know an app consists of more, but this is just a demo and if you see, I've already covered the prime aspects. We don't care about a settings page right now. The purpose of my calling app is to view my contacts, view details about a specific contact and finally be able to call that contact.

You might want to take a breather here. We're only half way through ;-)

Buy the Book Anyone can design a user interface, but if you're interested in designing one that is effective and converts your users better, I suggest you read 'UI is Communication - Everett N McKay'. A brilliant book that teaches how to communicate with your users, through your UI.

Putting it together with InVision

To do what I've mentioned above, we'll use a web app called InVision. I happened to take part in a Startup Weekend challenge last year where I happened to learn about this beauty.

InVision an online tool that allows us to put together our screens, define clickable regions that navigate to other screens. It helps sculpt our app navigation flow. As a bonus we got animation on click effects and they even wrap our designs neatly in a phone so when we look at it, its like looking at the real thing! Now InVision has a pricing plan, but upto one project it is free. I find this fair enough, because unlike other prototyping tools I've used, most of my time is spent up in trying to learn the tool or worrying about limitations on the free version. At least I don't have to bother about that with InVision. I can simply design my screens using any of my favorite graphic software, then upload to InVision and arrange them. Simple and intuitive.

How it Works

Start by signing into InVision (or creating an account). I'm actually surprised as how much InVision has changed over the year. They support Dropbox and Drive, even let you upload various image formats, including direct PSD files. But I am using JPG.

Setup

Create a new project for Android Phone in Portrait. Then add in all your screens. Just make sure their named well enough for you to identify (if you're handling many). The dashboard might take a little time getting used to, but trust me its easy. Simply tap the screen you want to start with and you're off. Start by going to Build Mode(B).Here's where most of work will happen. From now on, what we'll be doing is three steps repeatedly.

The 3 Step Process:

Define your clickable regions (Hotspots)
Select a destination screen
Choose a transition effect to go with it

That's all there is to it! Rinse repeat these 3 steps for all your screen controls. Don't forget to include back navigation at the bottom. Selecting a transition will add a more realistic feel for the app. Also note that you can optionally chose a different gesture apart from a tap, which includes swiping, double taps and more.

Final Mockup

So here it is! The final app mockup. Personally to me, it looks great. I've wrapped it in a white Galaxy S4, hidden the status bar as well (accessible via the gear icon below), and the app navigates as it should. Watch on YouTube Now I don't know who you are Trevor, but thank you for gracing my design.

Advantages

Now that we're done. Let me tell you WHY I chose to do my mockups this way. Well, I can use a software of my choice for design, one that I'm comfortable with. I'm able to design faster as a result of that. InVision is a powerful tool because it:

can sync from the cloud
accepts various image formats (PSD & Sketch too!)
can collaborate with other teammates
can help receive real-time feedback on designs
has a intuitive preview tool that looks great
can be shared with others via a simple link
can view design on an actual smartphone (via link)

Finally we're done with this long post. I see design as creative work that must be enjoyed. We've been introduced to two great tools: Illustrator and InVision, which help us create designs with great flexibility and put them together as a working prototype respectively. With InVision you can take it a step further, update your designs on the fly, add team members to collaborate as well. Both are powerful tools to help ease your design process. So if you're still struggling in code for initial design showcases, ditch that and get started here!

Material Design Android Ripple Effect

Wed, 01 Jul 2015 00:00:00 GMT

Here's on how to add a neat Ripple effect for your UI components. I'll take a button for this. Create new folder res/drawable-v21 and create a new XML ripple.xml

Add this to your button layout: android:background="@drawable/ripple" Note that the Android ripple effect only works on Lollipop versions and above. So you might want to use a normal color selector for previous versions as a fallback. So set your background to be a regular color selector, and for Lollipop handle it like this in your Activity.java

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
             button.setBackground(getDrawable(R.drawable.ripple));
}

Integrate Facebook Login with Parse - Part 2

Sat, 27 Jun 2015 00:00:00 GMT

If you've managed to survive Part 1, then welcome to Part 2 of the post! Here we'll look at actually integrating Facebook login with Parse. We'll fetch needed details from Facebook, sign up the user with Parse and store those details. In the previous part, we focused solely on getting Parse and Facebook SDK integrated in our apps, which by in itself was no ordinary feat. Now let's dive into our app and get these things to work.

Why Social Sign In?

The very fact that why we opt for a social login is to provide a richer login experience. The user already has his registered credentials on Facebook. We can use that do validate an existing user, rather than asking him to manually fill input fields. This is tedious on the user's part, which can be avoided. Moreover we can optionally pull other relevant data, which we can utilize to provide a richer user experience.

Create a Login Experience

The reason why I've purposely labelled it a login 'experience' which in short is your login screen, is because this is where users get to see your app for the first time, and if they don't like it now, they're probably never going to return. This is the very first screen your user will see and I strongly you spend ample time creating a good signup screen. Here's mine:

But for practice purposes, just a button would do for now. This button on click, will log in the user via Facebook.

Facebook Login

mBtnFb.setOnClickListener(new View.OnClickListener() {
           @Override
           public void onClick(View v) {
         ParseFacebookUtils.logInWithReadPermissionsInBackground(MainActivity.this, mPermissions, new LogInCallback() {
                   @Override
                   public void done(ParseUser user, ParseException err) {

                       if (user == null) {
                           Log.d("MyApp", "Uh oh. The user cancelled the Facebook login.");
                       } else if (user.isNew()) {
                           Log.d("MyApp", "User signed up and logged in through Facebook!");
                           getUserDetailsFromFB();
                       } else {
                           Log.d("MyApp", "User logged in through Facebook!");
                           getUserDetailsFromParse();
                       }
                   }
               });
           }
       });

The logInWithReadPermissionsInBackground is what we'll use to log in the user. We must supply a list of permissions to this method. This is akin to an AsyncTask. The LogInCallback provides a done() method. This is essentially what you must do upon log in completion. The 3 if conditions are clearly denoted by their respective Log tags. Upon logging in for the very first time, the app will redirect you to a Facebook screen where he/ she must consent that your app requires their Facebook information. After this we're back to our app. So now, you might want to take the user to your home screen with a successful Toast message! Alternatively, if it get's cancelled you should handle the error.

New Users

user.isNew() helps us identify that a new user is signing up. So after they log in via Facebook, we will retrieve their profile photo, name and email from Facebook. Then we will save those details to Parse. The getUserDetailsFromFB() method will help in fetching our Facebook data.

private void getUserDetailsFromFB() {

     // Suggested by https://disqus.com/by/dominiquecanlas/
     Bundle parameters = new Bundle();
     parameters.putString("fields", "email,name,picture");

     new GraphRequest(
             AccessToken.getCurrentAccessToken(),
             "/me",
             parameters,
             HttpMethod.GET,
             new GraphRequest.Callback() {
                 public void onCompleted(GraphResponse response) {
         /* handle the result */
                     try {

                         email = response.getJSONObject().getString("email");
                         mEmailID.setText(email);

                         name = response.getJSONObject().getString("name");
                         mUsername.setText(name);

                         JSONObject picture = response.getJSONObject().getJSONObject("picture");
                         JSONObject data = picture.getJSONObject("data");

                         //  Returns a 50x50 profile picture
                         String pictureUrl = data.getString("url");

                         new ProfilePhotoAsync(pictureUrl).execute();

                     } catch (JSONException e) {
                         e.printStackTrace();
                     }
                 }
             }
     ).executeAsync();

 }

As you can see, in essence this method will be responsible for executing 2 AsyncTasks:

GraphRequest - to fetch user name and email
AsyncTask (native) - to download profile photo and display on ImageView

The GraphRequest can help us fetch all sorts of data from Facebook. It requires some time understanding how it works, so I suggest you go through. The GraphResponse returns back JSON data which we can use to retrieve our required information. If you're unfamiliar with JSON parsing and how it works on Android, you can follow this brilliant post on AndroidHive that explains it brilliantly. However, that's only if you're interested in learning more. For the purposes of this post, you can just copy over my code snippet and it will work just fine :-)

saveNewUser()

If you noticed carefully, we call this method in the onCompleted() method of our GraphRequest. Why because, this method indicates what must be done upon completing the fetch request. This means that the requested data has been fetched. So once that is done, we can safely store our data in Parse. Doing so before might result in a crash! Alternatively, see the AsyncTask where we download our profile photo. If this takes longer to execute, then our saveNewUser() will still fail. Know why? We're attempting to download the photo while the AsyncTask may still be executing. If your AsyncTask takes a while, then again the app would crash. I have purposely done it this way to highlight the various issues when tasks execute in parallel. The fail safe way would be to call saveNewUser() in your AsyncTask's onPostExecute() method.

  private void saveNewUser() {
        parseUser = ParseUser.getCurrentUser();
        parseUser.setUsername(name);
        parseUser.setEmail(email);

//        Saving profile photo as a ParseFile
        ByteArrayOutputStream stream = new ByteArrayOutputStream();
        Bitmap bitmap = ((BitmapDrawable) mProfileImage.getDrawable()).getBitmap();
        bitmap.compress(Bitmap.CompressFormat.JPEG, 70, stream);
        byte[] data = stream.toByteArray();
        String thumbName = parseUser.getUsername().replaceAll("\\s+", "");
        final ParseFile parseFile = new ParseFile(thumbName + "_thumb.jpg", data);

        parseFile.saveInBackground(new SaveCallback() {
            @Override
            public void done(ParseException e) {
                parseUser.put("profileThumb", parseFile);

                //Finally save all the user details
                parseUser.saveInBackground(new SaveCallback() {
                    @Override
                    public void done(ParseException e) {
                        Toast.makeText(MainActivity.this, "New user:" + name + " Signed up", Toast.LENGTH_SHORT).show();
                    }
                });

            }
        });

    }

saveInBackground(), evident by the method (Yep you guessed it!) is used to save our user details to Parse via an AsyncTask. You can optionally have a SaveCallback if you want to do anything after a successful save. I've just showed a simple Toast notifying the user he signed up. The ParseUser class is used to fetch information from Parse related to the user, which we have defined globally and initialize only when needed. We set our user's email and username from what we retrieved from Facebook. Then we save our downloaded Facebook profile photo Bitmap as a ParseFile. Note how I'm saving this file. I dynamically create the thumbnail's file name based off the username. 'profileThumb' is a column which will automatically be created in our User class if it doesn't exist.

Profile Photo AsyncTask

Create a new class called ProfilePhotoAsync and make it extend AsyncTask. Now I'm not going too in depth about what these are for the post's sake.

AsyncTask enables proper and easy use of the UI thread. This class allows to perform background operations and publish results on the UI thread without having to manipulate threads and/or handlers.

In short, any task that will take time to execute or its duration to finish is unknown. If it risks stalling the UI making the app non responsive, then AsyncTask is your solution. This is exactly what we'll use to download our profile photo from Facebook.

class ProfilePhotoAsync extends AsyncTask {
      public Bitmap bitmap;
      String url;

      public ProfilePhotoAsync(String url) {
          this.url = url;
      }

      @Override
      protected String doInBackground(String... params) {
          // Fetching data from URI and storing in bitmap
          bitmap = DownloadImageBitmap(url);
          return null;
      }

      @Override
      protected void onPostExecute(String s) {
          super.onPostExecute(s);
          mProfileImage.setImageBitmap(bitmap);

          saveNewUser();
      }
  }

The brunt of your work must be done in the doneInBackground() method, which is why we're handling the actual download there. After your task is complete, what is be done next must come in the onPostExecute() method. When this method enters, our download task would be complete. So now we can set our downloading bitmap to our ImageView.

DownloadImageBitmap()

We'll use this handy utility method to handle our download. We simply pass a URL as a parameter to this method, which will return a Bitmap at the end. NOTE: Network operations must be run off the UI thread!

public static Bitmap DownloadImageBitmap(String url) {
        Bitmap bm = null;
        try {
            URL aURL = new URL(url);
            URLConnection conn = aURL.openConnection();
            conn.connect();
            InputStream is = conn.getInputStream();
            BufferedInputStream bis = new BufferedInputStream(is);
            bm = BitmapFactory.decodeStream(bis);
            bis.close();
            is.close();
        } catch (IOException e) {
            Log.e("IMAGE", "Error getting bitmap", e);
        }
        return bm;
    }

Whoa! That was really long. Let's take a breather here and look at what we've done so far. Up till now we've seen how to handle a NEW user. Fetched relevant details and photo from Facebook and saved it to Parse. Just make sure you're testing this app on a REAL device so we have internet and Facebook to work with. LG Nexus 5 is said to be the best device for this by many. Do run the app just ONCE. Log in and you will get a Toast saying you signed up. Great! Back to the post. We'll now show a Welcome back Toast if its a returning user that logs in. This is what your Parse panel should show you, after successfully running it once. There is now one new entry in your User class. Note all the relevant details from your Facebook fed into your Parse backend.

Returning User

We will simply fetch 3 data from Parse: name, email and profile photo (which we saved to a ParseFile).

 private void getUserDetailsFromParse() {
        parseUser = ParseUser.getCurrentUser();

//Fetch profile photo
        try {
            ParseFile parseFile = parseUser.getParseFile("profileThumb");
            byte[] data = parseFile.getData();
            Bitmap bitmap = BitmapFactory.decodeByteArray(data, 0, data.length);
            mProfileImage.setImageBitmap(bitmap);
        } catch (Exception e) {
            e.printStackTrace();
        }

        mEmailID.setText(parseUser.getEmail());
        mUsername.setText(parseUser.getUsername());

        Toast.makeText(MainActivity.this, "Welcome back " + mUsername.getText().toString(), Toast.LENGTH_SHORT).show();

    }

The email and username is fetched after initializing ParseUser and directly passed on to our TextViews. The ParseFile is retrieved via parseUser by specifying the 'key' (column name in the table). However, simply retrieving the file will not suffice so we basically have to undo the file conversion steps we did while storing the Bitmap into a ParseFile. Here, we have to reconstruct the Bitmap from the ParseFile data. Finally after all that, display a Toast welcoming back the user! Finally run the app now (second time) and log in via Facebook. You will see our name, email and profile photo appearing. Nothing new same as last time, but as developers, we know that only this time, the data which was earlier saved in Parse, is now being retrieved. :-)

End Result

I know the post has been long without any visual result. But finally here's an output you all can feast your eyes on!

Do ignore the grey rectangle in the middle. That's just me doing a miserable job of trying to hide my email ;-) Also note that the Facebook confirmation screen for you will look different (better and faster). I'm using an emulator (which sucks). You can also check out this code sample on GitHub. Just be sure to replace your Facebook AppID, Parse Application ID and Client Key in values/strings.xml.

Great. Now go ahead and jump in joy as you're done with this long post. Don't forget to Follow @Suleiman_194 and subscribe (below) for instant updates!

Integrate Facebook Login with Parse - Part 1

Thu, 25 Jun 2015 00:00:00 GMT

If you've heard about Parse back-end, then you'll also know that its a wonderful service which simplifies back-end management for your Android apps. Let's look at adding a Facebook login experience using Parse. This is part one of the post where I'll take time to help you familiarize yourself with these services. Along with integrating Parse, we'll also look look at adding a Facebook login to our app. For simplicity's sake, in part one we'll ONLY be looking at integrating the two. I will be mentioning essentials only, so that you can be swiftly done with a tedious boring process. We will first create a backend server for our app using Parse, upload test data to your backend as a check and then finally add the Facebook SDK and link it to Parse.

What is Parse?

Parse is a Backend as a Service (BaaS). It helps maintain a backend for your app, eliminating the need for you to manage a server or get caught in server side code. Parse greatly simplifies this process with their Android SDK. You'll wonder at just how much you're able to do with so little code, it's almost a miracle! Their pricing plans is quite generous as well so its more than enough for our purposes. Even for small realtime apps!

Facebook SDK

Facebook's SDK for Android lets us augment our apps with powerful social features. But for now, we're only interested in their Login feature. We need to connect Facebook's SDK to Parse first. Upon doing so, we can handle Facebook login with Parse.

Android Studio Setup

I'm including my Gradle settings in case any of you should run into issues, you can cross check here first :-)

compileSdkVersion 23
buildToolsVersion 23.0.2
minSdkVersion 15
targetSdkVersion 23
support libraries 23.1.1

Setting up Parse

Start off with creating a Parse account (if you don't have one). You'll be presented with a welcome screen.

New Project

Click Data> Mobile> Android> Native (Java)> Existing Project Now you could go ahead following Parse's on screen instructions, but I strongly suggest you follow mine instead for a more updated approach. But don't close that page just yet. Why existing? Because trust me, its better to add Parse manually to our app. On the last step, start off with downloading the latest SDK from there, or here. Hate to break it to you, but unlike other libraries that we include via a single line in Gradle, Parse doesn't give us such a luxury (yet). So we'll have to download the library and include the .jar manually.

dependencies {
    ...
    compile 'com.parse.bolts:bolts-android:1.3.0'
    compile 'com.parse:parse-android:1.12.0'
}

Connect app to Parse

With the libraries in place, we need to now add the respective permissions to the Manifest file and initialize Parse with our unique App ID.

Create a new class 'MyApp' extending Application and add this:

public class MyApp extends Application {

    @Override
    public void onCreate() {
        super.onCreate();

        // Enable Local Datastore.
        Parse.enableLocalDatastore(this);
        
        Parse.initialize(this);
    }
}

If you didn't close your Parse page yet, the last step will conveniently display your applicationId and clientKey you can just copy it over. Head over to your AndroidManifest.xml and add this directly under your application tag.

...

If all goes well, there won't be any errors being highlighted using the Parse API.

Test

However, lets not jump to conclusion and just test if our app is really connected. As Parse says, add the following code in your MainActivity.java onCreate method.

ParseObject testObject = new ParseObject("TestObject");
testObject.put("foo", "bar");
testObject.saveInBackground();

Run your app once, hit the Test button and all should be well :-) Once you're through with that, head over to the Dashboard and click your App. Click the Core tab above. You should see the Data with a class 'TestObject' and one data entry.

Each data you insert is part of a class which you must define. You can see from the above code sample that "foo" is our column name and "bar" is its corresponding data. To retrieve the data you would use testObject.get("foo"); Parse has a really good documentation which is a pleasure to read. I highly recommend that you spend some time reading it.

Finally we've included the Parse Android SDK, linked our app with Parse and even tried storing test data to confirm that it works. Now we'll move onto adding the Facebook SDK for the login.

Adding Facebook SDK

We need to setup Facebook's SDK to be used with Parse. Head over to Facebook and add a new Android app. Now you can follow the on screen instructions over at Facebook to integrate but as always, I suggest you follow this post to get the long version short. You might have noticed that when we copied over the Parse.jar, we did so for the FacebookUtils.jar as well. This is what that's going to help us link Facebook so Parse can handle the login for us. Add this line to your Gradle to include the Facebook SDK in your app:

compile 'com.facebook.android:facebook-android-sdk:4.7.0'

Do try to follow closely from this point on, otherwise the SDK won't work. You could have a coffee, relax and get back!

Key Hash

Just head over to the Key Hashes section in Quick Start. Add your package name and just the 'class' name for the 'Default Activity Class Name'. Make sure you save the development key hash. To generate a key hash, use this code snippet and then run your app.

try {
            PackageInfo info = getPackageManager().getPackageInfo(
                    "com.suleiman.parseapp",
                    PackageManager.GET_SIGNATURES);
            for (Signature signature : info.signatures) {
                MessageDigest md = MessageDigest.getInstance("SHA");
                md.update(signature.toByteArray());
                Log.d("KeyHash:", Base64.encodeToString(md.digest(), Base64.DEFAULT));
            }
        } catch (PackageManager.NameNotFoundException e) {

        } catch (NoSuchAlgorithmException e) {

        }

Copy the key hash from your logs. Head over to your app's Settings and paste your key hash there. This key is required to access any data from Facebook with their Graph API.

NOTE: If you happen to get a key hash related error when running your app in the future (after the integration), Facebook will show your key hash along with your error. You can manually type that into your App> Settings.

Linking Facebook to Parse

Go to your Parse app's Settings> Authentication and enable Facebook. Copy over your 'App ID' and 'App Secret' from Facebook over to your Parse Settings.

Open your AndroidManifest.xml and add these directly below the tag.

...

Initialize ParseFacebookUtils

ParseFacebookUtils allows Parse to hook up with Facebook. This makes sign up via Facebook as seamless as possible. We need to import a library for that:

dependencies {
           ...
           compile 'com.parse:parsefacebookutils-v4-android:1.10.3@aar'
}

Initialize Parse with Facebook in your MyApp.java's onCreate method. Make sure you do it AFTER Parse.initialize

ParseFacebookUtils.initialize(this);

Now, for whichever Activity that will implement the login, head over to that very Activity.java and add this method.

@Override
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        super.onActivityResult(requestCode, resultCode, data);
        ParseFacebookUtils.onActivityResult(requestCode, resultCode, data);
    }

After this, if you want you can try a simple Facebook GraphRequest or even signing up the user yourself via Facebook through Parse, if you're feeling bold enough! However this post has gone long enough, so head over to Part 2 for the rest.

Now give yourself a pat on the back if you've made it this far. You've successfully integrated both Parse AND Facebook SDK for your app, and that sir, is no ordinary feat! In the next part, we'll look at how to do a proper Facebook login, pull required user information, store it on Parse and then display it. Give yourselves some credit for making it to the end. Hope you've been able to follow along. For further queries, fire away in the comments below and as always, I'd be happy to help. Cheers.

Tint Icons in Android for pre Lollipop

Sun, 21 Jun 2015 00:00:00 GMT

Tint icons were first seen on Android Lollipop. The same can now be done on previous versions too with the help of Support Libraries. Here's on how to tint your icons: 1. Retrieve your drawable and wrap it first. Then set the tint

Drawable drawable = getyourdrawablehere;
drawable = DrawableCompat.wrap(drawable);
DrawableCompat.setTint(drawable, Color.GREEN);

Set the Tint mode

DrawableCompat.setTintMode(drawable, PorterDuff.Mode.SRC_IN);

If you want to retrieve the original drawable, don't forget to unwrap using DrawableCompat.unwrap() .

Quick Return Pattern with Android Design Support Library

Thu, 18 Jun 2015 00:00:00 GMT

The 'Quick Return' is a famous UI pattern seen in Android apps. It aims to dedicate the screen's maximum possible real estate to content, instead of controls. With Android Design Support Library, the same which was harder in the past, is now quite easy!

Quick Return Pattern

This is similar to Google Now's search box. It scrolls off-screen with the rest of the scrollable content, but upon scrolling slightly up at any point, it scrolls back into view - Roman Nurik

You might have come across this in my Implement a FAB post where I would've showed you how to implement this which was quite a tedious process. The good news is, in this post the very same effect is quite easily achievable with pure XML only! Take a look at this video for a better understanding. Watch on YouTube We can see a lot of famous apps implement the Quick Return pattern such as Google +, WhatsApp and Play Store. The Android Design Support Library enables us to achieve this pattern with minimal effort. Something which was an intensive process to do in the past!

When to use it?

The pattern works best when you have a long list of scrollable content. A perfect example would be a contacts list, a news feed and even a gallery. Content always takes top priority and giving maximum screen space to just that is essential. Screen real estate is all the more important in phones which have smaller displays compared to their tablet counterparts. Controls such as the Toolbar (ActionBar), Split Action Bar, Floating Action Button, all take up space and prove to be a hindrance. Hence really long scrollable content is the perfect opportunity for us to implement this pattern and hide such persistent controls. These can always be revealed upon scrolling up again. Also read:

Layout

Let's take a look at how our XML structure will be first. The AppBarLayout will help us control the Toolbar behavior.

If any of the new widgets don't make sense to you, then I highly recommend that you go through my previous post which clearly explains everything.

Do note the highlighted lines as these two are key in making the Quick Return pattern actually work! The scroll flag enables views to scroll off the screen, while enterAlways enables the Quick Return pattern. The string resource 'appbar_scrolling_view_behavior' tells the AppBar how to react upon scrolling the RecyclerView.

Wrapping it up!

That's all there is to it really! Just don't forget to do the usual drill where you need to set up your Toolbar as ActionBar and then populate your RecyclerView! ;-) When you're done with all that, go ahead and run your app. Your Toolbar will now be responding to scroll in RecyclerView. The Quick Return pattern will be enabled. As you scroll down the Toolbar moves out of the screen and while scrolling down even slightly, the Toolbar moves back into the screen.

Check out this code sample on GitHub.

Maximizing screen real estate is of real importance for apps especially those running on phone that have small screens. Making use of the available space smartly allows us to hide what's not required, allowing our content to stand out. This eliminates hindrances, prioritizing the content our users want to see comfortably. NOTE: The Design Support Library is the first of its kind and aims to achieve big. But being released recently, it is bound to have its bugs. Do subscribe (below) or Follow @Suleiman_194 for instant updates on new posts, tips and tricks in Android design. Cheers!

Create a Card Toolbar (Nested Toolbar) in Android

Mon, 15 Jun 2015 00:00:00 GMT

I heard Android updated its Material Design specs, so I revisited the site to check out what's new. While looking around the Layout Structure section, I came across a particular image "Flexible toolbar and card toolbar". So being the inquisitive person I am , I went ahead trying to replicate the pattern.

In this post we'll look at how to make this. A Card Toolbar resting above another extended Toolbar. Also read: Add a Toolbar Elevation on pre Lollipop.

Layout Structure

If you observe closely, the background is a regular Toolbar with an extended height. It doesn't have a menu, whereas the secondary Toolbar is set within a CardView, inflates a menu and a Title as well. There is a divider (View) that rests below the secondary Toolbar. Let's look at how our layout structure will look like first.

Extended Toolbar

The extended Toolbar takes double the default Toolbar height (i.e. 56dp x 2 = 112dp) keeping in mind that's the measurement for a portrait oriented phone. So you might want to add relevant values under your dimens.xml for landscape and tablet sizes as well! However, I will cover the minimum dimen values here.

Toolbar Height

Below are the default Toolbar heights. Remember we need twice the Toolbar's height for the extended Toolbar. Mobile Landscape: 48dp Mobile Portrait: 56dp Tablet/Desktop: 64dp Under res/values/dimens.xml add this:

112dp

Then, under your values-land and values-sw600dp, add the same item with dimensions 96dp and 128dp respectively. If you're still wondering how I got those values, you might want to check this out. So our extended Toolbar's XML will simply be this:

...

Card Toolbar

You might have noticed the card has some margins. The top margin is the Toolbar's height. We'll wrap the Toolbar in a LinearLayout, along with a 1dp tall View which holds the divider. The CardView side margins when used on a phone must be minimal (since it already lacks width). However for landscape and tablet forms, you could add side margins anywhere between Toolbar Height or Toolbar Height x 2.

Final Layout

Final Setup

Lastly, we need a bit of Java to wrap things up so open your Activity.java and setup your SECONDARY Toolbar (Card Toolbar) to be the ActionBar. This will use the inflated menu resource as well. Keep in mind the primary Toolbar (extended) on the top will be holding just the Navigation Drawer icon.

// Card Toolbar as ActionBar (to inflate menu)
setSupportActionBar(mToolbar2);
getSupportActionBar().setTitle("Title");
// Extended Toolbar (holds drawer icon)
mToolbar1.setNavigationIcon(R.drawable.ic_action_menu);
mToolbar1.setNavigationOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
         // TODO: Handle Navigation Drawer menu click here
    }
});

With that we're done! You might have noticed how our layout is turning out to be on the Preview pane in Studio, while creating the XML layout. However do run the app and take a look, just in case ;-)

Divider Height Issue

Note that the divider view below the Card Toolbar must align in height exactly with where the extended Toolbar's height ends. Now while the preview shows it just fine, when we actually run the app, this may not be the case leading to misalignment due to reasons unknown. However this can be resolved with a simple fix. Add a layout_marginTop="-4dp" to your Card Toolbar. Feel free to alter that value as you see fit in order to align the divider and extended Toolbar exactly. Though -4dp works perfect for me! So with all things in place, run your app for the last time. It will be perfectly aligned now! Try it on different screen sizes and orientations to check if it aligns properly. Here are final screenshots from my phone, portrait and landscape orientation.

Click to buy Nexus 9

NOTE: This layout style works best on tablet devices. Nexus 9 is a brilliant tablet device and one of the best to buy.

In this post the fact that the Toolbar can be used flexibly like another other view is reinforced. We've added two Toolbars in our layout and attached one inside a CardView. Check out the code sample for this on GitHub. Do subscribe (below) or Follow @Suleiman_194 for instant updates on new posts, tips and tricks in Android design!

Add a Toolbar Elevation on pre Lollipop

Mon, 08 Jun 2015 00:00:00 GMT

Being a Material Design lover, I get put off by that default flat Toolbar with no shadow or elevation. It's alright on Lollipop devices as it gives us a nice shadow by default, but pre Lollipop doesn't. While that's too bad, we can take care of that real quick! After you're done with this post, your Toolbars on pre Lollipop will never be plain and boring again! Also read: Create a Card Toolbar (Nested Toolbar).

Faking a Toolbar Elevation

Since we can't use the actual Toolbar elevation property for pre Lollipop devices, we'll imitate one by using :

9-patch PNG
XML gradient

Personally, I find the XML method more clean, so we'll go with the second one.

Shadow Drawable

Create a new XML file res/drawable/shadow.xml

Here we set a gradient from top to bottom of an opacity of black to transparent respectively.

Creating the Toolbar

Now the trick doesn't lie in modifying the Toolbar as such, but in simply adding a View below it. Usually we may define a Toolbar in a separate XML file and call it in via the tag. We'll stick to the same format (to avoid large and complex layouts). Create a layout res/layout/toolbar_shadow.xml and add this:

Calling it in

Now with that in place, all we need to do is to reference this in our activity's layout like this:

That's it we're done! Take a look at the results yourself and see the difference.

on pre Lollipop

Toolbar Elevation on Lollipop

You can default to the elevation property for Lollipop devices. Now in some cases, as with the new Design support library's new widgets, after the animation the Toolbars by default have a shadow. So do the Tabs. You could reference the shadow's View via an id, and removing it with:

shadowView.setVisibility(View.GONE);

Then set the Toolbar elevation with

toolbar.setElevation(4);

But Wait!

In my opinion, just stick to using the shadow.xml on both pre Lollipop and Lollipop devices. Why? The difference isn't much and is hardly noticeable.

This is a better trade-off than having to handle it in code, where you must remove the shadow view, then elevate it. That is just a lot of code handling and possible layout inconsistency, you're much better off this way. One must not waste time as a developer to get something like that to work.

With this way, you can now mimic an elevation for your Toolbars on pre Lollipop as well. We created a shadow drawable in XML using a gradient property. Also you've probably accepted the fact that its okay to continue using the same drawable on post Lollipop as well, being a well worth sacrifice.

Do subscribe (below) for instant updates as I continue to bring you more awesome content like this!

Material Design Tabs with Android Design Support Library

Sat, 06 Jun 2015 00:00:00 GMT

This is my third post where I continue to bring you more from the Design Support Library. Let's look at adding a Material Design Tab strip for our apps with on scroll animations.

Tabs make it easy to explore and switch between different views. Provides a way for displaying grouped content.

– Material Design, Tab Component

This article has been updated for AndroidX!

Material Design Tabs made easy

You can see Material Design tabs popularly on the Play Store app, and more recently on WhatsApp as well (after their Material Design update).

Material Design Tabs in Play Store

Tabs in WhatsApp

To implement Tabs earlier, we had to rely on external libraries. Also, let's not forget the hide on scroll animations which we had to make ourselves!

When you're done reading this post, you'll be able to create amazing Material Design tabs for your apps. Like the ones above.

So let's get to it!

Also read:

Layout

Have you closely observed how Tabs actually behave?

When you click a Tab, it becomes active and slides in a new screen. Rather a new sub-screen called Fragment. We either tap a Tab, or swipe left or right to access adjacent Tabs.

Tabs are typically found anchored to the bottom of the Toolbar.

In essence, the entirety of those Tab screens are Fragments, which will be handled by a ViewPager. Think of it like a gallery slideshow.

But before we dive into all of that, let's setup our main layout.

Here's a skeleton of the layout.

<androidx.coordinatorlayout.widget.CoordinatorLayout>
   <com.google.android.material.appbar.AppBarLayout>
      <androidx.appcompat.widget.Toolbar />
      <!-- The Tab rests directly below the Toolbar, attached below it -->
      <com.google.android.material.tabs.TabLayout />
   </com.google.android.material.appbar.AppBarLayout>
   <!-- Helps handing the Fragments to load for each Tab -->
   <android.support.v4.view.ViewPager />
</androidx.coordinatorlayout.widget.CoordinatorLayout>

For creating Tabs, we use the TabLayout widget class. This is a new widget, part of the Design Support Library.

Additionally, you might notice other new widgets as well. If you're not familiar with them, I strongly suggest you go through this post first.

That's the skeleton of our Activity layout. Let's start defining it now. Open your Activity's layout.xml

<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <com.google.android.material.appbar.AppBarLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar">

        <androidx.appcompat.widget.Toolbar
            android:layout_width="match_parent"
            android:layout_height="?attr/actionBarSize"
            android:background="?attr/colorPrimary"
            app:layout_scrollFlags="scroll|enterAlways"
            app:popupTheme="@style/ThemeOverlay.AppCompat.Light" />

        <com.google.android.material.tabs.TabLayout
            android:layout_width="match_parent"
            android:layout_height="wrap_content" />
    </com.google.android.material.appbar.AppBarLayout>

    <android.support.v4.view.ViewPager
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        app:layout_behavior="@string/appbar_scrolling_view_behavior" />

</androidx.coordinatorlayout.widget.CoordinatorLayout>

The scroll flags for the Toolbar specify how it must behave upon scroll (i.e. its animation).

scroll|enterAlways says make my Toolbar react to scroll events. Hide it when scrolling down, and reveal it when scrolling back up.

This behavior will be indicated by our ViewPager which will be hold our Fragments. The Fragments hold our scrollable view. So when we scroll down a list, the Toolbar knows when to react.

TabLayout and Toolbar in XML preview

Setting up TabLayout

That's our main layout. Now open up YourActivity.java.

final Toolbar toolbar = findViewById(R.id.tabanim_toolbar);
setSupportActionBar(toolbar);

final ViewPager viewPager = findViewById(R.id.tabanim_viewpager);
setupViewPager(viewPager);

TabLayout tabLayout = findViewById(R.id.tabanim_tabs);
tabLayout.setupWithViewPager(viewPager);

First, start off by setting up your Toolbar. Then define the ViewPager. We'll attach an Adapter to in the setupViewPager() method. Finally define the TabLayout, and attach the ViewPager to it.

Remember that we must attach an adapter to the ViewPager first. Then attach the ViewPager to TabLayout.

`setupViewPager()` method

Here I will simply initialize a ViewPagerAdapter (our custom adapter class which I will explain in a moment) and add 3 fragments to it.

For simplicity's sake, I will be attached the same Fragment thrice which different backgrounds. However in a real app scenario, you would be attaching different once.

Let's assume you have 3 tabs. Games, Movies, Books. Then you should be loading their respective fragments here in ORDER of the tabs.

private void setupViewPager(ViewPager viewPager) {
 ViewPagerAdapter adapter = new ViewPagerAdapter(getSupportFragmentManager(), FragmentPagerAdapter.BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT);
 adapter.addFrag(new DummyFragment(
  ContextCompat.getColor(this, R.color.blue_grey)), "CAT");
 adapter.addFrag(new DummyFragment(
  ContextCompat.getColor(this, R.color.amber)), "DOG");
 adapter.addFrag(new DummyFragment(
  ContextCompat.getColor(this, R.color.cyan)), "MOUSE");
 viewPager.setAdapter(adapter);
}

So let's define our Tabs and give each one a name. Cat, Dog and Mouse (for the lack of better names) will be my 3 Tabs.

Defining our Adapter

Remember that ViewPagerAdapter I told you about? Let's create a class for it now, extend FragmentPagerAdapter and implement the required methods.

We need to store, first our Fragments itself, and then the Tab titles. We'll do this with a List.

private final List<Fragment> mFragmentList = new ArrayList<>();
private final List<String> mFragmentTitleList = new ArrayList<>();

Our entire Adapter class will look like this:

class ViewPagerAdapter extends FragmentPagerAdapter {
 private final List < Fragment > mFragmentList = new ArrayList < > ();
 private final List < String > mFragmentTitleList = new ArrayList < > ();

 public ViewPagerAdapter(FragmentManager manager) {
  super(manager);
 }

 @Override
 public Fragment getItem(int position) {
  return mFragmentList.get(position);
 }

 @Override
 public int getCount() {
  return mFragmentList.size();
 }

 public void addFrag(Fragment fragment, String title) {
  mFragmentList.add(fragment);
  mFragmentTitleList.add(title);
 }

 @Override
 public CharSequence getPageTitle(int position) {
  return mFragmentTitleList.get(position);
 }
}

Note that addFrag() is my own custom method. I'm using it to add Fragments and its titles to the ViewPager adapter.

Tabs with ViewPager Adapter

Tab Fragment

Now that we've done all this, you might be wondering what is 'DummyFragment' and why its showing an error?

DummyFragment is to be your Fragment (obvious from the name), which holds the layout content. This is what we see when we swipe to each Tab. Ideally, you should be loading a different Fragment for each tab.

The layout could be anything. But I don't want to complicate things.

Just be sure for testing, to make a list long enough so that its scrollable. This will allow the Quick Return scroll animation to work.

I encourage you to create your own layouts for the Tab Fragment. You could refer mine, but if you're like "Hey, I can do this!", then good job! Scroll down to the next section.

    public static class DummyFragment extends Fragment {
        int color;
        SimpleRecyclerAdapter adapter;

        public DummyFragment() {
        }

        @SuppressLint("ValidFragment")
        public DummyFragment(int color) {
            this.color = color;
        }

        @Override
        public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
            View view = inflater.inflate(R.layout.dummy_fragment, container, false);

            final FrameLayout frameLayout = view.findViewById(R.id.dummyfrag_bg);
            frameLayout.setBackgroundColor(color);

            RecyclerView recyclerView = view.findViewById(R.id.dummyfrag_scrollableview);

            LinearLayoutManager linearLayoutManager = new LinearLayoutManager(getActivity().getBaseContext());
            recyclerView.setLayoutManager(linearLayoutManager);
            recyclerView.setHasFixedSize(true);

            List<String> list = Arrays.asList(VersionModel.data);

            adapter = new SimpleRecyclerAdapter(list);
            recyclerView.setAdapter(adapter);

            return view;
        }
    }

Tabs with Fragments attached

Tab Listener

We can interact with the TabLayout and dictate what must happen when selecting a Tab, unselecting, reselecting and so forth.

While we're staying on topic, let me show you how we can add such a listener to it.

tabLayout.setOnTabSelectedListener(new TabLayout.OnTabSelectedListener() {
 @Override
 public void onTabSelected(TabLayout.Tab tab) {
  viewPager.setCurrentItem(tab.getPosition());

  switch (tab.getPosition()) {
   case 0:
    showToast("One");
    break;
   case 1:
    showToast("Two");
    break;
   case 2:
    showToast("Three");
    break;
  }
 }

 @Override
 public void onTabUnselected(TabLayout.Tab tab) {}

 @Override
 public void onTabReselected(TabLayout.Tab tab) {}
});

Note viewPager.setCurrentItem(tab.getPosition()) handles changing the Fragment based on Tab click.

Yes, all it takes is to use setOnTabSelectedListener with TabLayout.OnTabSelectedListener().

Just for demonstration, I'll show a simple Toast when you tap a Tab item. This works not only when tapping, but also when swiping left or right! In essence, a Toast pops each time the Fragment loads into view.

v23.0.0 Tab Listener Fix:

With the release of Android Marshmallow, libraries got updated to 23.0.0 including the Design Support Library. This update somehow broke the tab listener in a viewpager + tab combination. So if click listener for the tabs stops working for you, here is a suggested workaround for it, suggested by Chris Banes himself.

Material Design Tabs in Action

Let's take a breath and break down what we've accomplished so far:

Created our main TabLayout
Initialized a ViewPager and attached an Adapter (ViewPagerAdapter) to it
Attached the ViewPager to our Tabs
Created the Fragment content to supply our ViewPager with

Finally with all that code behind us, lets run our app and see how it looks like.

Watch on YouTube

That's it! We've got some great looking Material Design Tabs (without a third party library). Created the needed adapter and even got those snazzy on scroll animations for our Toolbar.

Note the Tab underline highlight takes colorAccent by default. Also, did you just notice we got those animations to work just by defining it in XML? No Java. Cheers!

Thats what Android Design Support library allows us to do. Making the easy stuff easier.

Get Source Code from GitHub

How are you using TabLayout in your apps? Have anything else to add? Let me know in the comments.

Toolbar Animation with Android Design Support Library

Wed, 03 Jun 2015 00:00:00 GMT

In this Android tutorial we'll create an on scroll, collapsing Toolbar animation.

The Design support library for Android makes it easy to create great animations. Let's look at how to create an app with a collapsing Toolbar animation. It's know as the Flexible Space with Image pattern, a popular scrolling technique.

I didn't know this pattern actually had a name until Ian Lake happened to point it out for me.

This article has been updated for AndroidX!

Flexible Space with Image Pattern

A scrolling technique that supports an image header with a scrollable view below it. Upon scrolling, the 'Flexible Space' (image header) gets tinted with or. At the same time, it collapses into a Toolbar.

– Material Design guidelines

This pattern is a popular scrolling technique. In familiar terms, you can see this in WhatsApp’s contact detail screen.

Here’s the step-by-step screenshots of the Flexible Space animation. Should give you a clear picture of what’s going on.

Flexible Space with Image Pattern - step by step

Notice the Toolbar dynamically changes color, depending on the image. It takes on the most dominant color present in the image.

We can do this with the Palette API, but more on that later.

You might immediately start to freak out with the amount of code it might take. But rest assured, there's no scary Java code to write. Most of it is XML, so cheers to that!

Other Design Support Library tutorials:

Here’s a useful index for navigating the article. Sections include not just how to implement the pattern. But also how to do it correctly, in terms of UI and UX.

Table of Contents

Getting Started
Floating Action Button
1. The Hidden Action
2. Updating Toolbar Menu
Dynamic Colors with Palette API
1. Using the Palette API
Complete Activity Code
Toolbar Animation in Action

Getting Started

Start by adding the Design Support Library to your app/build.gradle file.

NOTE
The Design Support package is now part of Android X.

dependencies { … implementation 'androidx.appcompat:appcompat:1.1.0' implementation 'com.google.android.material:material:1.0.0' }

Layout Structure

As always, we’ll get started with the XML first. Open your activity.xml layout.

Here’s the layout skeleton.

<androidx.coordinatorlayout.widget.CoordinatorLayout>
   <com.google.android.material.appbar.AppBarLayout>
      <com.google.android.material.appbar.CollapsingToolbarLayout>
         <ImageView />
         <androidx.appcompat.widget.Toolbar />
      </com.google.android.material.appbar.CollapsingToolbarLayout>
   </com.google.android.material.appbar.AppBarLayout>
   <!-- Your scrollable content here -->
</androidx.coordinatorlayout.widget.CoordinatorLayout>

Design Support UI Widgets

I understand if all these layouts might appear new to you. But you won't have to worry. I'll do my best to explain them in the easiest way.

1. CoordinatorLayout

A powerful FrameLayout that specifies behavior for child views for various interactions. It also allows anchoring of floating views in your layout.

2. AppBarLayout

It is a special kind of vertical LinearLayout. It helps respond to its children’s scroll events (scroll gestures). Additionally, it's responsible for implementing many features of Material Design’s AppBarLayout.

But, there's one thing to note. Its usage relies on being a direct child within CoordinatorLayout. The layout skeleton above demonstrates this.

3. CollapsingToolbarLayout

It is a Toolbar wrapper which makes the ‘Flexible Space’ pattern possible. It collapses the image header while decreasing the expanded title to a Toolbar title.

What’s left is the ImageView which holds our actual header’s image and Toolbar which we’re familiar with.

4. FloatingActionButton

I'm sure you're familiar with what a Floating Action Button is, aren't you? Android gave it a thumbs up by giving us an official UI widget. It's a part of the Design Support Library.

Defining the XML Layout

Alright, with that out of the way lets get to the actual XML.

A word of caution. The layout below might look threatening in size!

<?xml version="1.0" encoding="utf-8"?>
<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:fitsSystemWindows="true">

    <com.google.android.material.appbar.AppBarLayout
        android:id="@+id/appbar"
        android:layout_width="match_parent"
        android:layout_height="@dimen/appbar_header_height"
        android:fitsSystemWindows="true"
        android:theme="@style/ThemeOverlay.AppCompat.Dark.ActionBar">

        <com.google.android.material.appbar.CollapsingToolbarLayout
            android:id="@+id/collapsing_toolbar"
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            android:fitsSystemWindows="true"
            app:contentScrim="?attr/colorPrimary"
            app:expandedTitleMarginStart="@dimen/activity_margin_content"
            app:layout_scrollFlags="scroll|exitUntilCollapsed|snap">

            <ImageView
                android:id="@+id/header"
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                android:background="@drawable/header"
                android:fitsSystemWindows="true"
                android:scaleType="centerCrop"
                app:layout_collapseMode="parallax" />

            <View
                android:layout_width="match_parent"
                android:layout_height="80dp"
                android:layout_gravity="top"
                android:background="@drawable/scrim_topdown"
                android:fitsSystemWindows="true" />

            <View
                android:layout_width="match_parent"
                android:layout_height="160dp"
                android:layout_gravity="bottom"
                android:background="@drawable/scrim" />

            <androidx.appcompat.widget.Toolbar
                android:id="@+id/anim_toolbar"
                android:layout_width="match_parent"
                android:layout_height="?attr/actionBarSize"
                app:layout_collapseMode="pin"
                app:popupTheme="@style/ThemeOverlay.AppCompat.Light" />

        </com.google.android.material.appbar.CollapsingToolbarLayout>

    </com.google.android.material.appbar.AppBarLayout>

    <androidx.recyclerview.widget.RecyclerView
        android:id="@+id/scrollableview"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:clipToPadding="false"
        android:paddingTop="@dimen/activity_margin_content"
        android:paddingBottom="@dimen/activity_margin_content"
        app:layout_behavior="@string/appbar_scrolling_view_behavior"
        tools:listItem="@layout/item_dessert" />

    <com.google.android.material.floatingactionbutton.FloatingActionButton
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_margin="@dimen/fab_margin"
        android:clickable="true"
        android:focusable="true"
        android:src="@drawable/ic_action_add"
        app:backgroundTint="#279AF1"
        app:fabSize="normal"
        app:layout_anchor="@+id/appbar"
        app:layout_anchorGravity="bottom|right|end" />

</androidx.coordinatorlayout.widget.CoordinatorLayout>

This is not complex code. XML just tends to be a little verbose. But you're welcome to try replicating the Flexible Space scroll animation in Java. Then I'm sure you'd truly appreciate how easy the Design Support library is!

However, I have highlighted the essential lines you need to focus on.

What you need to know from this?

line 24: layout_scrollFlags
Tells the CollapsingToolbarLayout and its children, how to behave on a scroll.
Here’s what the flags mean, straight from the developer’s blog:
- scroll:
  this flag should be set for all views that want to scroll off-screen. For views that do not use this flag, they’ll remain pinned to the top of the screen.
- exitUntilCollapsed:
  causes the view to scroll off until it is ‘collapsed’ before exiting
- snap:
  enables the expanded view to snap to either a collapsed state, or expanded state. There is no in-between state. If the View has been dragged more towards expanding, it expands completely. If its dragged more towards collapsing, the View collapses completely.
line 33: layout_collapseMode
Indicates how the ImageView reacts while collapsing on-scroll.
There are 2 collapse modes:
- COLLAPSE_MODE_PARALLAX (use for ImageView)
- COLLAPSE_MODE_PIN (use for Toolbar)
line 63: layout_behavior
The CoordinatorLayout performs most of its magic using Behavior. Behaviors tell how its child Views must interact with each other.
line 73: layout_anchor
Remember we spoke about anchoring Views earlier? This attribute tells FloatingActionButton to anchor' itself to AppBarLayout.
line 74: layout_anchorGravity
This attribute tells our View where to display, on its anchor View.

Here’s what the Android Studio’s Preview pane shows us.

Flexible Space with Image Pattern - XML Layout Preview

But wait. Does the expanded title look clear enough to you? I’m sure it’s not.

Whenever you display a label (TextView) against a background image, use a 'scrim'. It will help make the text more readable.

TIP
Use a Scrim for clear, readable Text

A Scrim is a semi-transparent gradient layer that helps Text appear more readable against backgrounds.

Just below your ImageView, add a simple View with a gradient Drawable as background.

Here’s the Drawable scrim.

See the difference for yourself.

Header without(Before) and with(After) Scrim

While the difference is subtle, the latter is much better right? Additionally, you can apply another scrim for the Toolbar. It can help the back and overflow icons be more visible. I leave this as an exercise for you.

There are many other techniques that you can use to display text over images.

Getting the Parallax Scroll right

I’ve already mentioned a hint above on parallax scroll. But there’s more to it. We can achieve parallax scrolling with ImageView by setting its layout_collapseMode to parallax.

Parallax Scrolling involves the background moving at a slower rate to the foreground.

– Creativebloq.com

Did you notice an extra collapse mode attribute for the Toolbar? Yes, you must use this as well. Why? Because, while the ImageView should collapse, the Toolbar must persist on scrolling.

Toolbar must use collapseMode:pin, because we want it to persist and remain on top, as the user scrolls down.

Note that I haven’t set any color for the Toolbar. The CollapsingToolbarLayout takes care of this. It dynamically picks up a color from our image and sets it to the Toolbar.

Floating Action Button

Let's look at the Floating Action Button for a bit. I'll stick to calling it FAB from now on. If you tried to create a FAB earlier, you'd realize how hard it was. Yes, my previous posts on the FAB are now redundant. Sigh.

But with the Design Support Library, that's not the case anymore. The layout above shows, how easy it is!

Notice that I haven't explicitly defined a size for the FAB. By default, it takes its regular width and height of 56dp. But, you can define this by using the following attribute.

app:fabSize="regular"

Optionally, you can set the fabSize as mini, which is a miniature version of the FAB at 40dp in size.

Next, in the layout, we position the FAB with alignment to the AppBarLayout. We do this with the layout_anchor attribute.

    <com.google.android.material.floatingactionbutton.FloatingActionButton
        ...
        app:layout_anchor="@+id/appbar"
        app:layout_anchorGravity="bottom|right|end" />

FAB without and with anchor attribute

That’s a wrap for the XML part. The good news is, this XML is all that's required to trigger the Flexible Space scroll animation.

But wait! There’s still one thing that seems a bit off. What about the FAB’s action? After scrolling, the action goes hidden. It becomes available, only when you scroll, all the way to the top.

The Hidden Action

Once the AppBar collapses, we need to show the FAB’s action somewhere.

Now I’m not saying this is the recommended approach. But my suggestion is that once the FAB vanishes, we add the action to the Toolbar’s menu.

Dynamic Toolbar Menu item

To do this we’ll need a listener first. We have to listen to the when the AppBarLayout expands and collapses. To be precise, we need an OffsetChangedListener.

If the AppBarLayout’s ‘verticalOffset’ is zero, then its fully expanded. So when the verticalOffset is almost equal to the fully expanded height, add the action to Toolbar’s menu.

First, let’s look at how to set the listener. Here’s how to do it.

appBarLayout.addOnOffsetChangedListener(new AppBarLayout.OnOffsetChangedListener() {
  @Override
  public void onOffsetChanged(AppBarLayout appBarLayout, int verticalOffset) {
   //  Vertical offset == 0 indicates appBar is fully expanded.
   if (Math.abs(verticalOffset) > 200) {
    appBarExpanded = false;
    invalidateOptionsMenu();
   } else {
    appBarExpanded = true;
    invalidateOptionsMenu();
   }
  }
 });

Here are some key takeaway points from the above code snippet.

verticalOffset returns negative values, so we wrap it with Math.abs(verticalOffset)
appBarExpanded is a boolean flag that I’m maintaining to know when AppBarLayout is expanded or collapsed
invalidateOptionsMenu() is called every time our AppBarLayout’s height crosses a threshold (200)

Now I wish there was a simpler way to know the AppBarLayout’s state. But I guess this solution works good enough.

Updating Toolbar Menu

invalidateOptionsMenu() helps update our Toolbar Menu. But we need to tell our Menu when to add and remove our extra Action.

Note that the FAB’s action is an ‘Add’ function.

First, we need a reference for the existing Menu. You can get this from the onCreateOptionsMenu() method.

@Override
 public boolean onCreateOptionsMenu(Menu menu) {
  getMenuInflater().inflate(R.menu.menu_main, menu);
  collapsedMenu = menu;
  return true;
 }

collapsedMenu is a global variable of type Menu. It allows us to keep a copy of the original Menu.

Next, we need to update our Menu. We’re already calling invalidateOptionsMenu() in the scroll listener. This will trigger the onPrepareOptionsMenu() method. Hence, we’ll add our dynamic Menu logic here.

    @Override
    public boolean onPrepareOptionsMenu(Menu menu) {
     if (collapsedMenu != null &&
      (!appBarExpanded || collapsedMenu.size() != 1)) {
      //collapsed
      collapsedMenu.add("Add")
       .setIcon(R.drawable.ic_action_add)
       .setShowAsAction(MenuItem.SHOW_AS_ACTION_IF_ROOM);
     } else {
      //expanded
     }
     return super.onPrepareOptionsMenu(collapsedMenu);
    }

You’ll notice that I haven’t done anything for the expanded state. We don’t need to either. I’ll tell you why.

After onPrepareOptionsMenu(), the onCreateOptionsMenu() is called. What do we need to do in the expanded state? The FAB becomes visible, which means we should hide the ‘Add’ action from Toolbar menu.

Since onCreateOptionsMenu() inflates the original Menu again, we don’t have to worry about manually removing it.

So now, when the FAB hides, its Action will be added to Toolbar Menu. When the AppBarLayout collapses and FAB hides, the ‘Add’ action becomes visible in the Toolbar Menu.

Now all that remains is to do the usual UI initialization in Java. So let's setup our Toolbar and then call in the Palette API.

Dynamic Colors with Palette API

The palette API is a support library that extracts prominent colors from images.

To use the Palette library, we first need to add it to your project. So open up your app/build.gradle and add the following line.

dependencies { … implementation 'androidx.palette:palette:1.0.0' }

Remember that we have to initialize our UI first. So open your Activity.java and type away. Or copy-paste this instead.

toolbar = (Toolbar) findViewById(R.id.anim_toolbar); setSupportActionBar(toolbar);

collapsingToolbar = (CollapsingToolbarLayout) findViewById(R.id.collapsing_toolbar); collapsingToolbar.setTitle("Suleiman Ali Shakir");

ImageView header = (ImageView) findViewById(R.id.header);

Now you might ask me, why I have set a title for CollapsingToolbarLayout, instead of Toolbar? That's a valid question.

Take a look at the Flexible Space with Image scroll animation. Yes, the GIF which I shared at the beginning of this post. Notice there's an expanded title, which on scrolling, collapses into the Toolbar title.

The CollapsingToolbarLayout handles this for us. Hence we set the title for that, instead of a Toolbar.

Additionally, the CollapsingToolbarLayout also handles tinting our Toolbar using the Palette API. I’ll show you how to do this.

Using the Palette API

First, pass the 'header' ImageView’s bitmap to the Palette API. Then the API will generate colors based on the header image, in an AsyncTask.

Once it completes, we can fetch a color we want and set it to CollapsingToolbarLayout. This, in turn, tints our Toolbar to our chosen color, when we scroll.

Let’s look at some code.

Palette.from(bitmap).generate(new Palette.PaletteAsyncListener() {
 @Override
 public void onGenerated(Palette palette) {
  int vibrantColor = palette.getVibrantColor(R.color.primary_500);
  collapsingToolbar.setContentScrimColor(vibrantColor);
  collapsingToolbar.setStatusBarScrimColor(R.color.black_trans80);
 }
});

I am fetching my bitmap from my resources directory. But, in a real-world scenario, you would be downloading the image from an URL. Then saving it as a bitmap and passing that to the Palette API.

The Palette API offers several color options (variations). Here are the basic four:

Light
Dark
Vibrant
Muted

Image credits: developer.android.com

You can also increase the number of colors generated from the image. Or you can even retrieve the entire color swatch! If you’re interested in playing around with the Palette API, I’d suggest you go through Chris Banes’ post.

Complete Activity Code

Here’s the complete Activity for your reference.

public class AnimateToolbar extends AppCompatActivity {

    private CollapsingToolbarLayout collapsingToolbar;
    private AppBarLayout appBarLayout;
    private RecyclerView recyclerView;

    private DessertAdapter dessertAdapter;

    private Menu collapsedMenu;
    private boolean appBarExpanded = true;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_animate_toolbar);

        final Toolbar toolbar = (Toolbar) findViewById(R.id.anim_toolbar);
        setSupportActionBar(toolbar);
        if (getSupportActionBar() != null)
            getSupportActionBar().setDisplayHomeAsUpEnabled(true);

        appBarLayout = (AppBarLayout) findViewById(R.id.appbar);

        collapsingToolbar = (CollapsingToolbarLayout) findViewById(R.id.collapsing_toolbar);
        collapsingToolbar.setTitle(getString(R.string.android_desserts));

        Bitmap bitmap = BitmapFactory.decodeResource(getResources(),
                R.drawable.header);

        Palette.from(bitmap).generate(new Palette.PaletteAsyncListener() {
            @SuppressWarnings("ResourceType")
            @Override
            public void onGenerated(Palette palette) {
                int vibrantColor = palette.getVibrantColor(R.color.primary_500);
                collapsingToolbar.setContentScrimColor(vibrantColor);
                collapsingToolbar.setStatusBarScrimColor(R.color.black_trans80);
            }
        });

        recyclerView = (RecyclerView) findViewById(R.id.scrollableview);
        //  Use when your list size is constant for better performance
        recyclerView.setHasFixedSize(true);

        LinearLayoutManager linearLayoutManager = new LinearLayoutManager(this);
        recyclerView.setLayoutManager(linearLayoutManager);

        dessertAdapter = new DessertAdapter(this);
        recyclerView.setAdapter(dessertAdapter);

        appBarLayout.addOnOffsetChangedListener(new AppBarLayout.OnOffsetChangedListener() {
            @Override
            public void onOffsetChanged(AppBarLayout appBarLayout, int verticalOffset) {
                Log.d(AnimateToolbar.class.getSimpleName(), "onOffsetChanged: verticalOffset: " + verticalOffset);

                //  Vertical offset == 0 indicates appBar is fully expanded.
                if (Math.abs(verticalOffset) > 200) {
                    appBarExpanded = false;
                    invalidateOptionsMenu();
                } else {
                    appBarExpanded = true;
                    invalidateOptionsMenu();
                }
            }
        });

    }

    @Override
    public boolean onPrepareOptionsMenu(Menu menu) {
        if (collapsedMenu != null
                && (!appBarExpanded || collapsedMenu.size() != 1)) {
            //collapsed
            collapsedMenu.add("Add")
                    .setIcon(R.drawable.ic_action_add)
                    .setShowAsAction(MenuItem.SHOW_AS_ACTION_IF_ROOM);
        } else {
            //expanded
        }
        return super.onPrepareOptionsMenu(collapsedMenu);
    }

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        getMenuInflater().inflate(R.menu.menu_main, menu);
        collapsedMenu = menu;
        return true;
    }

    @Override
    public boolean onOptionsItemSelected(MenuItem item) {
        switch (item.getItemId()) {
            case android.R.id.home:
                finish();
                return true;
            case R.id.action_settings:
                return true;
        }
        if (item.getTitle() == "Add") {
            Toast.makeText(this, "clicked add", Toast.LENGTH_SHORT).show();
        }

        return super.onOptionsItemSelected(item);
    }
}

Output - Toolbar Animation Results

Finally, we’ve completed what’s needed for the Toolbar animation. In fact, much more than what’s required! So go ahead, run your app and watch the magic.

Toolbar animation output

To be honest, it was surprising to see such a smooth Toolbar animation. Even the FAB beautifully reacts upon touch with a higher elevation.

**Source Code:
**Available on GitHub

Material Design is a powerful visual language that can help you design a brilliant app. The Design Support Library makes it easy to create powerful animations, like this. It allows us to create rich app experiences our users can enjoy.

How are you using the Design Support Library? Do you have your own take on the 'Flexible Space with Image' animation pattern? Let me know in the comments below.

Also, if you liked reading this, don't forget to share with your friends.

Easy Navigation Drawer with Design Support Library

Sat, 30 May 2015 00:00:00 GMT

In Google I/O 2015, a lot of new stuff was revealed. One particular thing that caught my eye was the release of Android's Design Support Library, which I found out thanks to Chris Banes' tweet. https://twitter.com/chrisbanes/status/603984333309784064 I'll show you how to create a Material Design Navigation Drawer almost effortlessly, how to handle Drawer click events and orientation changes too!

What is the new Design Support Library in Android?

Before we get to that, I feel its best if we get comfortable with what the Design support library actually is.

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- android-developers.blogspot.in

It includes components such as a NavigationView for Drawer, Floating Action Buttons, Snackbar, Tabs and a motion and scroll framework as well.

Navigation Drawer- then and now

Earlier making a Navigation Drawer in Android, took considerable effort and with the arrival of Material Design, including a header view and stuff, things got even harder.

Design Support Library, Our Savior

To make lives easier we needed to rely on external libraries to create a Material Design Navigation Drawer in Android (unless you were brave enough to attempt it yourself). But thanks to Design Support library, this is now very simple to do. Let's get started making an awesome Material Design Navigation Drawer for our Android app.

Using the Design support library

We'll start off by adding its dependency in Gradle. compile 'com.android.support:design:22.2.0' Since the library depends on the AppCompat and support-v4 libraries, we can replace those two dependencies with JUST this.

Navigation Drawer Layout

Go to your activity XML layout and structure your DrawerLayout like this:

With this as the base, let's add in our Toolbar layout with: <include layout="@layout/toolbar" />. Remember we can open the Drawer by tapping the burger icon as well, and for that we need a Toolbar. Note the new NavigationView. This comes from the Design support library. You can define its headerLayout and must assign a menu resource for it. The fitsSystemWindows attribute tells Android to draw this view behind the Status Bar. So when you open the Navigation Drawer, it appears behind a transparent Status Bar.

Drawer Menu

This is like your regular menu resource you use for your Toolbar ActionBar, but with a slight change. All menu items must be in a group. (Unless you want to categorize your menu items in groups). It's checkableBehaviour MUST be single.

Navigation Drawer Divider

If you wish to add a divider between your menu items, then simply add items in another group with a different ID. So all items residing in the second group will be separated from the first by a divider.

Header Layout

For the Drawer's Header layout, we create another XML layout that contains a simple ImageView and TextView.

You could add whatever you need, but I'm going to keep it simple with this.

That is all the XML we'll be seeing for this post. Let's dig into some Java now.

Setting up the Activity

Open up your Activity.java. Here we need to:

Initialize the Toolbar
Handle Drawer click events
Handle orientation changes
Introduce the Drawer to 1st time users (via Preference)

1. Initialize the Toolbar

Frankly, I like to keep my o_nCreate()_ method free of clutter. So we'll create a method for this and call it in.

private void setUpToolbar() {
       mToolbar = (Toolbar) findViewById(R.id.toolbar);
       if (mToolbar != null) {
           setSupportActionBar(mToolbar);
       }
   }

2. Set up Navigation Drawer

private void setUpNavDrawer() {
       if (mToolbar != null) {
           getSupportActionBar().setDisplayHomeAsUpEnabled(true);
           mToolbar.setNavigationIcon(R.drawable.ic_drawer);
           mToolbar.setNavigationOnClickListener(new View.OnClickListener() {
               @Override
               public void onClick(View v) {
                   mDrawerLayout.openDrawer(GravityCompat.START);
               }
           });
       }

   }

Here we're allowing the Toolbar (ActionBar) to display a home as up button, and supplying the icon for it. Then define its click listener where we open the Navigation Drawer upon click. Remember to call this method in o_nCreate()_ as well.

3. Handle Drawer click events

While the Drawer opens/ closes using the DrawerLayout as a reference, the click events for the list items (menu) is handled by the NavigationView via its setNavigationItemSelectedListener**()** method.

mNavigationView.setNavigationItemSelectedListener(new NavigationView.OnNavigationItemSelectedListener() {
           @Override
           public boolean onNavigationItemSelected(MenuItem menuItem) {

               menuItem.setChecked(true);

               switch (menuItem.getItemId()) {
                   case R.id.navigation_item_1:
                       Snackbar.make(mContentFrame, "Item One",                
                           Snackbar.LENGTH_SHORT).show();
                       mCurrentSelectedPosition = 0;
                       return true;
                   case R.id.navigation_item_2:
                       Snackbar.make(mContentFrame, "Item Two", 
                           Snackbar.LENGTH_SHORT).show();
                       mCurrentSelectedPosition = 1;
                       return true;
                   default:
                       return true;
               }
           }
       });

Within the switch case is where we'll actually be handling our Drawer's item clicks. I will explain a bit later on why we need to track mCurrentSelectedPosition. If you wish to handle Fragment transactions with your Navigation Drawer, just remember that it stays the same as before. Just below your Toolbar add a FrameLayout like this:

You can handle the fragment transactions under the switch case. This is all we need to get our Material Style Navigation Drawer with Design support library up and running. But honestly, if you plan on implementing something: Do it good, or don't bother doing it. With that being said, that last 2 parts is handling the drawer upon orientation changes (so your app doesn't crash when you flip the phone) and showing the Drawer for the first time to users (part of the guidelines).

4. Handling Orientation Changes

If the phone orientation changes, the app will redraw or reload the activity to adapt to the new orientation. So when this happens, data existing during the previous load must be held. Loss of this data during the redraw results in a crash. Remember we used mCurrentSelectedPosition a bit earlier when handling our Drawer clicks? Well, we're going to use that now. This is used to track which item on the Drawer was clicked, by storing its position. If you don't follow what I'm saying, with what we've done until now, go ahead and run your app. Tap any item on the Drawer apart from the default and flip your phone in landscape. You'll note that what you selected is reset. We're going to prevent that. To handle the state before and after the orientation change, we need to implement two methods:

public void onSaveInstanceState(Bundle outState) {
        super.onSaveInstanceState(outState);
        outState.putInt(STATE_SELECTED_POSITION, mCurrentSelectedPosition);
}

Note that STATE_SELECTED_POSITION is our key. We'll transfer mCurrentSelectedPosition's value to a Bundle and save it. Upon restoring, we recover that value from the bundle using the key. Before we change the orientation, we want to save the last position we clicked. Once that's done, we need to restore the data on reload.

protected void onRestoreInstanceState(Bundle savedInstanceState) {
        super.onRestoreInstanceState(savedInstanceState);
        mCurrentSelectedPosition = savedInstanceState.getInt(STATE_SELECTED_POSITION, 0);
        Menu menu = mNavigationView.getMenu();
        menu.getItem(mCurrentSelectedPosition).setChecked(true);
    }

We retrieve our stored position data via a Bundle and then make that menu item checked. In your Activity's onCreate() method, immediately after initializing your views and before calling your setup methods, add this.

if (savedInstanceState != null) {
           mCurrentSelectedPosition =  
             savedInstanceState.getInt(STATE_SELECTED_POSITION);
           mFromSavedInstanceState = true;
}

With this our Navigation Drawer will now handle orientation changes properly without crashes. If you have no idea about what these methods mean, then this should give you a better idea.

4. Introduce Drawer First Time

When a user launches an app for the first time, we must open the drawer and show it to them. We'll do this using Preference. First off, add these two methods in your Activity.

public static void saveSharedSetting(Context ctx, String settingName, String settingValue) {
       SharedPreferences sharedPref = ctx.getSharedPreferences(PREFERENCES_FILE, Context.MODE_PRIVATE);
       SharedPreferences.Editor editor = sharedPref.edit();
       editor.putString(settingName, settingValue);
       editor.apply();
   }

   public static String readSharedSetting(Context ctx, String settingName, String defaultValue) {
       SharedPreferences sharedPref = ctx.getSharedPreferences(PREFERENCES_FILE, Context.MODE_PRIVATE);
       return sharedPref.getString(settingName, defaultValue);
   }

Preference file is private static final String PREFERENCES_FILE = "yourappname_settings"; We'll store a simple true/ false value in our Preference settings file and use that to know whether the app is launched for the first time or not. Initially read your preference with this:

mUserLearnedDrawer = Boolean.valueOf(readSharedSetting(this, PREF_USER_LEARNED_DRAWER, "false"));

PREF_USER_LEARNED_DRAWER is my key (String type) which I use to fetch my Preference value. Now, go to where you initialize your DrawerLayout (setUpNavDrawer() method) and add these lines:

if (!mUserLearnedDrawer) {
           mDrawerLayout.openDrawer(GravityCompat.START);
           mUserLearnedDrawer = true;
           saveSharedSetting(this, PREF_USER_LEARNED_DRAWER, "true");
       }

If the user hasn't learned about the Drawer (not seen it yet), then open the Drawer and set the learned preference to true. We now have a complete working Navigation Drawer:

Note the deliberate slow down while closing the Drawer. The Status Bar overlaps the Navigation Drawer. This is quite easy to achieve. You just need to add this to your theme in v-21 styles.xml. <item name="android:windowTranslucentStatus">true</item> Check out the working sample over at my GitHub.

That's it. I know the post was pretty long, but let's just see what we've achieved: We've managed to create a fully working Material Design Navigation Drawer with Design Support library in Android, which handles orientation changes perfectly and also greets users for the first time on app launch! While that was a mouthful, I'm sure you realize that this is actually a walk in the park considering how hard a Material Design Navigation Drawer was to create in the past! :-) Do subscribe (below) or Follow @Suleiman_194 for instant updates as I continue to bring you more awesome content!

Android M

Thu, 28 May 2015 00:00:00 GMT

Android Lollipop came in fast, went out faster! Welcome Android M. The Developer Preview was made available along with its reveal in Google I/O 2015. Along with it came a slew of features, some which were being asked for a while and some, totally new. Here are the top 6 features in Android M.

1. App Permissions

Android M finally simplifies app permissions by a great extent! You don't have to agree to permissions you don't need anymore. Android M allows you to selectively turn off permissions for specific features, restricting apps from using them. You can choose your permissions and see which apps have access to it. This is good news for app developers as well as its faster to get users up and running compared to the previous permission model. Android M allows for a more seamless app install process.

2. Web Experience

Web today is pushing its priority towards mobile as more and more users prefer to browse that way. Android M keeps their experience in mind and provides a better way to improve that very experience.

Custom Chrome Tabs

With this feature, Android M allows you to open links from within your app into a 'Custom Chrome Tab' that overlays your app screen seamlessly with a transition. The Custom Chrome Tab, adapts to match the look and feel of your app so that you can comfortably browse its content.

3. App Links

App linking is now made possible with Android M. Links can now be provided in the app via Intents in the Manifest file. This allows content to be more trusted and verifiable making the user aware of the content before actually tapping on it!

4. Android Pay

Say goodbye to your wallet!

Your phone's going to take care of your payments from now on thanks to Android M! Android Pay was made with three things in mind:

Simplicity
Security
Choice

The payment method is very easy to use and can instantly help you make payments from your phone. This means lesser digging your wallet for those notes, and more of paying quick (like a boss). The payment process itself is entirely secure in Android M. Being an open source platform, security is one of the highest concerns and Google hasn't forgotten this.

Virtual Account Number

A virtual account number is used the entire time to process the payment. This means that your actual card number is not known or used in the transaction itself. Android Pay provides users the flexibility and choice in choosing their payment methods. You can hook up any supportive banking app to Android Pay, existing credit or debit cards as well. They're even working with mobile carries such as Sprint, Verizon and T-Mobile. It works with any devices having NFC support.

5. Fingerprint Support

Honestly, I would've flipped, hadn't Google announced this. We've already seen Apple do this on their iPhones putting it to creative uses and its about time Google did with Android too. Your fingerprint can now be used to process payments, make purchases on the Play Store and even unlock your device! Any developer could use it within their apps to authenticate either a payment or process using the fingerprint APIs.

6. Power & Charging

Smartphones always faced the problem of not holding enough charge, and if you're a mobile data user, you'd probably be tagging along a power brick all the time! With more features being added in, the gravity of power management went higher. Android M kept this in mind and came up with a solution for it.

Say hello to Doze!

Doze is your smart(er) power management solution in Android M. While the device is asleep it manages power smartly, putting the device on a standby mode, while still handling the high priority messages and notifications you receive. During a test, Android M Developer Preview was capable of lasting x2 times longer than the same device running Android Lollipop.

Other Features:

While those were definitely the highlights, Android M Developer Preview still had a few aces up its sleeve for the reveal. Smaller, yet significant.

New USB Type-C Standard

We've seen this in Apple's new MacBook and we've all talked a lot about how not many support it. Google is really pushing this forward with Android M for it to be the new standard. The new USB type allows for much faster charging of devices. Almost 3-5 times faster! You could either charge using the port, or use the phone itself as a charger for other supporting devices. Here comes my favourite feature: The USB pin is finally flippable!

Improved Word Selection

Android M finally understood our need to copy paste certain text by letting us do just that, easier, faster and above all, more intuitively. Copying and selecting parts of texts is no longer frustrating and it also provides a hovering Tooltip letting us to select actions such as copy and paste.

Easier Sharing

While Android did promote sharing of content/ media across apps, it really was downright annoying to do so. For instance, I often share on WhatsApp to my circle of friends. Me having to scroll all the way down to choose WhatsApp, isn't always the easiest thing to do. Android M gives users easier sharing by providing options to share from apps which you use the most and with which you share more. It now shows you app suggestions accordingly. Neat!

Simplified Volume Controls

I don't know what's up with Android Lollipop's volume controls. I mean Material Design was great, I loved it. Was a delight to use, but man those volume controls... Cheers to the fact that Android M got that straight with simplified volume controls that are easier to use and actually make more sense compared to Lollipop!

Release date

Android M Developer Preview available today for Nexus 5, 6, 7, 9 and Player. Final version is due to launch in Q3, 2015.

+1 Button with Google Play Services 7.3.0

Thu, 14 May 2015 00:00:00 GMT

Here we'll look at adding Google's +1 button in your app. Yep, its that tiny little g +1 button that turns red when you click it. You might have noticed it on the Play Store. Using the latest libraries, I'll show you how to include one real quick in your apps. So people can +1 directly from your app!

Why do you need it?

If you're wondering why should you care about it? Here's Mashable's take on it. While it says it affects SEO of websites, the same is true for apps too. The more people +1 it, the more frequently its going to appear on other's Play Store home screens. While the Play Store allows you to +1, its better if people can do that comfortably from within your app!

Pre 7.3.0

The earlier versions needed us to use the PlusClient class from Google Play Services library. Too bad that its now deprecated. In fact, that class isn't even available for use anymore. So how do you go about it then?

The GoogleApiClient

This class was introduced with the Google Play Services 7.3.0 update. After this you have to use this class mandatory. Using the PlusClient will give you an error. The good news is that its relatively simple with the GoogleApiClient class. We'll start off by adding the gradle dependency for it first. Add this to your app's build.gradle file.

dependencies {
    compile 'com.google.android.gms:play-services:7.3.0'
}

The main entry point for Google Play services integration. GoogleApiClient is used with a variety of static methods. Some of these methods require that GoogleApiClient be connected, some will queue up calls before GoogleApiClient is connected; check the specific API documentation to determine whether you need to be connected. - developer.android.com

Create the +1 button

We need to place the button in our layout first, before we do anything else.

Note the plus namespace used. At the minimum, the PlusOneButton widget needs two XML attributes defined. That being its size and the annotation. There are different sizes and annotations that you could use for your button. More on that here.

PlusOneButton mPlusOneButton = (PlusOneButton) findViewById(R.id.plus_one_button);

@Override
protected void onResume() {
    super.onResume();
    mPlusOneButton.initialize("YourAppUrlOnPlayStore", PLUS_ONE_REQUEST_CODE);
}

After hooking up our PlusOneButton to its XML widget, we just need to initialize it. It takes 2 parameters:

The URL you want (usually your app url on the Play Store) Goes like "http://market.android.com/details?id=com.yourpackage.name"
Plus one request code private static final int PLUS_ONE_REQUEST_CODE = 0;

GoogleApiClient Builder

Using the GoogleApiClient.Builder we can quickly initialize whatever is needed for setup. The developer docs say that we need to call the connect() and disconnect() method in our onStart() and onStop() methods of our activities respectively, regardless of the state. Firstly, let's initialize the client.

GoogleApiClient mGoogleApiClient = new GoogleApiClient.Builder(this)
        .addApi(Plus.API)
        .addScope(Plus.SCOPE_PLUS_LOGIN)
        .useDefaultAccount()
        .build()

The GoogleApiClient class allows us to use various Google services APIs. We need that of Google+ so we add its API here .addApi(Plus.API). Suppose you want to use Google Drive, then the parameter would be Drive.API. Next we need to add the scope. This is the OAuth 2.0 scopes for use with Google Play services. It entails what part of the services you require. You can even use multiple APIs with each of their respective scopes together. Thirdly, we need to set the user account. the userDefaultAccount() lets the user pick his Google account (if he has multiple). Otherwise you could explicitly specify it using .setAccountName("accountname@gmail.com"). However this is not recommended.

@Override
protected void onStart() {
    super.onStart();
    mGoogleApiClient.connect();
  }

 @Override
    protected void onStop() {
        super.onStop();
        mGoogleApiClient.disconnect();
    }

Finally to handle the GoogleApiClient connection in the onStart() and onStop() methods respectively. That's it! You can now try hitting the +1 button in your app, and it will turn red! You can take this further with connection callbacks or click listeners informing the users with a Toast like "You +1'd this!". Completely up to you!

DIY Floating Action Button Part 2

Fri, 08 May 2015 00:00:00 GMT

In this post, I'll show you how to make your Floating Action Button behave as it should on Lollipop devices. Elevation and ripple effects is what we'll be achieving. Part 1 of this post already covered how to make a Floating Action Button (FAB) and set it up for pre Lollipop. Check out part 1 first if you haven't already. NOTE: There is now a native widget for a Floating Action Button (FAB). You can learn how to implement it from here. In order to give those special treats for Lollipop devices, what we're going to do is:

Remove the shadow beneath the FAB
Replace the FAB selector with a selector
Add a 'State List Animator' to the FAB (elevates the FAB on touch)

Removing the shadow

By removing what we'll do is, take out the shadow from the layout completely if the phone's running Lollipop. This can be done simply by using a Build check such as: if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {...} Now, if the build version is Lollipop and above, we'll remove the shadow using the setVisibility method for our shadow like this: fabShadow.setVisibility(View.GONE);

setVisibility() method

The method allows you 3 options for its parameter:

View.VISIBLE - this is the default by which the view will be visible. You won't be using it unless you want to bring back an invisible view.
View. INVISIBLE - exact opposite of the previous one (obviously, its in the name). The view remains in the layout, but cannot be seen
View.GONE - this takes the view OUT of the layout. It doesn't exist or reside in the layout.

While both INVISIBLE and GONE don't display the view, INVISIBLE makes the view still exist, while GONE completely takes the view off the layout. We don't need the shadow beneath our FAB at all, which is why we'll use View.GONE

 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
            fabShadow.setVisibility(View.GONE); 
}

State List Animator

This is what will replace our removed shadow. This is nothing but a regular selector, but its items will be an objectAnimator. Using this we will alter the Z translation of our FAB which will elevate higher on click, and come back to its default elevation afterwards. This feature is part of the Lollipop SDK, and for it to be used properly, it must be placed in its proper folder. Create a new folder res/animator. This folder holds the XML animations exclusive to Lollipop. Create fab_elevation_selector.XML under it. Our default Selector framework is this:

For our pressed item, the objectAnimator will change the FAB's translationZ from 8 to 12dp. The default animator do the opposite. Change the translationZ from 12 to 8dp (bring it back to its original state).

I've chosen the default short animation time for the duration. Gives us a smooth enough elevation. Now we've got to tell our FAB to use it. A state list selector is referenced differently than a regular background selector. Unlike its drawable or color which is changed on click, a state list selector changes its property (translationZ) here upon click. Add this line in your FAB's ImageView: android:stateListAnimator="@animator/fab_elevation_selector"

Notice how its referenced as @animator instead of @drawable or @anim. While the property may read as a stateListAnimator, the XML that it references is actually a selector XML.

Ripple Effect

Personally, I love the ripple effect. A new XML tag dedicated solely to this effect has been introduced since the advent of Lollipop <ripple />. It's pretty easy to use, but the only thing to keep in mind is it must reside in the drawable-v21 folder. So lets go about creating it. Create res/drawable-v21/ripple_accent.xml Why name it accent? Because my FAB uses the accent color, and so will its ripple!

Yep, its as simple as that. The color belonging to the ripple tag, is the ripple color itself. The one in the item, bounds the ripple to a shape and gives it a base color. Not including the item would give us a ripple on a transparent FAB! With that done, we just have to change the background selector for our FAB (ImageView). Remember that we've already set a background selector in Part 1. This is the one the FAB will use by default. For Lollipop, we need to tell it to use the ripple selector instead. We can do this simply by adding a line to our already existing Build check:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
            fabShadow.setVisibility(View.GONE);
            fabBtn.setBackground(getDrawable(R.drawable.ripple_accent));
}

Well, maybe the ripple may seem to subtle for you. But if you ask me, its already a bit heavy on the animations and a more prominent ripple would be overkill. Though feel free to alter the ripple if you wish via its XML. :-) You can head over to my GitHub repository to check out the code samples.

That's all there is to it! All we've done is, hide our 'fake' shadow drawable and replaced it with a stateListAnimator that adds a shadow via elevation. Then replace the background selector to a ripple drawable. IMAGE CREDITS (card ripple gif) : android-developers.blogspot.com

Create a Material Color Palette in NO time

Mon, 04 May 2015 00:00:00 GMT

If you're familiar with the new theme setup in Android since AppCompat v21, you'll need to define 3 colors from the start. That being your colorPrimary, colorPrimaryDark and accent. However I'm pretty sure JUST those 3 isn't enough for your robust app and to add to it, deciding on colors and how it would look is no ordinary feat (at least for me). There are a lot of online resources that give us a visual palette to pick from. I'll point you to one that gets the work done in just 2 clicks!

Google's Material Color Palette

Personally, this is where I'd go ALWAYS, to find myself some material colors. They have an exhaustive list of all the Material Design colors, complete with darker tones and accents. Copy pasting the HEX codes into my projects as and when required seemed intuitive at the time. They even let you download the entire color swatches as a zip.

materialpalette.com

If you've never come across this website, then let's just say that, I'd literally force you to use this instead. Why, you ask? Primarily because, in just two clicks, you've got yourself an entire color palette ready for your theme, along with a preview! It's created by the same guy who runs MaterialUp, Matt Aussaguel. You first pick your primary color and then your secondary. That's all you have to do. Sit back and watch the website generate a complete robust palette inclusive of your darker primary tone, text colors and lighter accent tone complete with a neat interactive preview on top. They make it even more convenient by allowing you to download it in different formats like XML, CSS, SASS, LESS, etc. If it's for your app, you can download the XML file and use it in your app. It works right out of the box!

Highlights:

Simplified palette only showing color primaries
Choosing a primary and accent color is the only effort on your part
Generates a complete, robust palette
Live preview of the palette in use
Readily downloadable in various formats
Single click to copy color HEX code

Ever since I've come across this website, it has been my go to place for some Material Design colors. You should give it a shot too!

Know of something better? Drop 'em in the comments below.

DIY Floating Action Button Part 1

Sat, 02 May 2015 00:00:00 GMT

If you've gone through my Implement a Floating Action Button post, it shows you how to setup a neat FAB by using a library with relatively minimal effort. This post is for those who would like to avoid using one (like me) and make your own instead. I'll show you how to make a FAB very easily using XML only. I'll first show you how to imitate one for pre Lollipop, and then how we can tweak that to give an authentic experience on Lollipop devices exclusively in part 2.

Pre Lollipop

Now there are a couple of DIY methods:

Make a custom view component by extending ImageButton class. For example in futuresimple's library, you can see how he's done it.
Simple XML method with a circle drawable to your ImageButton and add a shadow drawable below it.
Create a layer-list

Personally, I prefer the second approach because I like to keep it simple and stick to XML for my UI as much as possible.

The Approach

What we'll be doing is similar to what we've done for our Toolbar. Which is create the layout in a separate XML file then reference it in our mail layout using the <include /> tag. We'll create an ImageButton which serves as the main FAB layout. Add a View below it for its shadow via a drawable. All this will be wrapped within a FrameLayout, finally to be referenced in our main layout.

My Floating Action Button

Create a new layout res/layout/myfab.xml. The root element here is a FrameLayout. The general layout for our FAB is this:

If you're wondering why the shadow view is ABOVE the FAB while it actually must be BELOW, the thing is:

in a FrameLayout, the z-index is defined by the order in which the items are added

So whatever place above, is drawn first. Our shadow will be rendered first, while our FAB will come next, overlapping the shadow.

Positioning the FAB

Unless, you're not familiar with the guidelines for a Floating Action Button, it says:

The floating action button should be placed 16dp minimum from the edge on mobile and 24dp minimum on tablet/desktop.

Since our FrameLayout will be holding the entire FAB layout, we'll start off by positioning it as per the guidelines. Position it at the screen's bottom right via layout_gravity with a 16dp margin.

The frame's width and height will be set to 100dp because we need some spacing around our FAB for the shadows. You can also notice that I've not set the 16dp margins as specified by the guidelines. Why? Some simple math.

Calculation

FAB Size: 56dp FAB Shadow (to be defined): 80dp Frame: 100dp Now, our layouts within the Frame are centered within. So anything within 100dp can be contained within comfortably. 100 (frame) - 16 (margins) = 84dp (remaining) 80dp is taken up by the shadow (FAB included). So that's 4dp extra remaining in our Frame! This will be useful for Lollipop's elevation property, which we will be using to "elevate" the FAB upon click in the next part. We do not want our shadows do be clipped off due to lack of spacing. Now THAT would be ugly! I'm sure we can allow ourselves a few dps of freedom for our FAB to float comfortably. Unless you want to strictly adhere to the guidelines, then simply alter the FrameLayout's dimensions as you see fit.

FAB Layout

We'll leave the View for now, and dive straight into our ImageView which is essentially our FAB.

The dimensions are the recommended size for a regular FAB, centered in our FrameLayout. The src is nothing but your FAB icon, whatever you want to keep. The background attribute is what will define our FAB's shape, color and its click selector as well.

FAB Selector

This is our basic selector. The first two are self-explanatory, that being the pressed and focused states for our FAB respectively. The last item is the default layout our FAB will use when not responding to any touch events.

We essentially need to define a circular shape for our FAB, its color (accent) and its color change (darker tone) upon touch for visual feedback. Within each item tag, we'll start by setting its shape and color.

The color will only be different for the last item which is our default. The first two hold the pressed state for our FAB. Now you needn't worry that we've not set any size for it because this will be defined by the ImageView that references the selector. Finally, your selector should look like this:

FAB Shadow View

I'm using a custom drawable png for my shadow here, so its dimensions should definitely be higher so that it can be visible behind the FAB. Now I've found 80dp to be a good value that works for me. Feel free to adjust as you see fit.

I found a neat shadow drawable being used in a Floating Action Button library by makovkastar. It's what I've used for my FAB and from trial and error I can say for sure that compared to those layer list shadows, this one looks best by far. There are drawable pngs for all densities. Grab the zipped file here.

Putting it together

Until now, what we've done is:

Created a separate XML for our Floating Action Button
Added the ImageView for our FAB.
Referenced a selector for the ImageView that defines shape & color
Added a View above the FAB layout for the shadow
Referenced a shadow drawable png as a background for our View

Finally, we add our fab layout to our main activity layout file, just like we do for a Toolbar. <include layout="@layout/myfab" /> Make sure to add this as the LAST element in your XML as the FAB must be the top most view of your layout.

You can check out my code sample over at GitHub. For the sake of this post's length and simplicity, I'll be continuing the Lollipop part in my next post. To augment your FABs on Lollipop, head over to Part 2 of this post!

AppCompat v22.1 Support Library

Tue, 28 Apr 2015 00:00:00 GMT

A lot of things have changed (for the better) with the support library. In AppCompat v22.1 various updates have been made to a lot of components as well. Let's take a look at what's new.

What's new?

AppCompat

The AppCompat Support Library started with humble, but important beginnings: a single consistent Action Bar for all API 7 and higher devices. In revision 21, it took on new responsibility: bringing material color palette, widget tinting, Toolbar support, and more to all API 7+ devices. With that, the name ActionBarActivity didn’t really cover the full scope of what it really did.

AppCompatActivity

To be used now instead of ActionBarActivity (deprecated).

Previously the only entry point into AppCompat was through the now deprecated ActionBarActivity class. Unfortunately this forced you into using a set Activity hierarchy which made things like using PreferenceActivity impossible. We’ve now extracted all of the internal stuff and exposed it as a single delegate API,AppCompatDelegate. AppCompatDelegate can be created by any Android object which exposes a Window.Callback, such as any Activity or Dialog subclass. You create one via its static create() methods.

AppCompatDialog

Finally Material styled dialogs! You can use this via the AppCompatDialog class. For themes use Theme.AppCompat.Dialog and for imports use android.support.v7.app.AlertDialog. I'm happy they finally included this which took quite a while! Now I can remove those third-party libraries that I use JUST for those dialogs.

Theming

Using AppCompat v21, we used to theme our Toolbars (and other views) using app:theme . In AppCompat v22.1 you can theme using android:theme . So you can now theme your toolbars like this:

If you continue theming with the app prefix, the downside is that theme inheritance will not work for layouts.

Widget Tinting

Tinting widgets are now available (plus a few new ones too!). This fixes the issue where widgets being used were not being tinted.

Support v4

Drawable Tinting

Drawable drawable = ...;

// Wrap the drawable so that future tinting calls work
// on pre-v21 devices. Always use the returned drawable.
drawable = DrawableCompat.wrap(drawable);

// Set a tint
DrawableCompat.setTint(drawable, Color.RED);

Palette

There's a new Palette.Builder class. You can then optionally change the maximum number of colors to generate and set the maximum size of the image to run Palette against before calling generate() or generateAsync() to retrieve the color Swatches. Plus there's a large performance increase since this update.

ColorUtils

ColorUtils has been moved out of Palette and into support-v4 as a public class. There's a lot of things to experiment with this!

For more details on implementation visit Chris Banes blog. Do check the developer's blog for a much more comprehensive take on AppCompat v22.1. Header image source: lifehacker.com There seems to be a lot to look forward to in AppCompat v22.1.1 and get excited about. Are you?

Why ActionBarActivity is deprecated?

Mon, 27 Apr 2015 00:00:00 GMT

The Solution

If you've updated to the new Support Libraries (AppCompat 22.1.1), then you've probably noticed by now that extending ActionBarActivity for your Activity classes is now deprecated. Woot!? Yes, after updating to the new AppCompat, it makes ActionBarActivity deprecated. You must now extend AppCompatActivity instead. No sweat, everything else stays the same.

AppCompat v22.1.1

Apart from this, there are loads of other changes made in AppCompat 22.1.1. Know exactly what's going on over here.

Implement Floating Action Button - Part 2

Sat, 25 Apr 2015 00:00:00 GMT

I'd recommend going through Part 1 of the implementation first. It covers how you can quickly setup a Floating Action Button. Though if you feel you've already got that covered, feel free to proceed. In this part, I'll show you how we can add some neat animations to our Floating Action Button (FAB) such as the initial grow animation, as well as a Quick Return pattern (famously seen on the Google+ app).

Floating Action Button Animations

As per the design guidelines, the FAB must:

hide upon scrolling down and reappear when scrolled up (known as the Quick Return Pattern)
initially greet users with a 'grow' animation upon entering app screen

The quick return pattern can most commonly be found in the current Google+ app. Screen real estate is important especially on smaller devices. Upon scrolling, the toolbar and FAB translate to being hidden. This allows you to view the main scrollable content, distraction-free. When you scroll up, both views translate back up. For a better idea on what it is, watch it in action below: Watch on YouTube

Quick Return

Custom ScrollListener

So first off, let's create the Quick Return pattern. It's better to sort and organize your project from the very beginning, so create a new package utils under your main package com.yourname.app. Now under the utils package, create a new abstract class MyRecyclerScroll. This is going to extend RecyclerView.OnScrollListener. Now its pretty obvious what extends class will do (judging from the name). Yep, you're right, listen to scroll events! Now the OnScrollListener provides us with 2 handy methods that we can use, such as the onScrolled() and the onScrollStateChanged() method. However, the method that we're interested in is the onScrolled(). So go ahead and implement that method.

public abstract class MyRecyclerScroll extends RecyclerView.OnScrollListener {
   
    @Override
    public void onScrolled(RecyclerView recyclerView, int dx, int dy) {
        super.onScrolled(recyclerView, dx, dy);
        ...
    }
}

Now why we made it an abstract class is because, we're going to create a custom scroll listener for our recycler view that detects the direction of scroll. Depending on that, we'll hide or show our FAB. We'll then hook it up to the fab in our MainActivity.java and implement its methods to handle them.

The Approach

So before we dive into the all the messy code, let's analyse how the Quick Return Pattern works.

When the user scrolls down, the FAB animates downward and gets hidden.
The FAB remains hidden while the user scrolls down.
If the FAB is not visible and user scrolls up, the FAB animates up and becomes visible.
FAB continues to remain visible while the user scrolls up.

With that said, in order to achieve this we need to track just two things:

The distance & direction of scroll
Whether the FAB is visible

Let's start off by declaring those 2 variables that we need.

int scrollDist = 0;
boolean isVisible = true;

Initialy scroll distance will obviously be zero, hence its set to that. By default upon entrance the FAB will be visible and so the boolean is set to true.

onScrolled Method

Now in the onScrolled() method, if we take a look at the last 2 parameters: int dx, int dy. These are the horizontal and vertical scrolls respectively. We're only concerned with dy, which gives us a positive value on scrolling down, and negative value scrolling up. We need to record the scroll distance first, then do appropriate checks whether the FAB is visible and accordingly show or hide it. Also, in order to check if the scroll distance will suffice, add a new variable static final float MINIMUM = 25. This is the value against which we'll check our scroll distance. Unless the scroll distance not going to be greater than that, we won't bother to hide or show the FAB. It helps avoid weird stuttering with the FAB, when we scroll slightly in either direction.

@Override
    public void onScrolled(RecyclerView recyclerView, int dx, int dy) {
        super.onScrolled(recyclerView, dx, dy);

        if (isVisible && scrollDist > MINIMUM) {
            hide();
            scrollDist = 0;
            isVisible = false;
        }
        else if (!isVisible && scrollDist < -MINIMUM) {
            show();
            scrollDist = 0;
            isVisible = true;
        }

        if ((isVisible && dy > 0) || (!isVisible && dy < 0)) {
            scrollDist += dy;
        }

    }

Algorithm

Nothing scary up there. We're just handling 2 if conditions; hide FAB if visible when scrolling down, and show FAB if not visible when scrolling up.

We're first checking if FAB is visible and if the scroll(down) is above the minimum.
If that's true then, hide FAB. Since it's not visible anymore, set its boolean and also reset scroll distance.
We only need to record scroll distance upto which the FAB hides/ shows. Need not bother recording the ENTIRE scroll distance.
Similarly, if the FAB is hidden, we'll call the show() method.
We're checking scroll distance against -MINIMUM because remember I said dy gives a negative value on scrolling up. Hence we must compare it against negativ MINIMUM.
Finally, the two OR conditions are whether the user scrolls up or down, we'll just count the scroll distance.

Below this method, add 2 abstract methods.

public abstract void show();
public abstract void hide();

We'll be using these methods in our MainActivity to handle our FAB.

Attaching to the Activity

Our custom ScrollListener is now complete. All we need to do is attach it to our MainActivity and implement its abstract methods show() & hide().

...
recyclerView.setOnScrollListener(new MyRecyclerScroll() {
           @Override
           public void show() {
               fab.animate().translationY(0).setInterpolator(new DecelerateInterpolator(2)).start();
           }

           @Override
           public void hide() {
               fab.animate().translationY(fab.getHeight() + fabMargin).setInterpolator(new AccelerateInterpolator(2)).start();
           }
       });
...

We're simply attaching our custom ScrollListener 'MyRecyclerScroll' as the ScrollListener for our RecyclerView. Upon doing so, we implement the 2 abstract methods. For the show method, we handle the show animation for the FAB. The translationY distance is 0 because we want the FAB to come back to its original position. For hide method, we obviously hide the FAB. It's translation distance will be the FAB height (56dp) + its margin (16dp). This is the distance the FAB is required to move off screen. You could play around with different Interpolators and their timings no issues, but I've found these to work just fine for me. Now go ahead and run your app. You can see our FAB animate quite nicely.

Grow Animation

Next, we'll implement a grow animation for our Floating Action Button.

The floating action button animates onto the screen as an expanding piece of material, by default. The icon within it may be animated. - source

This one's relatively easy to implement. All that we're going to do is create an XML scaling animation that grows our FAB from 0 to its original dimensions. We will then reference that animation in our Activity and attach it to our FAB.

The XML

Start by creating a new folder called anim under your res folder. Create a new XML file for a scale animation and name it simple_grow.xml. So our path should be like res/anim/simple_grow.xml.

The X & Y to and from scale parameters are essential. We tell the animation that we need to start from 0 scale, which is no dimensions ( so you cant see it) and then scale the X & Y to 1.0 (maximum scale) so that we can see the FAB. 700 is a nice duration for the animation (which I've fixed at after a lot of trial). We need to give the animation some time to run and for the user to admire it.The pivot X & Y say that we want to scale it from the center. Without defining these two, the animation will scale from the top left by default. Lastly, we set a Decelerate Interpolator so that it looks nice. It lets the scale ease the animation towards the end.

If you're interested in knowing more about Interpolators, you can give this a read, or watch it live below. Have fun experimenting with different Interpolators to achieve different effects!

Add animation to the FAB

Open the MainActivity.xml and define the animation before we set our content view using Animation animation = AnimationUtils.loadAnimation(this, R.anim.simple_grow); Then after we've referenced our fab from the XML, we simply set the animation to the FAB with fab.startAnimation(animation);

 protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        Animation animation = AnimationUtils.loadAnimation(this, R.anim.simple_grow);
        ...
        fab = (FloatingActionButton) findViewById(R.id.fab);
        fab.startAnimation(animation);
       
}

Whatever you've got running in your onCreate() method, make sure you start the FAB animation at the end. Making it start too early would cause to animation to skip by the time the user gets to see. So make it run towards the end of your onCreate(). Watch the video below to see how it finally looks like. Watch on YouTube With this, we're done. Cheers! We've got a nice little growing animation that greets the user upon entering the app, and then the FAB translates nicely when the user scrolls up and down the list. Download the project or head over to my GitHub repo to check out the animation code sample.

Implement Floating Action Button - Part 1

Mon, 20 Apr 2015 00:00:00 GMT

What is a Floating Action Button?

A new component introduced in Material Design is the Floating Action Button. It is an elevated circular view that floats above the UI in the bottom right. Its usually noted by its distinct visual that emphasizes that screen's most important action.

I'll show you how we can quickly set up one that works on devices preceding Lollipop in this relatively simple tutorial.

Floating action buttons are used for a promoted action. They are distinguished by a circled icon floating above the UI and have motion behaviors that include morphing, launching, and a transferring anchor point. - Material Design source

Set Up

Create new project in Android Studio and set minSdkLevel to 14 (Icecream Sandwich). Why Icecream Sandwich you ask? Well, by using API Level 14 and above you're targeting more than 90% of the Android devices. I'm sure you'd agree with me when I say that its worth the sacrifice. We should be focusing on delivering quality for current users rather than sacrificing for supporting very old devices. The world's moving forward, so should you and your apps.

Quick implementation with library

Let's start off by adding a gradle dependency for a wonderful Floating Action Button library created by futuresimple. We'll be implementing our Floating Action Button with this. Not too fancy, but its just what we need.

dependencies {
    compile 'com.getbase:floatingactionbutton:1.9.0'
}

Why use a library?

Avoid building from the ground up
Can quickly set up what we need with minimal effort
Saves LOADS of time and frustration
Most of all, easy to use!

With this library implementation, we immediately can create a FAB like any other normal UI widget in XML. We can also set its properties easily. With the complex part of the UI code handled by the library, that leaves us to focus on building our actual app faster. As a rule of thumb, if you've found a good library that's not too heavy on file size and suits your purposes well. Then I'd suggest you go for it. Why do you want to build something from scratch, when the exact same thing already exists, available for use? Enough talk, let's get to adding a FAB to our layout.

Adding FAB to the layout

Open up your activity_main.xml under res/layout and add this to it.

I'm wrapping my FAB within a RelativeLayout, hence why you see the alignParent properties used. Suppose you wrap it within a FrameLayout, use android:layout_gravity="bottom|right"instead. The properties with the fab namespace belong to the library. According to Material Design guidelines, the FAB must be:

positioned at the bottom right of screen
elevated higher that other views, such that it appears to be floating above them
maintain a margin of 16dp from the bottom and right edges of the screen
have a size of either 56dp (default) or 40dp (mini)

Don't worry if your Preview doesn't show you much of a

FAB, just compile and run. The emulator should show you what you expect to see. We've now got a nicely positioned FAB at the bottom right. Note that the only thing we've done is add the fab to our layout and we've already got all of its visual aspects set such as the shadow mimicking elevation, thanks to the library. For the sake of this tutorial whose purpose is to show you how a fab works, I will use a simple RecyclerView that holds a list (for scrolling). Now if some of you have issues with your fab not changing color on tap, or not detecting your taps entirely, its mostly a layout ordering issue. Note that within my RelativeLayout, I have a RecyclerView that holds some dummy data for a list. Now the fab layout must be below the RecyclerView for it to work.

Click Listener

Go to your MainActivity.xml and reference the FAB from XML. It is setup like any other normal click listener.

FloatingActionButton fab;

@Override
    protected void onCreate(Bundle savedInstanceState) {
    ...
        fab = (FloatingActionButton) findViewById(R.id.fab);
        fab.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
               // Your FAB click action here...
               Toast.makeText(getBaseContext(), "FAB Clicked", Toast.LENGTH_SHORT).show();
            }
        });
...

}

The final output will be like this. A Floating Action Button positioned correctly, that reacts on click events.

Sum it up

We've seen how to setup a Floating Action Button quickly using a library. We then added it to our layout and defined its custom properties. We've also seen how to handle it's click events with a simple Toast message. Check out part 2 where I'll be showing you how to add some neat animations to our FAB!

Toolbar Height in Landscape mode (FIX)

Sun, 19 Apr 2015 00:00:00 GMT

Toolbar height issue

If you've noticed by now, the Toolbar height by default when compared in normal and landscape mode, is different. There seems to be extra padding at the bottom where the Toolbar title is not vertically centered.

This issue is all the more prominent when you attach a scrollable view. The views scrolls slightly into the toolbar.

The solution

Now, the fix for this is relatively simple. We need to change our toolbar height to what our minimum height is. Open toolbar.xml, remove the minHeight attribute and change the layout_height to ?attr/actionBarSize

So your initial Toolbar layout would be like this:

That would be changed to:

Here is a deliberate side by side comparison for you to see the difference between how the Toolbar height WAS in landscape, and how its supposed to be on the right (after we fixed it).

So my suggestion is to stick to using the android:layout_height attribute for your Toolbar layout height and avoid using app:minHeight especially when dealing with landscape mode and scrollable views.

Why app design is important

Tue, 14 Apr 2015 00:00:00 GMT

As developers, we code our apps stuffing them with every possible feature we thought of it to have. It originated with one great idea, and we thought of numerous ways to better it by adding more 'cool' features to it, overlooking app design. Finally when we've made our apps, maybe put it on the Play Store, showed it off to our friends and others, we may begin to see that not everyone is as pleased to use your app like you do.

Users have options

Today, users are spoilt for choice. The 'great' app idea you thought of is highly likely that it already would be existing, so if you plan on still going ahead with it, unless you have a strong reason as to why your app is better, no one's going to bother.

Remember, the Play Store now has more than 1.4 million apps (source). With a count that huge, and so many options. You need to give them a reason to pick yours over others.

Q & A

Initially at start, we'd ask ourselves, or at least you should have is "Why am I making this app?". It's answer would be something like "Because it has these A B C feature(s) that would help make people's X Y Z work easier".

With a Q&A like the one above, you've pretty much got yourselves an idea for an app that would actually serve some purpose and cater to a niche group of people who would probably use that app.Maybe you've even taken it a step further to scout the Play Store checking if anything similar already exists. If it doesn't, well, good for you! If not, then give users something that makes them want to use yours more than the other.

The users are not you

Gather some people you know, say your friends. Let everyone use the app. Don't tell them anything, do not guide them. Just let them learn the ropes on their own.

While they're at it, observe how they use the app and check their reactions. "What does this do?", "Where do I go from here?", "What's happening now?". These are somethings that they're gonna ask you, and if its a lot of questions then you've got some serious design issues.

"Why don't they get it? It's so obvious and simple." To think those people were stupid and ignoring them would be your stupidity. YOU know because you made it, but not them and its your responsibility (via your app) to educate, inform and guide the users throughout.Its your creation so obviously you're in love with it, and I don't blame you. But why should others feel the same?

Simple yet effective

“I strive for two things in design: simplicity and clarity. Great design is born of those two things.” - Lindon Leader

Stick to clean and distinct visual design. Less is more. This is the current design trend and everyone is pushing towards it. Clean design helps make your actual content stand out and highlights the most important aspects in your app design.

For instance, look closely how Google has slowly improved its Gmail app consistently. Over time, it has become more clean and simpler in design.

"Focus on the user and all else will follow"- Google's Design Philosophy

App design is important

It incorporates not only just the visual elements that occupy the screen, but app design also involves the users' experience while using them. As developers its our responsibility to create those experiences for users that they remember and want to keep coming back to.

Why are the top apps so popular? Take WhatsApp for example. Did you ever feel frustrated using it? Its purpose is instant messaging and it does just that. In fact it does it so well, people rely on it heavily due to its sheer convenience. When the user automatically sees and understands what to do, what does what and how to do it, without anyone telling them, that is good design.

We have so many variations for a single app now, you need to make yours stand out. Go the extra mile for a strong emphasis in design that delights users. That's some great experience right there.

Android Material Design: Getting Started with Lollipop

Sun, 12 Apr 2015 00:00:00 GMT

In this tutorial, I’ll show you how to implement Android Material Design for your apps running on pre Lollipop devices. Material Design is Google’s new design language for Android apps, replacing the previously used Holo theme.

A material metaphor is the unifying theory of a rationalized space and a system of motion. The material is grounded in tactile reality, inspired by the study of paper and ink, yet technologically advanced and open to imagination and magic. Read more about it here.

I will be using Android Studio 1.1 (you should too!). My gradle settings are (by default):

compileSdkVersion 22
buildToolsVersion 22.0.1
minSdkVersion 9
targetSdkVersion 22
appcompat-v7:22.1.1

NOTE: This new version of AppCompat released a lot of changes, so you might want to read further what exactly is changed. If you want to implement Material Design for Tablets, you can get started here.

Setting up the project

Create a new Studio project with the following:

Check Phone and Tablet
Minimum SDK: API 9
Blank Activity template

You may immediately notice a new folder called mipmap, instead of drawable density folders. Just remember that, mipmaps store your launcher icons. You can create the regular drawable folders as before and continue to use them. More on mipmaps here.

Check your build.gradle file for the following dependency

dependencies {
    compile com.android.support:appcompat-v7:22.0.+"
    ...
 }

Set up theme

Brand Colors

The app requires you to define 3 colors for your brand identity:

primary 500– main color of your app. Used in toolbar.
primary 700– a darker tint of the primary color. Used for the status bar.
accent– different color, used in action buttons and components like sliders or switches.

You can refer them from the official material color palette , or define your own.

Go to res/values and create colors.xml. Here are my colors:


#2196F3

#1976D2

#FF5252

Add colors to your theme

Now that we’ve created the colors, we need to tell the theme to use them. Open your styles.xml in res/values and add the colors like this:

@color/colorPrimary
@color/colorPrimaryDark
@color/colorAccent

UPDATE: Since AppCompat v21.1.1, you need to make sure your themes inherit from parent="Theme.AppCompat.Light.NoActionBar". Otherwise you'll get an error similar to the one over here at Stack Overflow.

Theming for Lollipop

By default when creating your project, the parent theme in res/values/styles.xml would be Theme.AppCompat.Light.DarkActionBar. Using AppCompat on Lollipop devices, elevates the theme to the real Material theme. In other words, we will be inheriting the same theme.

Creating a folder res/values-v21 and create styles.xml under it.


      <item name="android:colorPrimary">@color/colorPrimary</item>
      <item name="android:colorPrimaryDark">@color/colorPrimaryDark</item>
      <item name="android:colorAccent">@color/colorAccent</item>

Notice that the only difference between the styles.xml under values and values-v21 is the prefix "android".

Hello Toolbar

Since Lollipop, ActionBar is now deprecated. A new component called Toolbar was introduced instead which is easier to use and more versatile. This can be used as any other normal view in your activity layout.

Create toolbar.xml in your res/layout folder. Apart from the compulsory width and height. You need the theme and minimum height (line 7 & 9) defined at the least.

The toolbar MUST use the primary color as per Material Design guidelines. It can be referenced via ?attr/colorPrimary as well. Default toolbar height is set using ?attr/actionBarSize. I've used a dark Toolbar theme so that my text by default is white against my background. Since a dark theme is set, the popup will be dark as well. To keep overflow menu light, hence I've set a light theme for it.

Now before we use our Toolbar, we need to tell our themes to NOT display a default ActionBar first. Add the following line to styles.xml in both your values and values-v21:

 true
 false

While we’re at it, why not allow Lollipop to make use of its beautiful activity transitions? Add these lines to your styles.xml under values-v21.

true
true
true
@android:transition/move
@android:transition/move

Adding the toolbar

Since toolbar is a view, we need to add it to our activity layout. Open res/layout/activity_main/xml. Firstly, remove the default padding in RelativeLayout, and add this line below:

As per convention, the Toolbar must be defined in a separate XML file (toolbar.xml) and then must be included in our layout by using the tag.

Now, earlier after including the Toolbar, any layout I added below it, would automatically have some padding. That is after setting the Toolbar as an ActionBar, the views below wouldn't overlap the toolbar. Oddly, after the new AppCompat-v22 update, I find the layout overlapping.

Now for those of you who find your layout overlapping the Toolbar, its a relatively simple fix. Just add a android:layout_marginTop="?attr/actionBarSize" to your layout. Like for instance how I've added it to my RelativeLayout below the Toolbar.


    

    

        //Your main layout here

Toolbar as ActionBar

Lastly, we need to tell Android to use our specified toolbar to behave like an ActionBar. Once this step is done, we can interact with it like we used to with the ActionBar. Enough XML for now, let’s dive into Java. Open your java/packagename/MainActivity.java and reference the toolbar.

Create a toolbar variable and initialize like you normally would for any view.

public class MainActivity extends AppCompatActivity{
    Toolbar toolbar;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        toolbar = (Toolbar) findViewById(R.id.toolbar);
        setSupportActionBar(toolbar);
    ...

UPDATE: You must now extend AppCompatActivity as ActionBarActivity is deprecated.

The key is line 10 where it instructs the activity to use our Toolbar as its ActionBar. After this, the Toolbar can be referenced as a regular ActionBar using getSupportActionBar() to perform your actions.

That took longer than expected! Time for some action. Hit Shift+F10 to compile your app and run. Your app should be looking like this.

Now you may notice, why is there no shadow under my toolbar? That because we need to add it. It won't be included by default.

Toolbar Shadow

Now there are two ways of doing this.

Use a 9-patch for the shadow
Create one using XML

Now I'm going to keep this clean and use an XML generated shadow for my Toolbar. After that, we can reference this shadow as a view in our layout.

Create shadow.xml under res/drawable/.

The XML is simply a gradient that goes from from a 64% of black (#000000) to a transparent color (The first 2 values after the # is the hexadecimal value for opacity). The angle specifies the direction of the gradient. We need it vertical, hence 90.

For a more detailed how-to on Toolbar elevation (shadow) , I suggest you read this.

Head back to your activity_main.xml. We now need to include the shadow we just created as a view directly BELOW our toolbar.

Now some of you may ask "Why not use the toolbar elevation property?". That property applies only on Lollipop devices. For pre-Lollipop, we're on our own. Honestly, there's not much of a difference between the two shadows as you can see above, but if you really want to use that elevation instead of the shadow drawable on Lollipop at least, then you could do this:

Check if the Android SDK version is Lollipop

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP)
If it is, then remove the shadow View with view.setVisibility(View.GONE);
Elevate the toolbar using getSupportActionBar().setElevation(4);

IMAGE CREDIT: Google Material Design You can download the sample project here or head over to GitHub.

Suleiman's Blog

How I use AI to partner on design problems

Giving AI the full picture

Automating my process

Connecting to live data

In practice

Handoff

What changed

Where this could go next

Caveats

Closing thoughts

Starter kit

Framer X For Design - 5 Reasons Why I Switched

Design tools of the past

What is Framer X?

Game-Changing Framer X Features

Responsive Design For Real

Frames over layers

Stacks

Prototyping in Framer X

Logic via code

Designing for the future

An Exciting Future Ahead

Build your UX Portfolio from Scratch – Choosing a Web Stack

Overview

Type of Tools Needed for your UX Portfolio

1. Text Editor

2. Front-end Web Framework

3. Build System

Final Tools in your Arsenal

Next Steps

Build your UX Portfolio From Scratch – Design

Design Process

Brainstorm - by finding inspiration

Make note of patterns

Paper Sketching

Wireframing

Medium-Fidelity

Design for High-Fidelity

3 Key things to remember

1. Create a styleguide to build faster

2. Consistency is key

3. Showcase who you are as a designer

Final Designs

Test for Feedback

Get Ready for Development Handoff

Use Zeplin for your Design spec

Recap

Takeaways

Next Steps

Build your UX Portfolio From Scratch – Getting Started

Getting Started

Tools Needed to Build your UX Portfolio

Design

Development

Domain Name, Hosting & Launch

Domain Name

Hosting

Wrap Up

Next Steps

Android Pagination Tutorial – Adding Swipe-to-Refresh

What is Swipe-to-Refresh?

Implementing Swipe-to-Refresh

Add the SwipeRefreshLayout

Add the Refresh Menu Item

Create the Refresh Callback Action

The Problem with this Approach

Use Caching

Modifying Retrofit to Support Caching

1. Declare Cache

2. Define Interceptor to Read Cache

Request from Network or Cache?

Tying it all with Swipe-to-Refresh

Output

Wrapping up

How To Design A Great Mobile App Intro By Learning From The Best

Onboarding VS App Intro

The problem with mobile apps

Really Good Mobile App Intro Designs To Learn From

1. Evernote

Add the `SwipeRefreshLayout`

2. Define `Interceptor` to Read Cache