Articles - Page 3 of 3

Loose Coupling & Interfaces

What is loose coupling and why is it important? Let’s first discuss this concept in an abstract sense.Imagine a glove – it is “loosely coupled” to your body. Any kind of glove can be fitted on to any kind of body. The glove does not have any knowledge of a person’s body, nor does it care. It is not really connected to the person in question. Now let’s say you wanted to change your skin colour. I’m sure you could imagine the painful and difficult process of removing your skin and attaching another. If you wanted a body with a different skin colour, you would have to make another one. This is the difference between tight and loose coupling in a nutshell. Loose coupling: If you want to change the glove you’re wearing, you are not forced to change your body. Tight coupling: If you want to change your skin, you would have to change your body. Tight Coupling in Code Let’s start off with an example of tight coupling in code. Take a look at the example below.

public class SmallEngine {
    
    public void start(){
        System.out.println("The engine is now on. It makes a quiet noise");
    }

    public void accelerate(){
        System.out.println("The engine is slowly gaining speed");
    }
}

public class SmallEngine {

public void start(){

System.out.println("The engine is now on. It makes a quiet noise");

}

public void accelerate(){

System.out.println("The engine is slowly gaining speed");

}

public class RocketEngine {

    public void start(){
        System.out.println("The engine is now on. It makes a really loud noise");
    }

    public void accelerate(){
        System.out.println("The engine is gaining speed very quickly");
    }
}

public class RocketEngine {

public void start(){

System.out.println("The engine is now on. It makes a really loud noise");

}

public void accelerate(){

System.out.println("The engine is gaining speed very quickly");

}

public class Car {

    private SmallEngine engine;

    public Car(SmallEngine engine) {
        this.engine = engine;
    }

    public void drive(){
        engine.start();
        engine.accelerate();
    }
}

public class Car {

private SmallEngine engine;

public Car(SmallEngine engine) {

this.engine = engine;

}

public void drive(){

engine.start();

engine.accelerate();

}

public class Main {

    public static void main(String[] args) {
        SmallEngine engine = new SmallEngine();
        Car car = new Car(engine);
        car.drive();
    }
}

public class Main {

public static void main(String[] args) {

SmallEngine engine = new SmallEngine();

Car car = new Car(engine);

car.drive();

}

Do you notice anything about the code that stands out? If you take a look at the Car class you can see it takes a SmallEngine object in its constructor. What if we wanted to make the Car class use RocketEngine ? We would need to go back and edit the class. This is not only bad architecture, but an example of tight coupling. Car is dependant strictly on SmallEngine , yet RocketEngine provides the same behavior (via its methods). How do we change this? Loose Coupling in Code

public interface Engine {

    void start();

    void accelerate();
}

public interface Engine {

void start();

void accelerate();

}

public class RocketEngine implements Engine{

    public void start(){
        System.out.println("The engine is now on. It makes a really loud noise");
    }

    public void accelerate(){
        System.out.println("The engine is gaining speed very quickly");
    }
}

public class RocketEngine implements Engine{

public void start(){

System.out.println("The engine is now on. It makes a really loud noise");

}

public void accelerate(){

System.out.println("The engine is gaining speed very quickly");

}

public class SmallEngine implements Engine{

    public void start(){
        System.out.println("The engine is now on. It makes a quiet noise");
    }

    public void accelerate(){
        System.out.println("The engine is slowly gaining speed");
    }
}

public class SmallEngine implements Engine{

public void start(){

System.out.println("The engine is now on. It makes a quiet noise");

}

public void accelerate(){

System.out.println("The engine is slowly gaining speed");

}

public class Car {

    private Engine engine;

    public Car(Engine engine) {
        this.engine = engine;
    }

    public void drive(){
        engine.start();
        engine.accelerate();
    }
}

public class Car {

private Engine engine;

public Car(Engine engine) {

this.engine = engine;

}

public void drive(){

engine.start();

engine.accelerate();

}

public class Main {

    public static void main(String[] args) {
        Engine engine = new RocketEngine();
        Car car = new Car(engine);
        car.drive();
    }
}

public class Main {

public static void main(String[] args) {

Engine engine = new RocketEngine();

Car car = new Car(engine);

car.drive();

}

We can define the actions of both RocketEngine and SmallEngine through an interface. Think of an interface as a behaviour and the methods you define as …

Improve Your App’s UI With Styles & Themes

Knowing how to take advantage of both Styles and Themes in Android can save you a lot of time. Not only do they lead to better looking user interfaces, but they primarily save you the work of writing lots of duplicate XML. There is a big difference between a Style and a Theme, but it’s easy to grasp. A Style will only affect the View or Widget it is applied to but a Theme will affect all Views and Widgets across your app. Themes are also only declared once – in your app’s (or build’s) manifest. Below we will dive in to the differences in depth. We’ll also discuss how to create Styles or Themes of your own. Styles A style is a set of XML attributes that can be applied to a View. In an Android project, styles are located in res > values > styles.xml. You can also create an API qualified styles.xml file in case some attributes would require a higher minimum API level. To create a new style, open the styles.xml file and give your new style whatever name you want. Within that style, you include the attributes you want it to provide within an item element. For example, if you want a style which will make a widget’s text red, it would look like this.

<style name="RedText">
    <item name="android:textColor">#ff0000</item>
</style>

</style>

This is quite a basic style as it contains only one attribute. Though, a very powerful feature styles allow us to take advantage of is – inheritance. This concept works similarly to how it does in Object Oriented Programming (OOP) . Like an Object in Java, we can create styles which inherit or override their parent’s attributes. Style Inheritance

<style name="RedText.Title">
    <item name="android:textSize">48sp</item>
    <item name="android:fontFamily">cursive</item>
</style>

<style name="RedText.Title.Bold">
    <item name="android:textStyle">bold</item>
</style>

<item name="android:fontFamily">cursive</item>

</style>

</style>

This is an example of styles inheriting from each other. RedText.Title has values for textSize and fontFamily . This means …

Implementing Swipe Tabs

Ever wondered how to implement swipe tabs in your android app? This article will explain everything. Having swipe tabs is a great way to provide an intuitive user experience. We can let our user simply swipe the screen to show a different UI or list item, without forcing them to navigate a menu. Android provides a very easy way to achieve this. We will need to make use of four different components: a ViewPager , a PagerAdapter , a TabLayout and at least two different fragments. Before getting in to any code, lets break down what a ViewPager and PagerAdapter are. ViewPager & PagerAdapter A ViewPager is essentially a layout manager that gives the user the ability to swipe right and left through “pages” of data. Fragments are the most common form of these pages. ViewPager needs an implementation of PagerAdapter in order to actually show our Fragments. Good thing for us, Android provides two such adapters built with Fragments in mind – FragmentPagerAdapter and FragmentStatePagerAdapter. FragmentPagerAdapter or FragmentStatePagerAdapter? The difference between each adapter comes down to what kind of app we’re building. FragmentPagerAdapter keeps a number of Fragments in memory. This is particularly useful if we have an app comprised of a small amount of screens, or “tabs”. Having just three different fragments does not take up a lot of memory. However, if we were making a book reader app, we would not want to keep every page in memory. In this case, we would use the FragmentStatePagerAdapter. This adapter will only save the fragment’s state, but will completely destroy it when moved off screen. Here’s a good rule of thumb for when to use each adapter: Navigating through a small number of screens? FragmentPagerAdapter Working with a large or unknown list of screens? FragmentStatePagerAdapter Preparing our Activity Let’s begin by …

All about Fragments in Android

Fragments are great for providing your app with UI flexibility. Suppose we have a simple app which shows a list of items. When clicking on an item in the list, we would like to present the user with more details about said item. This diagram shows how we would like our app to behave: As a beginner, you may assume that the best way to go about doing this would be to use two activities. One for showing the list and another for showing details when the user clicks on an item. While this solution works, it is not flexible in any sense of the word. What happens when we decide to display this information on a larger device? If we were to restrict ourselves to only using activities, each Activity UI would take up the entire screen. This is not a good use of our available screen space. Doing this would make our app would feel barebones and empty. Luckily for us, there is a way to show multiple (or single) UIs in our Activity. This is where Fragments come in to play. A Fragment in Android is essentially an individual part, or portion, of a UI. Building and combining multiple fragments allows us to compose them in an Activity to create multi-pane user interfaces. Fragments are essential when it comes to following the master/detail design concept, as shown in the diagram above. Like Activities, Fragments have their own layouts and life cycle methods. However, unlike Activities, the Android OS does not have any knowledge of an Activity’s Fragment . Its life cycle methods are called and managed by the Activity which hosts the Fragment (s). Creating our Fragment class First, let’s take a look as to how we actually make a Fragment class. For starters, we have to manually inflate the …

The Activity Lifecycle

The Activity lifecycle is one of the fundamental concepts of Android development you must familiarize yourself with as a beginner in Android development. You’re probably asking yourself, what is this lifecycle and why is it important? Well, once you understand how state is managed in Activities, you will (hopefully!) never come face to face with the commonly dreaded screen “rotation problem” that exists in Android. There exists four different states an Activity can be in: resumed, paused, stopped or non-existent (not in memory). With these states, there are different lifecycle methods which notify the Activity of a change in state. Activity Life Cycle Methods onCreate() is called when an Activity is being created. Most of the time, this is where an Activity’s UI is prepared. Activity exists in memory, but is not visible in any way. onStart() is called after onCreate() . This is where the Activity is about to become visible, but not in focus. Activity exists in memory, is in background. onResume() is called when the Activity comes in to the foreground and has focus. Activity exists in memory, is in the foreground (visible). onPause() is called when the Activity is in the background and is still visible to the user, but no longer has focus. Activity exists in memory, is in background (visible). onStop() is called when the Activity is no longer visible to the user, but is still in memory. Activity exists in memory, but is no longer visible. onDestroy() is called when the Activity is about to be removed from memory. Activity is no longer visible and will be removed from memory. Handling Rotation Changes An Activity in Android goes through many different Activity lifecycle methods. However, once you rotate the device, or if you prefer the more technical term, make the Activity go through …

Page 3 of 3
←
1
2
3