Automatically close Angular Material Sidenav when menu element is clicked

I’ve recently started digging deeper into Angular Material – the UI kit by Google to be used in Angular projects.

The stack of components available is pretty rich and flexible and includes a variety of things that you can use to quickly scaffold an application, including a Toolbar, Menu, Sidenav, etc.

One thing that I discovered that doesn’t come out of the box is the ability to automatically hide the Sidenav (left side menu) when you click on some of the menu items. Here’s an example structure that I had for a recent project:

The left side is the <mat-sidenav> component and the right side (the table) is wrapped in a <mat-sidenav-content> component. Both of them are wrapped in a <mat-sidenav-container> component.

I wanted to automatically hide the sidebar whenever any of the menu elements: Homepage, Transactions, Accounts, My profile – is being clicked. The solution was pretty simple actually:

<mat-sidenav-container class="example-container">
  <mat-sidenav #sidenav (click)="sidenav.toggle()">
    // My menu is here
  </mat-sidenav>
  <mat-sidenav-content>
    // My main content is here
  </mat-sidenav-content>
</mat-sidenav-container>

The trick is to call sidenav.toggle() when a click is triggered on the <mat-sidenav> component.

Error while uploading APK to Firebase Test Lab: “The uploaded APK does not have a valid signature”. Reason and solution

Recently, while experimenting with Firebase’s new features in general, and more specifically – a tool called Test Lab, I encountered the following issue: whenever I tried to upload the APK file that I exported from Android Studio (the production-ready version of an Android app), the Test Lab was constantly throwing an ambiguous error: “The uploaded APK does not have a valid signature”.

After some searching around, the reason and the subsequent solution, was pretty clear. Here’s why this error occurs:

Android “Nougat” (SDK v7) introduced a new APK signature sheme v2, which comes with its own benefits over the old v1 signature scheme, as described well in its documentation:

APK Signature Scheme v2 is a whole-file signature scheme that increases verification speed and strengthens integrity guarantees by detecting any changes to the protected parts of the APK.

Signing using APK Signature Scheme v2 inserts an APK Signing Block into the APK file immediately before the ZIP Central Directory section. Inside the APK Signing Block, v2 signatures and signer identity information are stored in an APK Signature Scheme v2 Block.

https://source.android.com/security/apksigning/v2

Reason

Since the v2 signing scheme was introduced in Android 7.0, APKs signed with this scheme can not be installed on older Android devices like Android 6.0 Marshmallow. Firebase Test Lab contains a variety of Android versions you can test against, including those that are pre-7.0. For this reason, it requires that the APK that you upload is signed with the older, widely-supported v1 APK signing schema.

Solution

  1. Inside Android Studio choose Build -> Generated signed Bundle / APK
  2. Choose APK on the first step (I think Android App Bundle is still not supported in Firebase Test Lab as of writing this)
  3. Select your provide key and enter the passwords in the next step.
  4. IMPORTANT: In the last step where you select the build variant and flavor, make sure Signature version V1 (Jar Signature) is selected:

Fixing a failing Composer installation: Unable to write keys.dev.pub to: /home/$USER/.composer

Recently, I started a project which uses Composer as a dependency management system. In the spirit of reducing the dependencies on the host system, I wanted to bundle even Composer itself inside the project’s source code. This is possible by downloading and including a composer.phar at the root of the project. However, failing Composer installation is not something new to developers, especially if you haven’t used it before.

What is composer.phar?

It’s basically a PHP script that contains the core functionality of Composer – namely, the ability to read a composer.json/composer.lock file (a JSON definition of the project’s dependencies) and manage those dependencies – download them, resolve them to the best possible version, lock them to a version, etc.

How to download composer.phar?

There are basically two main ways to download the composer.phar:

  • Programmatically (easier)
  • Manual (safer)

For my most recent project, I opted for the programmatical approach, which is documented on the Composer website.

Using that approach, you pretty much have to run a single command:

wget https://raw.githubusercontent.com/composer/getcomposer.org/76a7060ccb93902cd7576b67264ad91c8a2700e2/web/installer -O - -q | php -- --quiet
Note: The command above is up to date as of writing this but may change in the future. For the up to date version, go through the website link above.
Troubleshooting: Composer installation error on Ubuntu – “Failing Composer installation: Unable to write keys.dev.pub to: /home/$USER/.composer”

Occasionally, I stumble upon this error when I try to include Composer in a real life project. The error is kind of ambiguous, but the reason behind it is pretty clear: your current user doesn’t have ownership over the /home/$USER/.composer folder OR some of the files inside.

Solution: Change the ownership of the .composer folder to be owned by your user ($USER is a variable that always refers to the current user in UNIX systems):

sudo chown $USER -R /home/$USER/.composer

Let me know in the comments if that worked for you. If you are still struggling with Composer issues, I am available for paid consulting.