Before you start to monetize your first mobile app, before you even start to program, or even conceptualize what its going to be, there is one thing that you might want to consider: Code reuse. Code reuse is when you use programming that was previously used to build some other software like a mobile app, either part of a program from a previous project, or all of it.


For instance, you’ve probably heard of the infamous game called Flappy Birds that took the world by storm in 2014. The programming behind Flappy Birds is not considered high-level by any means, but the compelling thing about the game is the number of images it employs; just five. Imagine those five images are called splash.png, up.png, down.png, bar.png, and background.png. The up.png image represents a bird flying upward and down.png is a bird dropping downward. The bar.png image moves across the user’s screen, the background.png provides a background, and splash.png is the splashscreen.

Now imagine taking Flappy Birds and changing it to a game called Happy Fish. The first step is to copy all assets, programming, images, etc. to a brand new folder. Go into the new folder and rename it Happy Fish. Once you are in the new folder, start by switching the bird images (up.png and down.png) out for fish images, the “sky” background (background.png) for a “water” background, the bar (bar.png) image becomes a seaweed image, and the splashscreen (splashscreen.png) says, “Happy Fish!” Notice all of the image names remained the same, even if they now are fish stuff instead of bird stuff. The programming never changed! It’s important to understand that the original program never accessed an image like upBird.png. Had that happened, you would have had to change some of the programming to access a file like upFish.png. The original image file names are kept very generic on purpose; hence names like up.png and background.png so no programming ever has to change when reusing code.


Think carefully about what this example of code reuse means. In the time it took you to make a new folder, copy the original programming, change a few images you’ve come up with a completely new product (Happy Fish) that can be deployed on mobile gaming platforms like Google Play or the iTunes Store. Instead of one game making money, now you have two, or ten if you please. Birds become fish or bugs or submarines, etc. Let’s say it took you 50 hours to program the original Flappy Birds program. The Happy Fish program probably took 20 minutes, the Crazy Bug program took 20 more, etc. Does the concept of code reuse change your thinking when you are coming up with a new idea for a mobile app? The answer is clearly yes.


A Closer Look

Let’s investigate the inner workings of a mobile app like Flappy Birds. A few things have to happen to make the game work. For instance, the bird in the game is constantly dropping down the screen until the user presses an “UP” button. In this example, when the bird is dropping, it employs an image called droppingBird.png so it looks like the bird in the game is descending. When the user presses the UP button, the image switches to risingBird.png and moves upward on the screen to represent the bird rising. Consider the following pseudo code:


1. var droppingBird = 10




5. droppingBird = droppingBird – 1

6. MOVE droppingBird.png TO LOCATION droppingBird

7. IF droppingBird = 0 THEN GAME OVER ENDIF




Line 1 of the pseudo code assigns the number 10 to a variable called droppingBird. The droppingBird variable will change constantly while the game is being played. For the purpose of this example, consider the number 10 as representing the highest physical location on the user’s mobile device screen, and 1 is the lowest. Since the droppingBird variable starts at 10, the idea is to place the droppingBird.png image at location 10 on the screen to start the game.





Line 2 assigns a name called BIRDDROP to all of the code between Line 3 and Line 8. The idea is that anytime the program calls the CLASS called BIRDDROP, Lines 3 through 8 will execute without having to retype them in the program every time. For example, instead of retyping the following…




droppingBird = droppingBird – 1

MOVE droppingBird.png TO LOCATION droppingBird

IF droppingBird = 0 THEN GAME OVER ENDIF



…All you have to do after you define what the class does is type BIRDDROP, and the coding above will execute.


Line 3 employs a WHILE loop that waits to see if the user is going to press the UP BUTTON. If the program doesn’t detect the UP BUTTON being pressed, the Line 4 coding waits 1 second, and then Line 5 reduces the value of the droppingBird variable by 1. On Line 5, keep in mind that droppingBird was originally assigned a value of 10, so droppingBird – 1 = 9.


Line 6 tells the program to move the droppingBird.png image to whatever the value of the droppingBird variable is. For instance, if the droppingBird variable is 6, the droppingBird.png image is placed on LOCATION 6 of the mobile device’s screen.


Line 7 checks if the value of the droppingBird variable is 0. The 0 location of the screen means the droppingBird.png image has dropped too low, therefor the game is over. The WHILE loop started on Line 3 will continue as long as the value of droppingBird is greater than 0. Line 8 ends the WHILE loop that was started on Line 3.


What’s Wrong With This Picture?


The pseudo code above is a very rough representation of how to make a bird image seemingly drop down a screen while waiting for a user to press an up button, keeping a bird “afloat,” to prevent it from ending the game. This pseudo code allows the user to manipulate the bird up or down to a certain height on the screen through a gap. The “gap” part of the program that the bird seems to fly through still needs to be written separately. This pseudo code is used to give a programmer a very rough idea of how a program might work. So what’s the problem? The problem is that although this code will eventually work, it is a poor candidate for code reuse. Notice the liberal use of the word “bird” in the code. What if you wanted to reuse this same code and replace the bird images with bug images? The variables would still work but be somewhat confusing as they refer to birds. A better way to write the code in the first place would be as follows:


1. var imageLocation = 10




5. imageLocation = imageLocation – 1

6. MOVE down.png TO LOCATION imageLocation

7. IF imageLocation = 0 THEN GAME OVER ENDIF




The code does the exact same thing with some minor changes. The variable called droppingBird has been renamed to imageLocation, a much more generic, yet still descriptive name. The CLASS name changed from BIRDDROP to IMAGELOCATOR, and the image called droppingBird.png is now called down.png. Because of these changes, nothing has to be modified within the programming if you want to reuse this code for submarines, flowers, or cats. Now when you copy the original app and all of its assets to a new folder called “Bug App,” the only thing to remember is that the bug facing downward is saved as down.png, the upward facing bug is saved as up.png, the new background image is still saved as background.png, the new splashscreen image is still saved as splash.png, and the new bar images are saved as bar.png.


When you start to program, try to keep reusability in mind. Can the “Candy Crush” type game you programmed be easily redeployed as something similar that has been repackaged with a different theme but uses the same code? How about the “Campus Locator” app you might have written for one particular university? Can the programming be easily reused to work at some other university by simply switching a map and a few images? The concept of leveraging code reuse should be top of mind when creating original code.


Monetizing and Licensing Code


Let’s say a friend of yours wants to get into selling mobile apps online, but doesn’t want the chore of learning how to code. Maybe they’re a really imaginative person that’s pretty good with Adobe Photoshop so they can make their own images. One option is to license your reusable code to them for a fee; let’s say 30% of their revenue they earn from the Apple iTunes Store.


The only things your friend really needs to know is the dimensions of the image files and what they need to be named. For instance, the up.png file that represents let’s say, a dog facing upward, is 50 by 50 pixels, as is down.png. Your friend can place their new images in the appropriate folder of the licensed code and they have a brand new game. Your friend is now free to market “their” new game as they please, and represent it as their own.