Image for post
Image for post

Since the introduction of the Navigation Component on Android, navigating the different parts of our application has become much more pleasant to implement. We’ve been able to better decouple navigation logic from our activities and fragments, along with being able to test these paths with more ease. However, the Navigation Component has only ever allowed us to achieve these things with components contained within Android application or library modules — with these not being the only kind of modules that our Android projects support, developers have been eager for more module type inclusion for the navigation component. …


Image for post
Image for post

That time of the year has come, a new Android version is on the horizon! As announced in a blog post earlier this week, the first developer preview of Android 11 is now available — along with details on some of the changes that are happening. With this announcement come some changes to how the system operates when it comes to permissions and how this will affect applications — I wanted to take this chances to flesh out some of these changes and share some thoughts around them.

This was originally posted on joebirch.co

One-time permissions

Currently when we grant an application some permission to access certain data (or perform a certain task) we get several options on the scope of that access. For example, if an application wants to access my location then I can either grant access whilst the app is being used, or deny access. I’ve always felt a bit skeptical about this — whilst the feature I am using at that time might require my location, I don’t really want the app having access to my location whenever it pleases (whilst the app is open). Whilst we can go into an application settings through the system and revoke access, some users may not be aware of this. With this in mind, having the option to only grant access (meaning, grant it all the time) feels like a big commitment. …


Image for post
Image for post

This was originally posted at joebirch.co

In many screens of our applications it’s likely that we’re making use of a Toolbar / AppBar within our Android applications. When it comes to building apps with Jetpack Compose, we’re going to want to recreate this component. In this article we’re going to take a look at the Top App Bar component which allows us to do so.

There is a supporting video for this blog post if you would prefer to learn about the Top App Bar through that medium:

The TopAppBar component is often used as the header for our screen — displaying a navigational title along with menu components or any other decorations that the design of our application requires. Within Jetpack Compose, this component can be created via two different functions. …


Image for post
Image for post

Within Android Studio 4.0 Canary 1 we can start exploring Jetpack compose, a new way to build the UI for your android applications in a declarative manner. To get started with jetpack compose, there is a great tutorial on the official developer site. In this series of articles I want to dive into each of the components that are available, exploring how we can utilise each of them within our applications.

This was originally posted on my personal blog

In this article we’re going to start with the Button component, something that we’re likely to use in most of our applications. Let’s image that we’re creating a button for the authentication screen of our app — here we’re going to create a new Button component. The Button is a composable component — there are two functions which can be used to build this. The first takes the text (used to declare the text displayed on the button), onClick (used to handle click events on the button) and style (used to handle the style of the button) attributes. …


Image for post
Image for post

I’ve always known about the GDE program. Even when I started to dive into Android development, I remember seeing a few Android developers who were GDEs — these are some of the people who I started to learn android from in the beginning. I was attending university at this time when I started learning Android — we didn’t have a specific course or module that covered mobile development, it was just something that I wanted to pursue alongside my other modules. …


Image for post
Image for post

When it comes to manipulating our user interfaces within Android applications, there are a couple of approaches that we can take. In these cases, we need to obtain a reference these views in-order to manipulate them in some way. For this, we’ll either use findViewById(), followed by casting the view to the corresponding type. Or if we’re using kotlin, then we’ll use the kotlin android extensions to perform synthetic access to the views from our layout files. Whilst these two are perfectly fine approaches to take, they do come with some possible pitfalls:

  • When using findViewById, the casting of view types is not type safe. This means that whilst we may think that we are accessing a specific type of view that we have casted to, the view we are referencing from our layout could actually be of a different type. This is more common to happen than you may think — maybe it’s a simple error you’ve made in a file you’re familiar with or an incorrect reference to the wrong view component from your XML file, with casting in place this will cause a class cast exception. …


Image for post
Image for post

We’ve all been there are some point — using our Android device and things start to feel like they’re getting a bit warm in our hands. Whether we’re playing a game or using an application that is performing an intensive operation, these things can often require a lot of resources which makes our device work harder.

In these kind of situations, applications should attempt to reduce the amount of resources that they are consuming in an attempt to bring the device out of that high temperature zone. If we’re playing a game then maybe it could reduce the frame rate being used, or the streaming app that we’re using could reduce the resolution being used for the media content. …


Image for post
Image for post

Settings screens provide a way for our users to configure our application for the way in which they want it to look, feel and behave. …


Image for post
Image for post

This article was originally posted on joebirch.co

If you’ve ever used the Camera APIs on Android, you may have felt that they’ve never been the simplest thing to implement. There was originally the Camera API, which was deprecated in favour of the Camera2 API — this iteration aimed to provide developers with a better experience when dealing with camera APIs on Android. However, with this there was still a lot of boilerplate involved when using the camera API (even for simple use cases) and a lot of the difficulties still existed when it came to dealing with implementing camera features within Android applications. …


Image for post
Image for post

This was originally posted on joebirch.co:

I’m sure there has often been a time when you’ve needed to send out an app update that has some form of urgency — maybe there’s a security issue or some bug which is causing a lot of issues for users. …

About

Joe Birch

Android Engineering Lead at Buffer, Google Developer Expert for Android & Flutter - Passionate about mobile development and learning. www.joebirch.co

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store