Android general index bar implementation code

Occasionally, when I see the code written before, I feel that a lot of things are used in almost many projects. Although the requirements and design of each project are different, the implementation effect is the same. It may only be a slight gap in data format and some colors. Sometimes, because of a small change, I have to modify the code repeatedly. If I don't bother, it is easy to lead to new problems and bugs

Take the index column suddenly thought of. It is used in almost all written projects, such as city selection, contacts, etc. the index column is needed in all these places, but the usage is the same. After looking at several codes written before, I found that every time the index column is used, I have to rewrite the method to process the data or extract the index of the data, So, try to refactor this part for later use

Let's take a look at the renderings first:

realization

There are many examples of the implementation of the index bar on the Internet, which are relatively simple and will not be explained too much. Because different projects may involve problems such as different font colors and sizes of the index bar, modify the previously used code and extract some custom attributes to facilitate modification. You don't have to modify it in the code every time and avoid affecting the use of others. Take a look at the code directly, Define some custom attributes in attr as follows:

attr:

Extract the color, text size and other attributes for easy modification. Then take a look at sidebar

SideBar:

It's very simple. It just extracts some custom attributes. There's nothing to say. Next, analyze how to make the index column universal. First, think about the general writing method of the index column. First, get a data source, then process the data source, and extract the first letter from the data source as the index (of course, the data source may already contain fields such as the first letter or index), After having an index, make a judgment in the adapter to control whether to display the index title (my practice is to judge whether the data source location of the current index is the same as the current location for the first time, and if it is the same, display the index title). After processing the display and hiding of the index title, finally bind it to the index bar (implement the callback method of the index bar and do relevant processing) The general steps are like this. Next, we look for different processing places and compare them. It is found that the problems basically occur in different data formats. Some data index fields may be called letter and some may be called lettername, which leads to rewriting or modifying methods every time these data are processed, So that these methods are not shared. How to solve this problem? The first thought is to write an abstract class, and then use an abstract method getlettername() to constrain the index. Each bean that needs to use the index column inherits the abstract class and rewrites the abstract method, so as to achieve the effect of uniformly constraining the index value, which solves the problem of different index value fields, In this way, we can use a common method to deal with different data sources. Later, we considered that the interface in this place will be more suitable, the interface flexibility is greater, and it is also an embodiment of interface oriented programming. After analyzing so many, we can implement the specific code and propose an interface, After that, all data beans that need to use the index can implement the getlettername () method in this interface and rewrite this method to return the index value

Interface sidebase:

Then the data bean implements this interface, such as the common citybean:

Return the index value in the getlettername () method

Next, you can write some public processing methods. For example

Because of the interface used, wildcards can be used here? Only care about and process the getlettername() method. You can also do other processing:

After analysis and refactoring, these methods that cannot be shared before will become common and convenient, and will be particularly simple and comfortable to use later

Complete code

Public processing class

CommUtil:

Adapter cityadapter:

MainActivity:

Layout file activity_ main:

Adapter layout item_ city:

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.