android

Swipe to dismiss compose fun

Let’s start with the official docs

The official documentation about drag swipe and fling can be found here: Drag, swipe, and fling. However, when you write the code you realize it’s deprecated due to a newer more flexible API that lives in the Compose Foundation layer instead of being only available through Compose Material. Google have provided an article detailing how to migrate from the old APIs to the new ones available here: Migrate from Swipeable to AnchoredDraggable. In this article however, we will use directly the new APIs to build our swipe to dismiss.

Observe as state is the new post value

LiveData - To set value or to postValue?

Before the times of Jetpack Compose, we used to directly observe LiveData for changes in Android components that have lifecycle, such as for example Activity and Fragment. When writing updates to the LiveData, we have two options to choose from - setValue and postValue. The first one is synchronous operation and has to be executed on the main thread. The second one is asynchronous and can be invoked on other threads. PostValue internally schedules an update to be executed on the main thread Looper for the next Looper cycle, similar to how we can call post or postDelayed on a view.

Don’t let the scope trick you

Kotlin standard library scope functions

The Kotlin language standard library comes with numerous very useful functions. Probably the most often used ones are the scope functions let, with, run, also, apply. In this post we will focus only on a common use case for the function let. For further information about the others please refer to the official library documentation available here: Kotlin standard library

Bound services with Messenger

Android inter-process communication (IPC)

TL;DR; if you want to get a very good understanding into how Android inter-process communication works, check out the following outstanding video about the Android Binder framework internals. It is long, but I really recommend it!

Alarms and Pending Intents

The Android SDK offers an API for scheduling one time or recurring events called alarms. This is for example how your alarm clock applications work, or how a reminder for a calendar event is triggered. It’s pretty simple to use but is has some specific behavior, which you need to take in account. In this post I will describe some of the problems I have encountered when not completely understanding how this API works.

Android clean architecture part 5

Some time has passed since the last clean architecture post. During this time the described architecture implementation has shown some of its drawbacks. In this post I will shortly describe the problems with the current implementation and propose some solutions to these problems. As usual you can find the updated version of the demo application Carbrands in its repository at GitHub - Repository Link.

Android clean architecture part 4

Although one could write a detailed description of the concepts and ideas behind an architecture, I believe that the easiest way to understand it is to see an example. Therefore, I have built a simple demo application, which is built with the VIPER architecture in mind. The following sections describe the application and some specifics related to Android.

Android clean architecture part 3

Android clean architecture

The first resource I would like to present is a superb blogpost by Fernando Cejas. Link

Android clean architecture part 2

The drama we have avoided

I guess every developer has at some point tried to come up with some clean architectural model. Most of the time, however, this happens in a late stage of the project, thus incorporating any particular architecture more often than not requires major refactoring and complete rebuild of many components. This is a pretty high cost, which the product management often does not want to pay, because it will probably not bring any direct benefit or improvement to the product’s users and the project’s stakeholders. Therefore, it never happens and the problems keep deepening until somebody burns out, screams loudly or becomes increasingly unhappy with his job and eventually quits. In order to avoid such dramatic events, our team has looked for some clean architecture from the very start of our project.

Android clean architecture part 1

Y U NO POST

Lately I have been pretty busy visiting different meetups, having some proper social life, working on my private projects and building apps at my work, thus this huge delay since the last post I have written. I want to talk about something I am particularly proud of. At the beginning of the year I have done a whole week of experiments and have put a lot of thought in order to come up with an Android version of the architecture, which our team used while building our iOS application. The main goal was to use the same familiar “architectural language”, which we have developped in our iOS application. This way we do not have to pay too high cost when switching between developing for iOS and Android. We have tried to establish a common language understood by all mobile developers, and I believe that we have succeeded. We have managed to build a pretty complex Android application with a lots of moving parts, which still feels quite right and does not bring us a lot of headaches. I have noticed that we tend to write almost the same subtasks for both platforms when implementing new features into our apps. I consider this a vital sign, showing that we have managed to achieve a harmony between our native implementations for iOS and Android. Therefore, I have decided to share some of the know-how and experience, which we have collected throughout the last months.

Apps just got sweeter talk

Today I have given a talk at a meetup of the Google Developer Group in Munich about Material Design. I have shared some insights and hands on experience collected during the process of redesiging one of my private apps - AppDetox.

Touch stealing wrapper

A couple of weeks ago I have been developing a new feature at my job, which included a lot of user interaction with a map. Althoug the MapView class provided with the Google Play Services SDK is really nice and easy to use, I had a case, which required me to do a very specific thing - get notified when a user interacts with the map itself without actually allowing touch events to go through in some occasions. It was crucial that I get notified before the touch event reaches the MapView itself.

ImageView scale types

When you build an app you have to think about thousand different things and probably you are like me and forget all the time the small details about a particular class of the framework. A common example is showing images in your app. Sometimes its just enough to add an ImageView to the layout and don’t care too much about all its specific parameters, but most of the time you’ll need to set up at least its ScaleType. This post does not present anything novel about this class, but I’m writing it as a reminder for myself and you about common ImageView configurations and some wanted or unwanted effects resulting from them.

Google Play permissions list style update

If you have been paying attention when installing new apps lately, you have definitely noticed the changes in the design of the pop-up dialog with permissions, which is presented to users in Google Play. Google design and user experience experts have worked together to come up with an improved version of this piece of UI. It is no longer a simple list of scary sounding names coupled with very technical and sometimes misleading short descriptions.

Permissions, features and Google Play

I have been dealing with adding extra features and permissions to an app I have worked on lately. Through the process I bumped into many problems since I had not fully understood a couple of concepts related to them. I would like to share some of them with you so that you do not miss them when reading the official documentation.

Headless fragments

When Fragments were introduced a couple of years ago, they were presented as reusable UI compontents which could co-exist in the same Activity. They also provide features related to backstack, which were not available before when people did the same thing using fat custom view. I will not go into much detail about all the features Fragments provide for building a dynamic and modern App UI. In this post I will focus on another property of Fragments, which many people are not familiar with, or just forget when they build Apps.

Messaging with LocalBroadcastManager

I guess every Android developer had at some point bumped into a callback hell, where you have to propagate some callback interface through thousands of objects in order to be able to do something when a user clicks on some UI element. And it gets even worse when you for example make it work across configuration changes such as orientation change. I had a similar pain a couple of weeks ago and had to come up with some solution to do the job without polluting all my UI components with huge amount of boilerplate.

Activity Intents builder

This post proposes an Android development pattern I have came up with while trying to refactor an ugly looking code (I was responsible for most of it anyway). You probably are familiar with programming a simple piece of code, which at some point after adding a ton of new options starts to get seriously cumbersome. At this point one has to do some refactoring to eliminate at least the serious code duplication which inevitably already exists.

Back to Top ↑

software development

Swipe to dismiss compose fun

Let’s start with the official docs

The official documentation about drag swipe and fling can be found here: Drag, swipe, and fling. However, when you write the code you realize it’s deprecated due to a newer more flexible API that lives in the Compose Foundation layer instead of being only available through Compose Material. Google have provided an article detailing how to migrate from the old APIs to the new ones available here: Migrate from Swipeable to AnchoredDraggable. In this article however, we will use directly the new APIs to build our swipe to dismiss.

Observe as state is the new post value

LiveData - To set value or to postValue?

Before the times of Jetpack Compose, we used to directly observe LiveData for changes in Android components that have lifecycle, such as for example Activity and Fragment. When writing updates to the LiveData, we have two options to choose from - setValue and postValue. The first one is synchronous operation and has to be executed on the main thread. The second one is asynchronous and can be invoked on other threads. PostValue internally schedules an update to be executed on the main thread Looper for the next Looper cycle, similar to how we can call post or postDelayed on a view.

Don’t let the scope trick you

Kotlin standard library scope functions

The Kotlin language standard library comes with numerous very useful functions. Probably the most often used ones are the scope functions let, with, run, also, apply. In this post we will focus only on a common use case for the function let. For further information about the others please refer to the official library documentation available here: Kotlin standard library

Bound services with Messenger

Android inter-process communication (IPC)

TL;DR; if you want to get a very good understanding into how Android inter-process communication works, check out the following outstanding video about the Android Binder framework internals. It is long, but I really recommend it!

Watch your returns in inline functions

Kotlin is a great programming language and I guess all Android developers have already started adopting it in their code base. However, it has a learning curve and numerous language features, which Java does not have. In order to write bug-free code, we need to be extra careful when using these new features, simply because we might make mistakes due to our years of Java coding. The following example mistake might be an extreme corner case, but it still managed to slip through code review.

Alarms and Pending Intents

The Android SDK offers an API for scheduling one time or recurring events called alarms. This is for example how your alarm clock applications work, or how a reminder for a calendar event is triggered. It’s pretty simple to use but is has some specific behavior, which you need to take in account. In this post I will describe some of the problems I have encountered when not completely understanding how this API works.

Android clean architecture part 5

Some time has passed since the last clean architecture post. During this time the described architecture implementation has shown some of its drawbacks. In this post I will shortly describe the problems with the current implementation and propose some solutions to these problems. As usual you can find the updated version of the demo application Carbrands in its repository at GitHub - Repository Link.

Android clean architecture part 4

Although one could write a detailed description of the concepts and ideas behind an architecture, I believe that the easiest way to understand it is to see an example. Therefore, I have built a simple demo application, which is built with the VIPER architecture in mind. The following sections describe the application and some specifics related to Android.

Android clean architecture part 3

Android clean architecture

The first resource I would like to present is a superb blogpost by Fernando Cejas. Link

Android clean architecture part 2

The drama we have avoided

I guess every developer has at some point tried to come up with some clean architectural model. Most of the time, however, this happens in a late stage of the project, thus incorporating any particular architecture more often than not requires major refactoring and complete rebuild of many components. This is a pretty high cost, which the product management often does not want to pay, because it will probably not bring any direct benefit or improvement to the product’s users and the project’s stakeholders. Therefore, it never happens and the problems keep deepening until somebody burns out, screams loudly or becomes increasingly unhappy with his job and eventually quits. In order to avoid such dramatic events, our team has looked for some clean architecture from the very start of our project.

Android clean architecture part 1

Y U NO POST

Lately I have been pretty busy visiting different meetups, having some proper social life, working on my private projects and building apps at my work, thus this huge delay since the last post I have written. I want to talk about something I am particularly proud of. At the beginning of the year I have done a whole week of experiments and have put a lot of thought in order to come up with an Android version of the architecture, which our team used while building our iOS application. The main goal was to use the same familiar “architectural language”, which we have developped in our iOS application. This way we do not have to pay too high cost when switching between developing for iOS and Android. We have tried to establish a common language understood by all mobile developers, and I believe that we have succeeded. We have managed to build a pretty complex Android application with a lots of moving parts, which still feels quite right and does not bring us a lot of headaches. I have noticed that we tend to write almost the same subtasks for both platforms when implementing new features into our apps. I consider this a vital sign, showing that we have managed to achieve a harmony between our native implementations for iOS and Android. Therefore, I have decided to share some of the know-how and experience, which we have collected throughout the last months.

Apps just got sweeter talk

Today I have given a talk at a meetup of the Google Developer Group in Munich about Material Design. I have shared some insights and hands on experience collected during the process of redesiging one of my private apps - AppDetox.

Touch stealing wrapper

A couple of weeks ago I have been developing a new feature at my job, which included a lot of user interaction with a map. Althoug the MapView class provided with the Google Play Services SDK is really nice and easy to use, I had a case, which required me to do a very specific thing - get notified when a user interacts with the map itself without actually allowing touch events to go through in some occasions. It was crucial that I get notified before the touch event reaches the MapView itself.

ImageView scale types

When you build an app you have to think about thousand different things and probably you are like me and forget all the time the small details about a particular class of the framework. A common example is showing images in your app. Sometimes its just enough to add an ImageView to the layout and don’t care too much about all its specific parameters, but most of the time you’ll need to set up at least its ScaleType. This post does not present anything novel about this class, but I’m writing it as a reminder for myself and you about common ImageView configurations and some wanted or unwanted effects resulting from them.

Headless fragments

When Fragments were introduced a couple of years ago, they were presented as reusable UI compontents which could co-exist in the same Activity. They also provide features related to backstack, which were not available before when people did the same thing using fat custom view. I will not go into much detail about all the features Fragments provide for building a dynamic and modern App UI. In this post I will focus on another property of Fragments, which many people are not familiar with, or just forget when they build Apps.

Messaging with LocalBroadcastManager

I guess every Android developer had at some point bumped into a callback hell, where you have to propagate some callback interface through thousands of objects in order to be able to do something when a user clicks on some UI element. And it gets even worse when you for example make it work across configuration changes such as orientation change. I had a similar pain a couple of weeks ago and had to come up with some solution to do the job without polluting all my UI components with huge amount of boilerplate.

Activity Intents builder

This post proposes an Android development pattern I have came up with while trying to refactor an ugly looking code (I was responsible for most of it anyway). You probably are familiar with programming a simple piece of code, which at some point after adding a ton of new options starts to get seriously cumbersome. At this point one has to do some refactoring to eliminate at least the serious code duplication which inevitably already exists.

Back to Top ↑

tip

Android clean architecture part 5

Some time has passed since the last clean architecture post. During this time the described architecture implementation has shown some of its drawbacks. In this post I will shortly describe the problems with the current implementation and propose some solutions to these problems. As usual you can find the updated version of the demo application Carbrands in its repository at GitHub - Repository Link.

Android clean architecture part 4

Although one could write a detailed description of the concepts and ideas behind an architecture, I believe that the easiest way to understand it is to see an example. Therefore, I have built a simple demo application, which is built with the VIPER architecture in mind. The following sections describe the application and some specifics related to Android.

Android clean architecture part 3

Android clean architecture

The first resource I would like to present is a superb blogpost by Fernando Cejas. Link

Android clean architecture part 2

The drama we have avoided

I guess every developer has at some point tried to come up with some clean architectural model. Most of the time, however, this happens in a late stage of the project, thus incorporating any particular architecture more often than not requires major refactoring and complete rebuild of many components. This is a pretty high cost, which the product management often does not want to pay, because it will probably not bring any direct benefit or improvement to the product’s users and the project’s stakeholders. Therefore, it never happens and the problems keep deepening until somebody burns out, screams loudly or becomes increasingly unhappy with his job and eventually quits. In order to avoid such dramatic events, our team has looked for some clean architecture from the very start of our project.

Android clean architecture part 1

Y U NO POST

Lately I have been pretty busy visiting different meetups, having some proper social life, working on my private projects and building apps at my work, thus this huge delay since the last post I have written. I want to talk about something I am particularly proud of. At the beginning of the year I have done a whole week of experiments and have put a lot of thought in order to come up with an Android version of the architecture, which our team used while building our iOS application. The main goal was to use the same familiar “architectural language”, which we have developped in our iOS application. This way we do not have to pay too high cost when switching between developing for iOS and Android. We have tried to establish a common language understood by all mobile developers, and I believe that we have succeeded. We have managed to build a pretty complex Android application with a lots of moving parts, which still feels quite right and does not bring us a lot of headaches. I have noticed that we tend to write almost the same subtasks for both platforms when implementing new features into our apps. I consider this a vital sign, showing that we have managed to achieve a harmony between our native implementations for iOS and Android. Therefore, I have decided to share some of the know-how and experience, which we have collected throughout the last months.

Apps just got sweeter talk

Today I have given a talk at a meetup of the Google Developer Group in Munich about Material Design. I have shared some insights and hands on experience collected during the process of redesiging one of my private apps - AppDetox.

Touch stealing wrapper

A couple of weeks ago I have been developing a new feature at my job, which included a lot of user interaction with a map. Althoug the MapView class provided with the Google Play Services SDK is really nice and easy to use, I had a case, which required me to do a very specific thing - get notified when a user interacts with the map itself without actually allowing touch events to go through in some occasions. It was crucial that I get notified before the touch event reaches the MapView itself.

ImageView scale types

When you build an app you have to think about thousand different things and probably you are like me and forget all the time the small details about a particular class of the framework. A common example is showing images in your app. Sometimes its just enough to add an ImageView to the layout and don’t care too much about all its specific parameters, but most of the time you’ll need to set up at least its ScaleType. This post does not present anything novel about this class, but I’m writing it as a reminder for myself and you about common ImageView configurations and some wanted or unwanted effects resulting from them.

Google Play permissions list style update

If you have been paying attention when installing new apps lately, you have definitely noticed the changes in the design of the pop-up dialog with permissions, which is presented to users in Google Play. Google design and user experience experts have worked together to come up with an improved version of this piece of UI. It is no longer a simple list of scary sounding names coupled with very technical and sometimes misleading short descriptions.

Image file extentions in posts

Although writing posts in a Jekyll based static website is fairly simple, sometimes you might bump into an unexpected WTF situations. Typically you would build the website locally on your machine to see everything looks nice, before pushing it to Github Pages. However, you can never be 100% sure that everything will work there as well, since the server which hosts your Github page is probably a very different machine running a different OS with different configuration.

Permissions, features and Google Play

I have been dealing with adding extra features and permissions to an app I have worked on lately. Through the process I bumped into many problems since I had not fully understood a couple of concepts related to them. I would like to share some of them with you so that you do not miss them when reading the official documentation.

Headless fragments

When Fragments were introduced a couple of years ago, they were presented as reusable UI compontents which could co-exist in the same Activity. They also provide features related to backstack, which were not available before when people did the same thing using fat custom view. I will not go into much detail about all the features Fragments provide for building a dynamic and modern App UI. In this post I will focus on another property of Fragments, which many people are not familiar with, or just forget when they build Apps.

Messaging with LocalBroadcastManager

I guess every Android developer had at some point bumped into a callback hell, where you have to propagate some callback interface through thousands of objects in order to be able to do something when a user clicks on some UI element. And it gets even worse when you for example make it work across configuration changes such as orientation change. I had a similar pain a couple of weeks ago and had to come up with some solution to do the job without polluting all my UI components with huge amount of boilerplate.

Activity Intents builder

This post proposes an Android development pattern I have came up with while trying to refactor an ugly looking code (I was responsible for most of it anyway). You probably are familiar with programming a simple piece of code, which at some point after adding a ton of new options starts to get seriously cumbersome. At this point one has to do some refactoring to eliminate at least the serious code duplication which inevitably already exists.

Back to Top ↑

pattern

Android clean architecture part 5

Some time has passed since the last clean architecture post. During this time the described architecture implementation has shown some of its drawbacks. In this post I will shortly describe the problems with the current implementation and propose some solutions to these problems. As usual you can find the updated version of the demo application Carbrands in its repository at GitHub - Repository Link.

Android clean architecture part 4

Although one could write a detailed description of the concepts and ideas behind an architecture, I believe that the easiest way to understand it is to see an example. Therefore, I have built a simple demo application, which is built with the VIPER architecture in mind. The following sections describe the application and some specifics related to Android.

Android clean architecture part 3

Android clean architecture

The first resource I would like to present is a superb blogpost by Fernando Cejas. Link

Android clean architecture part 2

The drama we have avoided

I guess every developer has at some point tried to come up with some clean architectural model. Most of the time, however, this happens in a late stage of the project, thus incorporating any particular architecture more often than not requires major refactoring and complete rebuild of many components. This is a pretty high cost, which the product management often does not want to pay, because it will probably not bring any direct benefit or improvement to the product’s users and the project’s stakeholders. Therefore, it never happens and the problems keep deepening until somebody burns out, screams loudly or becomes increasingly unhappy with his job and eventually quits. In order to avoid such dramatic events, our team has looked for some clean architecture from the very start of our project.

Android clean architecture part 1

Y U NO POST

Lately I have been pretty busy visiting different meetups, having some proper social life, working on my private projects and building apps at my work, thus this huge delay since the last post I have written. I want to talk about something I am particularly proud of. At the beginning of the year I have done a whole week of experiments and have put a lot of thought in order to come up with an Android version of the architecture, which our team used while building our iOS application. The main goal was to use the same familiar “architectural language”, which we have developped in our iOS application. This way we do not have to pay too high cost when switching between developing for iOS and Android. We have tried to establish a common language understood by all mobile developers, and I believe that we have succeeded. We have managed to build a pretty complex Android application with a lots of moving parts, which still feels quite right and does not bring us a lot of headaches. I have noticed that we tend to write almost the same subtasks for both platforms when implementing new features into our apps. I consider this a vital sign, showing that we have managed to achieve a harmony between our native implementations for iOS and Android. Therefore, I have decided to share some of the know-how and experience, which we have collected throughout the last months.

Activity Intents builder

This post proposes an Android development pattern I have came up with while trying to refactor an ugly looking code (I was responsible for most of it anyway). You probably are familiar with programming a simple piece of code, which at some point after adding a ton of new options starts to get seriously cumbersome. At this point one has to do some refactoring to eliminate at least the serious code duplication which inevitably already exists.

Back to Top ↑

architecture

Android clean architecture part 5

Some time has passed since the last clean architecture post. During this time the described architecture implementation has shown some of its drawbacks. In this post I will shortly describe the problems with the current implementation and propose some solutions to these problems. As usual you can find the updated version of the demo application Carbrands in its repository at GitHub - Repository Link.

Android clean architecture part 4

Although one could write a detailed description of the concepts and ideas behind an architecture, I believe that the easiest way to understand it is to see an example. Therefore, I have built a simple demo application, which is built with the VIPER architecture in mind. The following sections describe the application and some specifics related to Android.

Android clean architecture part 3

Android clean architecture

The first resource I would like to present is a superb blogpost by Fernando Cejas. Link

Android clean architecture part 2

The drama we have avoided

I guess every developer has at some point tried to come up with some clean architectural model. Most of the time, however, this happens in a late stage of the project, thus incorporating any particular architecture more often than not requires major refactoring and complete rebuild of many components. This is a pretty high cost, which the product management often does not want to pay, because it will probably not bring any direct benefit or improvement to the product’s users and the project’s stakeholders. Therefore, it never happens and the problems keep deepening until somebody burns out, screams loudly or becomes increasingly unhappy with his job and eventually quits. In order to avoid such dramatic events, our team has looked for some clean architecture from the very start of our project.

Android clean architecture part 1

Y U NO POST

Lately I have been pretty busy visiting different meetups, having some proper social life, working on my private projects and building apps at my work, thus this huge delay since the last post I have written. I want to talk about something I am particularly proud of. At the beginning of the year I have done a whole week of experiments and have put a lot of thought in order to come up with an Android version of the architecture, which our team used while building our iOS application. The main goal was to use the same familiar “architectural language”, which we have developped in our iOS application. This way we do not have to pay too high cost when switching between developing for iOS and Android. We have tried to establish a common language understood by all mobile developers, and I believe that we have succeeded. We have managed to build a pretty complex Android application with a lots of moving parts, which still feels quite right and does not bring us a lot of headaches. I have noticed that we tend to write almost the same subtasks for both platforms when implementing new features into our apps. I consider this a vital sign, showing that we have managed to achieve a harmony between our native implementations for iOS and Android. Therefore, I have decided to share some of the know-how and experience, which we have collected throughout the last months.

Back to Top ↑

kotlin

Swipe to dismiss compose fun

Let’s start with the official docs

The official documentation about drag swipe and fling can be found here: Drag, swipe, and fling. However, when you write the code you realize it’s deprecated due to a newer more flexible API that lives in the Compose Foundation layer instead of being only available through Compose Material. Google have provided an article detailing how to migrate from the old APIs to the new ones available here: Migrate from Swipeable to AnchoredDraggable. In this article however, we will use directly the new APIs to build our swipe to dismiss.

Observe as state is the new post value

LiveData - To set value or to postValue?

Before the times of Jetpack Compose, we used to directly observe LiveData for changes in Android components that have lifecycle, such as for example Activity and Fragment. When writing updates to the LiveData, we have two options to choose from - setValue and postValue. The first one is synchronous operation and has to be executed on the main thread. The second one is asynchronous and can be invoked on other threads. PostValue internally schedules an update to be executed on the main thread Looper for the next Looper cycle, similar to how we can call post or postDelayed on a view.

Don’t let the scope trick you

Kotlin standard library scope functions

The Kotlin language standard library comes with numerous very useful functions. Probably the most often used ones are the scope functions let, with, run, also, apply. In this post we will focus only on a common use case for the function let. For further information about the others please refer to the official library documentation available here: Kotlin standard library

Bound services with Messenger

Android inter-process communication (IPC)

Back to Top ↑