They are imports that let you use other packages in your project. Somewhere, there’s a .java file with the package name “com.google.appinventor.components.common.ComponentCategory”, and you’re importing the public methods and fields of that file into yours.
This is where the directory structure @Shreyash was talking about comes in handy. You can expect the file (in this case, ComponentCategory.java) to exist in com/google/appinventor/components/common/
And you would be right in assuming so: appinventor-sources/ComponentCategory.java at master · mit-cml/appinventor-sources · GitHub
If you click on the link, you’ll see there are other .java files in the folder alongside ComponentCategory.java. Suppose you wish to import all of them into your file, you’d use something called a wildcard import. That’s what these lines are:
You’re effectively importing all files inside com/google/appinventor/components/annotations
and com/google/appinventor/components/runtime
. More on wildcard imports here: Everything You Need to Know about Java Packages and Import Statements
Similarly, these files are present in android/content/Context
and android/util/Log
. But you won’t find their source code (.java files) in the App Inventor repository. This is because they’re provided by Android and are not specific to App Inventor. (Also note the importance of picking the right package name here. Since the package name in the case above starts with android
, we can assume it’s part of Android’s standard library. And the others have com.google.appinventor
, which indicates these files are part of App Inventor’s library. (You might wonder why it isn’t com.mit.appinventor, and that’s because these files were originally written by Google. It’s hard to rename packages without breaking compatibility, especially with third-party code, which is why the original package names have probably been retained))
But the source for these Android files surely must exist somewhere… the compiler can’t fetch code from thin air. You’re right, and Java solves this problem by letting us build .jar files. .jars are packaged .java files. They contain executable code (bytecode, if I’m being pedantic) generated from your source code. Google provides one such .jar for the Android library which App Inventor uses in its components. You can find it here: appinventor-sources/android.jar at master · mit-cml/appinventor-sources · GitHub
Further reading on bytecode and libraries if you’re interested:
Java bytecode:
JAR File Overview
Java bytecode - Wikipedia
Some of these imports are essential for your extension to work, while some are optional and depend on what you wish to do with your project. For example, if I were to make a Twitter extension, I’d first look for a .jar supplied by Twitter that contains the endpoints I can use (say, TwitterAPI.sendTweet(…)).
I then download this .jar and add it to my extension. (This is not possible with the online IDEs, by the way. You have to use the extension template or AI repository to include libraries in your project that App Inventor doesn’t already provide). Finally, I import the Twitter packages into my project using the import
keyword.
Tip: Avoid wildcard imports as it makes it harder to track where certain parts of your code are coming from. It’s rare that you would want to include all files in a folder. Use it only when needed. java - Using the wildcard when importing packages - Code Review Stack Exchange