12 Helpful Tools for Every Step of Building a Mobile Application

12 Helpful Tools for Every Step of Building a Mobile Application

You cannot build a mobile app in isolation using just the native developer kit. Building an app requires that you have the right tools to deliver efficiently on every aspect of its life cycle.

Developing your first app can be a daunting experience, especially when you do not have enough knowledge of the tools available. Adopting these third-party tools will help you get to market quickly so that you can focus on getting the product/market fit for your app.

Prototyping

Prototyping your app gives you clarity on its every aspect, feature and the user flow. You need to have this bit sorted even before you approach a developer for building the application. The more clarity you have on your requirements, the more precise your timeline and pricing estimate for development.

1. Proto.io lets you create a full mobile-app experience without coding. What you get is a complete user flow and navigation of your app with interactive elements such as gestures and touch events to make it interactive.

2. InVision is another tool that allows you to create a fully interactive app prototype. The free tool also allows you to interact with your team members through a collaborative framework.

3. POP helps entrepreneurs, designers or even students to transform their pen and paper ideas into a prototype. If you started by sketching on a notepad, simply import it into this app by taking a picture.

Alpha/Beta Testing

The only way to know if something is working in your app is to test and measure it. You need to keep testing until you reach the desired result.

4. Amazon A/B Testing: Amazon has a free scalable tool for creating and running in-app experiments. Check out Air Patriots’ case study on how it improved its retention using the Amazon tool.

5. Heatmaps highlights the hottest areas on your mobile app, letting you track gestures, device orientation, user flows (navigation) and engagement.

6. Testdroid enables your development to be truly agile. It helps you test your application across different Android devices with different screen sizes, resolutions and different OS versions. Continuous Testing on real mobile devices saves up to 60% budget for mobile app development-testing cycle.

Mobile Backend

If your app requires users to sign up to use or any data is stored externally, then you need to build a backend. This means additional costs as well as signing up with a hosting provider. Early-stage mobile-app startups now have the option of using a third-party mobile-backend-as-a-service (MBaaS) provider to minimize those costs and develop quickly.

7. Parse was recently bought by Facebook. One of the most popular apps using Parse is Instagram. It gives you a great deal of flexibility along with a very easy to use iOS and Android developer kit that automatically takes care of synchronizing your app’s data with its cloud database.

8. Kinvey excels in the third-party integration provided through the platform. With Kinvey, you can pull rich video content from Brightcove’s App Cloud.

9. Xamarin has an impressive set of clients such as Rdio and MarketWatch using its backend. It’s helpful if you’re building native iOS or Android apps in C#.

Analytics

Analytics allow you to analyze user behavior in your app to get insights into what features are being used and which parts are driving conversions. They are also helpful in building an efficient marketing strategy.

10. Flurry (by Yahoo!) is a free tool that gives you insights into your users and app performance. You can track every menu tap, understand the user path, create funnels to optimize conversions and create user segmentations.

Marketing

Most often, the mistake that most entrepreneurs make is to think about marketing only after their product is live in the app store. You should start marketing the day you put your app into production.

11. Hello Bar is the simplest way to drive visitors to your highest-converting landing pages. It also helps you collect more emails and get more social shares.

12. FameBit connects you to YouTube influencers to create content that is shared a huge network. It’s fantastic for startups as videos start at $100.

Which tools do you recommend? Tell me in the comments section below.

(Original Arcticle: http://www.entrepreneur.com/article/237242)

Is Android Apps Development Better Than iPhone Development?

App Development

While there are more Android handsets than iPhone, over 30% of internet traffic from mobile devices comes from iPhone, compared with just under 26% from Android devices. The remaining 44% comes from RIM and Symbian devices and other iOS devices like the iPad.

When all iOS devices are considered, 73% of ad revenue generated by them comes from apps rather than mobile websites. The typical mobile user spends around 100 minutes per day using apps, and nearly 18 million apps are downloaded yearly. Today, around 20% of all searches are mobile, and of those, 40% are local searches.

Android apps development is big. Really big. According to research firm Gartner, 79% of all smartphones sold between April and June this year were running Android: 177.9m handsets compared to Apple’s 31.9m iPhone. Another research firm, IDC, estimates that 62.6% of tablets that shipped to retailers between April and June were running Android: 28.2m devices versus 14.6m iPads.

Meanwhile, Google says that more than 1.5m new Android devices are being activated every day, it’s nearing 1bn activated in total so far, and that by the end of this year that total will include more than 70m Android tablets.

Yet a lot of apps still come out for Apple’s iOS first or even exclusively. Right now, if you own an iOS device, you can play Plants vs. Zombies 2, Clash of Clans and Worms 3, but Android owners can’t. Why are android apps developments behind?

Instagram launched on Android 18 months after iOS. Nike’s Nike+ Fuel Band still hasn’t made the leap. Mailbox and Tweetbot are still no-shows, and while much-praised children’s app-maker Toca Boca has 18 apps available on iOS, only one of them is also on Android.

It’s one of the blogosphere’s favorite tech topics. Is the iPhone this, can android apps development do that? Every new nugget of competitive information is fodder for an avalanche of coverage. Oftentimes, a story will declare that android apps development is beating iOS development or that iOS is beating Android.

Really, though, it’s silly to obsess over any one data point. If what you’re after is a clear idea of how the world’s two dominant mobile operating systems are doing — rather than an excuse to make bold proclamations and/or cheer for your favorite — you want to consider lots of data points.

Is android apps development better than iPhone? Let us know what you think. The battle rages on!

[Source]

10 Tips for Efficient Android Apps Development

Android App Development Tips

The best recipe for becoming a complete flop in Google Play is to release an app that is battery and memory hungry with a slow interface. Most likely, these qualities will ensure negative reviews from users and result in a bad reputation, even if your app has great design and a unique idea. Every drawback in product efficiency, battery and memory consumption can really affect your app’s success. That’s why it is critical to develop well-optimized, smooth running apps that never make Android system guard against them. We will not speak about efficient coding, since it goes without saying that the code you write should stand any performance test. But even brilliant code takes time to run. In today’s post, we’ll talk about how to minimize this time and make Android apps that users love.

Efficient threading


 

Tip 1: How to off-load operations onto threads in background

Since by default all operations in an app run on the main thread (UI thread) in the foreground, the app responsiveness might be affected, which will imminently result in hangs, freezes and even system errors. To reinforce responsiveness, you should shift long-running tasks (e.g. network or database operations, complex calculations) from an app’s main thread to a separate background thread. The most effective way to accomplish this task is at a class level. You can use AsyncTask class or IntentService class to organize background work. Once you have implemented an IntentService, it starts when needed and handles requests (Intents) using a worker thread. When using IntentService, you should consider the following limitations:

  • This class does not put results to UI, so to show results to users use Activity.
  • Only one request is processed at a time.
  • Any request processing can not be interrupted.

Tip 2: How to avoid ANR and stay responsive

The same approach of off-loading long-running operations from the UI thread will save your users from the “Application Not Responding” (ANR) dialog. What you need to do is to create a background worker thread by extending AsyncTask and implementing doInBackground() method. Another option is to create a Thread or HandlerThread class of your own. Keep in mind that unless you specify “background” priority for the thread, it will slow down the app since the default thread priority is the same as of the UI thread.

Tip 3: How to initiate queries on separate threads

Displaying data is not immediate, although you can fasten it by using CursorLoader objects, which allows not to distract Activity from interacting with a user while query is processing in the background. Armed with this object your app would initiate a separate background thread for each ContentProvider query and return results to Activity from which the query was called only when the query is finished.

Tip 4: What else you can do

  • Use StrictMode to detect potentially lengthy operations you do in the UI thread.
  • Use special tools, i.g. Systrace, Traceview, to find bottlenecks in your app responsiveness.
  • Show progress to users with a progress bar.
  • Display splash screens if initial setup is time-consuming.

 

Device battery life optimization


We cannot blame users for angrily uninstalling applications that abuse battery life. The main threats to battery life are:

  • Regular wake-ups for updates
  • Data transfer via EDGE and 3G
  • Textual data parsing, regex without JIT

Tip 5: How to optimize networking issues

  • Make your app skip operations if there is no connection; update only if 3G or WiFi is connected and there is no roaming.
  • Choose compact data format, e.g. binary formats that combine text and binary data into one request.
  • Use efficient parser; consider choosing stream parsers over tree parsers.
  • For faster UX lessen round-trip times to server.
  • When possible use framework GZIP libs for text data to make the best use of CPU resources.

Tip 6: How to optimize apps working in foreground

  • When designing wakelocks, set the lowest level possible.
  • To avoid battery costs caused by potential bugs you might have missed, use specific timeouts.
  • Enable android:keepScreenOn.
  • In addition to GC (garbage collection) consider recycling Java objects manually, e.g.:
    • XmlPullParserFactory and BitmapFactory
    • Matcher.reset(newString) for regex
    • StringBuilder.setLength(0)
  • Mind synchronization issues, although it can be safe when driven by UI thread.
  • Recycling strategies are used heavily in ListView.
  • Use coarse network location not GPS when possible. Just compare 1mAh for GPS (25 sec. * 140mA) and 0.1mAh for network (2 seconds * 180mA).
  • Make sure to unregister as GPS location updates can continue even after onPause(). When all applications unregister, users can enable GPS in Settings without blowing the battery budget.
  • Since the calculation of a floating point requires lots of battery power, you might consider using microdegrees for bulk geo math and caching values when performing DPI tasks with DisplayMetrics.

Tip 7: How to optimize apps working in background

  • Since each process requires 2MB and might be restarted when foreground apps need memory, make sure the services are short-lived.
  • Keep memory usage low.
  • Design app to update every 30 minutes but only if device is already awake.
  • Services that pall or sleep are bad, that is why you should use AlarmManager or <receiver> manifest elements: stopSelf() when finished. When you start service using AlarmManager, apply the *_WAKEUP flags with caution. Let Android bin your application update together with the rest through setInexactRepeating(). When using <receiver>, enable/disable its components in manifest dynamically, especially when no-ops.

Tip 8: What else you can do

  • Check current states of battery and network before launching a full update; wait for better states for bulk transfers.
  • Provide users with battery usage options, e.g. update intervals and background behavior.

 

Implementing UI that leaves minimum memory footprints


 

Tip 9: How to identify layout performance problems

When creating UI sticking solely to basic features of layout managers, you risk to create memory abusing apps with annoying delays in the UI. The first step to implementation of a smooth, memory caring UI is to search your application for potential layout performance bottlenecks with Hierarchy Viewer tool included into Android SDK: <sdk>/tools/. Another great tool for discovering performance issues is Lint. It scans application sources for possible bugs along with view hierarchy optimizations.

Tip 10: How to fix them

If layout performance results reveal certain drawbacks, you might consider to flatten the layout by converting it from LinearLayout class to RelativeLayout class, lowing level hierarchy.

To perfection and beyond


Even though each tip mentioned above might seem like a rather small improvement, you might see unexpectedly efficient results if these tips become an essential part of your daily coding. Let Google Play see more brilliant apps that work smoothly, quickly, and consume less battery power, bringing the Android world one more step closer to perfection.


Information provided by Anna Orlova [Source]

Compressing and Uncompressing Data in Android/Java Using Zlib

Compressing and Uncompressing Data in Android/Java Using Zlib

This Could Be Better

The Zlib data compression library is built into Java, and allows you to compress and decompress data. So, uh… ’nuff said?

1. If you have not already done so, download and install the Java Development Kit. Details are given in a previous tutorial. Make a note of the directory to which the files “javac.exe” and “java.exe” are installed.

2. In any convenient location, create a new directory named “CompressionTest”.

3. In the newly created CompressionTest directory, create a new text file named “CompressionTest.java”, containing the following text.

import java.io.*; import java.util.*; import java.util.zip.*; public class CompressionTest { public static void main(String[] args) { Compressor compressor = new Compressor(); String stringToCompress = "This is a test!"; //String stringToCompress = "When in the course of human events, it becomes necessary for one people to dissolve the bands that bind them..."; System.out.println("stringToCompress is: '" + stringToCompress + "'"); byte[] bytesCompressed = compressor.compress(stringToCompress); System.out.println("bytesCompressed…

View original post 713 more words

How to Override Android’s Back Key When Soft Keyboard is Open

There are various scenarios where we need to handle the Android powered handsets’ hardware “back” key to do some important stuff. One scenario that’s very common is to use it on your custom search view where pressing back key only leads to hide the keyboard and user has to tap it again to hide the search view.

Let’s consider this:

Here we have a search view with keyboard open. If user wants to cancel searching and go back, he can press the back key and here is what we get on back key press:

You can see that the keyboard has gone but the search view is still there. User has to press the back key another time to navigate back to original activity.

Apparently, there is no method in your activity which listens to hardware key events when software keyboard is open. onKeyDown() and onKeyUp() methods work only when keyboard is hidden and this happen because Android considers on-screen keyboard as a separate activity and behaves accordingly.

So what should one do to override it?

Answer is simple and the easiest way to do is to override onKeyPreIme() method which is inherited from View class. To override it, you need to create a custom view. we’ll do it With minimum of the effort. For the example above, we have an EditText which we have using for searching.

Now create a new class which extends from EditText class. Override all the constructors to avoid any possible app crash. Now we’ll override the onKeyPreIme() method and check for Back key:

@Override
public boolean onKeyPreIme(int keyCode, KeyEvent event) {
    if (keyCode == KeyEvent.KEYCODE_BACK) {
        // User has pressed Back key. So hide the keyboard
        InputMethodManager mgr = (InputMethodManager) mContext.getSystemService(Context.INPUT_METHOD_SERVICE);
        mgr.hideSoftInputFromWindow(this.getWindowToken(), 0);
        // TODO: Hide your view as you do it in your activity
    }
    return false;
}

Replace your EditText with this brand new class and that’s all. Now whenever the soft keyboard is hidden through back key, you’ll be notified and you can do the required code to get things work your way.

Bonus Trick:

Here’s a bonus trick for you. If you have implemented menus in your activity, you might face a problem like this:

If you press menu key when the keyboard is opened, you ‘ll have your menus over the keyboard. Now isn’t that funny? But don’t worry, we don’t have to worry about this. What do we want here is that menus should not become visible when keyboard is opened. Piece of cake!! Update your above code to this:

@Override
public boolean onKeyPreIme(int keyCode, KeyEvent event) {
    if (keyCode == KeyEvent.KEYCODE_BACK) {
        // User has pressed Back key. So hide the keyboard
        InputMethodManager mgr = (InputMethodManager) mContext.getSystemService(Context.INPUT_METHOD_SERVICE);
        mgr.hideSoftInputFromWindow(this.getWindowToken(), 0);
        // TODO: Hide your view as you do it in your activity
    } else if (keyCode == KeyEvent.KEYCODE_MENU) {
        // Eat the event
        return true;
    }
    return false;
}

And here you go!! Menus won’t show up on pressing menu key when the keyboard is visible.
Please share the post if you liked.

Creating an Alternate-Colored List View in Android

This post will help you make a list with alternate row in different colors. This is What your list will look like:

To accomplish this, first of all create a layout file and add a listview in it. We name this file “categories.xml“:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent" android:layout_height="fill_parent" android:id="@+id/RelativeLayout1">
    <ListView android:layout_width="fill_parent" android:layout_height="fill_parent" android:id="@+id/listView1" />
</RelativeLayout>

Next, you need to create an activity. Let’s name this file “CategoriesActivity.java” and enter following code in oncreate() method:

setContentView(R.layout.categories);
ListView listView = (ListView) findViewById(R.id.listView1);
listView.setAdapter(new CategoriesListAdapter(this));

Next step it to create create a custom adapter for our list. In our code above, we’ve named it CategoriesListAdapter. Extend this class from BaseAdapter and implement the methods as usual.

Now, in CategoriesListAdapter.java, we’ll first declare and initialize a list of colors:

public class CategoriesListAdapter extends BaseAdapter {
    private final int[] bgColors = new int[] { R.color.list_bg_1, R.color.list_bg_2 };
}

You have to define these colors in an xml file e.g., colors.xml under res/color. Alternatively, you can use Android’s built-in colors like Color.YELLOW or Color.BLUE for which you don’t need to define these colors. But if you select the first method, your colors.xml will look like this:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <color name="list_bg_1">#ffffff</color>
    <color name="list_bg_2">#fef2e8</color>
</resources>

Now the last step is to set these colors in getView() method. Use the following code snippet for this:

@Override
public View getView(int position, View convertView, ViewGroup parent) {
    ViewHolder holder;
    if (convertView == null) {
        convertView = inflater.inflate(R.layout.item_categorylist, null);
        holder = new CategoryContentsHolder();
        holder.title = (TextView) convertView.findViewById(R.id.txtCategoryName);
        convertView.setTag(holder);
    } else
        holder = (CategoryContentsHolder) convertView.getTag();
        int colorPosition = position % bgColors.length;
        convertView.setBackgroundResource(bgColors[colorPosition]);
        if (holder != null) {
            holder.name.setText(categoryStringArray[position]);
        }
        return convertView;
    }
}

class CategoryContentsHolder {
    TextView title;
}

That was all! The same way you can create a list with 3 or more color.

A Beginner’s Guide to Design Patterns with Java Examples

Ever wondered what design patterns are? In this article, I’ll explain why design patterns are important, and will provide some examples, in Java, of when and why they should be used.

What are Design Patterns?

Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it’s much more than that. It is a template that has to be implemented in the correct situation. It’s not language-specific either. A good design pattern should be implementable in most—if not all—languages, depending on the capabilities of the language. Most importantly, any design pattern can be a double-edged sword— if implemented in the wrong place, it can be disastrous and create many problems for you. However, implemented in the right place, at the right time, it can be your savior.

There are three basic kinds of design patterns:

  • Structural
  • Creational
  • Behavioral

Structural patterns generally deal with relationships between entities, making it easier for these entities to work together.

Creational patterns provide instantiation mechanisms, making it easier to create objects in a way that suits the situation.

Behavioral patterns are used in communications between entities and make it easier and more flexible for these entities to communicate.

Why should we use them?

Design patterns are, by principle, well-thought out solutions to programming problems. Many programmers have encountered these problems before, and have used these ‘solutions’ to remedy them. If you encounter these problems, why recreate a solution when you can use an already proven answer?

Example

class StrategyExample {
    public static void main(String[] args) {
        Context context;

        // Two contexts following different strategies
        context = new Context(new ConcreteStrategyAdd());
        int resultA = context.executeStrategy(3,4);

        context = new Context(new ConcreteStrategySubtract());
        int resultB = context.executeStrategy(3,4);
    }
}

// The classes that implement a concrete strategy should implement this
// The context class uses this to call the concrete strategy
interface Strategy {
    int execute(int a, int b);
}

// Implements the algorithm using the strategy interface
class ConcreteStrategyAdd implements Strategy {

    public int execute(int a, int b) {
        System.out.println("Called ConcreteStrategyAdd's execute()");
        return a + b;  // Do an addition with a and b
    }
}

class ConcreteStrategySubtract implements Strategy {

    public int execute(int a, int b) {
        System.out.println("Called ConcreteStrategySubtract's execute()");
        return a - b;  // Do a subtraction with a and b
    }
}

// Configured with a ConcreteStrategy object and maintains a reference to a Strategy object
class Context {
    private Strategy strategy;

    // Constructor
    public Context(Strategy strategy) {
        this.strategy = strategy;
    }

    public int executeStrategy(int a, int b) {
        return strategy.execute(a, b);
    }
}

Pretty simple, right? Now, let’s take a closer look at the strategy pattern.

Strategy Pattern

The strategy pattern is a behavioral design pattern that allows you to decide which course of action a program should take, based on a specific context during runtime. You encapsulate two different algorithms inside two classes, and decide at runtime which strategy you want to go with.

In our example above, the strategy is based on whatever the context variable was at the time the class was instantiated. If you give it the context for ConcreteStrategyAdd, it will use ConcreteStrategyAdd, and vice versa.

Cute, but where can I use this?

Imagine that you’re currently developing a class which can either update or create a new user record. It still needs the same inputs (name, address, mobile number, etc.), but, depending on a given situation, it has to use different functions when updating and creating. Now, you could probably just use an if-else to accomplish this, however, what if you need to use this class in a different place? In that case, you’ll have to rewrite the same if-else statement all over again. Wouldn’t it be easier to just specify your context?

Class User {
    public void createOrUpdate(String name, String address, String mobile, String userId)
    {
        if(userId == null) {
            // it means the user doesn't exist yet, create a new record
        } else {
            // it means the user already exists, just update based on the given userid
        }
    }
}

Now, the “usual” strategy pattern involves encapsulating your algorithms inside another class, but in this case, another class would be wasteful. Remember that you don’t have to follow the template exactly. Variations work as long as the concept remains the same, and it solves the problem.

Adapter Pattern

The adapter pattern is a structural design pattern that allows you to repurpose a class with a different interface, allowing it to be used by a system which uses different calling methods.

This also lets you alter some of the inputs being received from the client class, making it into something compatible with the adaptee’s functions.

How can I use this?

Another term to reference an adapter class is a wrapper, which basically lets you “wrap” actions into a class and reuse these actions in the correct situations. A classic example might be when you’re creating a domain class for table classes. Instead of calling the different table classes and calling up their functions one by one, you could encapsulate all of these methods into one method using an adapter class. This would not only allow you to reuse whatever action you want, it also keeps you from having to rewrite the code if you need to use the same action in a different place.

Compare these two implementations:

Non-Adapter Approach

User user = new User();
user.createOrUpdate( //inputs );

Profile profile = new Profile();
profile.createOrUpdate( //inputs );

If we needed to do this again in a different place, or even reuse this code in a different project, we would have to type everything all over again.

Better

That’s opposed to doing something like this:

Account account = new Account();
account.createNew( //inputs );

In this situation, we have a wrapper class, which would be our Account class:

class Account()
{
    public void createNew( //inputs )
        User user = new User();
        user.createOrUpdate( //subset of inputs );

        Profile profile = new Profile();
        profile.createOrUpdate( //subset of inputs );
    }
}

This way, you can use your Account again whenever you need it—plus, you’d be able to wrap other classes under your account class as well.

Factory Method Pattern

The factory method pattern is a creational design pattern which does exactly as it sounds: it’s a class that acts as a factory of object instances.

The main goal of this pattern is to encapsulate the creational procedure that may span different classes into one single function. By providing the correct context to the factory method, it will be able to return the correct object.

When can I use this?

The best time to use the factory method pattern is when you have multiple different variations of a single entity. Let’s say you have a button class; this class has different variations, such as ImageButton, InputButton and FlashButton. Depending on the place, you may need to create different buttons—this is where you can use a factory to create the buttons for you!

Let’s begin by creating our three classes:

Interface Button {
    public String getHtml();
}

Class ImageButton implements Button {
    public String getHtml() {
        return "..."; //This should be whatever HTML you want for your image-based button
    }
}

Class InputButton implements Button {

    public String getHtml() {
        return "..."; //This should be whatever HTML you want for your normal button (<input type="button"... />);
    }
}

Class FlashButton implements Button {
    public String getHtml() {
        return "..."; //This should be whatever HTML you want for your flash-based button
    }
}

Now, we can create our factory class:

Class ButtonFactory
{
    public static Button createButton(String type)
    {
        try
        {
            Class buttonClass = Class.forName(type);
            java.lang.reflect.Constructor cons = buttonClass.getConstructor(classParm);
            return cons.newInstance(objectParm);
        } catch(Exception x) {
            System.out.println("The button type " + type + " is not recognized.");
        }
        return null;
    }
}

We can use this code like so:

String[] buttons = {"ImageButton", "InputButton", "FlashButton"};
for(int i=0; i<buttons.length; i++) {
    ButtonFactory.createButton(buttons[i]).getHtml();
}

The output should be the HTML of all your button types. This way, you would be able to specify which button to create depending on the situation and reuse the condition as well.

Decorator Pattern

The decorator pattern is a structural design pattern which enables us to add new or additional behavior to an object during runtime, depending on the situation.

The goal is to make it so that the extended functions can be applied to one specific instance, and, at the same time, still be able to create an original instance that doesn’t have the new functions. It also allows for combining multiple decorators for one instance, so that you’re not stuck with one decorator for each instance. This pattern is an alternative to subclassing, which refers to creating a class that inherits functionality from a parent class. As opposed to subclassing, which adds the behavior at compile time, “decorating” allows you to add new behavior during runtime, if the situation calls for it.

To implement the decorator pattern, we can follow these steps:

  1. Subclass the original “Component” class into a “Decorator” class
  2. In the Decorator class, add a Component pointer as a field
  3. Pass a Component to the Decorator constructor to initialize the Component pointer
  4. In the Decorator class, redirect all “Component” methods to the “Component” pointer, and
  5. In the Decorator class, override any Component method(s) whose behavior needs to be modified

Steps courtesy of http://en.wikipedia.org/wiki/Decorator_pattern

When can I use this?

The best place to use the decorator pattern is when you have an entity which needs to have new behavior only if the situation requires it. Once we’ve established our decorations, we can start programming them.

The following example illustrates the use of decorators using coffee making scenario. In this example, the scenario only includes cost and ingredients.

// The Coffee Interface defines the functionality of Coffee implemented by decorator
public interface Coffee {
    public double getCost(); // returns the cost of the coffee
    public String getIngredients(); // returns the ingredients of the coffee
}

// implementation of a simple coffee without any extra ingredients
public class SimpleCoffee implements Coffee {
    public double getCost() {
        return 1;
    }
    public String getIngredients() {
        return "Coffee";
    }
}

The following classes contain the decorators for all Coffee classes, including the decorator classes themselves:

// abstract decorator class - note that it implements Coffee interface
abstract public class CoffeeDecorator implements Coffee {
    protected final Coffee decoratedCoffee;
    protected String ingredientSeparator = ", ";

    public CoffeeDecorator(Coffee decoratedCoffee) {
        this.decoratedCoffee = decoratedCoffee;
    }

    public double getCost() { // implementing methods of the interface
        return decoratedCoffee.getCost();
    }

    public String getIngredients() {
        return decoratedCoffee.getIngredients();
    }
}

// Decorator Milk that mixes milk with coffee. Note it extends CoffeeDecorator
public class Milk extends CoffeeDecorator {
    public Milk(Coffee decoratedCoffee) {
        super(decoratedCoffee);
    }

    public double getCost() { // overriding methods defined in the abstract superclass
        return super.getCost() + 0.5;
    }

    public String getIngredients() {
        return super.getIngredients() + ingredientSeparator + "Milk";
    }
}

// Decorator Whip that mixes whip with coffee. Note it extends CoffeeDecorator
public class Whip extends CoffeeDecorator {
    public Whip(Coffee decoratedCoffee) {
        super(decoratedCoffee);
    }

    public double getCost() {
        return super.getCost() + 0.7;
    }

    public String getIngredients() {
        return super.getIngredients() + ingredientSeparator + "Whip";
    }
}

// Decorator Sprinkles that mixes sprinkles with coffee. Note it extends CoffeeDecorator
public class Sprinkles extends CoffeeDecorator {
    public Sprinkles(Coffee decoratedCoffee) {
        super(decoratedCoffee);
    }

    public double getCost() {
        return super.getCost() + 0.2;
    }

    public String getIngredients() {
        return super.getIngredients() + ingredientSeparator + "Sprinkles";
    }
}

Here’s a test program that creates a Coffee instance which is fully decorated (i.e., with milk, whip, sprinkles), and calculate cost of coffee and prints its ingredients:

public class DecoratorTest
{
    public static void main(String[] args)
    {
        Coffee c = new SimpleCoffee();
        System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());

        c = new Milk(c);
        System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());

        c = new Sprinkles(c);
        System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());

        c = new Whip(c);
        System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());

        // Note that you can also stack more than one decorator of the same type
        c = new Sprinkles(c);
        System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());
}
}

The output of this program is given below:

Cost: 1.0; Ingredients: Coffee
Cost: 1.5; Ingredients: Coffee, Milk
Cost: 1.7; Ingredients: Coffee, Milk, Sprinkles
Cost: 2.4; Ingredients: Coffee, Milk, Sprinkles, Whip
Cost: 2.6; Ingredients: Coffee, Milk, Sprinkles, Whip, Sprinkles

Example courtesy Wikipedia decorator pattern example

Singleton Pattern

The singleton design pattern is a creational design pattern which makes sure that you have one single instance of a particular class in the duration of your runtime, and provides a global point of access to the single instance.

This makes it easier to set up a point of “coordination” for other objects that use the singleton instance as well, since the singleton’s variables will always be the same for anything that calls it.

When can I use this?

This solution is thread-safe without requiring special language constructs, but it may lack the laziness of the one below. The INSTANCE is created as soon as the Singleton class is initialized. That might even be long before getInstance() is called. It might be (for example) when some static method of the class is used. If laziness is not needed or the instance needs to be created early in the application’s execution, or your class has no other static members or methods that could prompt early initialization (and thus creation of the instance), this (slightly) simpler solution can be used:

public class MySingleton {

    private static final MySingleton INSTANCE = new Singleton();

    // Private constructor prevents instantiation from other classes
    private MySingleton() {
    }

    public static MySingleton getInstance() {
        return INSTANCE;
    }
}

By doing this, we can access our MySingleton instance from different parts of our code, even in different classes. This data will persist throughout all getInstance calls.

Conclusion

There are many more design patterns to study; in this article, I’ve only highlighted some of the more prominent ones that I use when programming. If you’re interested in reading about the other design patterns, Wikipedia’s Design Patterns page has a plethora of information. If that’s not enough, you can always check out Design Patterns: Elements of Reusable Object-Oriented Software, which is considered to be one of the best design pattern books available.

One last thing: when you use these design patterns, always  make sure that you’re trying to solve the correct problem. As I mentioned previously, these design patterns are a double-edge sword: if used in the wrong context, they can potentially makes things worse; but if used correctly, they become indispensable.


Post inspired from: http://net.tutsplus.com/articles/general/a-beginners-guide-to-design-patterns/


I’ll highly appreciate your feedback on this article.