From what I understand, isn't XML used for layouts and to setup how an activity looks?
My book says that XML files are converted into Java code but then, why not just write everything in Java?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this communityFrom what I understand, isn't XML used for layouts and to setup how an activity looks?
My book says that XML files are converted into Java code but then, why not just write everything in Java?
Its because its simpler - tools can be written to manipulate a XML document far easier than understand java code, so the layout can be created and modified by a simple tool that does not need to also be a java parser.
Its also easier for people to describe a layout in XML than in java directly.
This technique is used by a lot of things, eg WSDL that describes a web service interface and is converted to (quite complex) code by a specialist tool. It helps the developer focus on one aspect without worrying about the implementation and allows tools to be written to generate different types of code (eg the wsdl can be turned into a server stub, and also a client API)
Because Android designers decided to implement it that way :)
In principle, everything could be written in Java. Microsoft did it for WinForms: the form description is saved as the auto-generated *.designer.cs file (or a generated region in early version of .NET framework).
Each method has its pros and cons. By storing the UI as XML, it may be easier to parse so the designer can be simpler to implement. However, it is another language for developer to learn: a totally new Domain Specific Language (UI), not just XML. By storing the UI as the target language (Java, C#...), the designer's implementation may be more complex but the code for creating UI is already familiar to the developers. Another advantage is that the existing code refactor tools can work without any changes.
I'm slightly late for the party, but here are my two cents on the matter, and I've been lucky enough to answer this question for someone who wrote a large app with 70+ screens and tons of business logic purely in Java. Here's why it's not advisable to write a pure Java/Kotlin Android app:
Proper Separation of Responsibilities - programs with UI are preferably implemented with a clear separation between how an interface looks and how an interface behaves. While you might not be able to kick out 100% of layout-related settings from your Java (or Kotlin) code, the layout itself would be defined by an activity's XML file. You see all your components in one place, and if need be, you access them from the activity's Java/Kotlin class and manipulate them programmatically (e.g. to bind event listeners). Separation of responsibilities should be a compelling reason to use XML for your Android app's activities.
Speed of Development - Android Studio, like other modern IDE's that support Android development, allows you to preview your layout based on your XML file without compiling the whole app. If you were to code your whole app inside the activity classes only, you'd probably have to compile the app each time you want to review your layout changes, and that's beyond inefficient. As a side note, there might be tools/plugins that preview your layout based on Java/Kotlin code only, but I'm not aware of them. Would you rather see your layout changes in split seconds or wait a minute or two for the AVD (Android Virtual Device) or your debugging device to get the compiled app up and running? Is it even running, or do you have a bug somewhere? It is a few orders of magnitude faster to define your Android layout in XML. This, too, should be a compelling reason.
Code Readability - if you aren't convinced yet, and you write your app as an individual developer, then surely you can understand your own code. You might even break down the views' construction into methods, create beautiful abstractions, re-use components and code with state-of-the-art design patterns. But what happens when a second developer gets in the picture? He or she would have to not only understand your code, but also sift view code from behavior code (see point #1) and try to get inside your head and decipher what crossed your mind when you had constructed the code. And keep in mind that layout code in Android can get very verbose, so no matter how beautifully your code would be written, no one really wants to onboard themselves a project that forces them to read a class with 1000+ lines of code for every single Android activity. The biggest advantage of writing your app's in XML, in terms of readability, is that XML is structured in hierarchy. The layout relationships between elements are immediately visible. If you construct your Android app without XML, you programmatically append children to their parent. You can't really indent your code to reflect the elements hierarchy on your screens.
Online materials - while it may not be a crucial point, I still find it a good one. Online materials are more prominently available for the XML+Java/Kotlin setup, because it's the encouraged way to code Android apps. If you get stuck on layout problems, you're more likely to find someone who solved your layout problems with this setup rather than the coding-only setup. You may need to read the manual (always encouraged) more often. And sure, you might find some aggressive developers online, telling you to Read the (.*) Manual, but don't let them fool you, as they, too, Google things in hope to find quick answers.
I hope it helps a bit.