Scroll listener - about code style guidelines and standards
Code style guidelines are available from a number of places. The 'old faithful' official Java ones have been pulled down, for some reason. Oh, they have been restored and are available in an archive format.... There are two other references that are commonly used for Java code style:


Original Java code style - Archived.
Google's Java code style
Eclipse/IntelliJ/Netbeans default formats (built-in guides).


This StackOverflow question seems particularly relevant: Official Java Code Guidelines/Conventions.

What all of these guides have in common is, and is contrary to your code, is:


don't put each parameter to the method on its own line. The limiting factor is the number of characters, not the number of parameters, on the line. This is true for both when you declare the method, and call the method.
never start a line with a close-parenthesis ). The close-parenthesis goes at the end of the previous line.
conditions in an if-block should be grouped where convenient, and line-breaks, if any, should be at logical breaks in the conditions. On the other hand, you are too generous with line-breaks in your conditions... !( on it's own line is bizarre.
when splitting long lines (string constants, long conditionals), put the 'operator' at the start of the next line, not the end of the previous one. For example, you have:


 mAdapter.isFiltered() &amp;&amp;
 mAdapter.isEmpty()    



and that should be:

  mAdapter.isFiltered()
  &amp;&amp; mAdapter.isEmpty()    



Really, there are only a few areas of real controversy in Java code style guidelines:


indentation using tabs, or spaces: all code-style guidelines I have read for Java indicate that spaces should be used. For example, the Official (old) Java spec: "Four spaces should be used as the unit of indentation", and the Google spec "Each time a new block or block-like construct is opened, the indent increases by two spaces."

For some reason (and I am not sure why), a number of IDE's ship using tabs as the default indentation mechanism (I'm looking at you, Eclipse).

The amount of indentation is often site-specific, whether 2 or 4 spaces. Personally I am happy with either (as long as it is consistent), but I prefer 4.

Tabs vs. Spaces can become a battle of cultures, and it is seldom resolved without someone feeling upset.... but, when working as a team, using a version-control-system, you have to decide on one system, and then you have to be consistent with all developers. Messing with indentation after the fact is a very messy process in a version-control system.
End-of-line open-brace {, or new-line brace: this is one of those style things that is hotly debated, but Java conventions are clear. Brace at the end of the line. The thing is, that many other languages recommend a brace on the next line, especially 'punctuated' C languages like C, C++, C#. Because people often write in multiple languages and they like their habits to be the same in both, they often code Java with a brace on the next line. For Java, this is wrong though, even if it is inconvenient for those folk. Java has lines like:

if (condition) {
    .... do something....
}


the C* languages put the brace on the new line:

if (condition)
{
    .... do something....
}


Let's be clear on this one. A lot of people use newline-brace, but, in Java, that is not right, even if it is somewhat common.

Further, there are arguments for, and against the brace style, but it's a pointless argument. As much as there may be meaningful arguments about one, or the other, the consistency of usage is more important than any one argument. 
indentation of switch-blocks: for some reason, there is a lot of inconsistency in switch-block indentation. I prefer the case/default blocks to be indented 4 from the switch, and the code for the case indented 4 from the case (Google style agrees with this indentation of the case, but uses 2 spaces). For example:

switch (somefowl) {
    case DUCK:
        System.out.println("Duck!");
        break;
    case GOOSE:
        System.out.println("Goose!");
        break;
    default:
        System.out.println("What?");
}


Many people, and some IDE defaults, do not indent the case/default (and the original Java guidelines use this style), and the code looks like:

switch (somefowl) {
case DUCK:
    System.out.println("Duck!");
    break;
case GOOSE:
    System.out.println("Goose!");
    break;
default:
    System.out.println("What?");
}


It's not a big deal. But, again, be consistent.
Braced 1-liners: One additional controversy is braces around 1-liners. You often see code like:


if (badDog)
    return "Sit! Stay!";



all code style guidelines recommend using braces even on 1-liners, and the code should look like:

if (badDog) {
      return "Sit! Stay!";
}


Google has this to say:


  Braces are used with if, else, for, do and while statements, even when the body is empty or contains only a single statement


The Java style guide says this:


  Note: if statements always use braces {}. Avoid the following error-prone form:

if (condition) //AVOID! THIS OMITS THE BRACES {}!
    statement;




In general I use Eclipse. The best thing for consistency in a team is for the whole team to use the same IDE for their code, and to install the same code-style 'rules'. Then, it becomes 'easy', you just type (in eclipse): Ctrl-A and Ctrl-Shift-F. Doing that, with your code, in my Eclipse, produces:

@Override
public void onScroll(AbsListView view, int firstVisibleItem,
        int visibleItemCount, int totalItemCount) {
    super.onScroll(view, firstVisibleItem, visibleItemCount, totalItemCount);
    if (mUpdateFixedHeader
            &amp;&amp; !(mAdapter.isFiltered() &amp;&amp; mAdapter.isEmpty())
            &amp;&amp; mDateHeader != null) {
        mDateHeaderTextView.setText(mDateHeaderLabel
                .concat(((MeetsListAdapter) mAdapter)
                        .getSectionForPosition(firstVisibleItem)));
    }
}


That looks about right, to me. No change needed.

When I auto-format your class, I get:

public abstract class AbstractListFragment&lt;T&gt; extends AbstractFragment
        implements OnItemClickListener, OnScrollListener, SearchListener {
    ...
}


Which also looks right to me.

Finally, for the above code formatting, I 'turned off' the Eclipse option to 'don't join lines'. Eclipse will 'collapse' lines when auto formatting. I often add additional empty lines in my code to make the code look like paragraphs. I want the auto-formatter to keep these empty lines, so I tell it not to format them out.

If I were to write this code, I would add some 'paragraphs' in to the code manually, and it would look like:

@Override
public void onScroll(AbsListView view, int firstVisibleItem,
        int visibleItemCount, int totalItemCount) {

    super.onScroll(view, firstVisibleItem, visibleItemCount, totalItemCount);

    if (mUpdateFixedHeader
            &amp;&amp; !(mAdapter.isFiltered() &amp;&amp; mAdapter.isEmpty())
            &amp;&amp; mDateHeader != null) {

        mDateHeaderTextView.setText(mDateHeaderLabel
                .concat(((MeetsListAdapter) mAdapter)
                        .getSectionForPosition(firstVisibleItem)));

    }
}