App Inventor Overview
Some of the code in this wiki is outdated. Check the latest source code (.aia file) for the latest code available.
Once you've opened App Inventor, and imported the latest release of the app's source code (decompiled-releases > aia > exoplayer[release #].aia), you'll land in the first screen of the project, which contains almost 3000 blocks by itself (Wowza!, that's a lot!) It might seem daunting, but here's an overview.
Use the ExoPlayerCore1.AddMediaItem block to add media items. They can be videos, or playlists. The select item in list block is used for playlist handling to add each URL as a separate media item. ExoPlayer takes note of this and allows for choosing a video to play in the playlist.
This code checks if a playlist already exists in the TinyDB database with the same name, or else uses the TinyDB database to add the contents of 7 textboxes (URLs) into a list (playlist, which is saved by TinyDB so it can be retrieved later. TinyDB is used in many apps, for example in video games, TinyDB is used to store offline save data, specifying how many characters you have unlocked, how many levels you have progressed through, etc, etc. The TinyDB components all share the same namespace so data from the playlist screen can transfer to the main screen, as they are using the same database.
This code checks if the playlist already exists, if so, loads all the data in the playlist and sets each TextBox's text to a playlist item (URL 1 goes into TextBox1, and so on). The save playlist button is replaced with an identical copy that when clicked, overwrites the old changes and replaces them with the new ones in the same tag in the TinyDB database, by storing the data in a local variable beforehand.
When the Open Playlist button is pressed, this code asks for a text input of a playlist to load. Then it sets the input to a global variable (playlistName) for reuse of the playlist's name in the future to load in ExoPlayer, and then checks the input against a random string. If the inputted name links to a tag in TinyDB that does not equal to that random string, it sets a variable called usePlaylist to one, which means that ExoPlayer can load the playlist and uses the playlistName variable to load it from a TinyDB tag.
In the latest version, this button shows a list of playlists that exist (in the "playlists" TinyDB tag) through a ListPicker. This is much more efficient and is also how the Edit Playlist and Remove Playlist buttons work as well since mid-3.x.
The code above is a snippet of handling which player is selected and how to create a player. The Spinner1.Selection blocks (now Spinner1.SelectionIndex blocks in some other sections), are used to identify which player has been selected. The createExoPlayer function is a large function that handles ExoPlayer playlists, passing in media items to ExoPlayer (with or without subtitles), handles whether or not ExoPlayer uses the simple UI, and handling video/audio files as well.
Available options are handled in this long series of if conditions. The visibility of available options is changed according to what is possible. For example, VideoView does not support URLs in App Inventor, so URL-related options are hidden when VideoView is selected.
Open the exoplayer project, and look on top. You should see a menu. Click on Build.
Click on Android App (.apk) if you're not uploading your app to Google Play. Apps compiled this way require the user to enable Unknown Apps on their device unless you choose to upload your APK to Google Play. The process of doing this is different depending on your Android manafacturer (it is different on Samsung, Xiaomi, Google, etc).
Warning
PLEASE note that it is heavily recommended to compile your app as an AAB instead if uploading to Google Play. The app will be smaller to download and will also have better performance.
Click on Android App Bundle (.aab) if you're uploading your app to Google Play.
AAB files can't be installed on a user's device, rather they are files that Google Play uses to generate optimized APKs. Optimized APKs are much smaller than un-optimized APKs exported using the Android App (.apk) option.
Un-optimized APKs are meant to work universally on every device, so they have to generalize performance, etc, to a certain degree that will work decently on all devices, not super-spectacular or anything, so as your app gets more complex, the more bloated your un-optimized APK will be.
Optimized APKs don't generalize performance and instead hone them in to each phone manafacturers' strengths and weaknesses to get the best results.