So my physical maladies are waning at the moment and I found an old Android Tablet (Asus Eee Pad) of my nephew's that he doesn't use anymore, and have been playing some free Apps and got interested in development, especially since Android is basically a physical Java environment and I'm comfortable with the Javascript that Sphere uses.

Operating under the assumption that Android development is all basically free, that I can simply download an SDK, write some code, root my device and run it on it, I'm...downloading the SDK and following the official "Build your first App" class on the Android site.

Since there's no other topic about mobile devices or such, I figured I'd start one and share my journey (and almost certain failure). But we can use this as a general app-discussion topic. iOS is fine, too, I just won't be doing anything with it since I'm almost certain it costs $$$ to even download the SDK and run your own programs on your own device (if you're even allowed to do that at all).

Hey Mooch, good to see you back!

Android development is fun. I haven't actually done it before, but the process doesn't look intimidating at all. iOS development I have done before and it's a pain in the ass. You need to purchase a developer license to put your code on a device. This means also registering your developer account to your dev machine AND to the device. It makes it hard to have open collaboration on the software you write since everyone involved needs to go through the same steps to be allowed access to build/deploy/test.

These days I make mobile responsive websites where I work, so the only "app" or smartphone development I do is anything involving a browser, which can be pretty dang powerful. And since there are no license fees and headaches, most usually you can build killer web apps for next to nothing and potentially make loads of cash on them when you sell them. Especially if they are a subscription based service.

Thanks!

Good to hear Android development's so painless -- I might actually stand a chance. I guess all that iOS hassle is why Android's taking over the market. Whichever platform is the easiest to develop for is what tends to garner the most developers (see: Playstation vs N64).

So are you making loads of cash? Heh.

Ugh, finally! The Android SDK (with custom Eclipse install) just finished downloading. I'm turning in for the night, though, so I'll take a gander tomorrow. Maybe. I wanna do a simple Sphere game to get my head back in the game. Something like a barely-interactive Progress Quest; nothing but displaying text and clicking buttons (since all my more-complex projects have failed to get off the ground due to my laziness and, well, crappy body).

I've done a little Android development.

The two main tools are the SDK (which includes the debugging tools and the simulator, which is a mixed bag) and the NDK. The SDK also includes the Java setup, while the NDK is an entire native toolchain for Android. You could really use either mainly, depending on whether your program is mainly Java/JVM or native based. You'd still need the tools in the SDK anyway, though.

They are both free, and don't even require a Google account to download or use, since all the associated tools are open source. They even work on OS X, Linux, and FreeBSD. And I can tell you, you will save yourself a bunch of time by using a Unix system. But it all works on Windows, too.

Getting things started is a little tough I found. I didn't use Eclipse, instead I just wrote the spec files by hand, and used the NDK and SDK as builders form SCons. That's probably not the easy way if you are starting a project from scratch, though!

Speaking of Android development, lately I've been messing with HaxePunk. It uses OpenFL and Haxe to allow you to write a game once and then run it on Android, iOS, Windows, Linux, OSX, Flash, HTML5... It's rather crazy how much it supports. Some commercial indie games have been made with it and the language looks a lot like JavaScript. Excellent for games. Perhaps it's worth looking into for you, too.

I've done a little Android development.

The two main tools are the SDK (which includes the debugging tools and the simulator, which is a mixed bag) and the NDK. The SDK also includes the Java setup, while the NDK is an entire native toolchain for Android. You could really use either mainly, depending on whether your program is mainly Java/JVM or native based. You'd still need the tools in the SDK anyway, though.

Native based? As in what? I thought everything that runs on Android is Java. Or do you mean raw ASM or ARM or whatever Android devices use?

They are both free, and don't even require a Google account to download or use, since all the associated tools are open source. They even work on OS X, Linux, and FreeBSD. And I can tell you, you will save yourself a bunch of time by using a Unix system. But it all works on Windows, too.

Why'll I save time using Unix? Aside from Windows being obtuse and crash-prone.

Getting things started is a little tough I found. I didn't use Eclipse, instead I just wrote the spec files by hand, and used the NDK and SDK as builders form SCons. That's probably not the easy way if you are starting a project from scratch, though!

Well, I'm just gonna follow the android.com tutorial for now, just to get my feet wet, and it uses Eclipse. But down the line yeah, I'll probably do something a bit more advanced.

Speaking of Android development, lately I've been messing with HaxePunk. It uses OpenFL and Haxe to allow you to write a game once and then run it on Android, iOS, Windows, Linux, OSX, Flash, HTML5... It's rather crazy how much it supports. Some commercial indie games have been made with it and the language looks a lot like JavaScript. Excellent for games. Perhaps it's worth looking into for you, too.

O_O

That sounds...friggin' awesome. And I do likes me some Javascript.

*googles*

Oh. It's Flash. Mmm. Not a huge Flash fan. Still neat though.

It's not Flash, that was just the first export target Haxe supported (before all the others). It'll export natively to all the target platforms I mentioned (that means you can make a .exe, .swf, .apk, html etc. of the exact same thing that'll run on its appropriate platform). Main downside is no native widget on any of them as a result, but that's fine for games.

Native based? As in what? I thought everything that runs on Android is Java. Or do you mean raw ASM or ARM or whatever Android devices use?

I worked on Firefox for Android, and later I did a couple little silly apps (a note pad and a calculator), all in C++. The NDK lets you use any language that GCC supports (I think, I can only verify C and C++), but you then need to write just a little Java and use the JNI interface. I was comfortable with this because a portion of my Firefox work included working on and improving a JNI binding generator.
I chose this because I am more comfortable with C++ and C than I am with Java, but I still know enough Java to make writing the shim easy.

Why'll I save time using Unix? Aside from Windows being obtuse and crash-prone.

Because the SDK tools are designed to work most natively on Linux (and to a lesser extend all Unices), and a nicer terminal environment (which almost all Linux setups have, just by having Bash, Ash, or Zsh) will be helpful. But it's not a deal breaker. If you are comfortable with Windows most, you should probably use Windows.

Whew, sorry to disappear there. Didn't start my studies yet, been busy. I'm gonna jump into it all now (following that android.com tutorial), and I have sort of a big question, even if it's getting ahead of myself.

What do I do with Github?

Open-source stuff is always hosted on Github, they say, "this program is open-source, here's the Github link." But the Github link typically has like, nineteen different things, and none of them are obviously labeled as "the source code," and even when they are it just downloads like, random weird files that don't actually look like anything and that I can't seem to open and that are typically so tiny I doubt they could possibly be the source to anything, anyway.

Take Pixel Dungeon for example...
https://github.com/watabou/pixel-dungeon
...what, exactly, am I even looking at here? What do I click on? What do I download? It's all so confusing.

Well, in the meantime, I'll go give that android.com tutorial a whirl.

Take Pixel Dungeon for example...
https://github.com/watabou/pixel-dungeon
...what, exactly, am I even looking at here? What do I click on? What do I download? It's all so confusing.

Well... you are looking at files on a virtual file structure. You can open the folders to see more files. The game is written in Java, and it's apparent that the source code is inside of src/com/watabou/pixeldungeon. The files you see that are "too small to be source code" are in fact random files, such as a readme, license, and a .gitignore which are standard files anybody would put into a basic git repository (at the root folder). So, yeah, what you are seeing is a list of files.

Source code repositories are like DropBox, right, so they are a place to put files. But it's more than that since you have a history, a "commit history" that has the changes and an explanation for each commit. The files you see on github are the latest files on that branch. The default branch is master. Git and other repositories use a tree structure to track all information. Branches of this tree can be made at any time, deleted, or merged. They can even be merged into master, which some system also call the "trunk" because like any decent tree, you gotta have a trunk.

Systems like these were made as metaphors of trees since it's easier to visualize them that way. Just like your filesystem. So that's what you see there.

Github for windows can make it really easy to get git up and running. There are plenty of git tutorials out there. Once you do have a git repo it's up to you to commit. I usually commit whenever the features I set for myself have been coded out, but some people do it daily or for every little change. It's up to you how you want to commit and sync (don't forget to sync a git repo because commits are stored locally until you push them online, this is different than say, how SVN does things (another code repository or 'subversioning' system)).

Take Pixel Dungeon for example...
https://github.com/watabou/pixel-dungeon
...what, exactly, am I even looking at here? What do I click on? What do I download? It's all so confusing.

Well... you are looking at files on a virtual file structure. You can open the folders to see more files. The game is written in Java, and it's apparent that the source code is inside of src/com/watabou/pixeldungeon. The files you see that are "too small to be source code" are in fact random files, such as a readme, license, and a .gitignore which are standard files anybody would put into a basic git repository (at the root folder). So, yeah, what you are seeing is a list of files.

Source code repositories are like DropBox, right, so they are a place to put files. But it's more than that since you have a history, a "commit history" that has the changes and an explanation for each commit. The files you see on github are the latest files on that branch. The default branch is master. Git and other repositories use a tree structure to track all information. Branches of this tree can be made at any time, deleted, or merged. They can even be merged into master, which some system also call the "trunk" because like any decent tree, you gotta have a trunk.

Systems like these were made as metaphors of trees since it's easier to visualize them that way. Just like your filesystem. So that's what you see there.

Github for windows can make it really easy to get git up and running. There are plenty of git tutorials out there. Once you do have a git repo it's up to you to commit. I usually commit whenever the features I set for myself have been coded out, but some people do it daily or for every little change. It's up to you how you want to commit and sync (don't forget to sync a git repo because commits are stored locally until you push them online, this is different than say, how SVN does things (another code repository or 'subversioning' system)).

I was actually just coming to change/delete my last post, heh. I downloaded the entire thing as a zip, unzipped it and started poking around the files with Notepad++. Thanks, though.

Unfortunately, the code is not commented. At all. From the few files I poked around in, there wasn't a single comment aside from the "this is open source licensed under the GNU" boilerplate at the top of every file.

I was hoping, somewhere down the line, to use Pixel Dungeon's code as a basis to play around with a point-to-move top-down game, but there's virtually no chance I'll be able to tell how the code works just from looking at it. I can't even tell which file is the "main" file or how it runs, in a fundamental way. Like, if I take a look at the main.js file of any given Sphere project, I can get a basic idea of what it's doing and how it's doing it, but those Pixel Dungeon files...

To be fair, I'm somewhat familiar with Sphere and not at all with Java or Android, but still.

At the very least, I can change the graphics, and I should be able to change any numerical or nominal data (enemy HP and names, for example) so I could tweak things for personal use. Though the main thing I want to do is get rid of the item degredation code, heh. (watabou introduced it two updates ago and everyone hates it, but he's not backing down.)

All that's getting super ahead of myself, though. The Android Studio just finished downloading (the android.com tutorial recommends it -- funny, just December it recommended Eclipse) so I'll start following the tutorial next time I get on the computer. Right now, my goal is just to be able to follow along with that.