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 ;)

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.

Beautiful Code: Pt. 1

***I'm starting this new series which will highlight code that I think is pretty/gorgeous/mind-blowing or all of the above. Generally it will be simple cases, and most of it will be Java only because of my limited knowledge of coding languages. Feel free to submit code to me (Using Pastie works best I believe) or to correct code highlighted in these segments.***

findPairs()

I'm making a dice game for android with a close friend of mine. The game is called Farkle and its highly addictive. A player needs to roll 6 die and choose the best combinations to score the most points. This method I just created will return the positions of other dice with the same value. The method came out very clean and I'm extremely proud of it. Even if it's extremely simple

public int[] findPairs(int index, int value) {

      int[] dirtyArray = { 0, 0, 0, 0, 0, 0 };

      int count = 0;

     for (int j = 0; j < dieValues.length; j++) {

            if (j != index && dieValues[j] == value) {

                  dirtyArray[count++] = j;

            }

     }

    if (count == -1)     return null;

    int[] cleanArray = new int[count];

    System.arraycopy(dirtyArray, 0, cleanArray, 0, count);

     return cleanArray;

}


Edit: Teehee made a mistake and just found it. Guess that's what happens when you post "Beautiful" code before testing. Note to self: variable++ returns the variable before it got incremented


Double Edit: And another one! It's perfect now (I promise)