EPTI actually began to write this guide about four months ago, but it became apparent that I needed give it some more time. I had created and published an Android App, but I did not have the skills to make something that I was actually proud of. In order to account for this, I was filling pages with the mindsets/routines I had to adopt in order to make myself finish such a project. This tendency kept leading into tangents which, perhaps valuable, don't necessarily need to be in this guide. If anyone is curious about how I was able to find the time/effort/discipline in order to actually get off my ass and write a functioning piece of software despite never having done it before, then please ask me. If that's something people are interested in, I can make a response or another blog on the topic. In this one, I'll try to stick to the confines of creating and publishing an Android App, start to finish, for noobs. I'll be working on this over the next couple weeks, so feel free to ask questions, correct me, or suggest topics.
Before I continue, one last bit of housekeeping. This guide speaks to how *I* went about creating and publishing an Android App from scratch. I had a single Comp Sci course (basic Java), and little experience in programming at all when I started. I've taught myself a few things about Design Patterns and Software Development, but I would still consider myself a novice in those areas. My approach has been to learn as I go, and to at times, sacrifice intricacy and best practices in favour of getting things done. If something that I say strikes you as incorrect, please let me know and I'll correct it if found to be wrong.
Why Android, instead of iOS or Microsoft?
The first thing you might consider is what hardware you have access to. Simply put, if you already have a Mac and an iPhone, or a PC/Linux machine and an Android device, you'll have a much easier time writing and debugging in your respective Operating Systems. It would seem that writing Android Apps on a Mac isn't too difficult, while writing iOS Apps on anything but a Mac requires a lot of fucking around (I'll be doing a lot more research into this next month, as I plan on learning iOS soon and would rather avoid buying a Mac just for that purpose).
Another consideration is that, while iOS developers generally make more money with their Apps (Apple users are used to paying out the ass for everything), Android has a larger user base; I'm not sure by how much and for how long though, the stats are changing. It is also cheaper to register as an Android developer (which you will need to do to publish on Google play), being $25/year, as opposed to the $99/year price tag of registering with the App Store. That may be chicken feed for some, but I didn't have the luxury of throwing down $100 bucks when I started.
The amount of user groups, combined with the effort which Google puts into helping Android developers, has made being an Android developer a hell of a lot easier than I expected it to be. Google has it's quirks when it comes to forcing developers to conform to their own rigid guidelines for design, but this attitude seems to stem from striving for consistency across the platform. Google has thousands of articles/videos/diagrams out there for free, and they've created documentation for the Android SDK which is (usually) intelligible without needing a PhD in Comp Sci.
I not sure what to advise beyond that. I don't plan on only making Apps for Android, and I would advise that you don't either. Having a winning concept on multiple platforms is a key to making fat stacks of cash and kissing your day job good by. Also, you may have noticed how I left Microsoft mostly out of the picture. No offense, but if you want to do anything outside of getting a job with Microsoft, I wouldn't suggest going that route. Feel free to prove me wrong though!
What do I need to know in order to begin?
If you are familiar with Java, the following glossary probable won't be anything new to you. For others, it will hopefully provide a brief idea of same basics in programming Java:
IDE (Interactive Design Environment) - The program which you use to write/compile programs in. Either Eclipse or Android Studio, for the purposes of this tutorial (more on that later).
SDK (Software Development Kit) - As you'll begin to understand the more you get into programming, someone has already done what you are trying to do (90% of the time anyway). If you are trying to build a Cabinet, think of an SDK as both the tools and materials you would use to put it together. Instead of spending a few hours fashion a rock to a stick, just reach into the toolkit and pull out a fucking hammer. Absent the metaphor, SDKs are libraries of instructions which a device (Computer) may require to make sense of your code, and you require to avoid having to write everything from scratch.
JDK - Java's own big ass SDK, which includes a JRE (see below).
JRE - Java Runtime Environment. For anyone even vaguely interested in Comp Sci, you'll want to do more research into this. Put as simply as possibly, Computers are dumb file clerks (Richard Feynman: Computer Heuristics, youtube), and every different type more or less speaks a different language at its core (machine language). How then, could we write code for both a PC and a Mac, and expect both of them to understand it at all, let alone the same way? Java seeks to fix this problem by creating an interpreter for every different machine language, called a Java Virtual Machine (JVM). These small programs (JVMs, to be clear), convert your Java code (High Level) into Java ByteCode (or something like that), and then translate it into the appropriate machine language or some shit. Do your own research if it interests you.
API (Application Programming Interfaces) - Generally a library of code which is designed to solve particular problems. If the toolbox is the SDK, an API might be one particular tool, like a fucking hammer. APIs can be more versatile than my analogy may imply, but isn't there so many things you could do with a hammer?
Class - This is one of the more difficult concepts you'll come across, so don't be surprised if it doesn't make sense at first. In this case, 'Class' refers conceptually to a 'Class' of Objects. Classes are used to describe the specific structure (variables) and actions (methods) which define an object. What is an object? It is simply a class which has been created (instantiated). Again, don't feel bad if you read that a few times and it doesn't sink in, you'll come to understand Classes thoroughly once you start working with them (at least that's what happened for me).
Variable - Can be a single piece of data, like a letter of the alphabet, or even an entire class. Java calls a few specific types of variables as "Primitives", such as:
int - Integer, no decimals
char - Character
boolean - true/false
float - Decimal
long - Fucking big Decimal
a few others, you get the point.
Primitives start with lower case letters as you can see, whereas non-primitives are upper case by convention. The most common non-primitive you will see is the String class, which is a collection of char variables, more or less.
Method - This is the place where your program actually 'does' something. They always begin with a lower-case letter (numbers/symbols may be ok too, but I don't know why you would do that. Google it or something), and the name generally tries to describe what a method does. For example, the Mods at TL might have methods like banOnFlame(String abouToBeBanned) inside their brains.
Method Parameter - Variables which are passed to a method when it is called (or run). With the banOnFlame(String aboutToBeBanned) method, the variable inside the parenthesis is the Method Parameter. 'String' is the type of variable (Variable Declaration might be the fancy name), and aboutToBeBanned is what we are calling the id of the user who said "X player iz fagot..."
Method Overloading - In Java, it is acceptable to have multiple Methods of the same name, provided their Method Parameters are different. To use a very tired example, let's say we have a class called shape, which has two methods, drawShape(float radius), and drawShape(int length, int width). This class is capable of drawing either a circle or a rectangle (don't concern yourself with how
. As stated before, Computers can't think and require some way of knowing what shape to draw. We could add another method in the Shape class which accepts the variables given to it, then decides the appropriate drawShape() from there. However, there's no need for a middle-man in Java, as you can simply pass either one float variable drawShape(float); or two int variables (drawShape(int, int); the computer will be able to tell which drawShape to call. final - Sets a variable (which could even be a class) as a constant. I've read plenty of explanations on what declaring something 'final' does, but I've never heard of a good explanation of when/where you should use it (imo the biggest problem in learning programming). I get very frustrated when people try to explain these concepts by using as much jargon as possible (i.e. every Java tutorial created by Oracle), and I would greatly appreciate it if someone more informed than me could write out a clear functional definition for me to add here.
static - Again, I have yet to come across a definition which explains this concept clearly and when to use it. When a class is declared static, you don't need to instantiate it (using 'new') in order to access it. Let's say that I want to convert the value of an 'int number' to a String num. All I need to do is say num = Integer.toString(number), and viola. Integer.toString is a static method, which I can access without instantiating the Integer Class. You can declare both Variables (a.k.a. Fields) as static, or Methods, as above. Feel free to add to this.
Inheritance - Classes may have "sub-classes" created from them, which can create a sort of hierarchy of objects (for example, a Toaster Class might be the sub-class of a KitchenAppliance Class). There are a terms which you'll see here commonly. In the example of 'Toaster' being a sub-class of 'KitchenAppliance', the latter can be referred to as the Parent Class, the former child/inherited class. Learning how to use inheritance is incredibly important, but its also difficult to explain without code examples.
Package - Packages are useful for two things. They function as directories with which you can place your Classes appropriately. For example, I usually place my 'Activity' classes and 'Fragment' classes in separate Packages. Also, your App will have sort of a main Package name (I forget the fancy word for it), and this is used to uniquely identify your App. A package name should be something unique, so most people use sort of a website name like com.google.developer or something like that. Also, when you publish your App to Google Play, the URL to your App's download page becomes https://play.google.com/store/apps/details?id="PACKAGENAME"
Alright, I'll end the list there. It is in no way a complete list, but I tried to pick out the things which gave me the most pause when I began programming. I would suggest checking out Bucky's videos on his 'thenewboston' channel, or Vivz on his 'slidenerd' channel, both on The Youtubes.
Setting up your Workshop
Unfortunately, I'll only be describing the process you need to follow on a PC, but walkthroughs on developer.android.com should be able to help you if you are on a different machine. The first thing you'll need, is either a JDK or a JRE on your computer (if you are wondering why either is applicable, just get the JDK). I would suggest getting the Java SE JDK 7 from here (insert link). I'm not sure what the state is now, but when I started coding for Android, JDK 6 seemed to be recommended, 7 was probably fine, and 8 was not recommended. I use JDK 7, but use your own discretion. Download and Install whatever you grabbed. After that, you'll want to set your PATH Environment Variable, which sounded like some matrix shit the first time I heard it. As far as I can tell, it just lets your computer know where the fuck your JDK/JRE/Whatever is located. Honestly, just google a guide on setting Java PATH, you'll find better ones than I could be bothered to make.
After that is done, you'll need to pick an IDE. I started out with Eclipse, which proved to be the most infuriating experience I've ever had programming. Its one thing to spend a few days debugging your own code, its another to spend an entire week trying to stop your stupid fucking IDE from bricking your program every time you fucking sneeze on the keyboard. Look, don't get me wrong, Eclipse is a beautiful program and I would use it were I strictly working with Java. Its just not getting the support it needs (no shit, its open source competing with FUCKING GOOGLE), and Android Studio is no longer in its Alpha stages. Be wary of the date of any article comparing the two, don't forget that Android Studio was just recently given the go ahead as a full release, and I really can't find fault with it at this point.
You can find Android Studio here (http://developer.android.com/sdk/index.html)
There are plenty of guides which will tell you how to put together a simple App programmatically, so I'm not going to bother with that. Instead, I'll talk about conceptual ideas which I had missed out on when I started building my first App. Ask me and I will add things if I know the answers.
The Structure of an Android App
Android Apps, programmatically speaking, are comprised of the following components. Again, this may be an incomplete list, but it should more than cover the basics for you.
Activity - You can think of an Activity as being a particular screen of an App. Although you can change the 'look' of an Activity in Java, an Activitie's 'look' is generally defined by it's layout.xml file. What it 'does' is mostly handled in your Java code. You may be wondering as I did, when/where/why would you change the 'look' of the App in Java, and what it 'does' in XML? In a broader sense, its almost always easier/faster to change the 'look' of the Activity in XML; Also there are very few things you can do (functionally speaking) in XML. That being said, setting the title of a toolbar requires using Java to call something like toolBar.setTitleText(""), and you can specify what a View does when clicked by setting the onClick attribute in the views XML attributes. In summary, use what gets the job done properly, in the shortest amount of time, and leave it at that.
Fragment - Fragments are basically mini-Activities which have their own lifecycle (see below). When I say mini, that doesn't necessarily mean that their layout can't take up the entire screen, but most of the time a fragment will be used to manage a particular sub-screen or smaller portion of the broader activity. One example is a DialogFragment, which provides an easy way to create a pop-up dialog that can handle its own events. In a sense, you don't need to use them, as you could probably do everything you need to using just an Activity. Unfortunately, doing that would make your App a cringe-worthy nightmare of unintelligible sphagetti code.
View - Views are what you use to interact with the user. Anything from interactive widgets like buttons, sliders, check boxes (a.k.a. RadioButtons), to more passive elements like images and text labels. Although Android comes with close to anything you need for basic Apps, you can create your own custom Views or download fancier ones made by others if you wish.
ViewGroup - These are Views which can contain Children, such as the LinearLayouts. They afford you some control over creating hierarchies of Views, adding/removing them from specific places, and make changes that effect multiple Views without having to change them individually.
After you create an new Project, you'll notice a rat's nest of files with obscure names (welcome to software development!). Here's a quick overview of the directories:
res - This folder contains all of the XML resources your program will use, as well as things like Pictures, Videos, and Soundbytes you might use. There are certain folders you'll need to add manually to this one. For example, if you want to have a preferences.xml file for use with a PreferenceFragment, you'll need to create a directory labeled "xml", and place preferences.xml within it.
drawable - Here is where you will place the images you wish to use with your program. You can also create things like State Lists (let's say you want a button to change its color as the user touches it, that's where a state list would come in), or even shapes created by XML tags. You may also see directories labeled drawable-hdpi/ldpi/xxhdpi etc. DPI stands for Dots Per Inch, and l/m/h/xh stand for low/medium/high/extra-high. Lets say a user has a shitty phone with a low resolution, by placing low res images in the drawable-ldpi folder, the App should run smoother due to loading smaller images. In practice, the difference doesn't seem to really warrant the effort unless you are working with a large number of High res images to begin with (that's been my experience anyway).
layout - Layouts have somewhat of a double meaning. In a previous glossary, I spoke of the LinearLayout being a ViewGroup. In that context, it is a tag you add to an xml file to help you format and position views, among other things. The 'layout' directory holds XML files which describe what your Activities, Fragments, and Custom Views look like. You may also create a layout-land directory, where you can place your XML files which are to be used when the phone changes to landscape mode. In summary, a layout can either be an entire xml file, or it can be one particular ViewGroup type object within an xml layout file.
values - Contains a few important files, some of which you will need to add. You may also create values folders for multiple languages, such as values-fr (French), values-es (Spanish) etc. Both strings.xml and styles/themes.xml (described below) may be added to the values directory.
string.xml - Should contain just about every piece of text your program uses, inside of tags that look like <string name="derp_herp">Text Here</string>. Why is this necessary? If you have multiple Views associated with a single string, you need only change the String to change the text of all associated Views. Also, if you plan on having text for and multiple languages, you can just create another strings.xml file for each new language, packaged inside a values folder with the appropriate name (i.e. values-fr).
styles.xml/themes.xml - I still can't figure out the difference between these two; I only use styles.xml (since it works fine without the other). Working with styles/themes is quite complicated, but immensely useful the moment you get a grasp of them. They can change the default appearance of anything from the entire App, to individual properties of specific Views. I would suggest getting the hang of them.
AndroidManifest - This file contains information which is necessary for your App to run and for Google to accept it when you decide to publish. If you wish to access some features of the user's device, such as internet, reading/writing storage, camera, and so forth, you'll need to add them as permissions in the manifest. You'll also have to make sure there is an <activity> tag for each Activity in your App, which Android Studio will add automatically if you select New>Activity; otherwise you'll need to add it yourself. If your project does not use gradle, you will also have to specify the Application version name and version code of your App. Google Play uses this information to keep track of versions of your App when it gets uploaded.
build.gradle - Gradle is a tool which helps build your project (or something). It appears to make adding libraries (a fucking nightmare in eclipse) very simple, and it also takes over a few things that the manifest would normally cover, like versioning.
APK - Once your project is built, you should have an APK file of it floating around (it will end in .apk, and may say app-release.apk). If you want someone else to test your App, but don't yet have it published (or want to publish it for that matter), you should be able to email this file to them, and they can install it from there, just don't let it get into the wrong hands!
Your First Real Project
Quite early on, I realized that if I was going to keep any momentum whatsoever, I would have to work on a specific project and limit my learning to the problems I came across in practice. This is because despite my best intentions, I am naturally lazy and no good at rote memorization of facts, unless I know they will be useful/interesting to me. As such, I would suggest that you spend little time faffing around with the small fries, and begin to work on a project you will see from end to start, of your own design. It doesn't need to be complicated (shouldn't be, more like), and it can be something that was done before. The purpose of this project is a learning tool first and foremost, so be prepared to abandon it once you have the skills to back up a better idea. Here's a process I used to settle on what kind of App I should make. You can choose to follow all or parts of it, it makes little difference to me:
-Think of something you like, such as a favourite hobby, activity, or game. I chose my favourite hobby, picking heavy things up and putting them down. Side note: If you plan on making money with this App down the road, pick something that has some kind of an audience.
-Think of some simple App which might be useful to this particular thing you enjoy. I decided to make a Workout Log, since I needed to start doing that anyway.
-Now that you have an idea for an App, make it as simple/basic as possible. What is the simplest thing that an App could do and still be complete with respect to the idea you've settled on? WRITE IT DOWN! Mine looked like: "The user is able to input the name, reps, weight, and sets for each exercise. This user input is then saved in some kind of format, viewable at a later time."
-Decide on a deadline for an Alpha version of the App. As I see it, an Alpha version simply needs to fulfill the above statement and not crash along the way, you worry about aesthetics in later iterations. If you're not sure what the deadline should be, I would shoot for no less than two weeks (if you've already built software, or your idea is very simple), and no more than six weeks (if you are brand new). I settled on one month, as I was working full time and had no idea how long it would take. Generally speaking, the work will shrink or expand to fill the deadline, as is human nature.
-Start designing!
Design on Paper
This is one of the most important lessons I learned, and I now always start out new ideas/designs on paper first. Now before you tell me that you can't draw for shit, I can't either. Not only do I have no artistic talent (never practiced drawing), but I was born with hand-tremors, making things even worse. Grab a pencil, ruler, a tall glass of STFU, and start drawing something. I should note that there are actually a few drafting programs which could probably do the job, but I find pencil and paper to be a much more organic process. As long as you have something visual to start work on, you'll make fucking around with the Graphical Editor much easier.
Make a list of the Activities you're App will need, and give them names describing what they do. In my alpha, I had three activities labelled HomeActivity, InputWorkoutActivity, SaveWorkoutActivity. You can probably tell what their respective jobs were.
I then like to begin writing out the functions of each View for the particular Activity/Fragment I'm working on. I'll then draw a rough screen shape, and start to place things vaguely where I want them. It doesn't need to be more complicated, and it doesn't need to look pretty. It just allows you to conceptualize the finished project, which helps to keep you from quitting once you see how frustrating the Graphical Editor can be. The following is an actual design sketch from my first App, which should give you a visual idea of what I'm talking about.
[Will add soon, phone is being repaired]
"What if I have no idea how many Activities I will need? What if I don't have any idea what its supposed to look like?" My first answer is for you to download a few Apps and see what they look like. That should give you a decent starting point. Failing that, wing it. Seriously, you can't let anything stop you write now, do something even if its wrong! At the end of building my Alpha, I had learned enough to know that it was a hideous piece of shit, so I rebuilt it from scratch. At the end of the beta, I was very unhappy with how it looked so I rebuilt 80% of it again. Although I've put the project on hiatus until my current App comes to fruition, I'll be rebuilding Catalyft again, and will continue to do so until it is the best Workout Log on the market. No one expects a first-year shop student to build a Parisian Armoire for their first project, why should you expect to build the next top 5 App first go around?
Debugging
In Android Studio, you'll notice a console window labelled "logcat". Whether you are using an actual device, or an emulator, when something goes wrong it will hopefully show up here. Here's a quick primer on understanding what logcat has to say. I've pulled this error log from this question on Stack Overflow [http://stackoverflow.com/questions/16164353/android-nullpointer-exception]:
FATAL EXCEPTION: main
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.datumdroid.android.ocr.simple/com.datumdroid.android.ocr.simple.SimpleAndroidOCRActivity}: java.lang.NullPointerException
//the log usually starts by telling you that something has fucked up, and where this fuck up has occured. In this case, the Activity called SimpleAndroidOCRActivity failed to run properly, because something in it threw a NullPointerException. Don't worry about what that means, I'll explain it later. After reading this, you'll want to find entries which start with "Caused By:". These will generally tell you where and what the fuck happened.
Caused by: java.lang.NullPointerException
at com.datumdroid.android.ocr.simple.SimpleAndroidOCRActivity.onCreate(SimpleAndroidOCRActivity.java:68)
If the line following the 'Caused By' entry starts with the package name of your app (this one is com.datumdroid.android.ocr.simple), it will also tell you which Activity/Class (SimpleAndroidOCRActivity), followed by which method within said Activity/Class (onCreate), and finally which line in the Class file the error occurred at (java:68). If you're IDE doesn't already display line numbers, make it so via File>Settings>Editor>Appearance>Show NumberLines (in Android Studio). Pretty freakin' sweat eh? Unfortunately, at times logcat will give you next to nothing useful. I was recently working with the PreferencesFragment class, and got an error which threw me for a loop [http://stackoverflow.com/questions/28093883/preferencefragment-crashing-null-object-reference]. Luckily, someone smarter gave me enough of a hint to figure it out.
Another nifty way of debugging is to use Log.d to add your own messages to logcat. Its difficult to get into how amazingly useful this is without diving into some coding examples, but here's a few conceptual ideas:
-You can check the value of a particular variable just before it seems to cause a crash. Use things like Integer.toString(int) to convert values, as Log.d only accepts Strings.
-If you get a particularly unhelpful error message, you can use logcat to figure out the exact point where your program is crashing (hopefully anyway) . I'll set a bunch of messages to display at various points of the program, such as "Check One", "Check Two"...you get the point. If Check One appears, and Check Two doesn't, I know that the program is crashing somewhere between.
-You can place messages inside of Control Statements (like if else) to see whether certain conditions are triggering or not. I usually will write something like Log.d("TAG", "Something is fucked"). This can create amusing situations when I forget to remove these logs, and one of my users has an App which records them on their phone.
In order to use logcat, you simply write Log.d("TAG", "Message"). TAG can be whatever you want, its just allows you to filter messages to particular tags, making things more legible at times. Message is of course whatever you want to display, and it must be a String.
Here's a few of the more common errors you will see, and what I've found to be the causes:
NullPointerException: As far as you phone/IDE is concerned, something doesn't exist. Its kind of like this: You are one of the three people who still uses telephone books. You go to look someone up so that you can call them, and on the line they are supposed to occupy, there is a black hole singularity which suddenly pulls you and the rest of the solar system inside of it, turning you into spaghettini. In Android, this generally occurs because you've either tried to assign something that hasn't been created yet (it's probably been placed in the wrong LifeCycle method), or you've just failed to create an object before trying to do something to/with it. If an object doesn't already exist, you will either need to use the 'new' keyword, as in "String s = new String("");", or some getInstance() type deal if its a static class.
IndexOutOfBoundException: If you are working with arrays and array lists, you'll probably see this at some point. Something that is frequently forgotten (I include myself) in Java, is that while the FIRST element in an Array or ArrayList may be referred to as such, it's INDEX is 0! In other words, the Nth element occupies an index of N-1 in the given collection (Array, ArrayList, LinkedHashMap, etc.). What causes the error? Lets say you tell your App to grab the third element in an ArrayList, by calling "arrayList.get(3)". At best, this will make the Array return the FOURTH element, as it has an Index of 3. At worst, the ArrayList has only 3 elements in which case the App will shit itself. Make sense?
So, if my list doesn't cover every problem you get ever for some strange reason, your best friend will be StackOverflow. This magical website will answer 90% of your questions, and allow you to ask the 10% that it doesn't for free! The difficulty is rarely whether something has been asked before, but rather finding the appropriate way to word the question. Also, they don't like morons, so if you've been on this forum long enough, you should get along with their community just fine.
Setting up Ads
Most commonly, there are two ways that people make money with their Apps. You can charge an up-front price do download it, or you can populate your App with advertising (You can even do both if you want to alienate your users). I've chosen the ads route for a few reasons. I would rather have more people using my Apps even if it meant making less money (which may not be the case anyway), because I want my Apps to be accessible and helpful to as many people as possible. Its my belief that helping people may be a longer and more difficult path, but the payoff of integrity and loyal customers is well worth the difference of dollars. Also, even if I was a greedy son of a bitch, I wouldn't charge people for an App unless it was spotless, innovative, and useful on a Daily basis. While I'm striving for that, I simply need to become a better programmer before I can get there. Lastly, Android users are more used to free Apps, whereas Apple users are used to paying out the butt for everything; target your audience.
While setting the upfront cost is as easy as setting about two things in Google Play, setting up Ads is a lengthy and complicated process. Before you begin, you will need to create an AdMob account. If you wish to use a different Ad provider, then you are on your own, and can skip this part. Making an AdMob account requires a gmail account and a 'valid' bank account where they will deposit your impending fat stacks. This process is better explained by AdMob, so follow their instructions.
The next step will be adding the Google Play Services library to your project. If you haven't done so already, open up the Android SDK Manager in Android Studio, and install the latest version of Google Play services, under the extras tab. Now, if you are using gradle, the next step simply requires you to open 'build.gradle', and under the dependencies tag, add "compile 'com.google.android.gms:play-services:6.5.87'". The last few digits are the version of play-services you are using, and I still don't understand why they can't make it easier to figure it out. Good luck finding it when it changes. You'll also have to add an entry into the AndroidManifest file, inside the application tag. Add
<meta-data android:name="com.google.android.gms.version
android:value="@integer/google_play_services_version" />.
Finally, add another Activity tag in the manifest as follows:
<activity android:name="com.google.android.gms.ads.AdActivity"
android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize"
android:theme="@android:style/Theme.Translucent" />
Before you go ahead, you'll want to decide the type of Ad you wish to display. So far, I've opted to only use Banner Ads, since I find interstitial (Full Screen Pop-Ups) to be annoying as fuck, but that's just personal bias. I've read that you make more money using interstitial. Now you can create some Ad Unit IDs. Log into AdMob and click on the 'monetize' tab. If for some reason your App is already published, search for it. Otherwise, click the 'Add New App' tab and input your App's name and platform. It doesn't matter that it hasn't been uploaded at this point (it didn't for me anyway). You can name the Ad unit(s) something relevant if you like, such as "Bottom Banner Main" or what have you. Copy down the ad Unit ids, you'll be adding them to your strings.xml file in a bit.
Open up the layout file for the Activity which will contain the Ad, and put one of these in:
<com.google.android.gms.ads.AdView
android:id="@+id/ad_View_Main"
android:layout_width="match_parent"
android:layout_height="wrap_content"
ads:adSize="BANNER"
ads:adUnitId="@string/banner_ad_id_main" />
If succesful, you should see a banner sized placeholder where you want the ad to appear. I haven't used interstitial ads so I don't know how the process differs. Also note that if you have a layout-land folder, you will need to ad another one of these AdViews to the appropriate layout file in layound-land. Finally, you should be able to put the ad Unit ids into your strings.xml file. Here's what I added:
<string name="banner_ad_id_main">ca-app-pub-0000000000000000/0000000000</string>
The last step is to punch in some code so that you're Activity knows what the fuck is going on. Open up the appropriate Activity's Class file, and ad this inside of the onCreate() method:
AdView adView = (AdView)this.findViewById(R.id.ad_View_Main);
AdRequest adRequest = new AdRequest.Builder().build();
adView.loadAd(adRequest);
Unless I've derped and forgotten something, that should be all you need. Keep in mind that these processes seem to constantly change, so if something seems completely different than what I'm talking about, assume that I made the entire thing up to confuse you, and search for another guide.
Making a Google Play account
Just do what it says here.
Publishing
At this point, you're almost done. Google Play requires you to create a signed APK file of your App. Its a security measure which helps to prevent others from fraudulently uploading your shit. Check out this link and do what it says for Android Studio users.
If you followed the detailed steps in the previous section (HAH), you should have a Google Play Developer's account. Open your Developer Console by searching "Google Play Developer Console." Click on the "All Applications Tab", and Hit "Add New Application". You can begin upload the APK file at this point, don't worry, it won't be published/visible until you've fulfilled some basic requirements for the store listing. Google will tell you how far along you are in the process, and what needs to be done before you can Publish. I'll cover a few things you may wish to know, but things are pretty self explanatory at this point.
Filling out the Store Listing can take quite some time, especially if you haven't prepared any graphics. Here's a few tips/tools I used to make the experience less painful:
If you are like me and don't listen to those people who tell you to get professional help with that kind of thing, I would suggest downloading Gimp (photoshop works if you have it already), and checking out "openclipart.org" for free graphics. Gimp is a pretty awesome open source Photo editing program, and most of my graphics in it. Otherwise, there are some websites which you can use to pay artists for graphics and such, which might provide a more polished presence for your App. I haven't done much research, but fiverr.com seems legit. I'm not affiliated with them and I haven't even used them yet, but I probably will once I can afford to.
For your App Descriptions, keep in mind that Keywords within them are one of the most important factors of whether your App gets exposure or not. If applicable, look through the descriptions of some of your competitors and take note of any relevant keywords which they share. Those suckers have usually done the work for you.
Most phones have some way of taking screenshots. My Nexus 5 requires me to hold down the power button and volume down button at the same time for a moment. Take a few screens and email/copy them to your computer.
Privacy Policy - For the moment, you don't have to upload a privacy policy. This will probably change soon. At the moment, I'm putting together a Privacy Policy by using one supplied by the Mobile Marketing Association. Its a bit of a process to get to, but somewhere on that site, they have a PDF version which should help you create at least some kind of a Privacy Policy. I'll be getting proper legal advise down the road, but the MMA's is something at least.
Congrats if you made it all the way through. As I said at the start, I'll be adding to this guide over the next few weeks, so please ask questions and give me advice/comments/criticism so that I can make it a better resource. Also, if you gain something useful from this guide and want to give thanks, you can support me by downloading, using, rating, and reviewing my App Posture Prod. Its a simple App which is designed to help people like us who sit in front of Computers all day, not have fucked up postures.
