Mobile Application Development

Eager to learn more about software development, I was fortunate to work with Patricia Duce in order to complete an Android Developer training course and use the material contained therein to develop a course taught for the first time at UMT in Fall, 2022.

What I've Learned: Application Fundamentals

Android development has been an excellent way to get hands-on practice writing clean code and to work with software architecture patterns commonly found in industry applications, especially model-view-viewmodel ( MVVM) which is endorsed as a best practice when building Android apps.

According to Android:

Another important principle is that you should drive your UI from data models, preferably persistent models. Data models represent the data of an app. They're independent of the UI elements and other components in your app. This means that they are not tied to the UI and app component lifecycle, but will still be destroyed when the OS decides to remove the app's process from memory.

This effectively separates the application into two layers: a user-interface (UI) layer and a data layer. This concept is just one example of various design principles that I learned while exploring mobile application development.

While Android applications have historically been written in Java, Google announced in May 2019 that the officially-supported language for Android development would be Kotlin. Kotlin has much in common with Java, but its syntax has been changed to support type inference and eliminate the terminating semicolons, among many other features such as inline lambda functions, null safety, range expressions, and coroutines, all of which were explored in depth in the training course.

This course also emphasised the importance of testing application code, and each module contained an activity related to writing effective unit and functional tests. After teaching foundational concepts such as user interface (UI) management using layout resource files, click listeners, etc, the course demonstrated how to implement a Recycler View. Recycler Views are the component inside of Android applications that allow for an infinitely scrollable list. Think of any 'feed' you have encountered such as news feed on LinkedIn or Twitter, and you have the idea. Recycler Views have been designed to provide a user-friendly experience by scrolling smoothly and not freezing or jerking as fresh list items are loaded into the list.

The following is a code snippet from my application ListMaker which demonstrates the use of a Recycler View. Its individual components will be explained below:

• The MainAdapter class constructor expects as arguments two click listeners that determine what occurs if a list item is clicked or long-clicked, respectively, and extends the ListAdapter class which expects a DifCallback object as an argument.
• ListAdapter is a base class used for presenting list data in a Recycler View.
• DiffCallback is a class that contains methods for computing the difference between two lists and is useful to detect when only one or a few list elements have changed, and update only those elements, as opposed to the entire list. Here DiffCallback is implemented as a companion object.
• A companion object is an example of the Singleton design pattern and also resembles static objects in Java in the sense that they belong to a specific class but not a given instance of that class.
• The ViewHolder class accepts a ListItemBinding object as an argument. A ListItem has been defined in a separate xml file and in this case contains only instructions on how to display a text field. The ViewHolder class is responsible for using this binding object to set the text field of a given list item to the appropriate item's name in the bind function.
• The onCreateViewHolder function returns a ViewHolder and is responsible for inflating the ListItem view.
• Additionally, two click listeners are set within onCreateViewHolder. Additional listeners can be set here as well that handle the application's response to specific gestures or other events.
• Lastly, the onBindViewHolder function is responsible for performing the work defined in onCreateViewHolder and, therefore, also any work defined in the bind function in the ViewHolder constructor. In this case, this entails setting a ListItem's text field to the appropriate item's name and setting two click listeners.

What I've Learned: Application Navigation

Android provides a Navigation Component which is intended to simply the process of navigating between views within an application. In Android, any screen displayed to a user is a view that has been defined in a layout.xml file. These views can be either activities or fragments. Simple applications can usually be contained within a single activity and make use of fragments to display different views. Utilizing the Navigation Component in such a situation is described below. The code for these examples has been taken from my solution to a project in the third module of the Android Basics in Kotlin course:

1. Android applications have their programmatic entry point located in a MainActivity class (this can be modified in the AndroidManifest.xml file, but changing this doesn't appear to be a common practice). Within MainActivity we can initialize a NavHostFragment, which is a fragment that will be used to display the views contained within our app. This fragment is owned by the NavHost, which contains the context for navigating using a NavController. We also initialize this NavController within MainActivity. These steps are demonstrated in the code below:

   class MainActivity : AppCompatActivity() {
   
       private lateinit var navController: NavController
   
       override fun onCreate(savedInstanceState: Bundle?) {
           super.onCreate(savedInstanceState)
   
           setContentView(R.layout.activity_main)
   
           val navHostFragment = supportFragmentManager
               .findFragmentById(R.id.nav_host_fragment) as NavHostFragment
   
           navController = navHostFragment.navController
   
           setupActionBarWithNavController(navController)
       }
   }
                           

2. Next, a navGraph.xml is necessary in order to define the fragments known to the NavHost and define both the directionality between fragments and their corresponding layout files: <fragment android:id="@+id/startOrderFragment" android:name="com.example.lunchtray.ui.order.StartOrderFragment" android:label="fragment_start_order" tools:layout="@layout/fragment_start_order" > <action android:id="@+id/action_startOrderFragment_to_entreeMenuFragment" app:destination="@id/entreeMenuFragment" /> </fragment> <fragment android:id="@+id/entreeMenuFragment" android:name="com.example.lunchtray.ui.order.EntreeMenuFragment" android:label="fragment_entree_menu" tools:layout="@layout/fragment_entree_menu" > <action android:id="@+id/action_entreeMenuFragment_to_sideMenuFragment" app:destination="@id/sideMenuFragment" /> <action android:id="@+id/action_entreeMenuFragment_to_startOrderFragment" app:destination="@id/startOrderFragment" /> </fragment> <fragment android:id="@+id/sideMenuFragment" android:name="com.example.lunchtray.ui.order.SideMenuFragment" android:label="fragment_side_menu" tools:layout="@layout/fragment_side_menu" > <action android:id="@+id/action_sideMenuFragment_to_accompanimentMenuFragment" app:destination="@id/accompanimentMenuFragment" /> <action android:id="@+id/action_sideMenuFragment_to_startOrderFragment" app:destination="@id/startOrderFragment" /> </fragment> <fragment android:id="@+id/accompanimentMenuFragment" android:name="com.example.lunchtray.ui.order.AccompanimentMenuFragment" android:label="fragment_accompaniment_menu" tools:layout="@layout/fragment_accompaniment_menu" > <action android:id="@+id/action_accompanimentMenuFragment_to_checkoutFragment" app:destination="@id/checkoutFragment" /> <action android:id="@+id/action_accompanimentMenuFragment_to_startOrderFragment" app:destination="@id/startOrderFragment" /> </fragment> <fragment android:id="@+id/checkoutFragment" android:name="com.example.lunchtray.ui.order.CheckoutFragment" android:label="fragment_checkout" tools:layout="@layout/fragment_checkout" > <action android:id="@+id/action_checkoutFragment_to_startOrderFragment" app:destination="@id/startOrderFragment" /> </fragment>
3. Now click listeners must be incorporated into each fragment that will trigger the appropriate transition from one view to another:

   class StartOrderFragment : Fragment() {
       private var _binding: FragmentStartOrderBinding? = null
       private val binding get() = _binding!!
   
       override fun onCreateView(
           inflater: LayoutInflater,
           container: ViewGroup?,
           savedInstanceState: Bundle?
       ): View? {
           _binding = FragmentStartOrderBinding.inflate(inflater, container, false)
           val root: View = binding.root
           // Navigate to entree menu
           binding.startOrderBtn.setOnClickListener { // Setting the click listener to call navigation action
               findNavController().navigate(R.id.action_startOrderFragment_to_entreeMenuFragment)
           }
           return root
       }
   }
                           

These steps demonstrate the implementation of code directly related to the Navigation Component, but it is worth noting that additional steps are necessary, such as placing a FragmentContainerView inside the MainActivity layout file, as well as defining the layout files for each individual fragment. (This app also makes use of a ViewModel, but this will be discussed in another section). Once all this has been finished, we can navigate through the application as demonstrated below:

What I've Learned: ViewModels and MVVM Architecture

In Android a ViewModel is used to store application data in a way that respects the Android application lifecycle. If data were to be stored local to a given activity or fragment, this data could be lost for any number of reasons out of the control of the application user or programmer, such as rotating the device screen, the operating system re-allocating memory resources, and the activity or fragment losing focus. Additionally, ViewModels simplify the process of sharing data between fragments. Separating application data from the user-interface is a common pattern in commercial codebases.

To explore the implementation of a ViewModel, I have copied code from my solution to the Cupcake codelab. Implementing a ViewModel within an application begins by simply declaring a new class that extends the ViewModel base class:

class OrderViewModel : ViewModel() { }
            

Next, we define fields for our OrderViewModel class. There is a convention when doing this in Kotlin termed the backing property, which holds that a mutable private variable is accessed by any functions within the OrderViewModel class and an immutable public variable is then provided for other classes to access. This is similar in theory to using getters and setters in Java. The example below uses LiveData types:

     private val _quantity = MutableLiveData()
    val quantity: LiveData = _quantity

    private val _flavor = MutableLiveData()
    val flavor: LiveData = _flavor

    private val _date = MutableLiveData()
    val date: LiveData = _date

    private val _price = MutableLiveData()
    val price: LiveData = Transformations.map(_price) {
        NumberFormat.getCurrencyInstance().format(it)
    }
            

The following function definitions demonstrate how the private immutable variables are used within the OrderViewModel class:

    fun setQuantity(numberCupcakes: Int) {
        _quantity.value = numberCupcakes
        updatePrice()
    }

    fun setFlavor(desiredFlavor: String) {
        _flavor.value = desiredFlavor
    }

    fun setDate(pickupDate: String) {
        _date.value = pickupDate
        updatePrice()
    }

    fun hasNoFalvorSet(): Boolean {
        return _flavor.value.isNullOrEmpty()
    }

    private fun updatePrice() {
        var calculatedPrice = (quantity.value ?: 0) * PRICE_PER_CUPCAKE
        if (dateOptions[0] == _date.value) {
            calculatedPrice += PRICE_FOR_SAME_DAY_PICKUP
        }
        _price.value = calculatedPrice
    }
            

Now that our OrderViewModel is implemented, we can access its fields and methods from within our application. The following example demonstrates accessing OrderViewModel from the fragment StartFragment:

• activityViewModels() is called to return access to an OrderViewModel instance shared between all fragments in the activity. The reference to this instance is declared in a variable sharedViewModel.
• The methods defined in OrderViewModel can be accessed in order to update the value of the fields such as quantity and flavor.

What I've Learned: Retrieving Data from the Internet

Most mobile applications perform network requests in order to retrieve and display information to their users such as emails, videos, and in the example for this section, weather alerts. Android recommends reforming this work on a background thread since network requests can take a significant amount of time to complete. Performing network requests on the main thread, also known as the UI thread in Android because this is where UI information is processed, is not recommended. It is best practice to perform these requests on a background thread in order to avoid the application appearing to freeze while the network request is handled. This situation is the basis of asynchronous programming. Additionally, Android recommends segregating application code relating to network requests within its own package, a practice which adheres to the modular design technique. In the example below, we will explore how this can be accomplished using two open source libraries designed for performing API requests and converting the returned JSON into a data class which can be passed in turn to a ViewModel.

First, we implement our network layer as shown below:

• First, we declare a reference to a BASE_URL which will simplify our API calls.
• Next, we create a Moshi object which will be used to deserialize the JSON we receive from the API endpoint into Kotlin data classes (we must still declare these classes; this will be demonstrated in the next section).
• Next, we must also define a RetroFit object responsible for converting the API HTTP response into an interface.
• With our RetroFit object declared, we can now implement the interface which describes our API call. In this case, we perform an HTTP request to a particular endpoint that will return weather alerts for Missoula County, Montana. The interface describes what the API call will do: return an Alert object, and the next step maps this HTTP request to a function getAlerts() that can be called from within our application code, specifically our ViewModel.
• Lastly, we create an Alerts object which holds an immutable variable (val in Kotlin) retrofitService described by the interface above that will be lazily constructed (here lazy means that this process will not occur until the Alerts object is first accessed).

• We can declare an enum class that contains the three possible states of our network request: LOADING, ERROR, DONE.
• We declare fields (using the backing property described in the previous section) to hold the value of both the network request status and the API response.
• The function getAlerts() launches a coroutine (discussed below) that will avoid making any asynchronous requests on the main UI thread.
• If the request is successful, we can access the Alert object via our AlertViewModel.
• If any errors occur, the UI will display an error icon and we can examine application logs in order to troubleshoot.

• The first binding adapter allows us to bind an appropriate image resource file (either a loading icon or an error icon) to an ImageView in our alert_fragment.xml layout file shown below: <layout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools"> <data> <variable name="viewModel" type="com.harr1424.privateweather.models.AlertViewModel" /> </data> <androidx.constraintlayout.widget.ConstraintLayout android:layout_width="match_parent" android:layout_height="match_parent" tools:context="com.harr1424.privateweather.MainActivity"> <androidx.recyclerview.widget.RecyclerView android:id="@+id/alert_list" android:layout_width="match_parent" android:layout_height="match_parent" android:padding="6dp" android:clipToPadding="false" app:alertListData="@{viewModel.alerts.component3()}" app:layoutManager="androidx.recyclerview.widget.LinearLayoutManager" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintLeft_toLeftOf="parent" app:layout_constraintRight_toRightOf="parent" app:layout_constraintTop_toTopOf="parent" tools:listitem="@layout/alert_item" /> <ImageView android:id="@+id/alert_status_image" android:layout_width="wrap_content" android:layout_height="wrap_content" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintLeft_toLeftOf="parent" app:layout_constraintRight_toRightOf="parent" app:layout_constraintTop_toTopOf="parent" app:nwsAlertStatus="@{viewModel.status}" /> </androidx.constraintlayout.widget.ConstraintLayout> </layout>
• The second binding adapter defines how the Alert data we are interested in will be passed to the RecyclerView. For this, we need to create an AlertAdapter class and also define an alert_item.xml layout file, which will be shown below.

AlertAdapter

class AlertAdapter :
    androidx.recyclerview.widget.ListAdapter(DiffCallback){


    class AlertViewHolder(private var binding: AlertItemBinding) :
        RecyclerView.ViewHolder(binding.root) {
        fun bind(alert: AlertFeature) {
            binding.alertHeadline.text = alert.properties.headline
            binding.alertDescription.text = alert.properties.description
            binding.alertInstructions.text = alert.properties.instruction
            binding.executePendingBindings()
        }
    }

    companion object DiffCallback : DiffUtil.ItemCallback() {
        override fun areItemsTheSame(oldItem: AlertFeature, newItem: AlertFeature): Boolean {
            return oldItem.id == newItem.id
        }

        override fun areContentsTheSame(oldItem: AlertFeature, newItem: AlertFeature): Boolean {
            return oldItem.properties == newItem.properties
        }
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): AlertViewHolder {
        return AlertViewHolder(AlertItemBinding.inflate(LayoutInflater.from(parent.context)))
    }

    override fun onBindViewHolder(holder: AlertViewHolder, position: Int) {
        val alert = getItem(position)
        holder.bind(alert)
    }
}
                

alert_item.xml

What I've Learned: Persisting user data using the Room library

Many applications receive and store information from their users. Oftentimes, this is done so that a user can return to the application at a later time and retrieve this data. In this section, we will explore how the Android Jetpack Room library can be used to accomplish this. This section demonstrates how a simple list application or note-taking application can be created. This application allows users to create a list of main items where each main item can be considered a task category. Clicking on a main item navigates to a list of items grouped as children of the main item. For example, a main item 'grocery' may be clicked to display a list of grocery items such as 'milk', 'eggs', and 'cheese'. This app is my original work and is available on the Google Play Store.

First, we must define a Data Entity, which describes a database table using SQL conventions:

• The MainItem data class will be used to create a table containing main items and contains only two columns: a unique id identifying the main item and the main item's name.
• The DetailItem data class will be used to create a table containing detail items and contains two columns: a reference to the parent main item and the detail item name. These columns are combined to form a primary key, in case a detail item appears within multiple main item categories.

• The getAll() function corresponds to a SQL query that will return all main items sorted in the order that they were added to the list.
• The getById() function corresponds to a SQL query that will return the item matching the id passed to the function as an argument. This will be useful when adding click listeners to each main item in order to define navigation to their detail item list.
• The findByName() function isn't currently used in this application, but I defined it because I would like to add search functionality in the future.
• The deleteDetailsFromMain() function will delete all detail items should their parent main item be deleted by the user.
• The insert() function has been modified such that if a main item exists already, a duplicate will be ignored.
• Notice that when function return types are specified above they are wrapped in a Flow type which allows for these values to be continuously updated.

• The AppDatabase class must be annotated with @Database and provide an entities array naming each data entity we have defined above.
• Optionally, a version number may be provided; this is essential if changes have been made to the database architecture; each change necessitates incrementing the version number by one.
• The AppDatabase class extends the RoomDataBase base class and contains methods corresponding to each DAO that has been implemented.
• The companion object (along with the BaseApplication class described below) ensures that only one instance of the AppDatabase class is available while the application is running.

MainAdapter

class MainAdapter(
    private val onItemClick: (MainItem) -> Unit, private val onItemLongClick: (MainItem) -> Boolean
) : ListAdapter(DiffCallback) {

    companion object DiffCallback : DiffUtil.ItemCallback() {
        override fun areItemsTheSame(oldItem: MainItem, newItem: MainItem): Boolean {
            return oldItem.itemName == newItem.itemName
        }

        override fun areContentsTheSame(oldItem: MainItem, newItem: MainItem): Boolean {
            return oldItem == newItem
        }

    }

    class ViewHolder(private var binding: ListItemBinding) : RecyclerView.ViewHolder(binding.root) {
        fun bind(item: MainItem) {
            binding.listItemText.text = item.itemName.toString()
        }
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
        val viewHolder = ViewHolder(
            ListItemBinding.inflate(
                LayoutInflater.from(parent.context),
                parent,
                false
            )
        )
        viewHolder.itemView.setOnClickListener {
            val position = viewHolder.adapterPosition
            onItemClick(getItem(position))
        }
        viewHolder.itemView.setOnLongClickListener {
            val position = viewHolder.adapterPosition
            onItemLongClick(getItem(position))
        }
        return viewHolder
    }

    override fun onBindViewHolder(holder: ViewHolder, position: Int) {
        holder.bind(getItem(position))
    }
}
                

DetailAdapter

class DetailAdapter(
    private val onItemLongClick: (DetailItem) -> Boolean
) : ListAdapter(DiffCallback) {

    companion object DiffCallback : DiffUtil.ItemCallback() {
        override fun areItemsTheSame(oldItem: DetailItem, newItem: DetailItem): Boolean {
            return oldItem == newItem
        }

        override fun areContentsTheSame(oldItem: DetailItem, newItem: DetailItem): Boolean {
            return oldItem == newItem
        }
    }

    class ViewHolder(private var binding: ListItemBinding) : RecyclerView.ViewHolder(binding.root) {
        fun bind(item: DetailItem) {
            binding.listItemText.text = item.detailItemName
        }
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
        val viewHolder = ViewHolder(
            ListItemBinding.inflate(
                LayoutInflater.from(parent.context),
                parent,
                false
            )
        )
        viewHolder.itemView.setOnLongClickListener {
            val position = viewHolder.adapterPosition
            onItemLongClick(getItem(position))
        }
        return viewHolder
    }

    override fun onBindViewHolder(holder: ViewHolder, position: Int) {
        holder.bind(getItem(position))
    }
}