The APKBuilder Era: Everything Boilerplate, Nothing Abstract

Every Android activity started the same way. You opened a new file, and you typed the same lines again — package declaration, import statements, the class signature extending AppCompatActivity, the onCreate method, setContentView. Every single time. By hand.

No snippet. No template. No IDE that offered to generate it for you. APKBuilder gave you an empty file and a cursor. The rest was you.

What APKBuilder was — and what it was not

APKBuilder is an Android app that lets you write Java code and compile it into an APK directly on-device. For what it was, it was remarkable. The fact that it worked at all — that it could take Java source code typed on a phone keyboard and produce a real, installable Android application — was genuinely impressive.

What it was not was forgiving. The feature set was limited. The editor was basic. There was no refactoring, no intelligent autocompletion, no error highlighting while you typed. You wrote, you compiled, you found out what was wrong. Sometimes the error messages were clear. Sometimes they pointed at a line that was not the actual problem.

The limitation that drove me the most was the library support — or more accurately, the lack of it. External libraries were either not supported or painful to integrate. Which meant that anything an external library would normally do, I had to write myself. No RecyclerView adapter boilerplate generated for me. No networking library handling HTTP. No image loading library. If the app needed it, I built it.

At the time this felt like a severe handicap. In retrospect, it was a kind of education that most developers now skip entirely.

Java one moment. Android the next. Constantly.

The hardest conceptual problem in those early months was not any specific Java concept or any specific Android component. It was the constant switching between the two.

Java is a general-purpose language. It has classes, objects, interfaces, inheritance, generics, exceptions, collections, threads. Android is a framework built on top of Java. It has activities, fragments, intents, views, adapters, services, broadcast receivers, content providers, the manifest. They are different bodies of knowledge that use the same syntax but operate on different levels of abstraction.

When you are reading a tutorial app that mixes them together without distinguishing which is which, and then you go into APKBuilder to try and apply what you just read, the confusion compounds. You are not sure whether the problem is your Java or your Android. You fix what looks like a Java error and produce an Android error. You fix that and hit a different Java error. You lose track of which level you are supposed to be thinking on.

There was no one to ask. I was at Mzuzu University studying Forestry. The people around me were interested in trees and land and ecosystems — not in why ListView needed an ArrayAdapter and why that ArrayAdapter required a specific constructor signature. I worked it out by writing code that failed and reading why.

The apps that came out of it

Despite the constraints — or because of them — I shipped things. Not impressive things by any external measure. But real things, installed on real phones, used by real people.

I built computer skills apps for friends — simple offline reference tools with notes on computing concepts. I built personal utility apps. A quiz app. Small tools for things I needed to do repeatedly that I could automate with three screens and some SharedPreferences.

What they all had in common was that every component was hand-written. Every ListView had a custom adapter written from scratch. Every screen transition was an explicit Intent. Every data save was explicit SharedPreferences calls. There were no abstractions I had not personally authored. I could trace every line of every app back to a decision I had made.

That is an unusual relationship to have with your own code. Most developers today, working with modern tools and libraries, could not tell you what is happening two or three layers beneath their abstractions. I had no layers I had not built. I knew exactly what was happening because I was the one who wrote it happening.

The point where APKBuilder ran out of room

There came a point where the tool could not keep up with what I wanted to build. Not because I had outgrown Android development — I was just getting started with that. But because the apps I was imagining needed things APKBuilder could not provide cleanly. Better layout support. Better project organisation. The ability to use external libraries when the standard SDK genuinely did not have what I needed. Better error messages.

That ceiling was frustrating. I had learned as much as I could within the constraints of the tool, and now the tool itself was the constraint. I needed something better. Not a laptop — I still did not have one. Something better that still ran on the phone.

That frustration is what eventually pointed toward NexaIDE. But before that, there was one more thing the APKBuilder era produced. The most personal project of that whole period. The one that came directly out of the combination of bad tutorial apps and limited tools and the specific frustration of learning Android on a budget phone in Malawi.

That was JavAndroid.