Over the holidays, I had the random chance to develop a control app for a water treatment company in Android Studio, which got me onto a new start in developing mobile apps. This app ended up looking like the below.
This got me thinking about the possibility of mobilizing all the tools I developed last year in this blog. This post will go through the code in Kotlin and Java, as well as xml for the payroll app I did last September.
Before we dive into the actual code, it’s important to point out that Android Studio has a file structure that looks like the below for a simple app, where the AndoidManifest.xml file describes the essential properties of the app and contains the definitions of the app’s components, the MainActivity.kt file contains the backend logic for the app, and activity_main.xml contains the frontend user interface design, and colors.xml and strings.xml contains the properties of the colors and text used in the app.
AndroidManifest.xml
Below is the code for the AndroidManifest.xml file.
<?xml version=”1.0" encoding=”utf-8"?> specifies that this is an XML file and sets the encoding to UTF-8, where UTF-8 is Unicode Transformation Format — 8-bit, which is designed to encode all possible characters in Unicode, which includes virtually every character from every writing system in the world, plus technical symbols and special characters.
<manifest xmlns:android=”http://schemas.android.com/apk/res/android” declares the namespace, which is necessary to use Android-specific attributes.
package=”com.example.myapplication_basic specifies the package name for the app. You’ll notice this is in the folder structure above under kotlin+java.
xmlns:tools=”http://schemas.android.com/tools adds a namespace for the tools, allowing the use of tool-specific attributes in the manifest.
All the code under <application> are describing essential properties of the app, which includes the app name specified in the strings.xml file, the basic app theme specified in the themes.xml file, the targeting API level is 31 that could be used to suppress lint warnings, and most importantly the app’s activity should be listed in the system’s app launcher.
MainActivity.kt file
Below is the code for the MainActivity.kt file.
Like the AndroidManifest.xml file, we need to put the package for the app on the first line. We also need to import the Android classes and interfaces for the applications to use, like ‘Button’, ‘EditText’, ‘TextView’, and ‘AppCompatActivity’.
‘override fun onCreate(savedInstanceState: Bundle?)’ initializes the activity’s layout and functionality. Within this initialization, ‘setContentView(R.layout.activity_main)’ sets the content view of the activity to the layout in the activity_main.xml file.
findViewById pulls the three user input fields from the activity_main.xml file and give them each a variable name
‘val calculateButton: Button = findViewById(R.id.calculateButton)’ finds the ‘calculateButton’ from the layout and assigns it to a variable.
‘calculateButton.setOnClickListener { calculate() }’ set an onClick listener on the button, and calls the ‘calculate()’ function below when the button is pushed.
Similar code is also laid out for the reset button.
The above code specifies the three user input fields, name, hourly rate, and hours worked, as well as the output.
The above code defines the data types for name, hourly rate, and hours worked.
The above code defines the amount and data types of the constants used in the app.
The above codes are the formulas for the values used in payroll calculations.
The above code defines the order that the above calculated amounts are displayed in the app. Recall the first code chunk in the calculate function as shown below. The output in this code pulls from the above resultTextView to display the results.
activity_main.xml
Below are the code for the activity_main.xml file.
The above code defines the ‘id’, which is the field name to reference within the app for each of the user input fields: name, hourly rate, and hours worked. The code also gives the width, height, expected data type, as well as the hint for users to input the expected information the app is looking for.
The above code defines the id, style, width, height, the relative space of each of the ‘calculate’ and the ‘reset’ buttons represented by layout_weight, as well as the text to be displayed on the buttons.
The above code defines the id, width, height, the space between each line of output in 16 density-independent pixels, as well as the text size in 18 scale-independent pixels.
And finally, the above code declares the input fields as well as the output through late initialization after the initialization within the onCreate method, and resets them to blank.
Below is the apk file for this app. Feel free to try this out on your Android mobile device.
YouTube Tutorial
The video that goes through the above in streaming format is below.
There is considerable uncertainty associated with the great majority of numbers we use every day and with the numbers used by politicians and decision makers, not to mention economists and financial analysts. This uncertainty results from measurement mistakes, statistical margins of error, and well the face that these numbers are often just estimates based on uncertain data. And the more digits and decimals we add to an uncertain number, the more certain and exact it appears. That the average interest rate for a house mortgage in the United Kingdom will be 3.15 percent in 2027 sounds pretty precise, doesn’t it? But consider for a moment the absurdity of including two decimals for this very uncertain prediction. In the midst of the pandemic, OECD Employment Outlook 2020: Worker Security and the COVID-19 Crisis predicted an unemployment rate “at or above the peak level observed during the global financial crisis, reaching 7.7 percent by the end of 2021 without a second wave (and 8.9 percent in case of a second wave).” The answer, just 18 months later, turned out to be closer to half that number, even with several new waves of the pandemic.