7 Best Apps for Your Coffee or Bathroom Break

(Guest post By Daniel Ors, Fueled)

Your coworker thinks you’re in the boss’ office getting the promotion he deserves. Your boss thinks you didn’t come into work today. Your love thinks you’re ignoring their texts, and your parents think you’re a senior executive who just doesn’t have time to reply to their emails. Everyone thinks you’re up to shenanigans, when you’re really just taking a coffee break or hiding out in the bathroom stall. Small breaks throughout the work day are needed to keep you focused, relaxed and refreshed as sitting at a desk too long impedes creativity and nullifies productivity. That brief escape can refresh your zombie-esque paper pushing feel into full-blown Renaissance art.

It’s too bad our employers don’t offer periods of recess, but where our jobs lack, smart technology provides a prescient solution. In fact, your next best time-burner is waiting for you in the App Store or on Google Play. Here are the 7 best apps for your coffee or bathroom break:

Instagram

Instagram may be the best time-wasting app available as it incorporates some of the things we value most dearly in our downtime. When you wonder what some of your friends are up to, follow them and refresh your timeline every time you take a break. When you want to just look at something cool, refresh the Explore page and discover something new. Be careful, though. Instagram’s easy-to-use interface could make it more than a bathroom or coffee break, and turn you into a diligent procrastinator.

Pinterest

Vision boards are great for helping us maintain focus in our daily lives, visualizing our purposed wants, needs and purpose. What if we could take our vision boards with us everywhere we go? Pinterest allows users to do just that. Pinterest users can build virtual vision boards in the by saving or “pinning” products, pictures or locations of things that interest them, breaking their “pins” out into different themes and categories. Bathroom and coffee breaks are the perfect time to build your Pinterest in their app or browse other boards to see what you may find.

iAssociate

Coffee and bathroom breaks are for resting your mind, but that does not mean you have to stop thinking. iAssociate is a word guessing game based on thematic word association. Complete one theme, then move to the next level. Sounds easy enough, right?

BuzzFeed

Do you like quirky yet interesting lists? Do you want to know something you never knew you did not know? Do you like random yet relevant information? Do you like taking strange quizzes that reveal something about you or your life experience? Take your Buzzfeed experience with you on every break and never miss out on their popular content.

HiFutureSelf

Make your coffee and bathroom breaks meaningful. Use them to make yourself more productive even while taking a break. To-do lists and calendars can easily be muted in the mind, but what about a text from your self? What if you could text future self, and remind yourself about things you need to do, people you should call or just to say hello. HiFutureSelf users can use the app to send themselves messages in the future, and breaks are the perfect time to tell yourself to not forget to do something later in the day.

If This Then That

Managing all your social presence can be a bit overwhelming. Update your status on Facebook. Send a tweet. Change your profile picture on that. Switching back and forth from one to the other can be a real pain, but with If This Then That (IFTT), you can bring order to your social chaos. Use your bathroom or coffee break to change your profile pictures across networks or blast updates to followers on different social apps simultaneously.

Pocket

Watercooler talk can be overwhelming. There’s always a show someone saw, article someone read or blog someone visited to be aware of. Frankly, it can be too much to handle on your own, so save all your content for a look later with Pocket. Categorize and organize your content in one bathroom or coffee break and go back to check it out later.


Your brand could be the facilitator of the next go-to app for coffee and bathroom breakers everywhere. Fueled has the expertise and experience needed to craft powerful, useful apps that will keep users engaged and give your brand exposure.

Android – render and animate with SVG

Few days back, we released the android version of Peekaboo HD. It’s a series of apps focusing on introducing animals and their voices to kids in a very pleasant way. It’s minimalistic and quite fun for toddlers. (more details here)

We chose SVG for rendering the images considering the smaller size and better scaling capabilities that it provides. This was an interesting choice considering android doesn’t support SVG natively, and the browser support for SVG started very recently (3.0+). We went the route of SVG renderers. We looked at few SVG renderers available and finalized AndroidSVG (by Paul Lebeau).

AndroidSVG rendered our svg files the best and seems more active than the other libraries available. (Also, Paul responded to our query email very promptly 🙂 ). This solved our problem for finding a good SVG renderer. Next up was animations..

Peekaboo animates the animals to add some fun and engagement. AndroidSVG doesn’t support SVG animations, so we chose to do a custom frame-by-frame animation.

Looking at the options, AnimationDrawable seemed almost perfect. So, we dynamically created an AnimationDrawable object and used the addFrame() method to add the Drawables to it. AndroidSVG gave us a picture object, which we could add as PictureDrawable. Here’s a brief of that particular code:


AnimationDrawable animationDrawable =
new AnimationDrawable();

SVG svgImage1 = SVG.getFromResource(context,
 R.raw.image1);

animationDrawable.addFrame(
new PictureDrawable(
svgImage1.renderToPicture(), 50));

SVG svgImage2 = SVG.getFromResource(context,
 R.raw.image2);

animationDrawable.addFrame(
new PictureDrawable(
svgImage2.renderToPicture(), 50));

//finally, set it to the imageView
someImageView.setPictureDrawable(
animationDrawable);

That’s pretty much it and we have an animated Animal. We had the animation choreographed for the voice, so that it seems in sync. We achieved that by varying the animation duration of each frame.

Hope this helps you if you’re trying out something similar. Let me know if you’ve been successful in other ways as well..

Save and Update with Sugar

This post helps demonstrate the ease with which you can save and update a record with the help of Sugar in android project.

For an introduction to Sugar, click here.

Firstly, to enable your model to utilize Sugar’s benefits, you need to have configured Sugar in the manifest file (as shared in the introduction) and the model needs to extend SugarRecord.

Saving a record becomes straight forward, as you’re only interacting with your objects and not the usually messy way of dealing with SQL queries directly. Here’s a way to save a record using Sugar:

// Note class represents model. It extends SugarRecord.
Note note = new Note(context);
note.setTitle("Make Tea");
note.setDescription("Add tea along with milk and sugar. Boil for few minutes");
note.save();

That is all you need to do to save a record into the android database. The save() method takes care of inserting the record into its corresponding table.
Similarly, modifying and updating a record is made very simple with Sugar. Here’s a way to do it.

// obtain a reference to the note record from database.
Note note = Note.findById(context, 1);
note.setDescription("Take some water. Add milk, tea and sugar. Boil it for few minutes");
note.save();

Here findById() is a query method to obtain the record with id 1 from the table. After getting the reference to the instance, modify the values and call the save() method to update the record into the table.

So, as you see, saving and updating records is made very straight forward with the use of Sugar. The code is located here  . Check out SugarExample for an example project.

Do try it out.

Sugar : Android database made easy.

UPDATE : Some of the code snippets in the below post are outdated. Please visit http://satyan.github.com/sugar/ for latest updates to the library.

This post is an introduction to Sugar library for android. The aim of the project is to simplify database access in Android.

The project draws inspiration from GORM for grails or Active Record for Rails. These patterns have been hugely successful in the web world, and have set a benchmark for libraries for database access.

The basic objectives of the library  are:

1. Creation and management of database and connection.

2. Simple and Intuitive API for database querying.

3. Simple CRUD operations.

Source Code

Source code is present at https://github.com/satyan/sugar

You can clone it and start hacking. There’s a build script along with it to compile and generate the binary.

An example project using the library is present at https://github.com/satyan/SugarExample

Usage

Android Manifest file: 

Include the android:name attribute in the application tag. SugarApp extends android’s Application and initiates the database creation for the project. By including the attribute, you’re basically starting with SugarApp instead of android’s Application class. If you intend to write your own Application class, you can extend SugarApp.

<?xml version="1.0" encoding="utf-8"?>
<manifest..>
<application.. android:name="com.orm.SugarApp">
.....
</application>
</manifest>

Entities
The entities need to inherit from SugarRecord including a typed parameter. SugarRecord provides for all the CRUD methods that will be available to the entity classes.

public class Note extends SugarRecord<Note>{
private String title;
private String description;
public Note(Context context){
super(context);
}
...
}

Thats about it. Configuration is done. You’re ready to dive into the sweetness of Sugar. (OK.. I couldn’t stop myself from saying this.)

# inserting values

Note note = new Note(context, "Note 1");
note.save();

# query

Note.findById(context, Note.class, 1);
Note.find(context, Note.class, "title=?", new String[]{"Note 1"});

# delete
Note note = Note.findById(context, Note.class, 1);
note.delete();

# few more..

Note.listAll(context, Note.class);
Note.deleteAll(context, Note.class);

Nice.. All done. Happy Android hacking.

Working with legacy code.

Its generally not a preferred option to work with legacy codebase, but every now and then you do come across a codebase which hasn’t undergone a overhaul in long long long time. It is very common to lose all your calm on it.. get frustrated, and either do nothing about it or leave the job to do something else.

I had a recent encounter with such a codebase and below are some of my findings and recommendations about handling such a codebase.

Let me start with the definition of the codebase.

It had been written 2 years back and the software has been used since by 2000+ people.  There have been multiple revisions of the product and all the changes have made the codebase fairly rigid and incomprehensible. It was supposedly written in hurry, so quality wasn’t taken care (typical of startups). Since then it has not been re-written or even cleaned up.

Long.. huge all powerful classes and methods. No object-orientation whatsoever. All static methods. Algorithms and logic written so beautifully that even the author finds difficult to navigate through them. Messed up assignments and states. It was at times a game to guess what a particular variable would contain after few iterations of the code.

Ok, you get the picture, right?

It is very easy to start criticizing the people who wrote it and make all noise. But, have a look at the good part.

The software has been running pretty successfully for last couple of years. Been used by thousands of people. Been earning money for the organization. Its not all that bad, isn’t it?

So, first step to tackle such codebase is to treat it with respect.

Not easy when you’re supposed to add functionality on top of it. But, appreciate the fact that the product has been useful for a longer period of time. Many software products never get to see the light of the day. Beautifully written, wonderfully functional, but never released. It is much better to release a product and iterate on it than never release at all.

Having said that, lets see some of the ways to tackle that code (in no particular order).

1. Don’t be afraid to change.

It is difficult, but not impossible. Leave the tendency to not touch the existing functions. The sooner you get comfortable with the code, the better chances you have of adding features on top of it.

2. Try to divide the codebase into smaller classes and methods.

Be methodical about it. Make small changes and test frequently. But nothing beats this approach. Separate a big class into multiple smaller ones. Long methods can be broken into more meaningful smaller methods. This will automatically give you a picture of what is going on within the code.

3. Change the names.

Work with the team to change the names to more appropriate ones as and when possible. You’re not only making it easy to understand the code, but, also making yourself comfortable with changing the code, without touching the solution much.

4. Write tests around existing code.

At times it gets difficult. But with some discipline and patience, you can write tests around existing code. It helps a great deal to understand the code and improves your confidence in changing it at a later stage.

5. Understand and manage dependencies.

Try and separate different areas of the code and manage the dependencies between them.

These are few strategies to approach a large legacy codebase. Please share if you’ve come across similar situations and how you handled them.

Don’t just sit there..

This post is for programmers and managers who believe that spending more time on the project (in the office) is directly proportional to productivity of the programmer.  Ok.. I’ll break a secret here.. “IT’S NOT”. Obviously you need to be in front of a computer to type, but the similarity with programming just ends there.

Here are few misconceptions by managers:

1. A programmer can produce more lines of code if he’s working on the project.

Probably true (if he’s programming at all). But more lines of code IS NOT necessarily what software needs. There are many other metrics which define productivity and ‘lines of code’ doesn’t really feature there. In fact its the other way around.

2. Programmer is available for status updates and meetings.

If one requires programmers to be around just for this reason, there are better ways to do it. Read about Scrum, offline status updates, etc. One argument is discussing technical issues with other programmers. That is true but can be done without extended hours too.

3. One is more committed to success of the project.

This one is completely WRONG. There are many factors that determine the success of project. Project execution, Team bonding, Effective communication… Spending time is not. A programmer can be doing lot of things right, with a long term view.. producing readable and highly maintainable code.

Ok. So what should programmers do with their time?

Utilize portion of your working time honing your skills and updating on getting more productive. Here are a few simple things you can do:

Productivity Tips for Programmers


Inherit or compose.. Hmm..

When designing your domain/classes, this is one decision that always results in conflicts within teams. Whether to inherit from a class or to compose that class. This is fairly subjective but here are few pointers for discussion..

Lets take this code for example:

public class GiftCollection extends HashSet {

    public Gift getRandomGift(){
        List giftList = new ArrayList(this);
        Collections.shuffle(giftList);
        return giftList.get(0);
    }
}

It is a collection of gifts that is represented as a set. The additional behavior from a set is that it can give you a random gift. It looks fairly straight-forward and would work in a even more straight-forward manner. Lets look at a usage of this..

public class GiftSelector {

    GiftCollection giftCollection;

    public GiftSelector(GiftCollection giftCollection) {
        this.giftCollection = giftCollection;
    }

    public Gift selectRandomGift(){
          return giftCollection.getRandomGift();
    }

}

This is a basic usage of the GiftCollection provided earlier. If one looks closely, though the two classes look very similar and doing similar things, there are basic differences between the two.

GiftCollection inherits a HashSet and extends to the behaviour by adding another method getRandomGift to it. However GiftSelector decided to contain a GiftCollection and delegate few calls to it.

I’ve always preferred the latter approach for following reasons:

1. The classes (both superclass and subclass) are much more flexible to change.

In this case, if GiftCollection decides to change the signature of the method getRandomGift(), it would not have an effect on the callers of GiftSelector, since it wraps the method call.

But any change to the Set implementation would affect the api of the GiftCollection class, without its knowledge. The users of GiftCollection have to change their code, though there has been no apparent change to the class. This is not an ideal scenario.

2. Easier to test.

It clearly shows that GiftSelector is much easier to test than GiftCollection. One can easily mock the dependency of the class and unit test the code. Whereas, in the case of inheritance, most mocking libraries do not provide a way to mock super classes. So its difficult to test in isolation.

3. Polymorphism through Interfaces is more flexible

One of the reasons for inheritance has been to reduce code and take advantage of polymorphic behaviour. Interfaces provide a more flexible way to achieve the same result. Composition coupled with Interfaces present a better alternative to achieve polymorphism.

This is not to say that one should not use Inheritance.

When modeling your domain, Inheritance should be used in case of a direct ‘is-a’ relationship. It should not be used only to achieve code-reuse or polymorphism.

Prefer composition over inheritance, unless you have good reasons to not do so..

Would love to hear your thoughts on this..