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

11 Reasons Why Windows Phone 7 is Better Than Android

I, myself, am an Android developer and have been developing apps for it for around 3+ years. I’ve seen Android emerging from the 1.5 version to the latest 4.0.3 (or Ice cream Sandwich). I had the privilege to use the very first Android handset G1 and used many others including latest phone like Sensation etc. But, the first time I heard Windows Phone 7 announced, as a mobile developer I looked into it with the mind that Microsoft cannot do anything good especially with the smartphones. But I was astonished. The clean, awesomely visible and attractive UI was the first catch. I seriously liked the idea of rainbow-less screens and dig in depth the WP7 OS.

Regardless of the numbers, WP7 is one of my favorite mobile platforms, outshining Android in almost every aspect. Don’t believe me? Well, allow me to try and change your mind.

Windows-Phone-7-Series

Windows Phone 7 Series

Streamlined User Interface

Android’s are different depending on the SKU of the handset. In other words, the UI you’ll be dealing with when using, say, a Motorola handset, will be radically different than one from Samsung or HTC. The ambiguity can be disconcerting. With WP7, you know what kind of interface you’re going to be working with, regardless of the handset manufacturer. We’d imagine that an un-tweaked user interface would also make lives easier for developers, as well. We love some Android user interfaces, but loathe others. With WP7, at least you know what user interface to expect, regardless of the handset maker.

WP7 Has An Easier-To-Use Interface

Windows-Phone-7-UI

Windows Phone 7 UI

It really does. And look, we get it. An Android is a power user’s phone, and we know that if you’re really looking for power-use, you’ve got to be willing to learn some things. But we’re the geeky minority here, and you’ve got to keep in mind that most people are looking for a phone that makes it easiest to do their day-to-day tasks. Keeping that in mind, WP7’s “tile” system is simply easier to organize and find the things you need to throughout the day. It looks cooler too; way cooler, actually.

WP7 Has Apps That Aren’t Crap

Open-source is good, and it’s a compelling reason to support Android as a mobile platform, but let’s face it: You’ve got to sift through some real $#@t in the Android Marketplace to find apps that are worth downloading, much less buying. Most people fail to realize that the Windows Mobile SDK has been around for quite some time now, and it shows in the Marketplace, especially on the gaming side of the spectrum. Many of the games we played featured awesome 3D graphics and a level of polish simply not(yet)-to-be-found in the Android hemisphere. Microsoft has a far stricter criteria set than Google about which apps and games can populate their respective marketplace.

Microsoft LIVE Integration Is Cool

Windows-Phone-7-Xbox-Live

Windows Phone 7 Xbox Live

If you’re achievement junkies like we are (you know who you are), then a WP7 handset is a must-have. Have a game on Xbox or PC that you love playing? Pop over to the Windows app store; chances are there’s a mobile version of that same game, where you can continue earning points and unlocking achievements with your handset. You can also keep tabs on your buddies’ achievements, and tweak and enhance your Xbox Live avatar. Granted, this integration is still in an infancy stage, but we’d be willing to bet that we’ll be seeing deeper and more intuitive connections between gaming and phones in the near-future. Forward progress is good progress.

Microsoft Mobile Office Integration

Windows-Phone-7-Office

Windows Phone 7 Office

We were actually blown away by how deep this rabbit-hole goes. Microsoft Word Mobile Edition, by way of an example, is actually a very intuitive little program, allowing you remote access documents using SharePoint Server 2010, you can use the “find” tool to look for particular words or phrases, and you can even email documents directly from the program.

We’ve had the pleasure of testing some Android phones that can dock with workstations to function as a laptop; imagine how crazy it would be if Windows launched a similar product with a full-fledged Office Suite. That’d be one step closer to a true fusion between phones and computers, and we’re all for that.

People Hub

Windows-Phone-7-People-Hub

Windows Phone 7 People Hub

The most amazing thing in Windows Phone 7.5 (“Mango”) is the People Hub. No matter how many social networks you use and how many accounts do you have on them, WP7 will manage everything. All you have to do is to add your accounts by giving usernames and passwords and WP7 will fetch all your friends, followers, buddies and place them in your contacts. What if I have same person on Facebook, Twitter and Windows Live, etc? Well, it will link all accounts under one name. Yes, that’s correct! It will match the names and link all the accounts with same name as a single contact. You can also manually add or remove an account as per your needs.

What the benefit of it? Let me tell you, it’s enormous. WP7 kills the need of checking all your social applications again and again. You don’t have to keep an eye on Facebook, Twitter and LinkedIn. All you’ve to do it to open your people app and everything goes listed here. All the feeds, tweets, updates are here. Also, you’ve all your notifications gathered at a single place. Similarly, you can write a status once and publish it to all or may be some specific networks in once.

Microsoft Isn’t Constantly Getting Sued by Apple

Whether targeting HTC a year ago or Motorola last fall or even Samsung (which is remarkable seeing how they are a flat out key supplier of Apple’s hardware components) just a few days ago, Apple has been regularly suing the hell out of Android handset makers; mostly in regards to hardware and software patents. So why is Apple seemingly ignoring WP7 in the courts? Well, there could be numerous reasons: Optimistically, it could be because the software and hardware developments on WP7 are truly original and innovative, meaning Apple can’t accuse Microsoft of lifting their ideas. A more realistic reasoning? Apple doesn’t see WP7 as that big of a threat…yet.

Stability

This is speaking from personal experience with various handsets across both platforms, but to put it simply, WP7 has just been a more stable experience. Apps like Facebook and Netflix simply run the way they were meant to with far less of the hiccups and crashes found on the Android platform. This runs parallel with the overall theme behind WP7 mobile devices: Simplicity. Granted, WP7 had to forgo some of the more complex actions Androids are capable of (i.e. lack of tethering support, lack of ability to capture screenshots, no multi-tasking), but to us, that’s a worthy trade for a phone that will do what you want it do, every step of the way.

Zune is a Native Client, and it’s Not Pay-Per-Song

We like Zune as a service—you pay a monthly fee and can download as many songs as you want, as opposed to being pigeonholed into paying per song, like with Apple and Android. Also, we really enjoy the fact that Zune is a native client that comes fresh out-the-box with WP7—setting up music services on an Android involves downloading various apps (like Google Music, which then has to synch to your Google Wallet, which then has to synch to your Google Music Server, which then needs a Gauntlet from Moredore to unlock your songs, which then needs…well, you get the point) that is just sort of a hassle, and glitchy to boot. Again, simplicity reigns supreme.

Snappier Keyboard

All right, we’re getting down to the nitty-gritty, and this is a minor nit to pick, but for the most part (with the exception of the Android Sprint Galaxy, which actually featured a physical slide-out QWERTY keyboard), Windows Phone 7 had a snappier, and more importantly, a more consistent keyboard that was snappy and accurate, regardless of the device. And, though Droid offered a few keyboard-contenders with the Galaxy S2 and the Incredible, others were really bad, (ahem, Droid X2, cough).

No Ad-Ware!

That’s right, there is nary a pop up ad to be found, whether you’re in the Windows Marketplace, or playing a game. There is nothing more irritating when using an Android that having to manually close pop-up adds, many of which appear mid game. There are, indeed, advantages to more stringent app restrictions, and WP7 seems to have found a perfect balance.


Source: Maximum PC

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.

How to Stay Fit at Your Desk

A large contributor to the weight problem in the United States is that more people than ever before are working in sedentary desk jobs.

Sitting at a desk with only the occasional hand and arm movements for 8 to 12 hours per day eliminates a large amount of time other people are using to get some form of exercise.

The lack of exercise may not just affect your health, but also your health insurance. Many plans are beginning to offer lower rates to those who belong to a gym. Others are requiring higher co-pays to individuals that smoke or who are overweight.

To overcome this problem, try a new set of exercises that can make sure you get adequate exercise while at work. The following are some tips and strategies for getting in some good exercise when you can’t get away from or you can’t stray very far from your desk.

Posture

The first step to maintaining your health at a desk job is sitting with proper posture. While sitting at your desk, your back should be straight, shoulders back, thighs parallel to the floor, knees bent at a 90-degree angle, feet flat on the floor, and eyes looking straight ahead. While keeping a proper posture won’t burn any calories, it is an important step for your overall health.

Stretching

An easy way to get some exercise at your desk is to engage in simple stretches. You can stretch your neck, torso, arms, legs, and more while sitting at your desk:

  • Neck – Stretch your neck by flexing your head forward and backward as far as is comfortable. Then, tilt your head left and right. Next, turn your head from side to side, looking left then right. Never roll your head around in circles.
  • Shoulders – Although you shouldn’t roll your head in circles because it is too prone to injury, you can roll your shoulders. Start rolling forward, and then switch directions after 10 repetitions.
  • Arms – Sit about two feet from the edge of your desk, about one shoulder-width. Put the outside of your hands on the edge of the desk and lean forward.
  • Wrists and ankles – Wrists and ankles are other joints that benefit from rolling.
  • Chest and back – stretch your arms out to your sides. Rotate your wrists so your thumbs are up and back. Now, push your arms back gently at the shoulders.
  • Abdomen and groin – Contractions are good exercises for the abdomen and groin. Contract your abdominal, hold, release, and repeat.
  • Calves – Stretch your calves by bringing your weight onto the balls of your feet and raising your heels. Then, lower and repeat.

Kick it up a Notch

Never do anything sitting that you can do standing. Along the same lines, never do anything standing that you can do walking around your office or desk space. Always try to stay as active as possible. Many people perform repetitive office tasks on a treadmill or exercise bike. When you can’t get up from your seat, make use of some simple forms of exercise equipment like a hand gripper, a small hand exercise balls, or elastic bands.

With a little inventiveness, it is not that difficult to get adequate exercise in a confined space or limiting situation. Most of us simply sit idly while we work. You don’t have to be idle. Put your multitasking skills to the ultimate test.


Original Post: Staying Fit at Your Desk