Question: I followed [this tutorial](http://www.joellipman.com/articles/google/android/application-development/android-os-add-googlemap-as-fragment.html) to add a map to one of my tabs. It works, but when I open the map tab I cannot swipe up/down, zoom in/out (except when I double click). Swiping left/right works, but the map moves very little. I made a customViewPager, and it disables swiping the tabs, but does nothing for he map.

At first I used tabActivity and my map fragment worked as it should, and looked like this:

```
   mapActivity extends FragmentActivity...

```

Since tabActivity is deprecated I added sliding tabs, following the tutorial above. Map could not be added with FragmentActivity, only with Fragment so I changed map fragment to: 

```
   mapActivity extends Fragment...

```

Now I have the following problem - I cannot navigate the map. Swipe and touch inputs are not detected. I cannot move up or down, zoom in or out, and the only thing I can do is move from left to right, but it is very slow.

Answer: 
One solution to this problem was introduced in Java 8 in the form of default methods in interfaces. It allowed to add new methods to existing Java SE interfaces without breaking existing code, since it supplied default implementation to all the new methods.

For example, the `Iterable` interface, which is widely used (it's a super interface of the `Collection` interface) was added two new default methods - `default void forEach(Consumer<? super T> action)` and `default Spliterator<T> spliterator()`.
Java 8 has introduced default implementation for methods. These implementations reside in the interface. If a new method with a default implementation is created in an interface that is already implemented by many classes, there is no need to modify all the classes, but only the ones that we want to have a different implementation for the newly defined method than the default one.

Now, what about older Java versions? Here we can have another interface that extends the first one. After that, classes that we want to implement the newly-declared method will be changed to implement the new interface. As shown below.

```
public interface IFirst {
    void method1();
}

public class ClassOne implements IFirst() {
    public void method1();
}

public class ClassTwo implements IFirst() {
    public void method1();
}

```

Now, we want `method2()` declared, but it should only be implemented by `ClassOne`.

```
public interface ISecond extends iFirst {
    void method2();
}

public class ClassOne implements ISecond() {
    public void method1();
    public void method2();
}

public class ClassTwo implements IFirst() {
    public void method1();
}

```

This approach will be ok in most cases, but it does have downsides as well. For example, we want `method3()` (and only that one) for ClassTwo. We will need a new interface `IThird`. If later we will want to add `method4()` that should be implemented by both ClassOne and ClassTwo, we will need to modify (but not `ClassThree` that also `implemented IFirst`) we will need to change both `ISecond` and `IThird`.

There rarely is a "magic bullet" when it comes to programming. In the case of interfaces, it is best if they don't change. This isn't always the case in real-life situations. That is why it is advised that interfaces offer just "the contract" (must-have functionality) and when possible use abstract classes.