DEV Community: Marco Coelho

5 things every senior developer must ask before modernizing legacy software

Marco Coelho — Tue, 24 Feb 2026 02:58:44 +0000

Pretty much every software developer has, at some point in their career, had to maintain old software. It could be a legacy system created in days gone by, or software recently built using outdated technology to preserve some backward compatibility. Either way, you've probably faced this challenge at some point: What do I need to ask before modernizing a piece of software? Here are five important questions you should ask yourself when working on an old project before you begin modernizing it.

First Question: Why Was It Created?

The first question you have to ask is why this software was created. This is the fundamental question: Why does this software exist? Talk to the people who use it, review the documentation, and try to find out as much as possible about its origins. What problem was this software meant to solve? Did it solve that problem entirely, or was it only a partial success? Does the issue that originally required this software still exist, or has it since been resolved by other means?

Understanding why this system or solution was created in the first place is essential. Depending on the answer, you may already be able to determine whether it makes sense to invest effort in modernizing it or not.

Second Question: Who Made It, and When?

The second question is: who made this software? Was it built in-house by the company or institution using it, or was it developed by a third party? You already know why the software was created, but it's equally important to know by whom. Knowing who built it also gives you a solid sense of when it was built.

With both answers — "Why?" and "Who?" — you can begin to picture the context in which this software came to life: at some point in time, there was a problem, and a person or team created this solution to address it. Just by answering these questions, you'll likely uncover a lot about the infrastructure and technology originally used, whether that's an open-source framework or a paid corporate solution.

Third Question: Do You Still Need It?

This is another critical question. Now that you understand the context in which this solution was created, the "Why?" and the "Who?". Ask yourself whether you still need to keep it. Think of this as the "For what?" follow-up question.

When considering this, factor in your viable alternatives. Could a modern solution be less costly than the effort and budget required to modernize the existing software? To answer this properly, you'll need to calculate how much the current software is costing you today, and how much implementing an alternative would cost.

Another possibility: You need this software, but only a small part of it, a small piece that solves a lingering problem. In that case, consider modernizing only what is currently required.

Fourth Question: Is It Possible to Maintain It As-Is?

By this point, you should have a solid grasp of why this software was created and why it's still in use. The next step is to ask: Can you avoid modernizing it by simply maintaining it in its current state?

It may seem counterintuitive to ask this in a guide about modernization, but any change carries both a cost and a risk. This is your "May I?" question, as in, "May I keep it as it is?"; building on the "Why?", "Who?", and "For what?" questions you've already answered.

To truly answer this question, you need to weigh the risks of modernizing versus not modernizing. Consider the growing complexity of the project, the costs involved, and the risks that come with changing the code. Keep in mind that new versions of libraries and frameworks are released constantly; code that could be used to update your older project. This is both a blessing and a challenge: Updating libraries can offload some maintenance responsibility, but updating one library may force you to update other libraries in a domino effect.

This effort needs to be calculated carefully. You need to identify what is truly critical to modernize and determine the minimum effort required to do so. The less time, money, and risk involved, the simpler and more cost-effective the modernization will be for your client.

Will you replace entire hardware and software components in bulk? Or will you refactor specific pieces of code for better control over the process? Either approach requires deep knowledge of the technology in use and an understanding of how the software evolved over time.

Fifth Question: What Is the Cost of Modernizing It?

If you've reached this fifth question, you've already concluded that modernization is necessary. Regardless of whether you'll rewrite part of the system or all of it, the work must be done. So the final question is: How much is it going to cost?

It's easy to see why this question must be answered before you start: It tells you whether modernizing this software is even feasible. By answering it upfront, you avoid the painful scenario of running out of time, money, or resources mid-project; thus leaving the work unfinished.

Final Thoughts

Modernizing software is a risky endeavor. I can't guarantee you'll be able to answer all the questions above. Sometimes it's impossible to know who originally built the software. Sometimes it's difficult to estimate the cost of modernization. And sometimes, the hardest question is whether it needs to be modernized at all.

There are structured methodologies that can help — such as Architecture Driven Modernization or Model Driven Engineering — but even deciding whether to modernize is a challenge in itself. When that happens, remember the original reason why you took up the task, and the right decision will eventually become clear.

If you found this article helpful, follow me on social media and on dev.to for more content on software modernization and related topics.

Cover image by Freepik - www.freepik.com
Animated GIFs by GIPHY - https://giphy.com/

4 things backend developers should consider when developing services for mobile apps

Marco Coelho — Sun, 31 Aug 2025 01:59:08 +0000

Let's say you are a backend developer, with some expertise in different systems. One day, your leader assigns you a new task; You have to develop and test a few REST endpoints for an upcoming mobile app. So far, so good. Since you have experience as backend developer, it is not that hard, alright?

You build and deploy the changes, and everything seems ok in the tests. No issues detected, the app is working fine, and so is the service running in the cloud to communicate with the app. But then, a few weird things start happening. A user complain about not being able to use the app. There was an error in the app first version, you already rolled out a hotfix, but the error seems to persist. Then, the system goes down due to a max quota rule. And you can't debug what is going on, no matter how much you try.

It is in times like these we would like someone to share with us how to get around problems like those. Lucky for you, in my years as mobile software developer, I learned a few tips about backend development. So, I'm going to share here four things I learned when developing a backend service for a mobile app.

1) You don't control when a mobile app updates

When developing a website, you will have control when to merge code and deploy. You choose when it's time for the test version to go into the production environment. You may migrate the database first and deploy the backend, or choose the frontend instead. It all depends on how you planned your product version migration. And you have to plan the compatibility between your frontend and backend instances. Either that, or updating both at the same time while keeping the downtime restricted. So far, so good.

With mobile app development, you may release a new version anytime, but you can't control when users will install it. The delay could be days or even years.

For instance, in a scenario where you need to perform an API migration (due to a framework update, for example). Do you consider the consequences of allowing both the old and new APIs at the same time? It could be a heavy load, or duplicated data. If that's not possible, you must plan for when the older app loses access to the deprecated API. Will your HTTP server return a 404 Not Found? How will the older app versions handle that response? Will they crash, or will they retry? Or will you return a 200 OK with an empty body? Is the client built to handle a successful response that contains no data?

So yes, migrating a service on a mobile app is a lot more complicated than on your own website. One classic way is to follow the version standard for rest apis, by adding /v1 or /v2 and such. Remember to adjust different versions of the app to use different endpoints.

Another way is to check the app version, and redirect it to the proper url. Or to deny the usage of the older api by returning an error message. The former is a more friendly approach, but it may lead to a complex scenario of spaghetti api endpoints. The latter is a more forced approach, and it may not resonate well with your public. Especially if the app has a large audience who expects to be able to access the app at any time. It is a matter of choosing the most adequate answer to your problem.

2) Always authenticate an api call

Let's say you are developing a stock broker website. You have to present information, and some of it will be specific for a user, and some will be public. For example, the history of operations by that user will be specific, while the real time value of the stock price will be open to everyone.

In this scenario, the architect may authenticate specific calls, leaving public calls unauthenticated. It is a sensible approach, as it helps avoid unnecessary overhead.

But when developing for a mobile application, this scenario changes. First of all, you no longer have a connection of 1 to 1, frontend to backend, instead now you have a connection of N to 1. When you create a service to enable hundred of thousands of simultaneous accesses, you could be vulnerable to a Denial of Service (DoS) attack. All it takes is to forget to authenticate the requests.

Before processing any request from a mobile app, you must identify and authorize it. It could be through an authentication token, an API key, or a client-side SSL certificate. And that rule applies even for open endpoints, like the one about stock prices, after all, you don't want to face avoidable downtime in your service.

You should also consider measures like rate limiting to prevent spam, often done via a reverse proxy. If you don't, you might get some leeches using your website service in their own website. Using a load balancer to distribute traffic across your servers is another suggestion.

3) Don't expect an api request to represent real time action

When responding to a request from a browser, you may assume the time the request arrived is a decent approximation of the time the request was made. Of course, it makes sense after all. When a user navigates take actions on the website, it will send requests to the service.

With mobile apps, this assumption is often false. A user might perform an action while offline (e.g., in airplane mode or outside roaming coverage). The app may store that action in the device and sync it with your server once connectivity returns, hours or days later. As such, the server's request timestamp does not reliably represent the instant when the action occurred.

If recording the event time is crucial, the mobile client should timestamp the action when it happens and include that timestamp in the data. The service must be ready to accept it.

4) Make sure you add product and OS information to your calls

Imagine the following scenario. You go to work at morning, and your first ticket to check out is about an user not being able to save or update a record. While checking the backlogs for the service, you see this problem seems to repeat, but only with this user. So, what is the first suspect in this erratic behavior scenario that affects only one user? The browser type and version, of course.

If the client's browser type and version does not explain the issue, the search expands. Other factors, like the OS version, network routing, or authentication may be why.

The same line of thought applies to a service providing an endpoint for a mobile app. Whenever a mobile client makes a request, it is very important to provide its OS version and manufacturer. Those details may be crucial to debug the issue at hand. Some issues only do happen on a specific version of OS or vendor. Send the information in the request header or body, depending on your strategy. Ensure your service logs this information for a reasonable time, especially alongside any errors. So the more you know about the error when it happens the first time, the easier will be when debugging it.

Final Considerations

Creating a backend service for a mobile app is no different from any other service. Yet, the mobile app is a consumer whose update cycle and environment are outside your control. Because of those restrictions, make sure to create a proper plan for updates and changes. Knowing the particularities of Android and iOS will help you when building and maintaing a reliable service for them.

Doing so should not be a daunting task, as the modern state of both Android and iOS are particularly similar. Given how hybrid technologies are popular today, most solutions will work for both. Still, having a background in native development, knowing each OS details will help you to design your service. Especially if you need to ramp up security and performance. And if you enjoyed this article, follow me on my website and social media pages for more articles.

Cover image by Freepik - www.freepik.com
Animated GIFs by GIPHY - www.https://giphy.com/

News from Google I/O '25 for Android devs

Marco Coelho — Wed, 09 Jul 2025 23:24:56 +0000

Google I/O '25: My personal take on the announcement regarding the Android ecosystem for this year and the next

Well, another Google I/O has come and gone, and the Android track for 2025 certainly didn't skimp on announcements. I've watched the presentations (most of them), scribbled down the highlights (and a few lowlights), and now it's time to distill what this means for us developers and the ecosystem at large, while presenting some compliments and criticism I believe to be valid and appropriate. So, grab a coffee, and let's dive in the news!

Part 1: Android 16 - The middle eastern dessert (Very tasty, actually)

Android 16 is the most antecipated announcement, and this year, it made an early appearance. Google’s team even color-coded the changes by importance, so we may know where to focus first, and where to focus later on (red, yellow, green – a bit like a traffic light for our development priorities).

Kicking things off, Jetpack Compose continues to be the solid library all modern Android UI development is now based on. We're getting new modifiers (Autofill text, Autosize text, Animate bounds, and fancier Visibility trackers), alongside welcome performance boosts and a rather impressive 32% reduction in experimental APIs, with increased stability. The way I see, that's a win. Navigation 3 is also on the horizon, rebuilt with Compose in mind, promising slicker transitions and customization, which is, of course, very welcome to have. But the bigger surprise to me was a Jetpack Compose based Media 3 and CameraX new libraries, a sort of overhaul of the already present libraries, and also very welcomed to have available. It seems good winds are blowing Compose further into the future.

Kotlin Multiplatform (KMP) enthusiasts, fans, skeptics and community alike, rejoice! Full Jetpack support for Tier 1 platforms (Android, iOS, JVM) is now available. This is genuinely good news, and shows KMP also has a promising future in the highly competitive market of hybrid mobile development.

Regarding security and privacy:

Digital Credentials Verification and restoration via new API calls look promising. Frankly, anything that makes the apps safer is welcomed, no questions asked.
The Privacy Sandbox now lets you isolate any third-party code in its own runtime process, not just ad SDKs. That's a neat trick for containing rogue code, although checking the reputation of a library before using it is also important.
Android Advanced Protection Mode is another new user-toggleable feature users can set, and that we'll need to integrate with in our apps before they will be able to use it – It means more coding, debugging and testing for us, but hopefully more peace of mind for users.
And the one I'm particularly glad to see: Theft Protection with Identity Check! An extra biometric layer to deter those snatch-and-run phone thieves? Excellent! We can't have enough of those, folks.

Health Connect is expanding, aiming to consolidate more health data for better medical context – think vaccines, allergies, alongside the usual sleep and movement. A positive change, I believe.

On the performance front, the perennial battery vampire, wake locks, are still an issue, often due to long-running jobs. Google is tweaking Expedited Work in WorkManager to try and tame this beast. Yet, it remains to be seen how effective that will be when applied.

And then there’s the big push: Adaptive Apps -> Android is doubling down on making apps look good everywhere. For larger screens, Android 16 will apparently start ignoring your carefully set orientation and resizability restrictions on activity recreation. While reorienting and resizing is something that should always be considered on our checklist, I fear developers will resist adopting this library and adding proper adaptative code.

Material 3 Expressive is also part of this, an "expansion pack" (as I see it) for Material 3, bringing 15 new/improved components with unexpected shapes, new physics, and colors. It sounds fun, but let's hope it doesn't carry any serious letdowns.

Other notable mentions for Android 16:

Live Updates: A new notification template for time-sensitive tasks like food deliveries, or map update for navigation. It is a notification in the notification tray changing content every few seconds. Very useful in some contexts.
Jetpack Glance 1.2 Alpha: A widget building API based on Jetpack Compose. Again, it's only fair for this to be available, since Compose is being standardized as the recommended way to develop UI on Android.
Google Low Light Boost: A software library using ML for better snaps in the dark. Nice.
Preload Manager for Media 3 and Native PCM Audio Offload: More tools for media-heavy apps, allowing performance improvements.
Gemini Nano Integration: Via a new GenAI API and Gemini Live APIs (text/audio I/O), now Android apps may make use of an on-device generative AI capabilities. As a developer who is very interesting in connecting people and integrating software, I find this feature very promising and very interesting.

My Sentiment on the changes for Android 16: Look, performance and usability optimizations in Jetpack and other libraries are always welcome, no questions about it. The anti-theft layer is something that warms my heart, knowing someone took their time to code something to help you in your moment of vulnerability, just after a theft. Even if you don't recover your device, it will likely still protect you by giving you more time to take measures. The way I see it, it's a massive win.

More KMP and Compose-centric libraries like Glance, Media 3, and CameraX are also desirable, and to be expected. I also agree the way Android manages screen reconfiguration is outdated, unnecessarily complicated, and sometimes, a letdown to developers. However, I find it too convenient for Google to push an update for multiple form factors on Android while at the same time, announcing the release of Android XR. This push for adaptive screens across multiple form factors... It is good on paper, but it seems people forget it will come at a cost for companies. And I can't help but think someone might be trying to strong-arm the Android community into supporting the fledgling Android XR... Adapting your app for yet another device category costs real money, and not every app needs to be on every screen.

Part 2: Polishing the Shelves of Google Play

The Google Play Console also got a fresh coat of paint and some new tools under the hood. The app dashboard has been redesigned to surface key metrics like "Test and release" and "Monitor and improve" more prominently. Each core object now gets an overview page, which should simplify navigation.

To tackle the challenge of multi-platform optimization, the console will now flag incorrect edge-to-edge rendering in a pre-review check. A new panel for quality issues and recommended fixes has also been added, alongside an Android Vitals metric for low memory app closures and excessive battery drain. As long as the UI and UX design can keep up with the amount of data the console provides, those changes should be helpful, I believe.

Store listings get more customizable, and a new panel for engagement metrics (installs, ongoing engagement) has arrived. Monetization sees more currencies and payment methods, with an AI model suggesting the most appropriate one. Good.

On the security front, the Play Integrity API gets enhancements for hardware-based security to reduce spoofing and a new abuse detection feature for apps in trial mode that doesn't rely on device IDs, which is a privacy-conscious move. Again, I may be biased, but anything related to security is a win in my book, so kudos to them.

Google says it's integrating the user end-to-end experience with developer tools to convert engagement into revenue. We'll see how that pans out.
Discovery gets a boost with topic browser pages (for movies, books, games, etc.) and a "Where to watch" feature. Those sound helpful, but I have to use it first to know where I stand regarding it. Audio samples are now available on app store pages, starting with health and wellness apps – an interesting idea.

The Engage SDK is expanding significantly with "Collections" – a full-screen immersive surface to pull content onto users' home screens, continue journeys across devices, create cluster recommendations, and promote specific clusters. Engage SDK content is also coming to the Play Store itself and now supports travel content and reservations. This "Collections" feature actually sounds quite promising for driving deeper engagement, and I'm warm to the prospect of using "Collections" in the future.

Subscription management gets some love too: Single checkout for multiple subscriptions, more visibility for subscription benefits (to fight voluntary churn), and more flexibility for grace periods on payment failures (to combat involuntary churn). The last one particularly stood out for me, especially given sometimes I have to cancel my virtual credit card when info leaks out, so it's nice to have a grace period.

For the game devs, Google Play Games is focusing more on engaging players on Mobile (a shift from PC), an Earnback program to help migrate PC games to Android, the Recall API for cross-platform retention, and bulk achievement creation via CSV. Frankly, I barely play any mobile games, so I don't have much to comment here.

My Sentiment on Google Play: The changes are welcome, but many feel like minor tune-ups rather than any major overhaul. Still, I'm lukewarm towards them. My biggest gripe remains: I feel there’s a lack of serious effort to curb malicious apps. This leads me to hesitate and suspect others when downloading apps from lesser-known developers who haven't shelled out for major marketing. I wish there were an easy way to tell malicious developers apart from genuine ones. Hopefully, AI could help with that, but so far, I've seen no announcement on that topic on Google Play. However, the Engage SDK "Collections" feature does seem genuinely interesting and promising, while the rest seems to be mostly quality-of-life improvements.

Part 3: Android Studio - Narwhal and the Gemini Effect

Android Studio codename "Narwhal" will be getting significant AI adoption, largely thanks to some Gemini powered new features.

A new KMP template is available, along with Compose preview, menu, and action enhancements. Good.
Gemini is embedding itself deeper into the IDE: It can help update all project libraries (proposing solutions before touching code), analyze files to create Composable previews, and now it has agent-like capabilities to identify bugs, correct them, and rerun tests. A very promising update.

But the headline act for me is Android Journey, the apparent successor to Android Espresso. The idea of instructing Gemini to test an Android app using natural language commands, rather than wrestling with Espresso's lists, intents, and the dreaded IdlingResources functionality, is a massive improvement. Plus, purging IdlingResource test code from release builds has always been a necessity when using Espresso, a necessity that will become outdated soon. Journey could solve a lot of headaches for exploratory, integration system and regression testing.

Yes, there are potential pitfalls with AI-driven testing, but I believe the benefits here could genuinely outweigh the risks.

Other notable Studio upgrades:

Firebase device streaming: Test on remote devices via device partner labs. Very welcomed in this age of remote work, for sure!
ADB Wi-Fi improvements. A nice quality of life improvement, since I've already lost some cables when working with debug apps in Android, hopefully this change will save me some money.
A new backup feature in Android 16 for app settings and data (presumably with Studio integration). Good.
Studio will now recommend .ktx syntax over plain .kt. Another minor change.
Official support for Android XR devices. Good.
And a heads-up: 16KB page size validation is coming, up from 4KB. Time to check those native libraries. I won't complain about it, in the age of gigabytes of RAM in computers, I believe we are way past the point of needing only 4KB or 8KB memory pages for any partition type or memory context. Still, I think we could have adopted larger memory pages, who knows?

My Sentiment on Android Studio: I’m actually quite excited about the upcoming changes in Android Studio Narwhal. Journey replacing Espresso is a potential game-changer, further allowing Jetpack Compose to assume the role of leading UI designing tool in Android, and helping in the rough edges of many different kinds of testing, especially regression test. The Gemini integration for library updates and bug squashing is also welcomed. Features like 16KB page support and better ADB over Wi-Fi are nice to have, but I see them more as quality of life updates than the real deal for the event.

Part 4: The All-Encompassing Adaptive Android

The push for "Adaptive Android" was a recurring theme, with Google heavily promoting support for various form factors: Phone, Tablet, Foldable, Wearable, Automotive, and the newest product (not so new, actually), Android XR. I believe the dream behind it is that many apps could work seamlessly across different product environments, while retaining the same UI and UX when used, without a huge effort to rewrite those apps. But, in my opinion, there were also another message, an underlying message: If your app isn't adaptive, you might be left out of the whole Android userbase, so you better use it. I think this kind of approach is counterproductive - an approach where a Jetpack Compose library helps the developers to adapt faster, easier and with a minimum cost to their companies, would be much more productive. Let's hope this is the road we are on.

The Navigation 3 library will allow metadata tags for different navigation styles (like list vs. panel) to help with this. We're also getting new animations for app reconfiguration: Levitation (moves a panel from landscape side to portrait center) and Reflow (moves it to the top/bottom in portrait). For Android XR, there are new Android XR exclusive components.

As mentioned earlier, Android 16 will start ignoring orientation, aspect ratio, and resizability restrictions on larger screens (defined as 360dp width or more). Instead of the developer, the user will have total control of the app on larger screens. Hence, it is understandable why Google is advocating for a single, adaptive app for all these form factors, built with Compose and their tooling. And this adaptive approach extends to games too.

My Sentiment on Adaptive Android: While the ambition is clear, and Android was long overdue for an update regarding screen reconfiguration, this heavy emphasis on adaptiveness for larger screen, again feels like a strong-arming Android towards bolstering the app ecosystem for Android XR, even before it is launched. I get the strategy – Android is growing on larger screens, like televisions, totems, monitors, automotive, so a form factor app library becomes necessary for this constantly evolving platform. But the reality for many developers is, they hardly have the time or budget to work on form factors, much less to adapt Android to a supporting platform, especially if it’s not a natural fit for their app. I fear the community and the Android Google team might be on different pages.

Perhaps for games, this one-app-fits-all approach will work wonders, but I suspect many specific apps may not translate well to XR. And I believe Android XR, much like Wear OS, will carve out its own small but dedicated niche, but nothing too far from that.

Regarding using Android XR for something like a translation tool, it may be interesting, but the thought of strapping a $1000+ gadget to my face, ripe for a quick slap-and-grab mugging, still gives me pause. I'm willing to consider using it, and Android XR may be an interesting product, no doubt, but perhaps not the revolutionary leap the presentation painted it as.

That said, the smaller changes aimed at improving Android's behavior across different screen sizes, like the navigation and animation enhancements, are definitely welcome.

So, that's my 2 cents regarding Google I/O '25 track about Android -> A lot of AI, a big push for adaptive everything (especially Android XR, it seems), new libraries and updates, and some genuinely useful improvements sprinkled throughout. Some of it is exciting, some of it feels a bit pushed, and the real test will be when these tools and APIs land in our hands.

I recommend that you take action: Download the newest Android Studio Narwhal, start testing your product with Journey and Gemini. Take some time to consider adapting your app with form factors (consider the time and budget necessary to do so), and don't forget to replace any workaround with a proper, Jetpack Compose based library. Even if it's in alpha development, I think it will be worth it. Time to update those build.gradle files, I suppose!

Cover image by Freepik - www.freepik.com

8 important security changes from Android 8 to Android 15

Marco Coelho — Fri, 16 May 2025 21:59:47 +0000

Yesterday, when I was at the bakery buying some snacks, I overheard a conversation between one attendant with another regarding her Android phone not downloading and installing the ChatGPT Android app. Curious about the subject, I decided to ask her more regarding her issue, and to talk about it. She explained her smartphone was an older model, using Android 8.0, aka Oreo, and that's probably why the chatgpt android app wasn't downloading and installing on it.

We talked a while, and I pondered that while there are a lot of reasons for an app not to work on an older Android OS version, the most relevant of them are the security reasons. So I decided to list eight changes from Android 8.0 (Oreo) to Android 15 (Vanilla Ice Cream), the most impactful and relevant of each major version:

1 - Project Treble on Android 8.0

Project Treble was, undoubtedly, the biggest change to architecture and security starting with Android 8.0, from the previous Nougat (Android 7.0). Not only did it compartmentalize the Android system image into a vendor partition and a system partition, it also increased the security and allowed for faster updates to be released and possibly longer device lifespan.

To understand the advance of the Project Treble, first you need to understand the basics of Android product development. In a very abridged form, the Android operating system is maintained and developed by the Open Handset Alliance, a consortium of different companies, but most of the code for next version of the AOSP (Android Open Source Project) is maintained and developed by a team at Google. This version of the OS usually does not contain a kernel and system drivers, something which is added later by the device manufacturers like Samsung, Motorola. The vendors usually retrieve and adapt the latest version of the Linux kernel, and the system drivers from the chipset manufacturer, like Qualcomm or MediaTek when not produced in-house. Only then, after it's developed and tested, the product goes to the resellers, who are too many to cite here. Think of it as an assembly line, where each step is done by a different company.

Project Treble changed some of that by separating the Android Framework software layer usually maintained by the AOSP team, which was named system partition, from the low level software layer maintained by the device manufacturer, which was named vendor partition. So now the assembly line has two distinct steps in regards to software instead of just one. To be honest, there are more than two partitions in an Android Device, but that's the general idea behind it. Not only did it allow for the AOSP to update an older device Android operating system as long as the interface remains the same, it made access to system sensitive resources like the camera and microphone (something we don't want malicious apps to have access to) much harder to happen. This allows security patches to be deployed much faster than before when bugs are found.

There were other improvements made to Android 8.0, like the Webview component running on an isolated process, making the device more secure against attacks via web, a serial hardware number access requiring a specific permission to be granted, and better boot security, but the biggest and most important change remains the Treble.

If you would like to know more about the Project Treble, check out this article: What's new in Android 8.0 Oreo Security

2 - Biometric API on Android 9

Android 9 Pie really started to tighten the screws on app permissions and how apps talk to the internet. For instance, it made secure connections (HTTPS) the default for apps, which is like ensuring all your mail is sent in a sealed, tamper-proof envelope instead of an open postcard. It also put stricter limits on what apps could do in the background, especially with things like your microphone and camera, stopping them from snooping when you're not looking.

But for me, the most important change in Android 9 was the Biometric API. Before this, every app had to build its own way to use your fingerprint, which wasn't always secure or consistent. With this API, Android provided a standard, super-secure way for apps to ask for your fingerprint or face scan. It's like having one master locksmith design a universal, highly secure keyhole that all trusted apps can use, instead of relying on a bunch of different, potentially flimsy locks. Relying on the Android OS also made biometric data interception by other apps less likely.

If you would like to know more about the Biometric Prompt, check out Android 9 release notes: Android 9 release notes

3 - Scoped Storage on Android 10

Starting with Android 10, privacy and security were taken to a whole new level, almost like building higher walls around your digital castle. It gave us much finer control over location access, letting you decide if an app gets your location only when you're using it. It also clamped down on apps launching activities from the background, which helped stop those annoying pop-up ads or worse. On the technical side, it boosted security with things like TLS 1.3 support and randomizing MAC addresses to prevent tracking.

However, in my opinion, the standout security feature in Android 10 was Scoped Storage. Think of your phone's storage as a big house. Before Scoped Storage, when giving another app permission to access your app files, the permissions were given to pretty much all files, for all the time, until rescinded. This was like giving them free access to your entire house when you only wanted to show them the kitchen. Scoped Storage gave each app its own private, locked room for its files by default. If an app wants to access a file, it has to ask for specific permission, and the permission is given for a specific action, for a specific file, for a specified timespan, making it much harder for a previously trusted app to go rogue and steal your data, something that was far too common at the time.

4 - Permission auto reset on Android 11

With Android 11, the focus was on giving users even more direct control and making permissions smarter. It introduced one-time permissions, which is like giving an app a key that only works once – super handy for apps you don't fully trust but need to use briefly. It also gained a better security for SIM Identifiers, and encryption for user-stored credentials. Also, Scoped Storage previously introduced on Android 10 is now enforced on all apps.

But the real game-changer for me here was the auto-reset permissions feature. If you install an app, grant it a bunch of permissions, and then forget about it for a few months, Android 11 steps in, like a helpful assistant, to automatically revoke those permissions from the dormant app. It’s like that assistant noticing you haven't had a particular guest (app) over in a while, so they proactively take back the spare key you gave them, just in case. This is a brilliant way to reduce the attack surface from old, forgotten apps, which again could sometimes hold malicious code to be executed only after days, weeks or months after being installed into a device and given permission for a legitimate use.

5 - Phantom touch blocking on Android 12

Android 12 brought a big visual overhaul, but it also packed some serious security punches. The Privacy Dashboard was a great addition, giving you a clear timeline of which apps accessed sensitive stuff like your camera, mic, or location. Those little green indicators for camera/mic use? Genius. Like a little light that tells you someone's listening or watching. It also allows you to give apps seeking your location only your approximate location, which is perfect for things like weather apps that don't need to know your exact address.

But for me, the most crucial security update in Android 12 was blocking untrusted touch events. Imagine a malicious app creating an invisible button over a real button in another app, trying to trick you into tapping something dangerous. Android 12 got much better at detecting and blocking these "tapjacking" attempts. It’s like having a filter for your screen that blocks shady attempts at tricking you into opening an app, or allowing a permission.

If you want to know more about the untrusted touch events block, check out the release notes for Android 12: Android 12 release notes

6 - Photo Picker addition on Android 13

Android 13 continued to refine these privacy and security controls. A new kind of permission was added to Android 13 - The app notification permission. Apps now do have to explicitly ask for this permission to send any notifications, if not granted, the app will not be able to send notifications! This was meant to curb the excessive spam via notification some apps were doing. It also introduced more granular permissions for media files, so an app wanting your photos doesn't also get access to your videos and audio files unless specified. The new unified Security & Privacy settings page also made it easier to see what's going on.

But, if I had to pick one, the most significant security improvement for me in Android 13 was the Photo Picker. Previously, if an app wanted a photo, you often had to grant it access to your entire photo library. This could include sensitive, private and personal photos, and the user wouldn't know if those photos were accessed or not. Now, any app has to use the Photo Picker, which is like a secure messenger; you tell it which specific photos or videos you want to share with an app, and only those items are made available, for that one time. The app never gets to rummage through your whole album, keeping other photos and videos private. It’s a much safer way to share your memories and keep your privacy.

7 - Memory Tagging Extension on Android 14

Android 14 built on this solid foundation, making several under-the-hood and user-facing security enhancements. It started nudging users towards 6-digit PINs for better lock screen security and gave IT admins more power, like disabling 2G connections which can be a security risk. Disabling 2G connections on your phone was possible since Android 12, but now, even remote administrators could do it. It also made it harder to install very old apps that might be riddled with known, unpatched vulnerabilities.

However, from my perspective, the most important step forward in Android 14 was the improved real-time malware protection, especially enhancements related to Memory Tagging Extension (MTE) where the hardware supports it. Think of MTE as an incredibly sophisticated alarm system for your phone's memory. It "tags" different parts of memory, and if an app tries to access a part it shouldn't, or messes with memory in a way that's common for malware, the alarm goes off instantly, often stopping an attack before it can do any damage. This helps catch and neutralize a whole class of tricky memory-related bugs and exploits in real-time, from stack injection to memory dumping.

8 - Anti-theft protection on Android 15

Looking at Android 15, it's clear they're doubling down on protecting you from more modern threats, especially physical theft. It's also bringing features like a "private space" to hide sensitive apps and data, and further hardening the system by using more memory-safe languages like Rust. There are also improvements to how it handles one-time passwords to prevent malicious apps from peeking at them.

But undoubtedly, for anyone who ever had their phone stolen, the most significant security feature in Android 15 is the advanced theft protection. This isn't just about remotely wiping your phone anymore, which was an important feature, but could be bypassed if the phone was stolen while unlocked. It's about considering the scenarios where there is suspicious behavior (like if a thief snatches your phone and tries to run) and minimizing the damage. If the anti-theft system thinks the phone is stolen, it can automatically lock it down, make it harder to factory reset without your credentials, and even lock the screen if someone repeatedly fails to unlock it or tries to disable "Find My Device." It's like an intelligent alarm for your phone, where it activates a killswitch of sorts, making the device much harder to compromise, requiring more time, technical expertise, and making it less appealing and valuable to thieves.

If you want to know more about the anti-theft, I recommend this article: Android Security 2025: The Most Important Security Features for Businesses

Final Thoughts

While talking with both attendants, I tried to explain why, sometimes, an Android app will not run on an older device. I didn't get too technical, but I made my point - Newer devices aren't simply a programmed obsolescence ploy to sell you something you already have again. Newer technologies like 5G and 6G aren't simply faster, they are also much more secure than 2G and 3G.

If I had to put it in simpler terms, I'd say we, users, are in the middle of an arms race between tech companies, and criminal entrepreneurs, who are always innovating in new ways to commit crime, either by tricking you into installing a malicious app, or physically stealing your phone. Either way, we should take measures to avoid unnecessary risks, and buying a new phone from time to time can be considered one of them. Of course, you don't need to buy the latest phone model every single year, but waiting too much to buy a new one could compromise your digital security, as the more time passes, the more vulnerabilities will be known by everyone, including attackers.

In my discussion with them, I tried to state that point. Also, just buying a new phone is not enough if the user is not going to make use of proper security practices. Make sure you enable your anti-theft system on your phone, avoid downloading strange unknown apps if possible, and pay attention to any strange behavior on your device, for example, if it feels too hot to the touch, it may be running a malicious code in background without your knowledge. Keep an eye out for risks, and you may avoid the worst of them.

Cover image by Freepik - www.freepik.com

Seven Legacy Technologies in Android Development and Their Modern Counterparts

Marco Coelho — Mon, 27 Jan 2025 13:01:47 +0000

Android development has come a long way since its inception in 2008. The tools and the framework that developers relied on in the early days have evolved or been replaced entirely, leaving behind a trail of technologies with legacy status. Here, we'll dive into seven of these legacy technologies, explore their importance to android software development, appoint their legacy and modern counterparts, and discuss why the evolution was necessary.

1. From Java to Kotlin

When Android launched, Java was the exclusive language choosen and designed for Android development. A lot of the reason was that Java had a developer community unlike other technologies, allowing Java to have a deeper penetration power into distinct and different markets.
It also had to do with timing and opportunity, due to Apache annoucing the project Apache Harmony, a open source free Java implementation back in year of 2005. One of the biggest reasons for that, was the concept of Sandbox - Each Android application (apk) would run in it's own instance of the JVM, hence making any possible unintentional crash less likely to affect other applications, or protecting the OS somewhat from malicious code. Hence, Java is vital to the Android project.

Of course, if you wanted to design an audio driver or if you wanted to create a specific game, most of the time you had to code some low level code in C/C++, something named native layer by the Android project. However, coding an Android apk with C/C++ came with it's layers of risks and restrictions, given it did not have the Sandbox protection.

It served its purpose well, but the language came with its baggage, notably the infamous Null Pointer Exceptions (NPEs) that caused endless headaches for developers. Also, Java had it's own share of conflicts, primarily conflicts between Microsoft, Sun, Oracle and RedHat leading to the creation of openJDK (an successor to Apache Harmony), and thus the main focus of the community wasn't Google and the Android project, despite Java being vital to Android.

Enter Kotlin, originally unveiled in 2011, but officialy launched in February 2016, as an alternative to Java due to those issues. Kotlin addressed these issues with nullable types and offered a syntax that is concise and readable, significantly simplifying code. While some argue that modern Java (version 21, for example) narrows the gap with Kotlin, back in 2017, Kotlin was a breath of fresh air for developers needing a language more adequate for Android development. The transition from Java to Kotlin took some time to gain traction with Google officially suportting Kotlin only on 2017, and the developer community largely embraced Kotlin since then, and as such, Kotlin has become the official language for Android apk development, despite both Java and C still being supported.

Of course, the main reason Kotlin is able to run on the Android OS is because Kotlin source code is compiled into Java .class (and later .dex) files, hence Kotlin itself is also heavily dependent on the Java Virtual Machine, something not likely to go away at any time in the future.

How to update:

Add the Kotlin plugin in your project if not added yet:

Groovy

classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:${version}

or in Kotlin DSL

alias(libs.plugins.jetbrains.kotlin.android)

In Android Studio, press Code > Convert Java File to Kotlin
You need to code check the conversion to make sure it's done properly. For that, reading the Kotlin official website docs will help: https://kotlinlang.org/docs/home.html

2. Jetpack Compose: Bye-Bye XML Layouts

Jetpack Compose, first announced in 2019, but released in July 2021, revolutionized UI development in Android. Gone are the days of juggling XML files, the inflater class, and various resource files for layouts, animations, and themes. Gone were the days where an app could crash if the inflater couldn't find a XML reference during runtime, or you could end up with a weird colored dialog box due to using an incorrect app theme. Compose consolidates all these elements into a declarative, Kotlin-exclusive framework, and makes sure that: 1) The code is coherent in compilation time, 2) it is always using the proper app theme, thus avoiding the runtime issues associated with missing classes, weird colors and improper reflection usage.

One standout feature is the composable preview library, which provides a more accurate representation of UI components compared to the old XML layout preview. Despite being stable, Jetpack Compose is still evolving, and developers are encouraged to adopt it gradually because some features are still experimental, like the Canvas, LazyColumn, LazyRow and ConstraintLayout. As such, those features are still prone to change, and it's not uncommon to find on internet older projects using outdated Compose code for those features - Beware!

Android studio default Jetpack Compose placeholder code:

import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.material3.Text

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            Text("Hello world!")
        }
    }
}

Still, Jetpack Compose's flexibility allows teams to update their apps step by step, changing one screen at a time, or even mixing parts of XML and Compose by using reducing the risk of breaking existing functionality. This can be done either by inserting a Composable inside an XML layout by using an XML element named ComposeView and calling setContent on it in the Activity class Kotlin source code. For example:

<androidx.compose.ui.platform.ComposeView
android:id="@+id/my_custom_composable"
android:layout_width="match_parent"
android:layout_height="match_parent" />

findViewById<ComposeView>(R.id.my_custom_composable).setContent {
    MaterialTheme {
        Surface {
          Text(text = "Custom composable!")
        }
    }
}

Or by calling an composable named AndroidView in the Activity class Kotlin source code, and then inflating in runtime the necessary XML component tree by coding the factory and update methods of AndroidView. For example:

AndroidView(
        modifier = Modifier.fillMaxSize(),
        // Occupy the max size in the Compose UI tree
        factory = { context ->
            // Create or inflate your view hierarchy here
            TODO()
        },
        update = { view ->
            // Called each time the composable is updated
            TODO()
        }
    )

How to update:

You may use ComposeView to insert a compose element inside an XML layout file tree hierarchy (As shown above).
You may use AndroidView to insert an XML element and inflate it inside a Compose hierarchy (As shown above).
Entire screens may be redesigned in Compose by studying how Jetpack Compose works. Since Compose uses Kotlin and Android inflater uses different languages, it will require studying Compose and how to build an equivalent screen using it.
This official tutorial will show how to use Jetpack Compose: https://developer.android.com/develop/ui/compose/tutorial

3. Google Material Design: Evolution to M3

Material Design has been the cornerstone of Android’s visual language since its introduction. Currently in its third iteration, Material Design 3 (M3), released in October 2021, offers a refined subset of color values, text sizes, and typography, enabling developers to create distinctive visual identities for their apps. The colors in Material Design are chosen to ensure they do not clash too strongly, making the app almost always visually pleasant and easy to read. The typography style is also designed to help apps adapt better to screens of any size, ensuring a consistent and polished look. If you want to quickly test or create a material theme, use the web builder for the theme: https://material-foundation.github.io/material-theme-builder/

Google Material Design came to replace older design styles for Android up to version 4.4 KitKat. Until Lollipop, there was no official design style for Android apps, with the design used on apps varying from styles copied from web development, or styles similar to the earlier Macromedia Flash apps, or styles trying to copy iOS.

Updating from M1 or M2 to M3 requires rethinking your app’s style, but the payoff is worth it. The latest version integrates seamlessly with Kotlin and Jetpack Compose, allowing developers to create pleasant apps with less effort than the previous versions. Also, the color scheme of Material 3 makes it far easier to support dark mode with very few changes necessaries to adapt the code.

How to update:

There is no straightforward way to migrate from earlier version of Material library into Material 3, but you may use the official documentation for some help: https://developer.android.com/develop/ui/compose/designsystems/material2-material3
If you need the official reference for M3: https://m3.material.io/

4. Dependency Injection: Dagger vs. Koin

Dependency injection (DI) has always been a crucial part of Android development. dagger, while powerful, wasn’t particularly friendly to Kotlin developers. hilt improved on dagger but still retained some limitations, like requiring injection methods to be public.

Koin, launched in November 2017, is a Kotlin-first DI framework that uses a domain-specific language (DSL) to make dependency management more intuitive. By embracing Koin, developers can better align with Kotlin’s object-oriented nature while simplifying DI. Also, the nature of Koin allows the developer to create distinct modules for testing scenarios, and productions scenarios, thus allowing the developer to also mock data under the right circusmtances.

How to update:

In build.gradle file, application level (not project level) replace the import of any dagger library with Koin library. Example: From

dependencies {
    implementation 'com.google.dagger:dagger:2.x'
    kapt 'com.google.dagger:dagger-compiler:2.x'
}

dependencies {
    implementation("io.insert-koin:koin-core:$koin_version")
    implementation("io.insert-koin:koin-android:$koin_android_version")
}

Afterwards, you need to read and understand the documentation of Koin to create and inject Koin modules.

For more info: https://insert-koin.io/

5. AsyncTasks to Coroutines and Flow

Android has a golden rule when it comes to thread - The main thread, also called UI Thread, should not take more than 16 ms to run. Each method in the Android framework has this time constraint, and if you wish to run a longer, blocking operation like network communication, you should run it on a background thread. So why not run all the code, including UI updating code, on the background thread? Simple, Android also required for it's view objects to be updated only in the UI Thread, to prevent race conditions since the Android UI Toolkit is not Thread safe.

When Android was created, all the parallelism done in the app had to be done using the Java Thread mecanism. While powerful, Java Thread can cause a lot of damage if misused, and Threads were also quite resource expensive in the earlier days of Android developer. To fix this issue, the Handler and Looper mechanism was created in API Level 1.

Looper and Handler worked like a pair, where the Looper would create a infinite loop inside a newly started thread, while Handler would be associated with this Looper and thus would be able to receive Runnable objects to run on the thread being managed by the looper. If you found that confusing, this was why the AsyncTask was created later on the API Level 3, to make short parallel tasks easier to plan and execute. It was much simpler to create an AsyncTask object, implement it's onPreExecute, onPostExecute and doInBackground methods to guarantee only the blocking code would run on the background, while the other code would run on the UI Thread.

So as it can be seen, managing parallelism back then meant wrestling with AsyncTasks, Looper, and Handler classes—a process fraught with pitfalls like UI thread clogging, the dreaded "Application Not Responding" (ANR) dialog, or crashes if a piece code tried to update the screen from outside the main UI thread. When Google adopted Kotlin as the language for Android development, the door was open for Kotlin based Android apks to use Kotlin Coroutines and Kotlin Flow, which are a Kotlin exclusive paralellism technology, providing a streamlined way to handle long-running and short-lived operations.

Kotlin Coroutines are a method of running parallel code without the need to design specific callback methods, like the AsyncTask used for doInBackground and onPostExecute. To create a coroutine, you use a scope as a source, add a job (Although this part may be skipped if you don't care about cancelling the coroutine), and then either launch it, or call it in a suspend mode. The thread being used may be switched by using a suspend method call named withContext, which returns only after switching the context (eg. The Thread) into the appropriate one. Hence, a code using a coroutine may look like this:

val job = coroutineScope.launch(Dispatchers.Main) {
    // Execute setup code
    withContext(Dispatchers.IO) {
        // Execute the blocking code here
    }
    withContext(Dispatchers.Main) {
        // Execute post blocking code here
    }
}

Android Lifecycle Jetpack library added a bunch of new tools to the Kotlin Coroutines, like lifecycleScope for activity classes and viewModelScope for ViewModels classes, simplifying memory and resource management. AsyncTask was officially deprecated in Android 11 (September 2020), marking the end of an era.

How to update:

Most AsyncTask classes may be updated by the rough following procedure. Adjust as needed - 1) Create the coroutine as above, 2) Add the code from onPreExecute into the setup part of the coroutine, 3) Add the doInBackground code in the Dispatchers.IO part of the coroutine and, 4) Add the onPostExecute in the block withContext(Dispatchers.Main)
For reference, use the official documentation on the Kotlin website: https://kotlinlang.org/docs/coroutines-overview.html

6. SQLiteDatabase vs. Jetpack Room

SQLite Databases have long been a staple for data management in Android, enabling apps to store SQL information securely. However, for many use cases, they’ve been supplanted by Jetpack Room, introduced in May 2018. Room simplifies database management with features like migration tools and query interfaces, offering an ORM-like experience similar to Hibernate.

To create a database in SQLite using SQLiteDatabase class, it was necessary to configure the params when opening the database (either read only, or read write), treat possible situations like a constraint violation, or a conflict when updating or inserting a data, and rollbacks. Also, each transaction had to be carefully set up before commiting, just like any other SQL database.

Using Room, a component of Android Jetpack, made the SQL database management in Android far easier. You can use an annotation to define the whole database in it's database class, by defining the entities, the version and even how to migrate the database from one version to another. Below is a piece of code from one of my projects:

@Database(
    entities = [CurrentWeatherCache::class, WeatherCache::class, HourlyWeatherCache::class, DailyWeatherCache::class],
    version = 4,
    autoMigrations = [
        AutoMigration(from = 1, to = 2),
        AutoMigration(from = 2, to = 3),
        AutoMigration(from = 3, to = 4)
    ]
)
abstract class WeatherPeekDatabase : RoomDatabase() {
    abstract fun getCurrentWeatherDao(): CurrentWeatherDao
    abstract fun getWeatherCacheDao(): WeatherCacheDao
    abstract fun getHourlyWeatherCacheDao(): HourlyWeatherCacheDao
    abstract fun getDailyWeatherCacheDao(): DailyWeatherCacheDao
}

Creating the select, insert, update and delete methods is even easier, just requiring the developer to create an interface with annotations on each method:

@Dao
interface WeatherCacheDao {

    @Query("SELECT * FROM WeatherCache ORDER BY id ASC")
    fun getAll(): LiveData<List<WeatherCache>>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertAll(vararg weather: WeatherCache)

    @Query("DELETE FROM WeatherCache")
    suspend fun clear()
}

Compare that to the SQLiteDatabase method of reading from a SQL table from the official documentation:

// you will actually use after this query.
val projection = arrayOf(BaseColumns._ID, FeedEntry.COLUMN_NAME_TITLE, FeedEntry.COLUMN_NAME_SUBTITLE)

// Filter results WHERE "title" = 'My Title'
val selection = "${FeedEntry.COLUMN_NAME_TITLE} = ?"
val selectionArgs = arrayOf("My Title")

// How you want the results sorted in the resulting Cursor
val sortOrder = "${FeedEntry.COLUMN_NAME_SUBTITLE} DESC"

val cursor = db.query(
        FeedEntry.TABLE_NAME,   // The table to query
        projection,             // The array of columns to return (pass null to get all)
        selection,              // The columns for the WHERE clause
        selectionArgs,          // The values for the WHERE clause
        null,                   // don't group the rows
        null,                   // don't filter by row groups
        sortOrder               // The sort order
)

val itemIds = mutableListOf<Long>()
with(cursor) {
    while (moveToNext()) {
        val itemId = getLong(getColumnIndexOrThrow(BaseColumns._ID))
        itemIds.add(itemId)
    }
}
cursor.close()

How to update:

Updating from one to the other is straightforward. You need to create a proper schema, and then a database class, and at least one dao class - Some of the query may be imported in the case of the daos, but most of the code from the database will be deleted, since it's usually boilerplate.
For reference, use the official documentation: https://developer.android.com/training/data-storage/room

7. Shared Preferences to DataStore

In older Android development, when the developer wanted to save key-value pairs, they used to rely on Shared Preferences, a Android class added on API Level 1, which worked well back when Android didn't require thread intensive applications, or elaborate user interfaces. It worked synchronously, commiting simple key value pairs into a local "database", the database being nothing more than a local file without the typical database expectations and properties.

However, using this Android Context framework component had it's risks in multithread environments, including the possibility of race conditions, and UI Thread blocking. Hence Android Project introduced in 2020 two distinct implementations, one called Preferences DataStore, and other called Proto DataStore as a modern alternative, providing reliable and structured data storage in a multithread environment, along with UI safe execution. For the context of this article, I'm going to consider Preferences DataStore, since this library is the most direct successor do SharedPreferences. Besides those advantages, another big advantage of DataStore is being compatible with Kotlin Coroutines and Kotlin Flow.

For example, to use SharedPreferences, you simply had to create the database and call a get or put method on it:

val sharedPref = activity?.getSharedPreferences(
        getString(R.string.preference_file_key), Context.MODE_PRIVATE)
with (sharedPref.edit()) {
    putInt(getString(R.string.saved_high_score_key), newHighScore)
    apply()
}

Simple, straightforward, but Thread unsafe. On the other hand, the modern equivalent is also easier to understand, but behind the method calls, it already take cares of things like UI blocking and Thread safety:

// At the top level of your kotlin file:
val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "settings")

val HIGH_SCORE = intPreferencesKey("high_score")

suspend fun incrementCounter() {
  context.dataStore.edit { settings ->
    settings[HIGH_SCORE] = newHighScore
  }
}

As seen above, DataStore signals a shift toward a Kotlin friendlier, thread safer, error signalling, exception safer solution, with data migration, addressing many of the shortcomings of Shared Preferences.

How to update:

Updating SharedPreferences to Preferences DataStore is easy - First, add the library in the build.gradle app file:

implementation("androidx.datastore:datastore-preferences:${version}")

Make sure to create only one instance of the DataStore for each file you are using. Afterwards, change each instance of edit() to make sure it's using Preferences DataStore edit()version, and it's using it inside a suspend function, like above.

The hardest part will be replacing the get method from SharedPreferences with the .data method from DataStore, which returns a Flow<T>. This will require understanding Kotlin Flow, and creating at least a single element Flow when retrieving info from the DataStore.
For reference, use the official documentation: https://developer.android.com/topic/libraries/architecture/datastore

Final Word

Android development is constantly evolving, adopting new languages like Kotlin, new UI development frameworks like Jetpack Compose, new coding paradigms like Kotlin Coroutines and Kotlin Flow, and even creating some solutions to be more friendly with other modern Android technologies, like Room, DataStore and Koin. Embracing modern tools like Kotlin, Jetpack Compose, Material Design 3, Koin, Coroutines, Jetpack Room, and DataStore not only simplifies development but also ensures apps are more robust, scalable, maintainable and secure.

The transition from legacy systems to modern frameworks isn’t always smooth, requires effort and time, may add some risks into the project, and new unexpected constraints, but the benefits far outweigh the challenges. Take for example the reduced development time by adopting Kotlin instead of Java, or Compose instead of XML. Or the reduction of boilerplate code when using Kotlin instead of Java, or the powerful functionalities of Kotlin DSL libraries like Koin. By keeping up with these advancements, developers can deliver better experiences to users, in a shorter time and accompany the ever-changing Android ecosystem keeping their product up-to-date.

Cover image designed by fullvector at Freepik - www.freepik.com

Four dramatic predictions regarding AI tools and the IT market

Marco Coelho — Mon, 20 Jan 2025 15:20:04 +0000

Disclaimer:
Of course, you should take everything I say here with a grain of salt, given this is my personal and professional opinion, and everything I state here could change if IT professionals and the market as a whole make a concerted effort to address the issues. Nothing I'm predicting here is set in stone; the future can change if enough effort is put into shaping it.

My prediction for the years ahead for IT professionals is grim, unless significant changes are made. Below are four reasons why I believe this:

1. The Tech Industry is Failing the Next Generation

Let’s be frank: the tech industry is neglecting the next generation. The biggest issue isn’t with senior developers, tech leads, QAs, senior designers, project leaders, or product owners. Those roles are relatively secure. The real problem lies with newcomers: junior developers and trainees. They are being marginalized by the AI industry boom, and this phenomenon isn’t limited to developers but extends to many other careers as well.

The root of the problem is a lack of foresight from industry leaders. CEOs seem to have forgotten the old adage memento mori ("Remember you are mortal"). People age, retire, and pass away. If there’s no new generation to replace them, the industry will falter, Children of Men style. Hiring and training newcomers is crucial, even if it appears economically inefficient in the short term.

Without new talent, the workforce pipeline dries up. Layoffs, industry crashes, and a lack of mentorship discourage new entrants. Reputation matters; burned bridges are hard to rebuild.

Some CEOs believe AI can fill the gap, replacing junior roles entirely. But this strategy is flawed, as explained in the next section.

My proposed solution:

Establish valid trainee programs.
Continue hiring junior developers.
Ensure teams have a mix of experience levels, fostering mentorship and growth.

2. Neglecting the Next Generation is Harmful to AI

AI tools don’t emerge from a vacuum. They require skilled AI developers, machine learning engineers and architects to create and maintain large language models (LLMs). Additionally, these models rely on vast amounts of high-quality training data.

Where does this data come from? The collective work of developers over decades. Open-source contributions, public repositories, and shared knowledge form the backbone of training datasets. If junior developers aren’t hired and nurtured, the pool of skilled engineers and open-source contributions will dwindle. Over time, the quality and availability of training data will diminish, hindering AI advancements.

My proposed solution:

Support and sustain the developer community by investing in the next generation.
Reduce over-reliance on AI tools.

3. Coding AI Thrives on Non-AI Tech Advancements

Many overlook the fact that AI’s impressive coding capabilities are a byproduct of advancements in developer-friendly technologies over the past two decades. Frameworks and tools like JVM, .NET, Compose, Swift, Next.js, and Node.js simplify development significantly.

AI tools thrive in this environment but struggle with older, more complex technologies. Let’s see an AI tool code x64 assembly, C, or C++ with the same proficiency and safety it exhibits in JavaScript or Python. Historically, poorly coded low-level software led to issues like the infamous Windows “blue screen of death.” Critical systems still rely on these languages, and skilled developers are irreplaceable in such contexts.

My proposed solution:

Reserve AI tools for tasks involving high-level frameworks, or user friendly frameworks.
Employ trained developers for critical software written in lower-level languages.

4. IT is Developing a Bad Reputation

The IT industry’s reputation is deteriorating. Hiring sprees during the pandemic followed by mass layoffs have created an environment of distrust. Promises of stability and growth often ring hollow, and statements like “AI will replace developers” only exacerbate the issue.

IT workers are also facing a mental health crisis. According to BIMA’s Tech Inclusivity & Diversity Report 2019, 52% of tech workers have experienced anxiety or depression. Additionally, tech professionals are five times more likely to be depressed than the UK average and report stress levels comparable to those in healthcare. Source: https://www.diversityintech.co.uk/workplace-diversity-and-mental-health-in-tech/

This environment discourages young people from pursuing tech careers. Burned by false promises and instability, few are willing to give the industry a second chance. Consider for a moment, how many people do you personally know that have been affected by those?

My proposed solution:

Prioritize mental health in the workplace.
Invest in reputation-building and transparency.
Maintain consistent principles and avoid abrupt policy shifts (e.g., remote work mandates).

Final Thoughts

The future of the IT industry depends on the actions we take today. Ignoring the next generation, over-relying on AI, and fostering a toxic work environment will lead to long-term consequences. Again, I need to state clearly: This article is not an argument against AI, but it is an argument against over realiance on it. With strategic changes and a commitment to growth, those grim predictions may be changed, and the industry can secure a brighter future for it's professionals and proper adoption for it's technologies.

Cover image designed by rawpixel.com at Freepik - www.freepik.com

Three Common Pitfalls in Modern Android Development

Marco Coelho — Wed, 15 Jan 2025 19:49:57 +0000

Developing a modern Android solution can feel like navigating a dense jungle. There are countless tools and methodologies at your disposal, but one wrong step, and you’re in quicksand. Let’s look at three common pitfalls that can trip up even the most seasoned developers—and how to sidestep them like a pro.

1. Overlooking WebView Limitations in Jetpack Compose

Jetpack Compose is a game-changer for building user interfaces. It’s sleek, declarative, and a joy to work with. But as much as Compose feels like the hero we deserve, it does have a kryptonite: WebView.

WebView, the trusty sidekick of the older View system, allowed developers to load external web pages seamlessly. Unfortunately, Jetpack Compose doesn’t natively support WebView because it’s rooted in the older system. While you can technically use interop solutions to embed a WebView in Compose, it’s not without its drawbacks. For instance, screen recomposition—a fundamental concept in Compose—can become resource-intensive if not handled carefully.

So, what’s the play? If your app relies heavily on WebView, you might want to reconsider how you’re integrating it or explore alternatives like fully adopting Compose-native workflows.

2. Mishandling Coroutines for Asynchronous Operations

Coroutines are the Swiss Army knife of asynchronous programming in Android. They’re powerful, efficient, and—when used correctly—a delight to work with. But like any sharp tool, they’re also easy to misuse.

One of the most common missteps is calling coroutines in contexts where they’re not lifecycle-aware. This can lead to issues like memory leaks or, worse, crashing your app because a coroutine outlived its welcome. The fix? Leverage lifecycle-aware coroutine contexts. Android provides viewModelScope for ViewModels and lifecycleScope for Activities and Fragments. These scopes automatically tie the lifecycle of your coroutines to the lifecycle of their respective components, ensuring you don’t end up with rogue processes.

Remember: coroutines are your ally, not your babysitter. Use them responsibly.

3. Mixing Old and New Technologies Haphazardly

We get it. Sometimes you’re working on a legacy project, and mixing old XML layouts with Jetpack Compose seems like the path of least resistance. Or maybe you’ve got one foot in the MVP camp and another in MVVM because the project evolved (read: spiraled) that way.

The problem with blending these approaches is that each technology or architecture has its quirks. Mixing them without a clear strategy can result in a Frankenstein’s monster of a codebase—and not the cute, misunderstood kind.

If you must mix technologies, ensure you’re doing so with a solid plan. Define clear boundaries between components, and don’t let one approach bleed unnecessarily into another. This ensures that your migration or hybrid solution is maintainable and predictable.

Wrapping Up

Modern Android development is full of exciting possibilities, but it’s also easy to get tangled in the weeds. By being mindful of Jetpack Compose’s WebView limitations, handling coroutines with care, and approaching technology mixing strategically, you’ll stay on solid ground.

Oh, and remember: development pitfalls are just stepping stones in disguise. Learn from them, and your next project will thank you for it.

Keywords: Jetpack Compose, Android development, WebView, coroutines, lifecycleScope, viewModelScope, MVP, MVVM, modern Android development, mobile solutions.

Cover image designed by fullvector at Freepik - www.freepik.com