In android, .java files are used to do two things:
- Allow the operating system to interact with your app
- Do the back-end/behind-the-scenes work, making the parts of your app interact with each other programmatically
On the other hand, .xml files are used primarily to
- Create GUI components known as "layouts", and
- Define "resource" items, such as entries in lists, strings that give names to individual .xml components, colors that appear within the app, styles that apply to many .xml components, and more.
Today, I was tasked with creating a Settings screen for my app. What seemed like it should have been one of the simplest things I've done yet turned out to require (manual) modifications to or creation of at least 9 files. That's right. Nine files, one settings screen.
And people wonder why so many start to learn code and end up turning away.
The sad truth is that many of the existing code-learning resources don't deal with how file structures interact, instead tackling syntax within individual files.
As I tried to implement the Settings-screen solution shown in the Deitel book I'm working out of, I realized I needed to chart out the file structures to understand what was going on. Which files referred to which other files? First, I made lists of all the .java and .xml files that I thought were relevant to my task, adding them as I found them.
.java files
MainActivity
QuizFragment
SettingsActivity
SettingsFragment
.xml files (folder they're in)
activity_main (layout)
activity_settings (layout)
fragment_quiz (layout)
main (menu)
preferences (xml)
Then, I traced how these files interact, starting with MainActivity. As shown in the upper left, all .java files are enclosed in boxes. (It got a little messy.)
I only wrote down instances where one file referred to another file, as opposed to just calling a method (java), creating a variable (java), generating final content (xml), etc.
The result? I was able to fairly quickly filter out the files unrelated to the task at hand (QuizFragment.java and fragment_quiz.xml) and then create analogues to all the remaining files or pieces of files in my own project.
In other words, a settings screen was made. With one adjustable setting.
Next: Splitting the project into two Activities: One for login, during which the Settings screen will not be shown, and one to become active once the user has logged in, during which Settings will become available to view and modify.

No comments:
Post a Comment