Welcome back, appdev initiates! If you’re like me, you’re more than ready to increase your app development skills. As mentioned previously, the 800-pound gorilla of online open source projects is GitHub. There are several Git-based choices in the marketplace, but for our purposes, we will use GitHub for this column, with the upside being that all of the projects, and mistakes, will be available to the community to view, give comments, and improve.
The good news for Android Studio is that it treats GitHub as a first-class source code repository host, that is to say, you can make other hosted Git providers work, but it’s just not quite as slick. This only means that if you choose to go your own way with something other than GitHub as your source control tool of choice, then we’ll leave it as an exercise for you, dear reader, to complete and let us know how it goes in the ODROID forums. With that, let’s connect the IDE with our hosted source control provider.
Get on GitHub
If you look back at the code in our last installment, it was very basic. It took Android Studio only a few moments to construct it, and then we had a project folder complete with build scripts, app code, and layout files. The downside of all this automation in integrated development environment tools is that it creates a lot of files, and keeping track of them (and the changes that get made to them) can be a big headache. This is where hosted sites like GitHub really help, because they allow you to keep a backup of all of your precious code files, ready to be recalled in case of disk crashes, equipment loss, or any number of other pitfalls. So, starting with the project we made last time loaded into Android Studio, we can head up to the “VCS” menu, select “Import into Version Control” and select “Share Project on GitHub.” If you haven’t already gone through the process of creating a GitHub account, which was mentioned last time, now’s your chance.
Once you have the account confirmed and set up, you can come back to Android Studio and inside the “Login to GitHub” dialog, select “Password” for Auth Type and enter your username and password. You will then be shown the “Share Project on GitHub” dialog, which lets you change the repository, or “repo”, name, remote name and description. For now, leave the repo name and remote name alone, and you can put in a simple description for the project. I chose something simple, like “My first Android project”. You can then confirm which files will be initially sent to GitHub, it’s fine to accept the default set, and click “OK”. In a few short moments, you’ll be greeted with the notification that your project is now on GitHub. You can click the link in the notification and check out your online source code.
The Most Basic App Ever Made™
With all the fuss about getting our code into version control, we really haven’t spent much time looking at what Android Studio generated for us. Let’s do that now. In creating this app, Android Studio generates a lot of files, but only a few of them are really vital to figure out what’s going on. These are the files we care about right now:
This is useful from the point of view that it actually tells the Android device what code will be run when the app is first launched. If you double-click on the file and view it in the IDE, it’s not much to look at, but everything in there is important to properly run your app. We will devote time in another installment to really delve what the manifest does for your app, but for today it is enough to know that Android Studio will take care of putting new activities and other app features into the file for you, at least until you’re more comfortable doing it yourself.
The file is only a few lines of code, but it directs the reader to one important resource that you will definitely spend time with: the activity_main.xml layout file. This is where the “look” of the app is defined, and where it can be changed using Android Studio’s visual layout tools. If you double-click on the activity_main.xml file, the IDE should present you with its visual layout editor. If you see a layout with an XML file pane next to it, you may have chosen the “Text” view of the layout. If you click the “Design” tab near the bottom of the layout pane, you will be switched back. While the layout is sparse, there’s still a lot going on here. In fact, if you look closely, our “Hello World” text is already in place in the middle of the view. That’s the thing about the Empty Activity: it’s not entirely empty, but has a simple TextView element in the layout to get you started. And what better sample text to put into a text widget than our favorite two word starter phrase?
Strings.xml is the last file to keep an eye on. The reason I mention this is that, as an application developer, good practices are essential, and the earlier you adopt them, the better. For throwaway one-off projects, it’s fine to go around typing in fixed text values for different buttons, text views, and navigation controls, but in the real world, there are many languages, and we’d be truly short-sighted, if not arrogant, to assume that English is the only language your app should use. So, let’s tweak a setting to make use of this file. If you double-click on the “Hello World” text in the layout, you will see the Attributes pane appear. As it turns out the TextView text attribute will most likely be highlighted, since you double-clicked it in the layout editor. To the right of that attribute box, you should see what looks like an ellipsis (...), which you can click now to display the resource window for this project. Inside are the resources that you can make use of for the attribute you’re editing.
Since we want to make a change, click on the “Add new resource” menu item in the top right of the window and then select “New string Value…”, which presents you with the “New String Value Resource” dialog. For “Resource name”, choose something sensible like “hello_world_text”, and then set the Resource Value to “Hello World!” You can then click OK and the value in the text attribute will have changed to “@strings/hello_world_text” but the layout will still display the value, which is “Hello World!” If you now look at strings.xml in the code editor, you’ll see that there is a new line in the file, which Android Studio put there for you. Brilliant!
Let’s run it!
Now we need to build this and see if it will run. At the top of the IDE window, the center of the toolbar has a green hammer icon. Click it, and the project will be built. It might take a few moments depending on the speed of your development machine, but it will ultimately get done. As an aside, as much as I love ODROID devices for running Android apps and Linux in general, and even the powerful ODROID-XU4 is not particularly well-suited for app development of this nature. It’s just that there’s a lot of memory involved in building software, and building a nontrivial app would ultimately lead to thrashing your eMMC or SD card media when Android Studio runs low on memory, shortening the life of your flash media at the very least. But hey, it’s your money, and if ODROID is what you have to build with, it can do the job, you might just have to wait longer for certain tasks. Now that the app is built, if you press the green “Play” triangle, the app will “run” and try to connect to an Android device. What’s that, you say? Don’t have an Android device handy? You haven’t gone to the ODROID Wiki to connect your ODROID-C2 using it’s USB OTG (https://wiki.odroid.com/getting_start/adb_fastboot) port? You haven’t started Network ADB on your ODROID-XU4 (https://wiki.odroid.com/odroid-xu4/troubleshooting/adb_over_tcpip)? While it’s always more valuable to test an app on actual hardware, if all else fails, you can always emulate an Android device.
Get Virtual (Devices)
So, if you’re seeing the “Select Deployment Target” and it is empty, you can click on “Create New Virtual Device” and be treated to a catalog of various Android benchmark devices that you can emulate on your computer, from TV to tablet, to phone to Android Wear devices. This time around, let’s create a middle-of-the-road phone device, like a Nexus 5X. Once you select it, click “Next” and go ahead and choose one of the “recommended” system images, which as of this writing would be Nougat, Oreo or the “P” Preview. You’ll probably have to click the “download” link next to the version to download the image prior to proceeding, and yes, it might take a while.
Once you have the image downloaded, click “Next”, give the virtual device a name (or keep the default that Android Studio generates), change the screen orientation to landscape if you’re into horizontal screens, and click “Finish”. At last, you have a device to launch your app!
If all goes according to plan, the virtual device will boot up the Android version you downloaded, and will place you at the launch screen. A few moments after that, Android Studio will connect to the virtual device using ADB and launch the app. It might not be as satisfying as having your app running on an actual Android device, but then again, you’ll never have the excuse that you don’t have an Android device when you need one.
Commit those changes
All that coding is hard work, and at the end of every coding session, you should always make it part of your practice to commit your work in progress. I’m the first to say that when it’s you working on a code repository by yourself, nobody is going to notice that your code doesn’t build correctly, or has a ton of bugs and errors in it. I invite you to get over it. The important thing is that you keep a backup in the event that something terrible happens and you’re suddenly without your workstation and its file storage. To do this, you can go to the VCS menu again, and select “Commit”, there is a keyboard shortcut for this, and also an entire pane of the IDE window that is for version control. Make sure to take a look at it and get familiar. You will then see that two files at least have been changed: the activity_main.xml and strings.xml files. You can take a look at the changes to make sure they are what you’re expecting to check in. Now you should enter a commit message, which will log a narrative of what changes are in the code that you’re committing to the repo. I will enter something terse, like “changed text to use strings.xml”. Hover your mouse pointer over the “Commit” button in the bottom right corner, and you’ll notice that there are some additional options. For our GitHub demo, let’s go ahead and select “Commit and Push…” which will present you with a dialog that lets you add tags to the push to GitHub. Click “Push” and you’re done! I can’t emphasize this enough: make sure you check in your code changes at the end of your work day, and you’ll never regret going to sleep (and you might even sleep better, but don’t hold me to that!)
Since this is a new column, I thought making a Hello World app would be a fun start. But honestly, it really is the Most Basic App Ever Made™. I’m now actively looking at options for working on an app that makes sense to deploy to an ODROID-XU4 or ODROID-C1+/C2 for fun and possibly good learning. Some ideas that come easily to mind include:
- An Android TV-based game, running on an ODROID-XU4 with LineageOS Android TV loaded, that uses multiple players’ own Android mobile or tablet devices to control and play a turn-based card or tile game.
- A custom Android home automation touchscreen, running on an ODROID-XU4 or ODROID-C2 with LineageOS, that uses background services to communicate with other home automation servers and devices to control and monitor your home without using cloud-based services.
- An Android Auto, running on an ODROID-C2 with a touchscreen, that collects information from your car and allows your Android mobile or tablet to connect and play media, navigate, communicate and inform the time you spend behind the wheel.
If the list seems daunting or you feel yourself recoiling in horror that this is all too complicated, just relax. I’m here to help, and I will do my best to explain everything as plainly as possible. I recognize that every one of those projects above is very much a combination of hardware elements and software elements working together to provide a solution. So you can expect that there will be editions of this column that will be hardware-focused in order to set up or at least mock up a hardware platform that we can then use to write apps for. There will also be editions of this column where we will break down bigger problems into chunks to which we can then apply Android-based app architecture practices in order to make them work the way Android device users expect them to. I think it will be a much more rewarding experience for everyone, and it will all be made open source and available online for future Android developers to build on. If you think these ideas are terrible and you are convinced you have a better one, I want to hear about it! You can always comment on the interactive version of ODROID Magazine for this article, or visit the ODROID Magazine forum at https://forum.odroid.com. The best part about this column is that the code I work on is online for you to check out as well. Feel free to visit my GitHub account at https://GitHub.com/randybuildsthings and laugh at many of the goofy things I do on there. I use GitHub mostly for playing around, but I look forward to seeing you there.
Be the first to comment