Basic Sprite Animations in libGDX

In the last post we discussed how to use the texture packer to create sprites. And now we will take a look into how to put these sprites into a libGDX application.

First things first, you need to copy the files you create with the texture packer into the app's asset folder. These assets are typically stored in the Android folder of the app, so in the case of Dot's Dots, the directory is something like this:

/home/netbook/AndroidStudioProjects/dotsdots/android/assets

Don't forget there are at least two files that need to be copied. The PNG file(s), which are the images, and the ATLAS file, which is a map of the images.

Now that the image files are in place, let's look at the code used to animate the sprite.

package com.petenotpete.dotsdots;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;
import com.badlogic.gdx.graphics.g2d.Animation;
import com.badlogic.gdx.graphics.g2d.TextureAtlas;
import com.badlogic.gdx.graphics.g2d.TextureRegion;

public class DotsDots extends ApplicationAdapter {
private SpriteBatch batch;
private TextureAtlas textureAtlas;
private Animation<TextureRegion> animation;
private float elapsedTime = 0;

@Override
public void create () {
batch = new SpriteBatch();
textureAtlas = new TextureAtlas(Gdx.files.internal("dotsprite.atlas"));
animation = new Animation<TextureRegion>(1/60f, textureAtlas.getRegions());
}

@Override
public void render () {
Gdx.gl.glClearColor(0, 0, 0, 1);
Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);

batch.begin();
elapsedTime += Gdx.graphics.getDeltaTime();
batch.draw(animation.getKeyFrame(elapsedTime, true), 0, 0);
batch.end();
}

@Override
public void dispose () {
batch.dispose();
textureAtlas.dispose();
}
}

Now let's look at the code. The magic here is this line:

animation = new Animation(1/60f, textureAtlas.getRegions());

This sets the animation speed (60fps in this case) and the sprite frames from the texture atlas. The next key part are these lines:

elapsedTime += Gdx.graphics.getDeltaTime();
batch.draw(animation.getKeyFrame(elapsedTime, true), 0, 0);

The elapsed time lets the animation know what frame should be displayed, and the 'true' following it shows that the animation should loop. So in this animation, it uses all the sprites on the sprite sheet, but oftentimes we will have more than one image or animation on a sprite sheet and will need to differentiate between them. If you use the libGDX texture packer to create the sprites, the sprite atlas names the frames after each image's individual filename. The best way to use this to your advantage is to add a prefix to each different image in a spritesheet and number them sequentially (like: walk001.png, walk002.png, walk003.png, run001.png, run002.png, run003.png, etc.). In the code you can separate the animations as follows:

public void create() {
batch = new SpriteBatch();
textureAtlas = new TextureAtlas(Gdx.files.internal("dotsprite.atlas"));

TextureRegion[] walkFrames = new TextureRegion[10];

walkFrames[0] = (textureAtlas.findRegion("0001"));
walkFrames[1] = (textureAtlas.findRegion("0002"));
walkFrames[2] = (textureAtlas.findRegion("0003"));
walkFrames[3] = (textureAtlas.findRegion("0004"));
walkFrames[4] = (textureAtlas.findRegion("0005"));
walkFrames[5] = (textureAtlas.findRegion("0006"));
walkFrames[6] = (textureAtlas.findRegion("0007"));
walkFrames[7] = (textureAtlas.findRegion("0008"));
walkFrames[8] = (textureAtlas.findRegion("0009"));
walkFrames[9] = (textureAtlas.findRegion("0010"));

walkAnimation = new Animation(1/60f, walkFrames);

//or you can just pass the frames directly

runAnimation = new Animation(0.1f,
(textureAtlas.findRegion("0011")),
(textureAtlas.findRegion("0012")),
(textureAtlas.findRegion("0013")),
(textureAtlas.findRegion("0014")),
(textureAtlas.findRegion("0015")),
(textureAtlas.findRegion("0016")),
(textureAtlas.findRegion("0017")),
(textureAtlas.findRegion("0018")),
(textureAtlas.findRegion("0019")),
(textureAtlas.findRegion("0020")));
}

And there you go, you have a sprite moving around.

Creating Sprites with libGDX texturepacker

One of the differences between using libGDX and and not using a game engine is that libGDX uses sprite sheets. This is good, because in OpenGL, binding textures is fairly resource expensive and it is better to bind one large resource once than many small resources.

There are plenty of tutorials online about creating sprites, and I am certainly not much of an artist, so I will leave that to others to explain. But, I will say this, if you are like me and end up with a GIF file or have each of your individual sprites saved as layers in a single image there is a trick to getting them out without saving individually.

To separate layers of an image file into separate images the easy way, save the image file as an OpenRaster file (.ora extension). GIMP can do this for free, and likely most other image editing software can as well. After saving, open the .ora file using compression software (7zip or WinRAR), open the 'data' folder, and you will see each individual layer saved as a separate .png file. Easy.

Otherwise, it is important that each of your animation frames is in numerical (or alphabetical) order so that the sprite sheet will be created in the proper order. In my case, I number each frame like 001.png, 002.png, 003.png and so on.

For this tutorial, I made a simple 12 frame animation of a dot running (the app I am making is called Dot's Dots*, right?). You can see it in GIF form below, but I won't provide the images or the sprite sheet for you, because I think it is important that you try this for yourself. And honestly, you don't even need to make it 12 frames, you could have a 3-4 frame animation of a stick man walking and it will be fine.

Now, hopefully you created a simple animation of a few frames. In order to create your sprite sheet the first thing you should do is download the texture packer JAR file. Save it somewhere convenient, and use the following command at the command line to create the sprite sheet:

// OS X / Linux java -cp runnable-texturepacker.jar com.badlogic.gdx.tools.texturepacker.TexturePacker [inputDir] [outputDir] [packFileName]

// WINDOWS java -cp runnable-texturepacker.jar com.badlogic.gdx.tools.texturepacker.TexturePacker [inputDir] [outputDir] [packFileName]

[inputDir] is where you saved your individual image files, [outputDir] is where you would like the sprite sheet to be saved and [packFileName] is going to be the name of the output file.

In my case, I want to take my image files and save the sprite sheet directly into my apps assets folder. Because I am using Linux, I would type this:

java -cp runnable-texturepacker.jar com.badlogic.gdx.tools.texturepacker.TexturePacker 'Images/Sprites/DotsDots' '/home/netbook/AndroidStudioProjects/dotsdots/android/assets' dotsprite

After the texture packer runs, you will find two types of file in the output directory. There will be the .png files, which will be the actual sprite sheets, and there will be the .atlas file. The .atlas file is a text file that tells libGDX the location of each individual image on the sprite sheet.

If you want to just make a simple sprite sheet, feel free to stop reading here. I will discuss slightly little more technical stuff below, but it likely won't affect sprite or animation performance.

Note that the texturepacker defaults to sprite sheets that are 1024px x 1024px. In 2018 that seems fairly paltry, and if you want to change the sheet size, or any other options, you just need to include a file called 'pack.json' in the same directory as your individual image files. The pack.json file can have the following options:

{

pot: true,
paddingX: 2,
paddingY: 2,
bleed: true,
bleedIterations: 2,
edgePadding: true,
duplicatePadding: false,
rotation: false,
minWidth: 16,
minHeight: 16,
maxWidth: 1024,
maxHeight: 1024,
square: false,
stripWhitespaceX: false,
stripWhitespaceY: false,
alphaThreshold: 0,
filterMin: Nearest,
filterMag: Nearest,
wrapX: ClampToEdge,
wrapY: ClampToEdge,
format: RGBA8888,
alias: true,
outputFormat: png,
jpegQuality: 0.9,
ignoreBlankImages: true,
fast: false,
debug: false,
combineSubdirectories: false,
flattenPaths: false,
premultiplyAlpha: false,
useIndexes: true,
limitMemory: true,
grid: false,
 scale: [ 1 ],
scaleSuffix: [ "" ],
scaleResampling: [ bicubic ]

}

You only need to include the options you want to change, any unlisted options will just return to the default settings. As for the sprite sheet size, I believe that on most modern devices that sheets of 4096px x 4096px will work fine. However, old devices, particularly those using old versions of OpenGL, will not work. I thought about this personally, and decided that it was more important for me to maintain backwards compatibility than it is to minimize texture binding resource use, so I decided to stay with the default. Of course that decision is up to each developer, so you can decide on your own.

Next, if your images don't fit all onto one sprite sheet, it might be a good idea to separate them into subdirectories in your input directory. By doing this, you can ensure that the texturepacker saves related files on the same sprite sheets. Because the libGDX texturepacker tries to create the most efficient packing result, related sprites could be spread across several sprite sheets, which would be very inefficient.

Finally, if you want to run the texturepacker as part of your app, it can be done. We won't cover it here, because it seems to be of limited value to hobbyist developers that are likely working alone, but the libGDX wiki discusses it in detail.

*I have no idea what Dot's Dots is going to turn out to be, I am creating it on the fly as part of this tutorial. Shhhh!

Compiling Your libGDX Project

So now that you have imported a libGDX project into Android Studio, you will probably notice that it doesn't look like a normal Android Studio project, and also that it won't compile right away.

This tutorial will explain the changes needed to be made so that you can compile your libGDX project for Android, desktop and HTML.

Android:

So if you tried to compile your new project you probably got a Gradle error that looks something like this:

What happens here is that currently (as of early 2018) projects imported from libGDX use a Gradle version of something like 2.14.1 and libGDX needs a Gradle version of 3.5 or above. Conversely, you will also get an error if you are using any Gradle version above 4.0, which would be the default of Android Studio. In either case, we want to change the Gradle version. To do this, we open the 'gradle-wrapper.properties' file under the 'Gradle Scripts' heading in the Project window.

We want to change the distributionURL line to:

distributionUrl=https\://services.gradle.org/distributions/gradle-3.5-all.zip

If you followed my previous tutorial in setting up the libGDX project in Android Studio, this should be all you need to do in order to make the APK able to be compiled.

If you are still having trouble, here are some other problems I have faced.

Error:(2, 0) Plugin with id 'jetty' not found

This error is caused when you are using a Gradle version above 4.0. Follow the steps above to change the Gradle version to 3.5, but additionally follow these steps:

1. Open the project level 'build.gradle' file (again under the 'Gradle Scripts' heading in the Project window)
2. Change the 'classpath' version:

classpath 'com.android.tools.build:gradle:2.3.3'

3. In the same file, under 'repositories' remove:

google()

NOTE: There are two places to do #3, under 'buildscript' and under 'allprojects'

Error: Plugin with id 'gwt' not found

If you run into this error, there is a simple solution. Just go into the project level 'build.gradle' file (again under the 'Gradle Scripts' heading in the Project window) and add the following line under the 'dependencies' inside the 'buildscript' tag:

classpath 'de.richsource.gradle.plugins:gwt-gradle-plugin:0.6'

Desktop: 

The easiest way to compile to desktop is to create a runnable JAR file. To do this, open the Gradle window by clicking the vertical 'Gradle' button on the right side. In that menu, expand ':desktop', then expand 'other', and finally click on 'dist'.

Once it is finished compiling, you can find the JAR file in this directory:

[APPLICATION PATH]/desktop/build/libs

If you end up having an error, read below.

Running the desktop app from Android Studio

This is easy, once you know what to do. Go into the Project Window and expand the 'Desktop' folder. Several folders will open and at the end there will be a java file 'DesktopLauncher'. Right click that and select 'Run DesktopLauncher.main()'. Unfortunately, this will cause an error. It will say something like Exception in thread "LWJGL Application" com.badlogic.gdx.utils.GdxRuntimeException: Couldn't load file: badlogic.jpg. If this is the case, the answer is simple.

Go into the run menu at the top of the Android Studio window and click on 'Edit Configurations...' This will open the Run/Debug Configurations Menu. Click on 'DesktopLauncher' from the dropdown menu on the left. Now, on the right side you can see an item called 'Working directory:'. To fix this error just append 'android/assets' to the directory listed. It should look like:

[APPLICATION PATH]/android/assets

This should allow it to run, but if you have another error see below.

"Exception in thread 'main' java.lang.NoClassDefFoundError: com/badlogic/gdx/ApplicationListener"

To solve this problem, we need to run the app as a JAR application. To do this, go into the run menu at the top of the Android Studio window and click on 'Edit Configurations...' This will open the Run/Debug Configurations Menu. In this menu, first click the green plus sign in the top left. Select 'JAR Application' from the drop down menu. You will see something like this:

You need to enter the 'Path to JAR:' which will be:

[APPLICATION PATH]/desktop/build/libs/desktop-1.0.jar

Next, in the 'Before Launch' section at the bottom, hit the green plus and add 'Run Gradle Task'. The 'Gradle Project' should be found at:

[APPLICATION PATH]/desktop/build.gradle

Finally, in the 'Tasks' box, type:

desktop:dist

And that's it. You should be able to run your app on the desktop as a JAR application by clicking the 'Select Run/Debug Configuration' button in the menu and selecting 'JAR Application'. Then just click the green run arrow to the right and wait for it to compile.

HTML:

Let's be honest, libGDX doesn't play well with HTML. But, if you are like me, you want to be a completionist and force it to work. Well, be forewarned: you will have to deal with a lot of code workarounds in order to make your application compile to HTML. For the time being, though, let's just look at how to actually get it to compile.

In Android Studio, open the Gradle window by clicking the vertical 'Gradle' button on the right side. In that menu, expand ':html', then expand 'other', and finally click on 'dist'. That will build your web app.

To find the files, you need to go into:

[APPLICATION PATH]/html/build/dist

All of the files will be in that folder and its subfolders.

A word of warning, though. Even with the default libGDX app (showing a picture on a red background), it doesn't seem to work in every browser. For example, on my Linux machine, it works fine on Seamonkey (2.49.1) but not on Chrome (63.0.3239.132). At some point in the future I might come back to figure out why, but for the time being I am going to accept that it compiles and leave it at that.

Setting up a libGDX project in Android Studio

***** This tutorial is based on the libGDX tutorial series at Game from Scratch. Their tutorial is helpful, but outdated, so I am going through and updating it based on Android Studio 3.0.1 and libGDX 1.9.8 *****

Before we start, please understand that I am only one person and I am going through this tutorial for my own benefit. Because of that, I won't be able to cover all instances exactly. Particularly, I use a crummy old Linux laptop for coding and don't have access to either a Windows or Mac machine to test how things work on other operating systems. Where possible I will try to provide help, but since I won't be able to test it, I can't make any guarantees.

The first step is to ensure that you have Android Studio and the Java Development Kit (if you have trouble, make sure you installed the 'JDK' specifically).

Next, download the libGDX project setup tool and put it in a convenient directory. (Note there is an official setup guide, although it, too, is a bit out of date.) Now that you have all the necessary files, let's get started on importing a project.

1. From the command line, go to the directory where you saved the libGDX setup file (gdx-setup.jar) and type:

java -jar gdx-setup.jar

You should see this screen now:

If you don't, the most likely issues are that you are not in the correct directory or that you haven't installed the Java JDK. Recheck those steps before doing anything drastic.

2. Now it is time to set up the project. 

• First, choose the name that you want to use. I will call my project Dot's Dots, but feel free to call your project whatever you like. 
• For the Package name, I follow the Google Play naming convention, so will use com.petenotpete.dotsdots.
• Game class isn't overly important, but I will also change it to DotsDots because I like to be thorough.
• Destination is fairly important for ease of use. I want to create the project in the same folder as the rest of my Android Studio projects just for convenience sake. If you do this, you should specify the actual folder of the project, and not the generic projects folders. For example, in my case you would want to specify:
  /home/netbook/AndroidStudioProjects/dotsdots
  If you don't know where that is, or don't care, just save the project somewhere convenient for you.
• Android SDK location is obviously important, but it should be automatically filled in. If for some reason it isn't, you can find the location of the SDK by opening an Android Studio project and selecting 'File' -> 'Other Settings' -> 'Default Project Structure...'
• For the subprojects, I just leave the default. We will discuss a bit about web based and desktop applications, so they are good to have, and who knows, you might just want to publish your app to the App Store some day.
• Under extensions, I just leave the default 'Box2d' checked.

3. Now that everything is filled out properly, click that 'Generate' button. When I do this I get two warnings:

In both cases I hit 'No'. I am not sure how things will work otherwise, but I read of some fairly recent (as of early 2018) issues on Stack Overflow where the libGDX project wasn't compiling because it didn't work with the newest Android and Gradle versions so figure it is better to stick with the recommended versions.

Once that is done, go get yourself a cup of coffee and watch everything get set up.

4. Once the libGDX project generator says it is finished, open up Android Studio and open the project.  Sometimes it doesn't show up in the menu immediately, but if you browse the directory structure you should be able to find and open the project.

5. When you open the project in Android Studio, it is likely you will get a popup similar to the following:

It honestly doesn't matter that much what you pick because we are going to have to change the Gradle version again anyway, but I personally select "Don't remind me again for this project" because otherwise you get an error immediately upon opening.

6. So now you should have the project open in Android Studio, and the next step is going to be getting the project to compile on desktop, HTML and Android.

Using LibGDX with Android Studio

All of my previous apps I had designed just using Java directly in Android Studio, but my ambitions have been growing and I decided that I need to use some sort of game engine to continue developing what I want. The problem is that there are so many game engines available for Android development. Seriously, go Google it (ok, you probably already have if you are reading this), I will wait.

I realize that none of the game engines are perfect, and choosing one would involve trade offs. In order to find the best game engine for me, I made a short list of must haves and preferences. I ended up with three musts:

1. Open source and free to use - I am not making any money here, well not anything to speak of, and I prefer to minimize any possible expenses.
2. Strong 2d engine - I don't foresee myself making any 3d games in the near future, so I prefer a game engine that focuses on 2d as it suits my needs.
3. Extensive documentation - I am not an expert and am doing this as a hobby, so I need to find a well developed engine that has a lot of tutorials available.

On top of this, I would prefer a game engine that uses Java so that I don't have to completely relearn everything. This isn't incredibly important, but I have limited time and would prefer not to use that trying to understand a new language.

Anyway, after some research, I had two game engines that I was interested in, Godot and libGDX. They both hit my three must haves, and it was hard for me to choose between the two. Originally I was going to go with Godot, but after a quick Googling it looked like libGDX had been around longer and had much more written in terms of tutorials and beginner's help.

While this was true, it turned out to not be that much of a blessing. Most of the tutorials and walkthroughs for libGDX are outdated and don't work with the current version, which has been causing me headaches. HOWEVER! I actually think this might be a good thing, because instead of being able to just copy and paste the code that I want, I have to go through and figure everything out. This is going to help me in the long run, and it will definitely make me a better developer.

At the same time, I understand that not everyone wants to go through the trouble, so I am going to do my best to chronicle my progress here so that people going forward can have an up to date walkthrough on how to get started.

Hard Truths about Android App Design

Here are some hard truths that every hobbyist Android developer needs to face at some point:

1. You are not going to make the next Flappy Bird - I mean seriously, I know that everyone thinks about their golden ticket. I would be lying if it didn't motivate me sometimes, but seriously, take a moment and scroll way way way way way down to the bottom of a search in the Play Store. The app you design is very likely going to be lower than that in search rankings. The likelihood of becoming a viral success is infinitesimal.
2. Your app idea isn't as good as you think it is - Yes, I know your mom (wife/best friend/whoever) told you that it is brilliant. But these are also the people who tell you how adorable your baby looks even though you know it uncannily resembles Yoda. It is hard to get honest criticism from the people closest to you, and it is hard for you, as the developer, to critically assess what you have made. But here is the thing, even if your app is awesome, you still have to contend with number 3.
3. Someone else (probably ten someone elses) have already made the app you are thinking of - Again, do a deep dive into the Play Store and take a look at what is available. I won't go so far as to say that there is nothing new under the sun, but people have been designing applications for Android phones for a long time now, and it is highly unlikely that you managed to come up with a totally original idea. And even if you did...
4. Marketing is as important as actual app quality -  Do you have any idea how much SuperCell spends in advertising? A quick Googling says something like 500 million dollars a year. If you dig into the details, it averages out to a cost of nearly $2 per install if you use a CPI (cost per install) marketing campaign for your Android app. Now, to justify that kind of spending, you have to be able to earn more than $2 per user on average. Can your app do that? If not, you have to look into other ways of marketing your app. Let me tell you from personal experience, marketing is tedious. I started Android development because I wanted to make apps, not beg people to look at them.
5. You are going to get bad reviews - So let's say you overcome all of these obstacles and people are downloading your app. Certain people are going to leave horrible reviews for no apparent reason. Out of six apps that I have have made, I am lucky enough that one of them gets a slow but steady stream of downloads. The problem is that it is a utility app (it allows you to use your phone and a Bluetooth speaker like a megaphone) and I get one star reviews without comment and one star reviews with walls of text criticizing me as a person and one star reviews saying "I don't like this game, it is stupid", and it drives me up the wall. I know that all the other apps in the market face the same issue (the average rating of similar apps is like 3.5, even though they all work generally fine), but it is frustrating that people are apparently writing bad reviews not based on the app itself.

At any rate, Android development can be fun and rewarding, but it isn't the free pass to early retirement that you wish it would be. You need to have thick skin, and you will be surprised how you feel when you release your perfect app, check the console the following day and see that zero people installed it. It is deflating, but that isn't a reason to stop. Keep working on your ideas, keep trying new things. Who knows, you actually might create the next Flappy Bird.

How Exactly Do I Start Android Programming?

There are two main things you need to begin to learn how to code. The first is practical knowledge, what language to learn, what sort of SDK (software development kit) to use, where to go for help, etc. The second, which I would argue is more important, is motivation. If you have an idea for a project that you want to build, learning to program will be much easier. While it is probably a good idea to start with a simple project, if your dream project is something large and complicated you can still break it down into bite sized chunks.

As for practical knowledge, I mentioned previously that I started by doing the Oracle Java Tutorials and didn't feel that they were helpful in learning about Android programming. However, after sleeping on it, I think that by following those tutorials it 'primed the pump' as it were and helped me understanding all the stuff I learned later.

Anyway, let's do this in list format so it is a bit easier to follow:

1. Have an idea - before you start it is a good idea to have at least a general idea of what kind of project you want to design. This will help with motivation and guide your learning so you can complete the project. It doesn't need to be a detailed road map, in fact I think it is better to keep your idea flexible so that it can change as your knowledge grows. For example, I have ideas for a lot of projects that turn out to be completely infeasible, but with a flexible mentality they often turn into other projects that are possible for me to complete.
2. Oracle Java Tutorials - Take a look at the first three to five beginner tutorials here. There is really no need to go further than that because they don't apply to Android development, but definitely the first three will be a great primer on how everything works. Particularly the second tutorial will be useful for people who are just starting out.
3. Install Android Studio - Now it is time to start the actual task of development. Download Android Studio, install it and get ready.
4. Use Android Tutorial - Check out the early developer guides provided at developer.android.com. These get pretty in depth, but if you go through just the first couple of them that will give you an idea of how Android development works.
1. Android Studio can compile native C code as well as Kotlin and Java, but I recommend sticking to Java for the time being because there are a huge number of resources for using Java in Android development and that will come in handy as you learn.
5. Fool Around - Now you should have an extremely rudimentary idea of how to develop a basic Android app. Try things out on your own. Add pictures and text, add links, try to change things programmatically, try to implement some code related to your app idea. A lot of this will not work, and that's OK. You can keep trying things and testing ideas, and it will give you a good idea what you want to learn and what direction you want to take your app idea in.
6. Search Stack Overflow - This is the single most helpful thing you can do as a beginner Android developer. Once you have figured out what you want to do and have realized that you don't know how to do it, it is a great time to go look at Stack Overflow. Nearly every question under the sun has already been asked and answered with code samples and explanations on how everything works. 
1. In addition to looking at the code in the answers provided, it is good to look at the code provided in the questions because we can see the kinds of problems people are running into. This will help us avoid these problems in the future.
2. It is ok if you don't understand what the code means right away. Some of the stuff is more complicated than others, and there is definitely going to be code that is opaque to you.  This is fine, because a nice  thing about Stack Overflow is that people leave explanations in addition to code samples. Follow along as best you can.
3. Don't be afraid to copy and paste code fragments into your own code and try to make it work. This is a great way to learn and it can help you figure things out on your own.
7. BACK UP YOUR CODE - Once you start making simple apps it is a good idea to open an account at Github or Bitbucket to keep your code backed up.  Both are fine, and there are other options out there, but I personally use Bitbucket because it allows you to keep your code private (Github does this with a paid tier, but on Bitbucket you can do it for free). This might not be a big deal to you, but I am a little bit ashamed of my code, so I don't want others to see it.
8. Sign up for a Google Play Developer Account - Once you have an app you feel ready to release, go over to the Google Play Developer page and sign up. Pay the $25 for a lifetime account, and get ready to publish your app!
9. Release your app through Alpha or Beta channels first - When you go to release your first app, you might feel like it is a good idea to release to production immediately. Hold your horses! If you turn on pre-launch reports (it is in the menu on the left of the Play Developer Console page, under 'Release Management') and upload the app to Alpha or Beta, the app will be briefly tested on a variety of devices. This has saved my bacon on several occasions where I forgot something simple (like switching from test ads to live ads or a weird crash that occurred from the soundpool that I didn't notice because I had sound off) and it causes crashes on the test devices. 
10. Pop open the champagne, you have an app in the Play Store!

This is a very brief overview of the basic steps that I followed to start Android app development, but I think they might be helpful to some others that feel like they don't know where to start. Over the next few posts I will dive into some of the steps in a bit more detail, and will discuss some of the hurdles that I faced in the very beginning.

Why Should Beginners Start with Android Development?

The main reason I decided to make Android apps rather than iPhone apps is because I have an Android phone (makes sense, right?), but there are other pragmatic reasons that make Android more appealing to hobbyist developers like myself.

First of all, to post your apps in the Google Play Store you have to pay a developer fee of 25 US dollars. This is a one time fee and once paid it allows you to post as many apps as you would like to the Google Play Store. Conversely, to post apps to the Apple app store, you have to pay a fee of 99 US dollars every year. While this isn't a big deal for larger developers, it is pretty unlikely for a hobbyist to make any significant money so a lower fee is going to be more comfortable.

While developing for the Apple app store might be slightly easier (fewer devices and screen sizes lead to less possible issues, Android's Java is notoriously bad at memory management, among other things), to a novice developer there won't be much difference at first. Also, this minor benefit is greatly outweighed by the ease of publishing on Android. Both app stores nominally review all apps that are posted, but Android has a much more lax set of standards which are easier for beginners (like me) to meet. This is good because as design novices it is very unlikely for us to create something amazing in our first go around and being able to see your app in the Play Store is much more motivation to continue compared to receiving a rejection letter from Apple.

Also, the Apple App Store has a policy of removing older, un-updated apps. While this is a reasonable policy, if you are creating apps as a hobby after your kids go to bed (like me!), it is a hassle to maintain all of your previous apps to ensure they meet future guidelines.

For these reasons, I think it is better to start out creating with Android. It is cheaper, it is easier to remain motivated, and your apps are likely to remain available longer.

A Journey of a Thousand Miles Begins with a Single Step

So a couple years ago I used to do Amazon Mechanical Turk to pass the time. I didn't really need the money, but it was fun (for some value of 'fun') and earned me a few spare dollars on the side. I never got super into it, but would just randomly do tasks that piqued my interest, and as such wasn't exactly efficient. At the same time, I wasn't really doing it for the money, so it didn't really matter.

Mechanical Turk is how I got interested in coding, though. One day I saw a long term job for like $10 or something (this was in 2016, so I am not totally sure) to test a Python teaching site. Aside from typing in lines of BASIC from the back of old computer magazines and doing some very, very basic coding in the same, I had no real experience with that side of things. At the same time, it was something I had been curious about and this spurred me to check it out. Plus, they would pay me to do it (sure, it was only like ten bucks, but why not?).*

After spending a few days going through the Python course I started thinking about how I could apply this to my own life, and decided that I wanted to try my hand at making Android apps. Knowing nothing about Android, I did a quick Googling and saw that most Android apps were created using Java. I then Googled how to learn Java and found the Oracle site, which had plenty of tutorials and documentation.

What I didn't realize at the time was that regular Java and Android Java were not exactly the same thing. I think doing those tutorials helped me grasp some basic concepts about object oriented programming and how everything fit together, so it was probably worthwhile, but had I known that they weren't directly related I might have skipped the Oracle stuff. Of course it is hard to tell how much it actually helped me, and I only spent a short time there, so it doesn't really matter much.

Next, I wanted to learn about how to put Android apps together. After a couple false starts, I ended up downloading Android Studio and from there began my incredibly successful and lucrative** app career.

Ok, the past two posts have briefly explained where I am coming from, and now the following posts will be a bit more pragmatic in nature so that they can hopefully help people like me who are just getting started. Until then, be cool and try to do something nice for a neighbor.


*I went back through my old emails and found the site but it is no longer active, which is unfortunate because I kind of want to reach out to the creator know that they at least helped me out. But I digress.

**this part is not true. 

Frist Post

So blogging is dead, but I have recently begun learning Android app design and wanted to kind of chronicle my progress. Unfortunately I might have waited a little bit too long because I already have six apps in the app store.

None of them are very complicated (or popular), and I think I only released my first app about a year ago (I just checked, it was about 18 months ago), though, so I am still very much a beginner.

One of the main reasons that I want to write about stuff here is that this is just a hobby to me. I am a university professor (totally unrelated field) and students are all under the impression that they can become zillionaire app developers or Youtubers or whatever. I would like to be able to point them somewhere that shows how making even a simple app is a ton of hard work and even if the app is perfect (as all of mine are ;)) that is no guarantee that anyone will download them.

Anyway, because of my job, I am lucky enough to have free time to do this as a hobby, but I also have three young kids so it isn't like I have hours and hours a day to spend coding and doing stuff. My main hope is that I can dissuade people who think that app making is a get rich quick scheme, and conversely I can hopefully help people who want to learn a bit about coding but are kind of scared and don't know where to start. To that end, my next post will discuss how and why I ended up designing Android apps. Until then, have a nice day and try to be kind.