Material Design Backward Compatibility Archives - Truiton

Android Chips Example: Material Design

Mohit Gupt — Sun, 21 Oct 2018 06:27:20 +0000

Google’s material design has been evolving year by year. At first when Material Design was introduced a lot of new components were listed in its documentation. But their implementation or official widgets were not released at that time. But with every support library release, few new significant components are released. With this year’s Google I/O, Androidx was released as a new implementation for Android’s support library framework, along with this a new material design component library was also released. As I mentioned above a few new components were released this year too, one of them is Android Chip. This new Android chips widget is now a part of design support library v28 and has also been introduced in this new material design component library 1.0.0. This library has many components but in this article we will be discussing on Android chips only and how to make an Android chips example, via the new Material Component library.

Android Pill button or chips have always been a part of our apps. One way or the other building a button like a pill has never been a difficult task for us. But now that Google has officially released a widget by the name of Chips, it will definitely make our lives easier to some level. In this Android chips example we would learn how to make an android chip button which looks like a pill shaped interact-able element. Please note: To make use of this example, you might have to switch over to AndroidX and com.google.android.material packages by refactoring from the Refactor menu of the Android Studio, as the new material library does not work with old support packages. If you wish to use old support libraries for the time being, please use the v28 of it. It has the Chip widget.

Exploring Material Design : Android Chips Example

Generally Android chips are used to capture user input, filter content, trigger actions and simply to make a selection from a choice of options. It should not be used in a situation where a single call to action has to be performed. One of the most obvious example of Android Chips, that you must have seen, should be the Gmail app. In Gmail app when an email address is entered, it is shown in an Android Chip like view. If you wish to make a UI element which looks like the gmail email address pill button type view, you should use the Android Chip widget. To start with the implementation part, first you would have to include the following dependency in your gradle file:

dependencies { 
implementation 'com.google.android.material:material:1.0.0' 
}

Using Android Chips with Styles

In simple terms Android Chip is just a combined object of text, icon and optional close icon. With this, the new material design component also gives us a few new attributes to change its appearance and behavior. It allows us to make it represent an attribute, text, entity, or perform an action. This eventually allows the user to trigger an action, filter content, select a choice, or enter information. Also if you have to represent a contact with image, this Android chip can be of good use. To have a more detailed look at the chips, lets have a look at its styles.

Action Chip (Default)

The most basic chip of all the available ones is the Action chip. Its a single actionable chip, in short its an alternative to the button widget. If you have to perform an action, based on users tap, this is the chip that you should use. Generally this type of chip is placed after the content of the page and is used as a clickable, just like a button. Have a look at the images below to understand its usage.

To make a working example of Android action chip, you can either define it in the XML or you can insert it dynamically by Java/Kotlin code. In this Android chips example, we will do so by XML and will use its properties in Java code. Please have a look below:

In the above code, please see that we have defined a style tag style="@style/Widget.MaterialComponents.Chip.Action". This is used to define the style for action chip, but in case if this is missing, it would still render an Android chip with ‘Action’ style. As this is also the default style. Moving ahead, to capture this Android chip’s click event, we use this piece of code:

        Chip actionChip = findViewById(R.id.action_chip);
        actionChip.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Log.i(TAG, "Clicked action chip");
            }
        });

Entry Chip (Input Chip)

Another type of chip is the input one, this chip used display captured user input in a non editable format. Its a very nice way to showcase the user input. One of the most obvious usages of Android Entry chip is shown in the gmail app. Particularly the email input experience- when an email is entered by the user, it is showcased as an entry chip, sort of a pill shaped layout. Now according to the material design this element should be an Android Chip with style as ‘Entry’. This chip can also have a close icon along with a chip icon. Generally this type of chip is contained in a ChipGroup. ChipGoup class is similar to RadioGroup class, as it is used to hold multiple chips. It has the properties to display all the chips in a single line. Have a look at the images below to have a better understanding on how the entry chips would look:

In case of Android entry chips, in the XML we will create an empty ChipGroup and add chips programmatically. Lets have a look at the layout.xml of the activity:

Now since we will be adding chips dynamically through code, a big challenge would be to maintain style along the chips. As per my understanding to maintain consistent styles there are two ways, either by code we style it and use in a loop. Or we create a standard chip style in XML and use it across. Interestingly Android Chips widget also supports a ChipDrawable class through which we can create a chip dynamically, and this ChipDrawable object can be created by using an XML resource. Therefore as per the principle I like this way better, have a look at my chip style which I used to inject a chip in ChipGroup :

Next to create an Input Chip dynamically we need to define a method :

    private Chip getChip(final ChipGroup entryChipGroup, String text) {
        final Chip chip = new Chip(this);
        chip.setChipDrawable(ChipDrawable.createFromResource(this, R.xml.my_chip));
        int paddingDp = (int) TypedValue.applyDimension(
                TypedValue.COMPLEX_UNIT_DIP, 10,
                getResources().getDisplayMetrics()
        );
        chip.setPadding(paddingDp, paddingDp, paddingDp, paddingDp);
        chip.setText(text);
        chip.setOnCloseIconClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                entryChipGroup.removeView(chip);
            }
        });
        return chip;
    }

And this is how an Android Entry Chip is inserted in the chip group:

final ChipGroup entryChipGroup = findViewById(R.id.entry_chip_group);
final Chip entryChip = getChip(entryChipGroup, "Hello World");
final Chip entryChip2 = getChip(entryChipGroup, "Test");
entryChipGroup.addView(entryChip);
entryChipGroup.addView(entryChip2);

Filter Chip

These type of chips should be used in situations exactly as its name suggests, i.e. for creating filters. Android filter chips are similar to check boxes, in a way they should be used to filter the content. For example if you have to show a UI where there’s a list and user has to filter a specific type of content from it, in this situation a filter chip would be an apt solution. Generally filter chips do not have a icon attached to them, as a check icon is displayed once a chip is selected. Please have a look at the images below:

Further lets define the XML for Android Filter Chips, they have style="@style/Widget.MaterialComponents.Chip.Filter" :

Now that we have filter chips in place, we need to detect clicks on the filter chips. We can do so simply by attaching a OnCheckedChangeListener to it:

        ChipGroup filterChipGroup = findViewById(R.id.filter_chip_group);
        Chip filterChip = findViewById(R.id.filter_chip);
        Chip filterChip2 = findViewById(R.id.filter_chip2);
        CompoundButton.OnCheckedChangeListener filterChipListener = new CompoundButton.OnCheckedChangeListener() {
            @Override
            public void onCheckedChanged(CompoundButton buttonView, boolean isChecked) {
                Log.i(TAG, buttonView.getId() + "");
            }
        };
        filterChip.setOnCheckedChangeListener(filterChipListener);
        filterChip2.setOnCheckedChangeListener(filterChipListener);

Filter Chip – Single Selection Mode

In this Android Chips Example, I will also show a filter chip with single selection mode. In this mode, filter chips would start acting as a radio button. This means in a way only one selection can be made at a time. This functionality is achieved by adding all the filter chips in a ChipGroup and setting the property : app:singleSelection="true" of Chip Group. To have a better understanding, lets have a look at the layout XML file:

Next to capture the selected chip out of all chips, we need to attach a ChipGroup.OnCheckedChangeListener() on the ChipGroup.

        ChipGroup filterChipGroupSingleSelection = findViewById(R.id.filter_chip_SS_group);
        filterChipGroupSingleSelection.setOnCheckedChangeListener(new ChipGroup.OnCheckedChangeListener() {
            @Override
            public void onCheckedChanged(ChipGroup group, @IdRes int checkedId) {
                // Handle the checked chip change.
                Log.i(TAG, "ID: " + group.getCheckedChipId());
            }
        });

Please Note: This ChipGroup.OnCheckedChangeListener() would return callbacks only when single selection mode is set to true.

Choice Chip

A perfect example of choice chip is similar to the filter chip one. Choice chip allows the user to select only one of the available options just like the filter chips. But with one difference, it does not have a check icon on it. Instead according to material design guidelines, it displays the selection with a change of color, when it is selected. If you wish you can use a chipIcon with this chip. But ideally they should be used wherever you feel the need to show RadioButton. Lets have a look at the UI for Android Choice Chip:

To use the choice chip, we use style="@style/Widget.MaterialComponents.Chip.Choice" parameter in the XML. Lets have a look at the XML:

As shown in this Android Chips Example earlier, ChipGroup can return the selected chip only when single selection mode is set to true. Even here we will utilize the same property and capture the selection:

        ChipGroup choiceChipGroup = findViewById(R.id.choice_chip_group);
        choiceChipGroup.setOnCheckedChangeListener(new ChipGroup.OnCheckedChangeListener() {
            @Override
            public void onCheckedChanged(ChipGroup chipGroup, @IdRes int i) {
                Log.i(TAG, i + "");
            }
        });

If you wish to have a look at all the working sample of the Android Chip types mentioned above, please have a look at the full source code here:

Full Source Code

In this Android Chips Example, as you can see we built a working sample of all the chip styles, by using the latest Google’s material library. Here in this tutorial we also showcased, that a chip has the properties of a radio button as well as a check box. In a way its a better representation of both. You can use it either in a single selection or in multiple selection mode. Both ways it would give a great experience. As the Android Chips are compact, relevant and focused. Hope this example made you understand things better, for latest news on Android connect with us on Twitter, Facebook and Google+. Also subscribe to our newsletter, for news right in your inbox.

Mohit Gupt

Born in New Delhi, India. A software engineer by profession, an android enthusiast and mobile development evangelist. My motive here is to create a group of skilled engineers, who can build better software. Reason being programming is my passion, and also it feels good to make a device do something you want. Professionally I have worked with many software engineering and product development firms. As of now too, I am employed as a senior engineer in a leading tech company. In total I may have worked on more than 20 projects professionally, but whenever I get spare time I share my thoughts here at Truiton.

www.truiton.com

The post Android Chips Example: Material Design appeared first on Truiton.

Android Bottom Sheet Example

Mohit Gupt — Sun, 17 Jul 2016 17:22:29 +0000

When in 2014, Google introduced Material Design, they introduced many new design components, like Floating Action button, Tabs, Cards, and Bottom Sheets for Android. Although most of the new components were not available for Android at that moment. But over time they released a support library by the name of Design Support Library. Which thankfully helped the developers to utilize the power of material design on Android. Recently a new design component was introduced in this support library called the Bottom Sheet. Here in this Android Bottom Sheet example, we would make a short example using the new component to understand its working. But first lets understand what is an Android Bottom Sheet.

According to material design, Bottom Sheets can be of two types: Persistent and Modal. Here in this example we would make samples for both types of Android Bottom sheets. As per documentation persistent bottom sheets are supposed to be in-app content. Hence they are included right inside the main layout. In a way they are supposed to be integrated with the app or screen. On the other hand Modal Bottom sheets are a little different; they are supposed to be used as the layer on top of your app. Mostly they are inferred as an external entity, like a menu. Also since they are like menus, therefore if they are visible to the user, they do not allow the user to interact with main screen in background. First they need to dismiss the Android Bottom Sheet, only then the user would be allowed to interact with main activity. Lets learn more about them in the next sections, also full source code is available for this example at the bottom of this write-up. But first, lets please include these dependencies in our build.gradle file:

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    testCompile 'junit:junit:4.12'
    compile 'com.android.support:appcompat-v7:24.0.0'
    compile 'com.android.support:design:24.0.0'
}

Android Bottom Sheet : Persistent

To make some content beautifully slide in and out of a screen, we can use the persistent Bottom Sheets on Android. To make a view as persistent Bottom Sheet in your screen all you need to do is have CoordinatorLayout at the top level of your layout. Next a behavior should be specified in the layout you need to make a Bottom Sheet. To understand better lets define the layout:

This would result in a screen with Android Bottom sheet like this:

One of the great parts about persistent Bottom Sheets is that, they can be dragged to go full screen, even if they don’t have the content for a full page. On the other hand Modal Bottom Sheets does not allow this.

Also if you closely observe the Android bottom sheet shown above, you may see that it stays below the Action bar. If you wish to make it go over the action bar. Please change the activity theme to Theme.AppCompat.Light.NoActionBar and add the elevation of 4dp in Bottom Sheet. It would start sliding right over the Toolbar (if added). Next lets have a look at the java file for this screen.

package com.truiton.bottomsheet_persistent;

import android.os.Bundle;
import android.support.annotation.NonNull;
import android.support.design.widget.BottomSheetBehavior;
import android.support.v7.app.AppCompatActivity;
import android.util.Log;
import android.view.View;
import android.widget.Button;

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        View bottomSheet = findViewById(R.id.design_bottom_sheet);
        final BottomSheetBehavior behavior = BottomSheetBehavior.from(bottomSheet);
        behavior.setBottomSheetCallback(new BottomSheetBehavior.BottomSheetCallback() {
            @Override
            public void onStateChanged(@NonNull View bottomSheet, int newState) {
                switch (newState) {
                    case BottomSheetBehavior.STATE_DRAGGING:
                        Log.i("BottomSheetCallback", "BottomSheetBehavior.STATE_DRAGGING");
                        break;
                    case BottomSheetBehavior.STATE_SETTLING:
                        Log.i("BottomSheetCallback", "BottomSheetBehavior.STATE_SETTLING");
                        break;
                    case BottomSheetBehavior.STATE_EXPANDED:
                        Log.i("BottomSheetCallback", "BottomSheetBehavior.STATE_EXPANDED");
                        break;
                    case BottomSheetBehavior.STATE_COLLAPSED:
                        Log.i("BottomSheetCallback", "BottomSheetBehavior.STATE_COLLAPSED");
                        break;
                    case BottomSheetBehavior.STATE_HIDDEN:
                        Log.i("BottomSheetCallback", "BottomSheetBehavior.STATE_HIDDEN");
                        break;
                }
            }

            @Override
            public void onSlide(@NonNull View bottomSheet, float slideOffset) {
                Log.i("BottomSheetCallback", "slideOffset: " + slideOffset);
            }
        });

        Button button = (Button) findViewById(R.id.button);
        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                if (behavior.getState() == BottomSheetBehavior.STATE_COLLAPSED) {
                    behavior.setState(BottomSheetBehavior.STATE_EXPANDED);
                } else {
                    behavior.setState(BottomSheetBehavior.STATE_COLLAPSED);
                }
            }
        });
    }
}

In the above piece of code, you may see that I have added a BottomSheetBehavior callback interface, to listen to the changes in Bottom Sheet states. Although in the above code its not serving any purpose, but its added for reference. Full source code is available here:

Source Code

Android Bottom Sheet : Modal

Second type of Bottom Sheet is the modal sheet. According to the documentation this component should act as a menu or a sheet which does not allow the users to interact with main screen until it is dismissed. Surprisingly when speaking of Android, this design pattern is similar to a dialog box. Hence a new class BottomSheetDialogFragment was introduced; extending the AppCompatDialogFragment. Which resulted in a perfect modal type Android Bottom Sheet.

Now technically speaking; when we talk of modal type Android bottom sheets, we have to create an XML outside of the activity separately to inflate in the BottomSheetDialogFragment. To start off lets have a look at the XMLs first:

Also have a look at the XML for MainActivity:

Now that we have XMLs in place. Lets have a look at some code for the MainActivity:

package com.truiton.bottomsheet_modal;

import android.os.Bundle;
import android.support.design.widget.BottomSheetDialogFragment;
import android.support.v7.app.AppCompatActivity;
import android.view.View;
import android.widget.Button;

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        final BottomSheetDialogFragment myBottomSheet = MyBottomSheetDialogFragment.newInstance("Modal Bottom Sheet");

        Button button = (Button) findViewById(R.id.button);
        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                myBottomSheet.show(getSupportFragmentManager(), myBottomSheet.getTag());
            }
        });
    }
}

Over here you may see that, to actually show a Bottom Sheet we are using an instance of the BottomSheetDialogFragment. Therefore lets have a look at the class for bottom sheet.

package com.truiton.bottomsheet_modal;

import android.os.Bundle;
import android.support.annotation.Nullable;
import android.support.design.widget.BottomSheetDialogFragment;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.TextView;

/**
 * Created by MG on 17-07-2016.
 */
public class MyBottomSheetDialogFragment extends BottomSheetDialogFragment {

    String mString;

    static MyBottomSheetDialogFragment newInstance(String string) {
        MyBottomSheetDialogFragment f = new MyBottomSheetDialogFragment();
        Bundle args = new Bundle();
        args.putString("string", string);
        f.setArguments(args);
        return f;
    }

    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mString = getArguments().getString("string");
    }

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
                             Bundle savedInstanceState) {
        View v = inflater.inflate(R.layout.bottom_sheet_modal, container, false);
        TextView tv = (TextView) v.findViewById(R.id.text);
        return v;
    }
}

As you can see, the working of above class is just like any DialogFragment in Android. Hence we inflated the layout in onCreateView() method, which made the Bottom Sheet to look like:

Another interesting thing about the modal type android bottom sheets is that, they render themselves on top of the view hierarchy making the background a little dull. Also this type of Bottom sheet automatically covers the action bar or toolbar, as its on top of the view hierarchy. Another thing that distinguishes between the modal and persistent Bottom sheets is that; modal sheets expand until the content is visible, once whole content is visible they don’t expand any further. Unlike the persistent type Android bottom sheet which cover the screen regardless of content. To view the full source code, please refer to the link below:

Source Code

Many apps are starting to use this component; as it has the inbuilt sliding feature, which adds on to a good user experience. In a way the new bottom sheet design component could turn out to be very useful in an Android app. As it gives a new hidden space within the screen, which the user can relate to and slide out at any time. Also since now it has been fully integrated in to the Android platform, I recommend all of the apps should use this component to make apps more interactive and more connected to the user. Hope this helps, connect with us on Twitter, Facebook and Google+ for more updates.

Mohit Gupt

www.truiton.com

The post Android Bottom Sheet Example appeared first on Truiton.

Android Material Design Buttons – Best Approach

Mohit Gupt — Thu, 09 Apr 2015 12:38:54 +0000

One of the most basic design component in any Android app is a button. Google released a new design pattern lately by the name of Material Design. With material design, Google released new standards for buttons. These buttons have a unique feature that they show a ripple when touched. When speaking of Android material design buttons, they are broadly categorized into four types:

Raised Button – A normal button
Flat Button – A button for cards, toolbars and dialogs
Floating Button – A hovering button for most important or promoted action
Other Buttons – Icons, drop downs etc.

Here we will discuss how to make raised and flat buttons according to the material design specifications for Android, with full backward support. Google has very clearly defined, how a material design button should look and feel when touched. But one of the most basic problem still prevails. How should a button look in the earlier versions of Android?

As of now, if you create a normal button with Button xml tag, it would look like a material design button in Android 5.0 and above. But before that it would look, as it should on the respective version. Another point that I would like to make is here is that, with android support v7 AppCompat library, you can support material theme to an extent. But sadly even with support library, as of now you may not be able to show Android material design buttons on all versions of android.

Android Material Design Raised Button

1) Standard Button

Use the code below to make a raised button:

First button in the screenshot below shows this button.

2) Material design raised button with CardView

If you want to make a button, which looks like the material design button, with backward support. Try using the CardView library for it. Have a look at the code below:

The above piece of code would make a raised button according to the Android material design guideline, with support from API 11 and above. If you closely notice I have used the "?android:attr/selectableItemBackground" property to show ripples on this view. This property can make any view to show ripples, if they detect touch events. Also please don’t forget to make CardView clickable by adding android:clickable="true" property as shown above. This button would look exactly the same across all supported devices. Learn more about CardView here. Have a look in the screen shot below, its the third button:

You can attach an OnClickListener to this button and make it work just like a normal button:

        CardView cv = (CardView)findViewById(R.id.card_view);
        cv.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Log.i("Activity", "Clicked");
            }
        });

Although the ripple effect would show only in 5.0 and above devices as even CardView or any other view does not support it on earlier versions. On earlier versions of Android, this is how the selection would appear:

But the button would still appear like a card, as expected. Therefore the above piece of code would make an Android material design button with backward support but with some limitations. Unfortunately there is no support from Google on it right now. Also in some of their posts they have mentioned, that ripple effect is not added in support library as it degrades performance. Just a personal thought: maybe in future, they might start supporting ripples too.

Android Material Design Flat Button

Another type of button is flat button. These type of buttons are used to avoid gratuitous layering. For example it is suggested to use this type of button on a CardView, instead of normal raised button. The main purpose of this button is to minimize the user distraction from content. To make a button flat button just add style="?android:attr/borderlessButtonStyle" in your button layout. Just like the code below:

This button is shown at number 2 in the screen shot above.

Conclusion

Although android material design buttons are not fully supported by all the versions till now. Still I would say that they add, great value to the style quotient of your app. They give a neat and clean look to your app. Hence I would suggest to use them with all the backward support available. Also I have not mentioned here, a lot of open-source libraries are also available which, endorse material design buttons. Hope this helped, please connect with us on Facebook, Google+ and Twitter for more updates.

Mohit Gupt

www.truiton.com

The post Android Material Design Buttons – Best Approach appeared first on Truiton.

Floating Action Buttons In Android

Mohit Gupt — Tue, 07 Apr 2015 17:34:02 +0000

Even though I am an Android developer, sometimes I feel, a lot of new concepts in Android are released in a jiffy. Take for an example, Android material design. It greatly emphasizes on the usage of Floating Action Buttons. But as a matter of fact, when material design was released; no supporting views were released with it, to display a floating action button in android. Although they did provide a sample here, but it had a limitation that it can be used on API 21 and above only. In a way it is correct, that it should not be used on earlier versions of Android. Since material design guidelines came with API 21. But on the other hand the AppCompat support library v7 makes makes most of the material design compatible with earlier versions of Android. Therefore, when we use the Android floating action button, we are bound to display it on all versions of android which are supported by our app.

This brings up a fresh debate on how to display a floating action button in an android app, with backward support. Thanks to recent developments a new addition in the support repository has been made which enables us to show FAB in Android. It is called Android Design Support Library. But since this addition came in almost a year late, many third party libraries are also available, through which a FAB can be implemented. In this tutorial, we will talk about some of the leading Android FAB libraries:

Android Floating Action Buttons Tutorial

I will use a RecyclerView, on top of which I will be displaying an Android FAB button. Further in this tutorial I will use that FAB button to add an item in my RecyclerView. To ease the development I will refer to my RecyclerView tutorial, which already has a defined method for adding an item in the RecyclerView.

1) FloatingActionButton by Official Android Design Support Library

As I mentioned recently in the start of June 15, a new library was added in the Android support repository, called the Design Support library. This library has many new UI widgets, but one of the most important addition is the FloatingActionButton. Now android supports the Floating action button from API 7 and above through the official support library. To start please include the new Android design support library in your project’s build.gradle file:

compile 'com.android.support:design:22.2.0'

Next to display the Android Floating Action Button, please use the android.support.design.widget.FloatingActionButton xml tag to include it in your layout:

You may observe that I am also using a CoordinatorLayout with this floating action button. Coordinator Layout helps us in building interactions between child views. Although in this example there is no use for a coordinator layout, but it can help if a snackbar is used. To read more about it please refer to this Android Snackbar Tutorial.

To detect clicks from an Android Floating Action Button please use this piece of code:

FloatingActionButton fab = (FloatingActionButton) findViewById(R.id.fab);
fab.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        //Write here anything that you wish to do on click of FAB
        // Code to Add an item with default animation
        int index = mAdapter.getItemCount();
        DataObject obj = new DataObject("Some Primary Text " + index,
                "Secondary " + index);
        ((MyRecyclerViewAdapter) mAdapter).addItem(obj, index);
        //Ends Here
    }
});

2) FloatingActionButton by makovkastar

This library is one of the most popular floating action button libraries available. Most of the apps are using this library. Its quite simple to use as well. It offers a great feature of showing and hiding the FAB with animation, which can give a wow factor to your app. It works for Android API 7 and above, and has an Apache 2.0 license. To start off, please include it in the dependencies section of your gradle file:

compile 'com.melnykov:floatingactionbutton:1.3.0'

Further, please add com.melnykov.fab.FloatingActionButton view to your layout for displaying an Android FAB with RecyclerView:

In the above layout I used a mipmap(drawable) image to display the plus sign:

Next please add the following lines to detect the click events of Android floating action button:

FloatingActionButton fab = (FloatingActionButton) findViewById(R.id.fab);
fab.attachToRecyclerView(mRecyclerView);

fab.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        //Write here anything that you wish to do on click of FAB
                
        // Code to Add an item with default animation
        int index = mAdapter.getItemCount();
        DataObject obj = new DataObject("Some Primary Text " + index,
                "Secondary " + index);
        ((MyRecyclerViewAdapter) mAdapter).addItem(obj, index);
        //Ends Here
    }
});

This would result in a floating action button like this:

3) android-floating-action-button by futuresimple

This library is a fork of FloatingActionButton by makovkastar. This library offers a FloatingActionsMenu, its a unique menu of floating action buttons which pop up when the main floating button is clicked. This menu of floating action buttons also offer labels, just like normal menu items. This library is also very popular among android apps. It works for Android API 14 and above, has Apache 2.0 license.

4) FloatingActionButton by FaizMalkani

This library offers a clean and simple to use implementation of floating action buttons in Android. This library can be used to speed up the development pace as it does not offer any useless features. A simple floating button nothing else. It works for Android API 7 and above, has MIT license.

5) fab by shell-software

This library is highly customizable and offers a lot of features. By using this library you can add different types of animations to the floating action button. Fab can also be used to define the shadow offset, stroke color, and stroke width of the button. Its a great library under Apache 2.0 license with support from Android API 9 and above.

6) FloatingActionButton by Clans

This library is also highly customizable offers a great range of features like shadow colors and offsets. A great feature about this library is that it offers support for custom animations. Also this library can be used to display menu items with labels. This library requires min Android API 15 to run, and has an Apache 2.0 license.

7) android-floating-action-menu by sephiroth74

Another floating action library which is inspired from Google+ floating menu. This library offers a builder pattern to build a menu of floating action buttons of same size. This is something new because with this library you can create an animation like the one in camera app of android. This library can run on Android API 9 and above, has an Apache 2.0 license.

8) CircularFloatingActionMenu by oguzbilgener

If you wish to go for something new, you can try this library. This library offers a new feature of circular floating action buttons. Although this sort of guideline is not described in material design, but I believe its something new and innovative. This library is under MIT license and requires Android API 15 and above.

Conclusion

Although I have tried to list down all the libraries for Android floating action buttons, in case I have missed out any one, please notify me. Hope this article helped you to find the best floating action button library for your project. Connect with us on Facebook, Google+, and Twitter for more updates.

Mohit Gupt

www.truiton.com

The post Floating Action Buttons In Android appeared first on Truiton.

Android RecyclerView vs ListView | Comparison

Mohit Gupt — Sun, 01 Mar 2015 18:33:46 +0000

Android is an evolving platform. Recently 5.0 (Lollipop) version of Android was released, along with the official RecyclerView support v7 library. As per the official documentation RecyclerView is a major enhancement over ListView. It contains many new features like ViewHolder, ItemDecorator, LayoutManager, and SmoothScroller. But one thing that certainly gives it an edge over the ListView is; the ability to have animations while adding or removing an item. Here in Android RecyclerView vs ListView sum up I would compare the various features of RecyclerView and ListView and form an opinion why it should be used in new implementations.

In this article I will not discuss on how to implement a RecyclerView. Although If you wish to know about the implementation of it, please refer to Android RecyclerView Example.

Differences Between RecyclerView and ListView

1. View Holders

In ListView, defining view holders was a suggested approach for keeping references for views. But it was not a compulsion. Although by not doing so, ListView used show stale data. Another major drawback of not using view holders could lead to a heavy operation of finding views by ids every time. Which resulted in laggy ListViews.

This problem is solved in RecylerView by the use of RecyclerView.ViewHolder class. This is one of the major differences in RecyclerView and ListView. When implementing a RecyclerView this class is used to define a ViewHolder object which is used by the adapter to bind ViewHolder with a position. Another point to be noted here, is that while implementing the adapter for RecyclerView, providing a ViewHolder is compulsory. This makes the implementation a little complex, but solves the issues faced in ListView.

2. Layout Manager

When speaking of ListViews, only one type of ListView is available i.e. the vertical ListView. You cannot implement a ListView with horizontal scroll. I know there are ways to implement a horizontal scroll, but believe me it was not designed to work that way.

But now when we look at Android RecyclerView vs ListView, we have support for horizontal collections as well. In-fact it supports multiple types of lists. To support multiple types of lists it uses RecyclerView.LayoutManager class. This is something new that ListView does not have. RecyclerView supports three types of predefined Layout Managers:

LinearLayoutManager – This is the most commonly used layout manager in case of RecyclerView. Through this, we can create both horizontal and vertical scroll lists.
StaggeredGridLayoutManager – Through this layout manager, we can create staggered lists. Just like the Pinterest screen.
GridLayoutManager– This layout manager can be used to display grids, like any picture gallery.

3. Item Animator

Animations in a list is a whole new dimension, which has endless possibilities. In a ListView, as such there are no special provisions through which one can animate, addition or deletion of items. Instead later on as android evolved ViewPropertyAnimator was suggested by Google’s Chet Haase in this video tutorial for animations in ListView.

On the other hand comparing Android RecyclerView vs ListView, it has RecyclerView.ItemAnimator class for handling animations. Through this class custom animations can be defined for item addition, deletion and move events. Also it provides a DefaultItemAnimator, in case you don’t need any customizations.

4. Adapter

ListView adapters were simple to implement. They had a main method getView where all the magic used to happen. Where the views were bound to a position. Also they used to have an interesting method registerDataSetObserver where one can set an observer right in the adapter. This feature is also present in RecyclerView, but RecyclerView.AdapterDataObserver class is used for it. But the point in favor of ListView is that it supports three default implementations of adapters:

Whereas RecyclerView adapter, has all the functionality that ListView adapters had except the built in support for DB cursors and ArrayLists. In RecyclerView.Adapter as of now we have to make a custom implementation to supply data to the adapter. Just like a BaseAdapter does for ListViews. Although if you wish to know more about RecyclerView adapter implementation, please refer to Android RecyclerView Example.

5. Notifying Change in Data

When working with a ListView, if the data set is changed you have to call the notifyDataSetChanged method of the underlying adapter to refresh data. Or set the setNotifyOnChange method to true incase you wish to call the notifyDataSetChanged method automatically. But in both cases the out come is very heavy on the list. Basically it refreshes the views of list.

But on the contrary in a RecyclerView adapter, if a single item or a range of items have changed, there are methods to notify the change accordingly. Those are notifyItemChanged and notifyItemRangeChanged respectively and many more like:

And of course it has the original method to refresh the whole list i.e. notifyDataSetChanged which notifies the adapted the whole data set has changed.

6. Item Decoration

To display custom dividers in a ListView, one could have easily added these parameters in the ListView XML:

android:divider="@android:color/transparent"
android:dividerHeight="5dp"

The interesting part about Android RecyclerView is that, as of now it does not show a divider between items by default. Although the guys at Google must have left this out for customization, intentionally. But this greatly increases the effort for a developer. If you wish to add a divider between items, you may need to do a custom implementation by using RecyclerView.ItemDecoration class.

Or you can apply a hack by using this file from official samples: DividerItemDecoration.java

7. OnItemTouchListener

Listviews used to have a simple implementation for detection of clicks, i.e. by the use of AdapterView.OnItemClickListener interface.

But on the other hand RecyclerView.OnItemTouchListener interface is used to detect touch events in Android RecyclerView. It complicates the implementation a little, but it gives a greater control to the developer for intercepting touch events. The official documentation states, it can be useful for gestural manipulations as it intercepts a touch event before it is delivered to RecyclerView.

Conclusion

I would like to conclude this Android RecyclerView vs ListView comparison by saying RecyclerView is filled with a lot customisable functionality. It can be very useful for implementing complex lists or grids. But also its a little difficult to implement as compared to ListView as it contains multiple classes where implementation is required. Hope this helped you decide. Please connect with us through Facebook, Google+ or Twitter for more updates.

Mohit Gupt

www.truiton.com

The post Android RecyclerView vs ListView | Comparison appeared first on Truiton.

Android Material Design With Backward Compatibility

Mohit Gupt — Sat, 21 Feb 2015 10:37:19 +0000

Earlier mid last year Google released a unified design guideline for web, smartphones, tablets and wearable devices, called Material Design. As per Google’s official design spec, material design is inspired from the concept of paper and ink. Keeping design simple and soothing, material design guidelines suggest to maintain continuity across screens. Being an Android developer, my perception was converting an existing app to material design could lead to huge code rework. But thankfully AppCompat v7 r21 was released recently, supporting Android Material Design Backward Compatibility.

The question is

If we design an Android app with material design will it be backward compatible?

The answer is yes. A single app can be designed maintaining Android material design backward compatibility. This can be done in three ways. But first lets discuss what happens if you start using it directly. Just like Android Holo theme, material design theme is also available in three variants:

@android:style/Theme.Material
@android:style/Theme.Material.Light
@android:style/Theme.Material.Light.DarkActionBar

But if you directly include any of these themes in styles.xml of your project it will give you this error:

java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity

As you may have extended ActionBarActivity in your activity class. This class is a support class and requires an AppCompat theme. Hence we need to include material design in a backward compatible way. As I mentioned above there are three ways we can do this. First lets discuss the most important one, where support library AppCompat v7 r21 is used.

1. Support Library

Whenever a new project is created in Android Studio, by default it comes with an attached AppCompat v7 library. Make sure that this support library is r21. As this new release supports backward compatibility with material design. To include it in you project add the line below in your :app build.gradle file:

compile 'com.android.support:appcompat-v7:21.0.3'

Using the AppCompat v7 r21 supports the maximum compatibility out of the three approaches. You can utilize the AppCompat library for displaying material theme by including code below in your regular styles.xml:

I have defined only three items of the material theme, but for complete Android material design backward compatibility, you can define all of them here. As of now AppCompat v7 r21 does not support all the widgets for backward compatibility, but it can support some of the major widgets:

I tried to customize them by applying a theme, have a look at the screen shot.

2. Provide v21 layouts

If you are planning to display material design only on new devices then you can take this approach as well. Its fairly simple. Just define the new layouts for v21(Android Lollipop), in res/layout-v21 folder of your project. Your app will show these layout only when an Android 5.0 device is in use.

3. Provide v21 styles

Another way of supporting Android material design backward compatibility is by using material theme styles only for v21(Android Lollipop). This can be done by defining a new style.xml file in res/values-v21/ folder of your project. These styles would also be displayed only in Android 5.0 devices.

With this I would like to conclude by saying, the new material design theme released by Google, can be included in existing projects, in three possible ways. Although each way has its own pros and cons but personally I would go with the first approach. It may be most difficult one to implement, but it supports maximum backward compatibility. Hope this helped you in making an informed decision. Please connect with us through Facebook, Google+ and Twitter for more updates.

Mohit Gupt

www.truiton.com

The post Android Material Design With Backward Compatibility appeared first on Truiton.