DEV Community: Andy Delso

My Studies of Head First Android Development 3rd Edition: Chapters 5 & 6

Andy Delso — Wed, 03 Aug 2022 14:23:52 +0000

My studies of Head First Android Development 3rd Edition – Ch 5 & 6

Welcome back to my series on Head First Android Development – 3rd Edition! This blog post is a continuation of a series of posts I will be doing on reading and working through Head First Android Development. This blog deals specifically with chapters five and six.

Are you new to the series? Please start at the beginning of the series here.

Note: This blog may contain affiliate links for books or products I reference. Clicking on these links may result in compensation.

Let's get a Life-cycle!

The next two chapters deal with some fairly core features of the Android operating system and apps in general:

Chapter 5: Being an Activity
Chapter 6: Finding your way

Chapter 5

This chapter covers a very important concept of Android called the activity lifecycle. As mentioned in earlier chapters, an activity is a class that control's the app's behavior, which includes buttons in your UI responding to clicks, or what happens when a user enters information into a text view.

All activities in android apps adhere to a specific lifecycle flow, and this chapter details most of them. Understanding this lifecycle can allow developers to better control behavior in their apps, as well as handle when a user closes the app, or changes its orientation from portrait to landscape (or vice versa).

The book chooses to illustrate this concept with a stopwatch app, which involved leveraging a new view type I had not seen yet, called a chronometer view. The most significant part about this view is that it has convenience methods for handling time, which made implementing the app much easier. The problem we will need to solve is handling the time when a user leaves the app, which lifecycle methods can help us understand.

Controlling the lifecycle involves overriding different methods based on the desired outcome.

Activity lifecycle methods discussed:

onCreate() - called following activity launch, usually used to display the layout
onStart() - called following app made visible
onResume() - called after the activity is brought to the foreground again
onPause() - called just before the app is not in the foreground
onStop() - called before app made invisible
onRestart() - called after the activity has been made invisible, and before it is made visible again
onDestroy() - called just before activity destroyed

What about partial invisibility?

The book quickly discusses on a state where the activity is still partially invisible. For example, this will happen when a Google Assistant card pops up. Usually this only covers a portion of the screen, and in this case it's specifically the bottom. For this type of pause, we use the onPause and onResume methods, as opposed to the onStop and onRestart methods. This is due to the fact that the methods would do the exact same thing, and in the full lifecycle flow, run one after another anyway. To be more specific, onStart and onRestart are followed by onResume, and onStop is followed by onPause(). So in this case we can omit the extras, but this is not always true. The book really tries to drive the lifecycle point home with state by state descriptions, including node charts and activities to complete.

Saving state to a Bundle

How do we save state when the app is not in focus? Android's simplest option for that is a Bundle. It allows a developer to save the current state, and then retrieve it when the app regains focus.

With the Chronometer app, most of the work ends up being done in the onStart and onStop methods. Within our override of onStop we need to save the current state to the Bundle.

This chapter is quite crucial to understanding how an activity works, so I made sure to attempt drawing the diagram from memory a few times for practice.

Chapter 6

The next chapter chooses to focus on Fragments, which is another important layer on top of Activities. Fragments, in short, are sort of like sub-activities, and are the way that Android solves apps that require more than one screen without using multiple activities. Instead, we can use a single activity that hosts multiple fragments, and simplify the code using Android's Jetpack Navigation component.

Fragments have their own lifecycle, similar to Activities, but with more/different optional methods to override, most importantly is onCreateView(), which executes each time our Fragment layout is needed. Upon further review of the chapter and my notes for it, I noticed they do not include the full fragment lifecycle flow at this point; however, I do remember seeing one later in the book. So we will definitely cover that at a later point!

Instead, the book continues with a basic setup for a Fragments code, which does resemble an activity. Although, it is called out fairly quickly that a Fragment does not extend an Activity, and defines its own similar methods instead of inheriting them.

Our main activity layout would end up looking something like this by using the Navigation component:

<androidx.fragment.app.FragmentContainerView  
    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"  
    android:id="@+id/nav_host_fragment"  
    android:layout_width="match_parent"  
    android:layout_height="match_parent"  
    android:padding="16dp"  
    android:name="androidx.navigation.fragment.NavHostFragment"  
    app:navGraph="@navigation/nav_graph"  
    app:defaultNavHost="true"  
    tools:context=".MainActivity"/>

We then would override onCreateView() to correctly inflate the layout for this particular fragment:

class ExampleFragment : Fragment() {  
    override fun onCreateView(  
        inflater: LayoutInflater,  
        container: ViewGroup?,  
        savedInstanceState: Bundle?  
    ): View? {  
        val fragmentView = inflater.inflate(R.layout.fragment_welcome, container, false)  

        return fragmentView  
    }  
}

Once we have the inflated view layout for the fragment, we can wire up a button with a click listener to then navigate to another fragment using :

// within ExampleFragment onCreateView() after fragment layout inflated
...

val startButton = fragmentView.findViewById<Button>(R.id.start)  

startButton.setOnClickListener {  
 fragmentView.findNavController()  
    .navigate(R.id.action_fromFragment_to_toFragment)  
}

...

My Current feelings on the book overall

I am really enjoying the way this book explains complex concepts. It tends to repeat concepts multiple different ways, designed for how the human brain works. This reminds me of the days I used to work in customer support, and had to explain to non-technical folks what an external IP address is. The variety of activities I have had the chance to work through have certainly helped with retention of the concepts over time.

Here's to the next chapters!

There is so much more to unpack than I have summarized. Truthfully, you should dive into it yourself!

I am looking forward to continuing this journey with you all and building more apps as I gain the knowledge I need to become an Android Developer. Next in the series I will be covering Chapter 7 and possibly 8, but I haven't decided yet. As you may have noticed, the posts are getting a bit longer, but I want to keep them a reasonable length. Let me know in the comments if you think they are getting too long!

What app would you make if you could? After reading this book, I bet you could to it!

Sources

Head First Android Development, 3rd Edition – Dawn Griffiths, David Griffiths

My Studies of Head First Android Development 3rd Edition: Chapters 3 & 4

Andy Delso — Wed, 27 Jul 2022 13:42:36 +0000

Welcome back to my series on Head First Android Development - 3rd Edition! This blog post is a continuation of a series of posts I will be doing on reading and working through Head First Android Development. This blog deals specifically with chapters three and four.

Are you new to the series? Please start at the beginning of the series here.

Note: This blog may contain affiliate links for books or products I reference. Clicking on these links may result in compensation.

Things Are Going to Start Getting Interesting!

In the next two chapters, things start to pick up! Chapters three and four include the following big ideas:

Deeper dive into Layouts
A really deep dive into Constraint Layouts
- Blueprints
- Working with ConstraintLayouts

Chapter 3

In chapter three, we gain a lot of tools in our tool belt, which sets us up for the meat of Chapter 4 about ConstraintLayouts.

This chapter goes a bit deeper into a few different layout types, and their general use cases, specifically:

LinearLayouts - child views arranged vertically or horizontally
FrameLayouts - child views stacked
ScrollViews - use to wrap layouts with a scroll bar

Each layout type was nicely presented with a small app example to build. This chapter (as well as previous ones) employs in-text activities to solidify your knowledge. The most memorable (in my opinion) has been the Refrigerator Magnet ones, which allow you to see some of the code and fill in the blanks.

A big learning point from this chapter was that all layouts extend the View class by extending the ViewGroup class. These layouts require almost all elements in an Android UI to declare their height and width and gain a common API to interact. Also, this is why a developer can nest layouts to create precisely what they need for their app.

For example, you can have a LinearLayout set to vertical orientation with two child LinearLayouts both set to horizontal orientation to have two rows of elements, but those rows are arranged vertically. Although, in the next chapter we quickly find out that this is not the best way to accomplish the task.

Chapter 4

Complex arrangements using nested layouts are not best practice in Android. In this chapter, we learn that these cause Android OS to do more work than it should because each layout and view is turned into an object in the code.

The solution (and the meat of this chapter) is the ConstraintLayout. I have seen plenty of ConstraintLayout during my initial coursework with Google. In hindsight, I don't know that the course explained it (or the reasoning) as well as the book.

To teach the reader this concept, the text explains the blueprint view in the Android Studio design editor and the Android Jetpack ecosystem of libraries. Both tools are essential for building a complex UI using ConstraintLayouts.

Chapter four dives deeply into the many abilities of this layout including

Constraints
Bias
Guidelines
Barriers
Chains
Flows

Additionally, this chapter goes into all the relevant Android Studio tools in the Design View to work with ConstraintLayouts.

Using all of the tools above was quite fun, and I am looking forward to designing and building my apps utilizing them. I am most intrigued by the use of barriers for dynamic resizing of child views that can change the overall layout. I am also interested in chains and flows for proper alignment of elements.

<androidx.constraintlayout.widget.Barrier  
 android:id="@+id/barrier1"  
 android:layout_width="wrap_content"  
 android:layout_height="wrap_content"  
 app:barrierDirection="bottom"  
 app:constraint_referenced_ids="editTextTextMultiLine,editTextTextMultiLine2"  
 tools:layout_editor_absoluteY="24dp" />

<androidx.constraintlayout.helper.widget.Flow  
 android:id="@+id/flow"  
 android:layout_width="0dp"  
 android:layout_height="wrap_content"  
 android:layout_marginTop="24dp"  
 app:constraint_referenced_ids="button5,button6,button4,button8,button7,button9"  
 app:flow_wrapMode="chain"  
 app:layout_constraintEnd_toEndOf="parent"  
 app:layout_constraintStart_toStartOf="parent"  
 app:layout_constraintTop_toTopOf="parent" />

I’m Only Skimming the Surface on What You Will Find in This Text!

There is so much more to unpack than I have summarized. Truthfully, you should dive into it yourself!

I am excited to continue with this book and build more apps to gain the knowledge I need to become an Android Developer. Next in the series I will be covering chapters five and six, providing my notes, thoughts, and questions for you.

What excites you about the prospect of reading it?

Sources

Head First Android Development, 3rd Edition - Dawn Griffiths, David Griffiths

My Studies of Head First Android Development 3rd Edition: Chapters 1 & 2

Andy Delso — Tue, 19 Jul 2022 02:18:14 +0000

For the better part of the past year, I have been working on becoming an Android Developer. As of recently, the effort I have been putting into it, has paid off, but that is for another post. My main issue has been learning consistently and being able to apply the knowledge to real-world applications. Between my day job and parental responsibilities, finding the time to sit down and study is difficult.

Note: my writings may contain affiliate links for any books or products I reference. Clicking on these links may result in compensation.

The Reasoning & Ideas Behind My Studies

At my previous employer, I had set the goal of completing the Android Basics in Kotlin course offered by the Google Development team. Upon completion, I would then work on passing the Associate Android Developer certification examwithin the year. Unfortunately, I was not fully able reach that goal.

I did make it through four of the 6 available units before the end of 2021 while balancing my work and personal life. Although this was difficult, I intentionally built time into my work day to make it happen because this was a work-related goal. It was also a big part of my personal development plan there.

Due to this on-and-off learning being an ineffective way to learn, I decided to take it a bit more seriously this year. So I have started to study Android for at least one hour every morning after working out. As it had been a few months since taking a break from the course, I knew I needed some review to tackle units 5 and 6 and the certification exam.

Dive Into Head First Android Development - 3rd Edition With Me

Personally I have enjoyed the first few chapters of Head First Design Patterns - 2nd Edition for both the first and second editions. So I thought I would give the newest edition of Head First Android Development a go.

Disclaimer: If you have not programmed before (or worked in Kotlin), I recommend looking into another book or set of lessons first. Since I am talking about Head First, the book recommends looking at Head First Kotlin - 1st Edition to get your feet wet with the language. I also would recommend taking a look at interactive courses like JetBrains Academy - Kotlin Basics. I enjoyed how it allowed you to try and skip sections familiar to you. Additionally, I enjoyed the integration with JetBrain's IDEs, such as Android Studio.

My Note-Taking Process

I have recently started using Obsidian.md to take notes alongside these blog posts. Obsidian.md is a nifty and fully featured note app. It is marketed as "a second brain, for you, forever" and described as a powerful knowledge base (read: wiki) on top of a local folder of plain Markdown files.

The selling point for me, and probably for the privacy concerned, is that your data is stored locally! For those interested in the app, I used this playlist to learn the basics, and I was able to start navigating it quickly.

Let's Dive in!

The first two chapters have been fairly easy for me (given my working knowledge of Android and Kotlin). These chapters include:

Chapter 1: Getting Started: Diving In
Chapter 2: Building Interactive Apps: Apps That Do Something

Chapter 1

The initial "dive-in" covers an introduction to Android Studio IDE (Integrated Development Environment) and how to setup a basic app. I have been using this application for a while, so this chapter went fairly fast for me. In fact, I had already set it up on my MacBook Pro before receiving the book in the mail.

This chapter will give folks new to Android development a thorough walk-through of setting up the IDE. The chapter also includes an overview of where to find things you need within the first few chapters. The first chapter also gives the reader a brief introduction to the Android API ecosystem and some basic concepts like layouts.

Chapter 2

The second chapter digs into making something I find interesting, a beer listing app. It features good introductions to layouts, UI component views, activities, and resources. This chapter has you build an app with a beer color Spinner (drop-down), connected to a Button, when pressed, generates a list of appropriate beers below.

The walkthrough of this build is very introductory and explains what it is doing multiple times to drive the concepts home. This method is central to the whole Head First series style. It desires to teach you about thinking (metacognition) and how to learn better, given their studies on how the human brain learns.

Completing the app was not too bad with my pre-existing knowledge, but it solidified my basic knowledge about Android as follows:

All UI elements extend the View class. To elaborate, this means Button and Spinner are Views, and all share common attributes and methods. TextView was just obvious... 😁
Placing strings in to a resource file is a forward thinking habit for localization practices.
Your resource file can also include arrays of strings that Spinners can consume for listing things.
Android methods like findViewById() and setOnClickListener() are essential code building-blocks for successful apps.
Using the above methods, we can locate elements and respond to actions on them, then update the UI by setting other elements' attributes.

Overall, I am excited to be back into learning Android development! I hope this helps you become excited to start learning (if you haven't yet). The Head First series learning style speaks in a way that makes learning easy for me. It may not be for everyone, but if you haven't tried it, I think you should give it a go!

Follow Along on My Blog Series Regarding Head First Android Development: 3rd Edition

Have you found my review of the first two chapters of Head First Android Development: 3rd Edition helpful? If so, check out my next blog featuring chapters three and four and what lessons I learned from them.

Sources

Head First Android Development, 3rd Edition - Dawn Griffiths, David Griffiths

Using a Component Model in Selenium to Increase Maintainability and Reusability

Andy Delso — Mon, 17 Jun 2019 15:49:31 +0000

Over the past 9 years of Sprout Social's existence, our Selenium framework has grown into 100's of scenarios with as many page classes and factory containers. We've noticed it has become cumbersome to manage and as such, our QA Engineers thought the models in use needed a refresh. So in recent times, we adopted what we like to call the Component Model.

Note: All code examples can be found in the following Github Gist.

The idea for this component model was a result of a few things:

Modern websites aren't really built strictly of static "pages" any more
A Grow@Sprout talk on the SOLID principles by Uncle Bob
Our web app’s use of React.js, which uses a similar idea of components for encapsulation

Modern websites (i.e. web applications) are highly dynamic pieces of software with global bars, side bars, content views, and pop-outs. Many of these pieces are yet composed of other smaller pieces. Reflecting on this and the SOLID principles, we realized that the monolithic classes the page-object model created were not working to our advantage anymore.

We noticed we had multiple functional zones and really only one spot for actual page content. We had a global top nav bar that also included settings access. Additionally, there is a secondary left nav bar for navigating within functional areas. A lot of pages also contained a rail on the right side commonly housing date pickers and filters for the content view. Please refer to the mockup below to help visualize this:

We noticed plenty of areas in the framework where we could DRY (Don’t Repeat Yourself) up the code. This is included in the SOLID software development principles. Buttons, inputs, and data visualizations all share common code in the UI implementation. Why, then, should our tests implement multiple ways to get and interact with filters across multiple page classes?

Instead, we agreed that the components our selenium tests use should be a 1:1 representation of their equivalent web UI component. Take this example CheckboxV1 (click for the gist code snippet) class. The most beneficial aspects of this model are: the component houses its unique selenium selector, and specific constructors and methods that your tests can consume. This significantly enhances the readability of code and the maintainability of the framework.

After using these components for a while, we started to notice that code was being repeated between classes. In order to DRY the repetition up, we created a class called BaseComponent to control much of the basic behavior of any component. One can then extend all other components from this BaseComponent to ensure every component implementation is as simple as possible.

Combining implementation from our original CheckboxV1 with inheritance from BaseComponent further simplifies the component and increases the maintainability of the framework. CheckboxV2 allows BaseComponent to do most of the heavy lifting not specific to the particular component. We also have one less spot to check when fixing issues as most of the behavior is within BaseComponent instead of multiple versions of similar functionality scattered across multiple components.

A quick note on the above CheckboxV2 implementation - we tend to use the String argument constructor the most with components that have attributes in the UI code. The By and WebElement argument constructors are backups for elements in our UI that might not contain special data attributes, what we refer to as QA attributes, but the follow same/similar component structure in the DOM. However, we encourage our team to add their own QA selectors if able to or further collaborate with the developers to get them added. Having them usually allows the component code and subsequent Selenium automation to be much simpler overall.

Here is a quick example of how we then use the components within a Page and Step Definition classes.

It has been a fun and interesting journey getting to this point through many refactors of our framework. However, it has proved time and time again to make our framework a bit easier to grok as well as maintain. We are already beginning to think of ways to improve upon this further such as with a wrapper class called Selector to help with formatting and making BaseComponent more friendly to work with. We look forward to providing more information on those in the future

Have you or your organization used or are currently using something similar? Please share your experiences in the comments!