Simple Backends for Android Apps - Part 1

        In my recent lunacy I decided to take up my friends offer and work with him on a multiplayer android game. It's a dice game, but we hope that people will give it a chance since it's very addicting. I'm currently suffering from Feature Rampage, and I'm deciding to add complex features before I'm done implementing simpler ones. It's a terrible business practice but considering that we specified no budget for this and that we are doing this part time, I don't care ;) One of the features that I decided to implement was online play (including friends and chats)! It's pretty ambitious considering this is going to be the first product I ever made and that I don't know any html, http or any other language besides Java. What can I say? I learn best by doing : D

       For this post I won't dabble too much into the details of the framework, instead I'm going to provide an overview and explain how I implemented push notification for android versions 1.6+.

       Since we already established that I'm a n00b at everything (I dropped the hint in the Blog name btw) I set out on Google's Blue, Green, Yellow, and Red road to find the right assets for me and my current needs. My criteria was simplicity, reliability and speed. Simplicity because I want to release this app before I get out of High School, so while I would love to read and learn about new technologies it wouldn't fit the schedule. I wanted reliability because I didn't want to re write the whole app because I chose the wrong service; I would rather take my time choosing that waste my time switching services. And lastly I wanted Speed because frankly who likes to use slow, unresponsive apps?

       Still here? I'm surprised you care that much!...erhmm....right! backends...I happened to mention that I wanted push notifications. I basically want to avoid polling for anything. I'd Rather put a load on a server than on a user's phone. I couldn't use Android's C2DM because I would be leaving almost 30% of Android Users       without Push, so XMPP ( or Jabber for you old timers) seemed like the perfect match up for me. After all, C2DM is based off of XMPP! I just needed to copy it.

     I set out to make my own XMPP server and after numerous failed attempts I found this wonderful service called XTIFY. It was a blessing! Saved me a ton of work and I have not had a single dropped notification. Don't be fooled, while the site heavily pushes developers to use their pre-made Notification Activity you can send a "custom" notification with your own custom intent in it. Like so:

In XTIFY you can add your custom intent

And in your code add this:

Btw this is assuming you followed the implementation guide (which is fairly good!)

From this central Broadcast Receiver I can organize and send intents to other activities, write to databases and just treat this like a response from a server without having to deal with stupid http requests. That's going to come in the next part of this series ;)

Android Animation Bug

After much head bashing I have found a bug in Android. Now I wouldn't be posting it here if I thought it was a big enough bug but I'm sure most of you will encounter it if your using the android.view.animation package. I'm also positive it's a bug because there are tons and tons of animationListener questions on StackOverflow. So there are many variable to make this bug happen so I won't go into the procedures to recreate it. I'm going to keep it Short and Simple and tell you this. If you ever do this:

Animation a = AnimationUtils.loadAnimation(this,R.anim.translate_animation);
a.setAnimationListener(new AnimationListener(){
        @Override
public void onAnimationEnd(Animation animation) {}
        @Override
public void onAnimationRepeat(Animation animation) {}
@Override
public void onAnimationStart(Animation animation) {}
});

And you figure out eventually that any of the onAnimation* methods never get called, then you ran into the bug.

So far the only solution that I found was to make a subclass of the view that you're using and override the onAnimationEnd method with whatever you want to do. Like this.

Shoutout to Matt Quigley. He's a software engineer that works on mobile phones. Follow his blog and his excitement on Android Engineer

Design before Code

        There's this image of the ultimate programmer that no doubt, at least, will flash through the newbie programmers mind. He's a genius, no doubt wearing glasses, he writes code by himself, he doesn't write bugs--ever, and he doesn't plan before coding (after all the code he excrements exceed the value of John Carmack's code). Now the first quality surely helps at programming but the rest are superfluous or just plain wrong. No one cares if you wear glasses or not. EVERYONE makes bugs, its natural because we're human beings and we make mistakes. And (depending on the size of the project) no one-I repeat- NO ONE can code all alone or start coding before designing a good bit of the structure.

Today I'll talk about the designing part of programming. I'm working on a dice game for Android and during the early stages of the game I made a class that you send an int Array (int[]) and it will return the highest score possible of that group of dice. While I was designing the class, it occurred to me that it was the perfect situation to use a Final Class. There was no instance dependency anywhere in the class and all the methods could have easily been static. BUT!, being the lazy person that I am I decided to make a regular class that used variables to keep track of the number of dice face values i.e. numOf1 = 3 implies that in the array there are 3 ones. During the development I kept having to change a lot of the code of the other classes to accommodate for the shortcomings of the class. For example, I forgot that since I used 1 instance the state of the variables were never reset to 0 after the class calculated the score of an Array. Little mistakes like these forced to make the class Final and all the methods in it static, which looking at it now makes the whole project A LOT easier.

What Am I driving at here? Well basically, all that hardship could have been avoided if instead of being lazy I stopped coding for a moment and thought about the future of the project. But I didn't. I love to code and while I was coding I was in the ZONE. You know how it is. Its like a vice. You feel omnipotent. I did and I didn't want to stop to think about the design of the structure. And it cost me. Getting in the zone is often regarded as when you get the most work done or the most important work done. Sometimes getting out of the zone and into design mode can help a lot more.

My shout out for this post goes to Joel Polsky who works at Fog Creek Software. He's very a very smart down to earth man who's blog post give a lot of advice based on a good bit of experience. This blog post should speak for him better than I ever will be able to ;-) Until next time. Follow me on twitter @tytdfn to send me suggestions or questions.