Please complete this document to confirm the work that has been done. You will also add your answers to the provided questions in the space provided
Please replace
Include an appropriate screenshot from your application to confirm completion. Screenshots should be added to
the /images folder in the top-level repo.
Include the provided question for your exercise and your answer in the space provided.
| First Part |
Extension |
|---|---|
 |
 |
The Birthday/Christmas Example is localised to the English language. What changes would need to be done to make this app localised for the Spanish language.
https://developer.android.com/guide/topics/resources/localization
How would you test that your localised app worked as expected on the emulator?
Please include a screenshot of the new version working as part of the answer.
My own example with German language translation is shown below.
Make sure to add a final commit to your birthday branch with the amended code.
To enable our application to support the Spanish language, we need to include the appropriate Spanish translations in our project. In Android, the values folder within the res (resources) directory is used to store static resources such as strings, colours, and dimensions. Currently, we have a strings.xml file in this folder that contains the text strings used throughout our application. Since Android does not automatically translate these strings, we will need to manually translate our existing English strings into Spanish. To add Spanish localisation, we need to create a new folder named values-es within the res directory. The -es suffix is required because it signifies the language code for Spanish, allowing Android to recognise the folder as containing resources specific to the Spanish language. Within the values-es folder, we will create a strings.xml file and add the Spanish translations of all the app's strings.
You can see how we've implemented this in the screenshot below.
We can then test our localised application is functioning as expected on the emulator by doing the following:
- Launch the emulator in android studio and exit the application running.
- Go to Settings > System > Language & Inputs > Languages.
- Tap ‘Add a Language’ and select Espanol (Spanish).
- Move Espanol to the top of the list to make it the default language.
Restart the application and you will now see the strings have changed from English to Spanish.
//
| First Part |
Extension |
|---|---|
 |
 |
In the quadrants exercise, the layout of 2x2 has no issues on an orientation change. However, consider the impact a 3x2 in portrait would have when orientated. Is the preference for it to remain 3x2?
Typically, layouts adapt to meet user expectations.
For this question, please provide an answer indicating how this would be done using Composables. You should include in the answer the specific code elements that are aware of the device orientation. A good place to start is androidx.compose.ui.platform
To further demonstrate your knowledge of the answer - include a screenshot of a modified version of your quadrants to handle a 3x2 to 2x3 switch. Add as a final commit to your quadrants branch.
Editing our application to use a 3x2 grid layout in portrait and a 2x3 in landscape offers several advantages. When in landscape orientation screens are wider than they are tall, making a 2x3 layout a more efficient use of available space. This allows us to display more items on screen at once which creates visually balanced proportions. Similarly in portrait mode we can fit more items on screen, making better use of available space.
If we were to implement a 3x2 layout in landscape using LazyVerticalGrid we would also see performance related benefits. LazyVerticalGrid only renders items currently visible on screen which is useful for conserving memory. This can be particularly important when displaying images that are resource intensive. LazyVerticalGrid also recycles view components as users scroll through the screen, which drastically improves performance with large datasets.
To achieve this layout within our own application we can use components of Jetpack Compose to dynamically adjust the layout depending on device orientation.
‘LocalConfiguration’ provides access to the device’s current configuration. This includes properties such as orientation and screen size. ‘configuration.orientation’ checks whether the screen is currently landscape or portrait. The ‘isPortrait’ flag allows our code to chose between the different layouts, 3x2 for portrait or 2x3 for landscape.
If the device is in portrait mode, the code creates three rows with each row containing two quadrants.
If the device is in landscape then it creates two rows each containing three quadrants.
The above screenshot displays what the updated application looks like in portrait and landscape after these changes.
| First Part |
Extension |
|---|---|
 |
 |
Woof displays a list of Cards. The Material 3 API offers several card definitions.
https://developer.android.com/reference/kotlin/androidx/compose/material3/package-summary
Having looked at this documentation, please list the changes that will need to be made to produce the following effect on a card - a pressed state that removes a dropped shadow. See the screenshot, this shows an elevated default state with a raised shadow and a pressed state with no elevation.
While this type of material change is the default behaviour for a Pressed State, how could this be overriden so that a border is added on the Pressed state.
Useful information can be found at:
https://developer.android.com/develop/ui/compose/touch-input/user-interactions/handling-interactions
Please add an additional commit to your woof branch and include a screenshot similar to the one shown. Please note the the colour of your card is unimportant and you should just use the card colours that you currently have in your project.
Using the Material 3 Documentation we can update our code so that the ‘Card’ composable shows elevation in its default state. We can also make our application remove elevation when a card is pressed. This can be achieved via the following:
- Create a state variable that will toggle between true and false. The following code snippet creates a variable that toggles between true or false.
- Add an ‘onClick’ handler that toggles ‘isPressed’ each time a card is clicked. The code snippet below handles this.
- Configure elevation based on state by changing the elevation conditionally. When ‘isPressed = true’ elevation is set to 0.dp removing the shadow. When ‘isPressed = false’ elevation is set to 8.dp, creating a visible drop shadow.
To remove the drop shadow from our Card composable and add a border when pressed, we set elevation to 0.dp and apply a BorderStroke when isPressed is true. Since Material 3’s default Card behavior only adjusts elevation, our code overrides this by conditionally adding a border.
The below screenshots show both versions of our updated application based on this question.
| First Part |
Extension |
|---|---|
 |
 |
In the documentation for Compose and LazyColumn, there is the paragraph:
https://developer.android.com/jetpack/compose/lists
“If you need to display a large number of items (or a list of an unknown length), using a layout such as Column can cause performance issues, since all the items will be composed and laid out whether or not they are visible.”
Using the LayoutInspector tool and the Affirmation example further explain the above statement. It is expected that your included answer will include a screenshot from the LayoutInspector tool that shows the issue with using Column rather than LazyColumn for long lists.
Layout Inspector is a tool inside of Android Studio that will show live views from the emulator
https://developer.android.com/studio/debug/layout-inspector
HINT: You will need to change the composable for the Affirmation example to:
The problem facing regular columns is that they compose and store all items in memory simultaneously, regardless of whether they’re screen or not. With long lists of items this can cause excessive memory usage and potential crashes. The layout inspector screenshot of our application shows this problem in more detail. We can see that card composables are all being loaded at once, despite only 4 cards being visible on screen at any time.
As seen in our LazyColumn screenshot, it only composes and loads the Cards that are currently visible on screen or slightly beyond the visible area. LazyColumn loads items as they're scrolled into view and disposes of items that are scrolled out of view. This significantly reduces memory usage and improves performance, especially when dealing with long lists of complex composables. We can see that using Lazy Column only four of our Affirmation cards are being loaded at once.