# background-work Published articles for background-work. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Background Work, Push Topics, And Richer Notifications DevFeed: [Background Work, Push Topics, And Richer Notifications]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-06-09T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [Mobile](), [Development](), [Android](), [iOS]() Tags: [android](), [background-work](), [development](), [ios](), [mobile-development](), [network](), [notifications](), [permission]() ### AI overview This article describes Codename One updates for constraint-based background work, foreground services, push topic subscriptions, shared-content handling, richer local notifications, and simulator support across Android and iOS. ### Source excerpt Constraint-based background work, foreground services, push topic subscriptions, shared-content handling, and a much richer local notification API, all with full simulator support. ## Waiting for PostgreSQL 19 - Online enabling and disabling of data checksums DevFeed: [Waiting for PostgreSQL 19 - Online enabling and disabling of data checksums]() Original publisher: [Read original article]() Author: depesz Published: 2026-04-15T18:05:36Z Content type: article Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [postgresql clusters](), [async](), [IO]() Tags: [async](), [background](), [background-work](), [checksums](), [data-checksum](), [io](), [pg19](), [postgresql](), [uncategorized](), [vacuum](), [waiting]() ### AI overview This article examines a PostgreSQL 19 patch that allows data checksums to be enabled or disabled while a cluster is running. The command is immediate, but rewriting every table and index occurs in the background and can require substantial I/O. The article also discusses cost-delay options for controlling the background worker. ### Source excerpt On 3rd of April 2026, Daniel Gustafsson committed patch: Online enabling and disabling of data checksums This allows data checksums to be enabled, or disabled, in a running cluster without restricting access to the cluster during processing. Data checksums could prior to this only be enabled during initdb or when the cluster is ... Continue reading "Waiting for PostgreSQL 19 - Online enabling and disabling of data checksums" ## How CockroachDB v26.1 Uses Elastic Admission Control and Go Scheduler Changes for Background Work DevFeed: [How CockroachDB v26.1 Uses Elastic Admission Control and Go Scheduler Changes for Background Work]() Original publisher: [Read original article]() Author: David Taylor Published: 2026-04-14T00:00:00Z Content type: article Language: en Sources: [Cockroach Labs]() Topics: [CockroachDB](), [Go Language](), [Concurrent Programming](), [Latency](), [cpu]() Tags: [background-work](), [backups](), [cockroachdb](), [elastic](), [latency](), [processes](), [statistics](), [work]() ### AI overview This article explains how CockroachDB v26.1 uses elastic admission control and a change to the Go runtime scheduler to let background work use spare CPU capacity while limiting its impact on query latency. ### Source excerpt CockroachDB runs background work -- backups, schema changes, statistics collection, changefeeds -- in the same processes that serve user queries. Traditionally, this creates a tension... ## Revision of restrictions on background work from Android 5.0 to 13 DevFeed: [Revision of restrictions on background work from Android 5.0 to 13]() Original publisher: [Read original article]() Author: Kirill Rozov Published: 2022-11-29T12:54:28Z Content type: article Language: en Sources: [Stories by Kirill Rozov on Medium]() Topics: [Android](), [Utility Software](), [Google](), [Google Play]() Tags: [android](), [android-app-development](), [androiddev](), [background-work](), [battery](), [firebase](), [google](), [google-play](), [notifications](), [permissions](), [services](), [sync]() ### AI overview The article reviews how Android background-work restrictions evolved from Android 5.0 through Android 13. It describes earlier background tools, including Alarm Manager, Broadcast Intent, services, Sync Adapter, and Download Manager, and explains that system-performance concerns led to tighter constraints involving background execution, battery use, file-system access, and permissions. ### Source excerpt Background restrictions in Android Once upon a time, running in the background was easy. Now Android has a lot of restrictions: running in the background, access to the file system, permissions that need to be approved by Google Play moderators, and others. Developers have to work with all of them. Let's remember where it all started and how the requirements changed with each new version of Android How it started Before Android 5.0, we had the set of tools to run tasks in the background: Alarm Manager. The tool that allows you to set an alarm on your system and receive notifications. Broadcast Intent. It sends notifications about events that are happening on the system (new messages, for example). Service -- Background, Foreground & Bound. Sync Adapter. A special ancient stuff, which is connected to account management for data synchronization. A clear example: when you set up a Google account in Android, you can set up synchronization of your calendar, contacts and other services. Under the hood, it works through the Sync Adapter. The tool has not lived up to our days. Download Manager. A utility that allows you to download files. It is not very smart, but it is simple and convenient. Google Play, for example, is what downloads files with it. The problems appeared because developers did not follow Spider-Man's rule: "With great opportunities for developers comes responsibility for the speed of the system". Google gave them huge opportunities from the first versions of Android, but did not warn them that they were working in a system that was responsible for quality. When users broke something, they didn't blame third-party developers, they said, "Android is lagging, but everything is fast on the iPhone." It turned out that the developers were good and Google was bad. Google decided to deal with this, but to do this, they had to find "enemies" affecting the quality of applications. They turned out to be: Battery size vs. device size. Everyone wants a thin device that ## Preventing WorkManager crashes when updating Android worker classes DevFeed: [Preventing WorkManager crashes when updating Android worker classes]() Original publisher: [Read original article]() Author: info@jeroenmols.com (Jeroen Mols) Published: 2022-04-27T00:00:00Z Content type: tutorial Language: en Sources: [Jeroen Mols]() Topics: [Android](), [migration](), [App](), [implementation]() Tags: [android](), [background-work](), [blogs](), [crash](), [crashes](), [implementation](), [lifecycle](), [migrate](), [retry](), [scheduled](), [workmanager]() ### AI overview This tutorial explains how Android WorkManager can crash after an app update when pending work references a worker class that was removed, renamed, or moved. It discusses cancelling or migrating pending work and using a custom WorkerFactory. ### Source excerpt WorkManager is great to schedule background work on Android. However, since scheduled work lives outside of the app lifecycle, you might run into unexpected crashes. ## Kotlin's Flow in ViewModels: it's complicated DevFeed: [Kotlin's Flow in ViewModels: it's complicated]() Original publisher: [Read original article]() Author: Christophe Beyls Published: 2021-08-28T10:42:09Z Content type: tutorial Language: en Sources: [Stories by Christophe Beyls on Medium]() Topics: [Android](), [Kotlin](), [Programming]() Tags: [android](), [android-app-development](), [androiddev](), [architecture-components](), [background-work](), [caching](), [configuration](), [flow](), [google](), [kotlin](), [livedata](), [net-conf](), [state](), [ui](), [viewmodel]() ### AI overview This article explains the challenges of loading UI data in Android applications when screen lifecycles and configuration changes are involved. It outlines goals such as caching valid data, pausing background work when screens are inactive, and avoiding unnecessary interruptions during configuration changes, then discusses ViewModel and LiveData as tools for addressing them. ### Source excerpt LiveData is still your friend Loading UI data in Android applications can be challenging. The lifecycles of the various screens need to be taken into account, as well as configuration changes leading to the destruction and recreation of Activities. The individual screens of an app constantly toggle between interactive and hidden as the user navigates further and back in an app, switches from one app to another, or the device screen gets locked or unlocked. Each component needs to play fair and only perform active work when given the ball. Configuration changes happen on various occasions: when changing the device orientation, switching the app to multi-window mode or resizing its window size, switching to dark or light mode, changing the default locale or font sizes, and more. Goals of efficiency To achieve efficient data loading in Activities and Fragments leading to the best user experience, the following should be considered: Caching: data that has been loaded successfully and is still valid should be delivered immediately and not loaded a second time. In particular, when an existing Activity or Fragment becomes visible again, or after an Activity gets recreated on configuration change; Avoiding background work: when an Activity or Fragment becomes invisible (moves from the STARTED to the STOPPED state), any ongoing loading work should be paused or canceled in order to save resources. This is especially important for endless streams of data like location updates or periodic refreshes of any kind; No work interruption during configuration changes: this is an exception to the second goal. During configuration changes, an Activity gets replaced by a new instance of it while preserving its state, so canceling ongoing work when the old instance is destroyed to immediately restart it when the new instance is created would be counter-productive. Today: ViewModel and LiveData To help developers reach these goals with code of manageable complexity, Google released the fir ## IO vs CPU operations DevFeed: [IO vs CPU operations]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2019-06-03T07:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [Programming](), [Concurrent Programming](), [IO](), [cpu](), [Operating system](), [Mobile]() Tags: [background-work](), [cpu](), [io](), [mobile](), [os](), [programming](), [thread]() ### AI overview The article explains why I/O-bound and CPU-bound work should use different thread pools. I/O operations wait on hardware and can leave threads sleeping, while CPU work performs computation; mixing them can delay CPU work behind I/O waits. ### Source excerpt This is a fantastic post by Erik where he explains the nuance between IO-bound and CPU-bound operations in programming. ... libraries have dedicated APIs for I/O scheduling work, separate from other types of operations .... but why is this the case? Why don't we use a single thread pool for all background operations? The operating system will handle the scheduling of these threads the same I love how this specific question is framed (a good interview question for advanced mobile developers): Why can't we just split work into: main (or UI) thread and "all other background work" thread pool? This way the UI shouldn't stutter and if you have a pool of threads running in the background, all that background work will conveniently be executed, no problem. Right? Even though both I/O-bound and CPU-bound work need to be executed in the background for mobile development, they have different demands and stress the operating system (OS) differently. Hence the need for different thread pool types to handle this kind of work differently. CPU operations (like number crunching, computation etc.) run incredibly fast I/O operations on the other hand (reading from a database, network etc.) take longer as the OS has to wait for underlying hardware to retrieve and deliver the data Typically the underlying hardware sends out a signal IOWait to the OS while the underlying hardware is out and about doing the IO work Instead of sitting and twiddling its thumbs, the OS should be finishing other tasks in the meantime (especially ones that are not waiting on underlying hardware) through other threads When the operating system encounters an IOwait, it pauses the execution of that thread and is free to pick up another thread that is ready to run. Theoretically, an operating system can have an unlimited number of threads that are sleeping due to IOwait, without the user noticing any difference That last point is subtle: this is why you don't want to mix CPU and I/O threads in the same pool. You coul