In the world of technology, "accessibility," often shortened to "a11y" (because there are 11 letters between 'a' and 'y'), means making sure that everyone can use them easily, no matter how they move, see, or hear. It's like building ramps and elevators so that everyone can enter a building, but for the digital world. In simple words, it's about making phones, tablets, and apps friendly for everyone, so nobody feels left out. Let's take a closer look at why this matters and how it affects both the physical parts (like buttons and screens) and the programs (like apps) we use every day.

Why Accessibility Matters in Tech

Have you ever had trouble using a phone or app because of small buttons or confusing screens? That's where accessibility comes in and why it's important. Think about your favorite app having tiny buttons or hard-to-read words – accessibility makes sure everyone, no matter their abilities, can easily use and enjoy their devices and apps.

Now, let's break it down. When we talk about the physical parts, like buttons and screens, we mean making them easy to see, touch, and understand. This helps people who might find small details hard to see or have difficulty touching the screen just right.

On the other hand, with apps, accessibility means designing them so that anyone can understand and use them, no matter their abilities. It's like making a map that everyone can read, so everyone can get the same information and use the same features. Whether you're sending a message, playing a game, or checking the weather, accessibility makes sure these everyday activities are fun for everyone, no matter how they use their devices.

Exploring Common Accessibility Features in Everyday Tech

Now that we know why accessibility is important, let's look at some common features that make our everyday gadgets and apps easy for everyone to use. Whether it's your smartphone, tablet, or computer, these features make sure that technology works for lots of different people.

Think about features like voice commands that let you control your device by speaking, which is helpful for those who might find touchscreens tricky. Then there are screen readers, which read out loud what's on the screen, helping people who can't see well. For those who can't hear well, technologies like vibration alerts or flashing lights give different ways to know when something's happening.

Many devices also let you change text size and contrast, which helps people who might find small text hard to read or need more color difference. These small changes can make a big difference for people with different needs.

As we explore these features, we'll see how developers can help everyone use technology easily and have a good time doing it.

Accessibility for Web

Making websites easy for everyone involves some technical stuff. First, it's important to organize the website properly using the right codes. For example, using proper HTML tags like <h1> for headings and <p> for paragraphs makes it easier for tools like screen readers to understand and explain the content to people who can't see the screen.

Pictures on websites need descriptions too. It's like adding a small text, known as alt text, to tell people with screen readers what the picture is about. For instance:

<img src="example.jpg" alt="A beautiful sunset over the mountains">

This makes the website more understandable for those who can't see the images.

Web developers also use something called ARIA to make interactive things on the website better for everyone. It's like giving extra information to help those who use different tools to navigate the internet. For instance, making a button more accessible with ARIA attributes:

<button aria-label="Play" onclick="playVideo()">▶️</button>

Colors matter too. Websites should use colors that make text easy to read. This helps people who have trouble seeing certain colors or have a hard time with small text. For example, ensuring good color contrast:

body {
  background-color: #ffffff;
  color: #333333;
}

For moving around a website, it's crucial to make it work with just a keyboard. Some people can't use a mouse, so being able to move around with keys is super important. Using focus styles in CSS to highlight keyboard focus:

a:focus, button:focus {
  outline: 2px solid #007bff;
}

Developers can also need to check if their websites are accessible by using tools like screen readers and other things to make sure everything works for everyone. It's like testing to make sure the website is friendly for all kinds of people.

To see more examples and learn about web accessibility, you can check out the W3C Web Accessibility Initiative (WAI) - Introduction to Web Accessibility for a comprehensive guide with practical examples. In short, making websites easy for everyone involves using the right codes, describing pictures, using ARIA, picking good colors, allowing keyboard use, and checking everything to make sure it works for everyone. That way, websites become friendly and useful for all people, no matter what they can or can't do.

Accessibility for Mobile Apps

When it comes to using phones and tablets, making apps that everyone can use is super important. Whether you have an Android phone or an iPhone, developers need to think about how to make apps that work well for everyone. Let's see how to do this in simple terms and with examples in both Kotlin (for Android) and Swift (for iPhone).

Making sure apps are easy for everyone involves some of the same ideas as websites. For example, developers need to make sure that the app has a clear and organized structure so that everyone, no matter how they use their phone, can understand and use it.

For Android, developers can use code like this to make a button more understandable for everyone:

val myButton: Button = findViewById(R.id.my_button)
myButton.contentDescription = "Play the video"
myButton.setOnClickListener { playVideo() }

This code sets a description for the button so that people who use special features on their phones can still know what the button does.

For iOS, developers can do something similar to make buttons accessible:

let myButton = UIButton()
myButton.accessibilityLabel = "Play the video"
myButton.addTarget(self, action: #selector(playVideo), for: .touchUpInside)

Here, setting an accessibilityLabel helps people who use special features on their iPhones understand what the button is for.

Just like on the internet, choosing the right colors in apps is really important. Developers need to pick colors that make text easy to read for everyone, especially those who might have trouble seeing certain colors.

For more details on making apps easy for everyone, you can check out the Apple Developer Accessibility Guide for iOS apps and the Build Accessibility Apps for Android

Special Mention

Before we wrap up, I want to share something incredibly exciting in the accessibility world that I find truly awesome – Project Leonardo from Sony PlayStation. It's not just about controllers; it's about making gaming a cozy experience for everyone, especially those with different needs.

Picture this: a kit that adapts to exactly how you want to play. Want different buttons or stick caps? No problem. Need the control stick longer or shorter? You got it. And you can place the controller wherever suits you best – on a table, your lap, or attach it to special mounts.

What blew my mind is that you can use up to two controllers together, adding features like vibrations and special triggers. Connect extra buttons and switches to make it your perfect setup. And the cherry on top – you can have different setups for different games, up to 30 of them! Just press a button to switch between them.

But the real magic? You decide exactly what each button does. Want a button to do more than one thing? Absolutely! And if there's a button you don't want to use, you can turn it off.

Even the packaging is a win – easy to open with loops on both sides. It's made so that anyone, no matter their abilities, can open it with just one hand and not too much effort. It's these little things that show they've thought about every detail to make sure everyone can enjoy gaming.

Project Leonardo is more than just a gaming revolution; it's a big step toward making sure gaming is for everyone. Kudos to Sony Playstation for making gaming not just accessible but downright fun for all of us!

Wrap Up

Okay, let's sum it all up. We talked about making tech friendly for everyone, from websites to gaming. It's like giving everyone a fair shot in the digital world.

You've got the basics – making websites easy to understand, buttons that work for all, and colors that don't play hide and seek. Then there's the cool Project Leonardo from Sony PlayStation, making gaming comfy for everyone.

Remember, it's not just about features; it's about making tech a breeze for everyone. So, whether you're building websites or diving into games, let's keep it simple, keep it friendly. Because every little step in making tech easy is a big win for a world where everyone can join the fun. Cheers to tech without limits!

When I was developing my personal blog, I was curious about how search engines like Google would crawl my site. What if I didn't want certain pages indexed? What if I didn't submit my site to Google Search Console? These questions sent me down a rabbit hole of discovery about the robots.txt file.

We know that our sites can appear on search engines like Google in two ways: either we submit them to the Search Console, or other websites link to us, creating a trail for those tireless search engine bots to follow. But even without our explicit permission, these bots are out there, tirelessly exploring and organizing the internet through links, sitemaps, and any accessible web page they can find.

What if a site doesn't want to be indexed?

If you're writing a novel, pouring your heart and soul into each chapter. You wouldn't want unfinished drafts or embarrassing early versions to pop up in search results before your masterpiece is ready, right? That's where robots.txt comes in. Think of it as a polite "Do Not Enter" sign for search engine bots, keeping your creative work hidden until you're ready to share it with the world. By adding a simple line like Disallow: /drafts/ to your robots.txt file, you can tell the bots to skip that entire directory, ensuring your literary gems remain under wraps until you're ready to unleash them on the world.

Why isn't the default the opposite?

It might seem strange that Google doesn't exclusively include websites that ask to be included. Why not make it "opt-in" instead of the current "opt-out" system? Well, the internet's core principle is openness and accessibility. Google wants to offer the most comprehensive search results possible, showcasing a diverse range of content. If it were opt-in, new websites would struggle to get noticed, and search results would become a stagnant echo chamber.

If only the biggest, most established websites were indexed. Smaller, niche websites with valuable information would be lost in the void. New voices and perspectives would struggle to appear. The internet, once have diverse of content, would become having less of content. That's why Google's open approach, though it might seem counterintuitive at first, it ultimately benefits everyone.

When was the robots.txt first introduced?

Now, let's rewind to 1994, the year dial-up internet was king, and floppy disks were still a thing. That's when the robots.txt file first entered the scene. It's like a friendly note placed at the root of your website, politely guiding those busy search engine bots. Think of it as a personal assistant for your website, politely whispering to search engine bots, 'Not this folder, please!'

Example code:

User-agent: *
Disallow: /private/
Disallow: /old-content/
Allow: /sitemap.xml

This simple code snippet tells all search engine bots (the "User-agent") to avoid the /private/ and /old-content/ directories, while still allowing access to the important sitemap.xml file. See? The robots.txt is surprisingly straightforward!

What happened before robots.txt?

Before this robots.txt existed, website owners had to get creative to control search engine crawlers. Meta tags with specific instructions, passwords protecting hidden sections, and even cleverly crafted URLs were all tactics employed in the wild west days of the internet. But it was a messy, inconsistent system, lacking a standardized way for website owners to communicate with search engines.

Imagine the chaos! One website might use a cryptic meta tag, another a password hidden in the source code, and a third might rely on a URL that only a decoder ring could decipher. It was a nightmare for both website owners and search engines. The robots.txt comes to solve the chaos, providing a clear and universal language for everyone to speak.

Why the .txt format?

Back then, complexity was a luxury. Text-based websites ruled the internet, and the humble .txt file was king. Why? Because it was like speaking in plain English – everyone understood it. No fancy software, no cryptic codes, just simple lines of text that anyone could read and edit. This made it perfect for robots.txt, a tool meant to be a universal translator between websites and search engine bots.

But what if robots.txt had been a fancy XML document, or a sleek JSON file? Those formats might be powerful and flexible, but back then, they were like speaking ancient symbol to a room full of toddlers. Only tech-savvy webmasters with advanced software could decipher them. For everyone else, it would be a confusing mess.

So, the humble .txt file stepped up to the plate. It was the bridge between the techy world of search engines and the everyday world of website owners. It was simple, accessible, and above all, it worked. It still does. Even today, in the age of fancy web frameworks and complex coding, the .txt file remains the go-to format for robots.txt, power of simplicity in a world that can get awfully complicated.

What if we use emoji?

Come on, this question is too creative not to explore! Instead of dry old code, we'd have "no way" signs ✋ to unwanted bots, and smiley faces pointing towards the good stuff like sitemaps . Sounds cute, right?

Well, this emoji paradise could quickly turn into a chaos. Just picture a bot mistaking a thumbs up for "crawl everything", or a winking face for "secret page, come peek!" The horror! Not to mention the cultural confusion. In some countries, a thumbs up is cool, in others, it's basically an insult.

Remember that friendly "Do Not Enter" sign for search engine bots? In emoji world, that might be a skull and crossbones ☠️, which, depending on the bot's mood, could be like throwing gasoline on a fire. No, thank you!

So, while emoji robots.txt files might be a hilarious thought experiment, let's stick to good old-fashioned text for now. It might not be as flashy, but at least it's a universal language that all search engine bots can understand. And who knows, maybe someday we'll have a fancy new format that's both powerful and easy to use, Until then, keep your emojis for your social media posts and let robots.txt stay nice and clear.

Conclusion

So, there you have it! Robots.txt, the hero of website control, quietly working behind the scenes to keep your precious pages hidden from unwanted eyes. It may not be the flashiest tool in the webmaster's toolbox, but its simple code speaks a universal language that search engine bots understand.

And remember, robots.txt isn't just about hiding things. It can also help you be a good website citizen, guiding search engines to the most important parts of your site like sitemaps and fresh content. It's a win-win for everyone, making sure your website shines in the best possible light. Now go forth and unleash your website on the world, with a little help from your friendly neighborhood robots.txt!

I recently found Flipper Zero on the internet, and let me tell you, it caught my eye! This little device seems packed with features for messing around with radio signals, access control systems, and all sorts of techy stuff. It kinda reminds me of those Swiss Army knives that do everything!

But before I hop on the hype train, I wanted to share some thoughts.

Cool, but is it complete?

From what I've seen online, the Flipper Zero can do a lot. It can mimic RFID cards, hack door locks, even control TVs! That's pretty awesome, but I'm not sure if it's truly "complete" for everything it wants to do. There might be limitations or technical hiccups here and there.

Fun for a while, then what?

Let's be honest, messing around with gadgets is always fun at first. But I gotta wonder, how long will the Flipper Zero stay interesting? After a few hours or days of "playing," will it just gather dust? I'm worried that the novelty might wear off quickly.

Tutorials galore, but will they be any good?

With a device like this, there's bound to be an explosion of tutorials online. But will they be any good? Will they be beginner-friendly, or just a mess of technical jargon? I'm hoping we get some clear, helpful guides to make the most of the Flipper Zero.

DIY alternative: Raspberry Pi & Arduino to the rescue?

As a techie myself, I can't help but think about building something similar using a Raspberry Pi or Arduino. Sure, it might be more challenging, but it could be a fun learning experience and give you even more control.

Indonesian Adventures: Shipping woes?

I'm based in Indonesia, and I'm a bit worried about getting my hands on this gadget. Shipping restrictions can be a real pain, so even if I wanted to try it out, it might not be easy.

Final thoughts: Don't just follow the hype!

The Flipper Zero looks cool, but before you empty your wallet, don't just follow the hype! Think about what you want to use it for, how long it might be interesting, and if there are better alternatives. And for my fellow Indonesians, be prepared for some shipping hurdles!

So, what do you think? Has the Flipper Zero sparked your curiosity, or do you see it as more of a techy fad? Let's chat in the comments below!

P.S. This is just my opinion based on what I've seen online. I haven't actually played with the Flipper Zero yet, so maybe it's even cooler than I imagine! I'll keep you posted if I get my hands on one.

Remember, stay curious, stay techy, and don't be afraid to experiment!

Have you seen an app that can change the app icon by itself? Apps that offer in-app purchases sometimes do this. For example, Discord with its Discord Nitro, Twitter with its Twitter Blue, or Reddit with its Reddit Premium. They allow the users to change how the app icon looks. For me personally, that kind of feature makes me think "What kind of magic is this?" Because we know the source of the app icon is coming from the manifest. So do they dynamically change the manifest file? Is that possible? Well, the answer is no, but they are using activity-alias for this magic trick. Let's take a look by checking how usually app icons are set.

Typically, app icons are set in the AndroidManifest.xml using attributes like android:icon and android:roundIcon. But for apps that offer users the ability to change their icons dynamically, developers employ the use of activity-alias in the manifest file.

In this example, two entries point to the same YourActivity class. The first acts as the main launcher icon, while the second serves as an alias with a different icon. When the app is installed, the icon of the main activity is set. Then, we can toggle the activity alias, to switch the icon to that of the alias on the runtime using PackageManager class.

The snippet above demonstrates the use of the setComponentEnabledSetting method of the PackageManager class. By passing the component names of both the activity-alias and the main activity, we can enable the activity-alias while disabling the main activity. This action effectively changes the app icon.

Now, here's the deal, we're all in this Android development game together. So, why not share the love? Drop this post to your dev buddies, start a chat, and let's make sure this icon-changing magic becomes common in our community. Can't wait to see more apps rocking this trick! 🚀

As an Android app developer, you may have found yourself wondering whether to "force" users to update your app or simply remind them to do so. Additionally, with a considerable number of users opting not to enable auto-updates or manually check for updates, it can become challenging to ensure they are using the latest version. Well, you can make your own implementation for "nicely asking" the users to update. Fortunately, the good news is that Google has already provided a solution for this, the Android In-App Updates feature.

Introduction

In-App Updates, as the name itself already self-explaining, is a functionality that enables updating the application from within the app itself. This convenient feature is available for devices running Android 5.0 (API 21) or later, but it requires the Play Core Library to be at least version 1.5.0. Additionally, for the feature to work seamlessly, the application must already be available on the Google Play Store. However, it's worth noting that this particular feature is not compatible with APK Expansion Files (.obb). Despite this limitation, it provides an effective way to keep your app's users up-to-date with the latest improvements and fixes.

In-App Updates offers two ways to carry out updates. The first method is called Flexible Updates, which comes in handy when you prefer a non-intrusive approach and the updates are minor in nature. With this option, users receive the choice to update the app in the background while continuing to use it, or they can opt not to update at that moment. On the other hand, the second method is known as Immediate Updates, which serves its purpose when you need to enforce updates, especially for critical fixes or essential improvements. When utilizing this method, users are immediately restricted from interacting with the application until they either update it or choose to close the application altogether. These two update options provide developers with the flexibility to accommodate different scenarios and user preferences efficiently.

How it works

After knowing Google Play In-App Updates support two ways updates. Maybe you wondering, how it actually works. Actually it's simple to make a flexible or immediate updates. First of all you can check if there is an update or not using AppUpdateManager, it will ask the Google Play if there is an update for your app using the package name of your app. Then, it will returning the update availability. If it's available you can start the update flow, either it's Flexible or Immediate update. That's it.

Well, if you want it to always using same flow over and over again then there is no other things that you need to do. For example, if you want your apps to be always using Flexible updates, then you didn't need to check whether it's need to start Flexible or Immediate updates. But what if you need? Then, you don't just need to start the flow. You also need to specify the flow based on your preferred way.

Google Play also give you other information along with the update availability. They give you Update Staleness and Update Priority, which will be useful if you want to have different flow for different cases.

The Update Staleness is an information about the number of days since the update became available on the Play Store. So if you want to decide to only Immediate update to the users that not updating after an update published for 1 month or so then you can use this.

The Update Priority is an information about how strongly to recommend an update to the user. It's ranging from 0 to 5, with 0 being the default and 5 being the highest priority. So if you want to decide to only Immediate update if the priority is the highest, which is 5. Then you can use this information.

But, unfortunately at this time of writing, Google Play Console doesn't have this kind of feature to edit or set the priority from the website. It's only available from Google Play Developer API.

How To Implement

After all of that information then I will give a step by step how to implement this feature on your apps, either its new app or existing app. The requirement here it's already uploaded to Google Play Store, not using APK Expansion Files (.obb), and can only be used on devices running Android 5.0 (API level 21) or higher.

Simple Example

The goal here on the simple example is to make an flexible or immediate updates without having logic for checking the Update Staleness and Update Priority. We will talk about that later on the next section of article, you can skip to the advanced example if you're more interested about that one.

OK First, we need to add the Play Core Library to the build.gradle (app). At this moment of writing the newest version is 1.10.0, make sure you're using the latest version. You can check the latest version here.

Then, in the Main activity we need to create an instance of the AppUpdateManager, request the update availability, then start the Flexible updates if there is update available. Here is the sample code.

That's it, you already added Google Play In-App Updates to your app using Flexible updates. You can simply change AppUpdateType.FLEXIBLE to AppUpdateType.IMMEDIATE to change to Immediate update flow.

Advanced Example

Now what if we need more than that? For example we want to use Update Staleness and Update Priority to make the decision whether we are going to use Immediate or Flexible updates. To make it simple, look at this table for our update strategy scenario.

Based on that table, users with Priority 0 to 2 always receive Flexible Updates, regardless of update staleness. For Priority 4 and 5, users always get Immediate Updates. However, for Priority 3, the update type varies with update staleness. If the staleness is under 7 days, they receive Flexible Updates, but after 7 days, they receive Immediate Updates.

So we need to modify our code from the above one to cater this scenario. The changes that we need to do here are on the success listener of appUpdateInfoTask, instead of directly start the flow if the update available, we also need to check the staleness and priority. Here is the sample code:

Finished? Well, not really. We already handle the client side which will update it based on the priority and staleness but we aren't setting up the priority yet using Google Play Developer API.

Set Priority Using Google Play Developer API

To be able to upload to Google Play via the Play Developer API, we are required to link the Google Cloud project to the Google Play Console. This step is required if we want to use Update Priority in the In App Updates feature. If not, this section can be skipped and directly uploaded as usual using Google Play Console.

Linking Google Cloud Project to Google Play Console

• Open Google Play Console
• Choose Settings > Developer Account > API Access

• Click Choose a project to link

• If you already have a Google cloud project, choose Link existing project, if not, you can choose Create new project

• Choose Create new service account

• A popup will appear like this, then open Google Cloud Platform

• Click on Create Service Account

• Fill in the name, and click Create

• In the next step, select Owner as the role, and click Done.

• Click the Actions icon and select Manage keys

• Click Add Key dan choose Create new key

• Choose JSON and then click Create

• Keep the downloaded file in a safe place, because it can't be re-downloaded if you lose it.
• Go back to Google Play Console, and click Done on this popup.

• Select Users and Permissions then Invite New User

• Open the .json file, and copy client_email and paste it in Email Address, and click Add app at the bottom, and select the app you want to add In App Updates to.

• In the permission popup, checklist 4 as shown below, and click Apply, and click Invite User.

Now after doing all the steps above, we can upload the application via the Play Developer API to add Update Priority. Here we will use one of the packages that I made myself to facilitate the upload process called abizareyhan/playpublish. But before that, make sure the application containing the In App Updates code that has been written above has been uploaded to Google Play, you can use the normal method through the Google Play Console, without having to add Update Priority because the goal is for the In App Updates popup to appear, after that just proceed to the steps below.

Upload via Play Developer API

• First, install the playpublish package via npm

> npm i -g playpublish

• Run the playpublish command, and follow the remaining steps

> playpublish

Try to keep the service account json and apk or app bundle files in the same folder to make it easier to write the path.

• If it works like the image above, you can check it directly in the Google Play Console. In this scenario what is uploaded is versionCodes 14 to the Internal Testing track and inAppUpdatePriority 5.

There you have it! Now you know all about In-App Updates and how to use them in your Android app. In-App Updates allow you to update your app from within the app itself, which makes it easier for users to stay up-to-date with the latest improvements and fixes.

So, with all this knowledge, you're ready to keep your app users happy and up-to-date with the latest features and bug fixes. Happy updating!