Articles - Page 3 of 4

Lambdas in Java

Lambdas in Java can be a little complex to understand at first, but I promise you, they aren’t! In fact, lambdas allow us to write our programs faster, with fewer bugs along with ending up with cleaner code. They also allow for functional programming, however this article will not be diving in to the ins and outs of functional programming in Java – only a basic overview of what lambdas are and how we write them. Before Lambdas… Before we even start talking about what lambdas are, let’s take a step back and look at the basic structure of a method.

public class SomeClass{

    public void someMethod(){
        System.out.println("Hello");
    }
}

public class SomeClass{

public void someMethod(){

System.out.println("Hello");

}

This is pretty basic right? Well, try to think of what a method really is in Java. A block of code – steps that are executed sequentially. On top of this, we write this method in a class. The methods we write in that class are actions which that class can perform. The methods are a part of the class. However, what if we wanted to pass this behavior around? Before Java 8, we would do something like the following:

public class SomeClass{

    public void printSomething(PrintText printText){
        printText.printToConsole();
    }

    public static void main(String[] args){
        SomeClass someClass = new SomeClass();
        Printer printer = new Printer();
        someClass.printSomething(printer);
    }

}

public class SomeClass{

public void printSomething(PrintText printText){

printText.printToConsole();

}

public static void main(String[] args){

SomeClass someClass = new SomeClass();

Printer printer = new Printer();

someClass.printSomething(printer);

}

public class Printer implements PrintText{

    @Override
    public void printToConsole(){
        System.out.println("Hello")
    }

}

public class Printer implements PrintText{

@Override

public void printToConsole(){

System.out.println("Hello")

}

interface PrintText{
    void printToConsole();
}

interface PrintText{

void printToConsole();

}

This is basic OOP in a nutshell. If we wanted to create a new behavior (implementation), all we would need to do is create a new class which implements the PrintText interface, create a new instance of it and pass it to our printSomething() method. Still, what we’re passing in to printSomething() is an object which implements our behavior. Now, what if wanted this behavior in isolation? Without having to create a new class implementing our interface? What if we were able to assign this code to a variable, in the same way we define other objects or primitives? Introducing Lambdas What we want to achieve with lambdas is something like the following: Note: the syntax for this section is for example purposes …

Understanding the Activity Back Stack

Knowing how the Activity back stack works will help you to better understand how your activities are managed in the background. As the name implies, the Activity back stack organizes your Activities in a linear stack structure, based on the order in which each is started. Imagine we have an app used for scrolling through and viewing text messages. Each time you tap on a message in the list, a new Activity for reading the full contents of the text is instantiated. Doing this puts our new “message viewing” Activity on top of the stack. Pressing the back button will remove (pop) the Activity from the stack, destroying it in the process, and present the user with the previous list Activity. Activities in the stack are only ever pushed and popped, never rearranged. This is the basic gist of the Activity back stack. When the user starts a new Activity, it is pushed on to the top of the stack and resumed (onResume). The previous Activity is stopped (onStop). Once the back button is pressed, it is popped off, returning the user to the previous Activity. A basic diagram showing how the stack looks before and after can be seen below What about tasks? There is also the concept of a task, which is basically a collection of activities committed to one app (or job). These activities are then organized in the back stack. The encapsulation can be seen as follows : Task –> Back stack –> Activities (a task contains Activities which are stored in the back stack) Launch Modes & Intent Flags Not all Activities behave the same way when they are launched. By default, a newly started Activity is always put on top of the stack while the previous is pushed down. This even holds true for …

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 …

Page 3 of 4
←
1
...
2
3
4
→