In an age dominated by technological advancement, the world of writing has not remained untouched. From news articles to creative pieces, AI has managed to infiltrate every corner of the writing realm, and blog posts are no exception. But what exactly is the effect of AI on blog posts? Are we witnessing a new era of efficiency and creativity, or are we slowly drifting away from the authenticity that once defined our writing?

The Pros: Enhancing Efficiency and Creativity

1. Increased Efficiency: One of the most obvious benefits of incorporating AI into blog writing is the efficiency it offers. AI-powered tools can generate content at a lightning-fast pace, significantly reducing the time required to produce a blog post. Writers can now focus on refining ideas and adding a personal touch rather than spending hours drafting the initial content.
2. Consistency and Accuracy: AI is capable of maintaining a consistent tone and style throughout a blog post, ensuring a seamless reading experience. Moreover, it minimizes the chances of grammatical errors and typos, contributing to the overall professionalism of the piece.
3. Content Ideas and Research: AI tools can aid in generating fresh content ideas and conducting extensive research on a given topic. This can be a boon for writers struggling with writer’s block or seeking to explore new niches.
4. Multilingual Blogging: Language barriers can be transcended with the help of AI translation tools, allowing bloggers to reach a wider global audience without being limited by linguistic constraints.

The Cons: Straying from Authenticity and Creativity

1. Lack of Human Touch: While AI can mimic writing styles, it often lacks the emotional depth and nuanced perspectives that human writers bring to their work. The emotional connection between the writer and the reader can sometimes be lost when AI takes the lead.
2. Template-Driven Content: Some AI-generated content may appear formulaic or template-driven, lacking the uniqueness that readers seek in a well-crafted blog post. This could lead to a decline in reader engagement and loyalty.
3. Ethical Concerns: As AI evolves, it raises ethical questions about plagiarism and originality. AI tools sometimes inadvertently generate content that closely resembles existing work, potentially leading to copyright disputes.
4. Moving Away from Reality: The convenience of AI-generated content might tempt writers to rely solely on automation, gradually moving away from authentic experiences and firsthand observations. This could erode the genuine, relatable essence of blog writing.

Striking a Balance: Human Creativity and AI Assistance

Rather than viewing AI as an adversary, bloggers can harness its power as a tool for enhancement. Here’s how:

1. Content Ideation: Allow AI to provide you with content ideas and data-backed insights, but infuse your unique perspectives and experiences into the narrative.
2. Draft Generation: Utilize AI to draft an initial outline or framework, then dive in to enrich it with your distinctive voice, anecdotes, and personal touch.
3. Editing and Refinement: Rely on AI-powered editing tools for grammar and style checks, but don’t overlook the value of human editing to preserve authenticity.
4. Innovation: Experiment with incorporating AI-generated elements, such as infographics or data visualizations, into your blog to enhance reader engagement.

Before we wrap up this journey into the realm of AI-powered blog writing, let’s unveil a little secret. Yes, you guessed it — this very blog post you’ve been reading was penned by none other than an AI. But fear not, dear reader, no humans were harmed in the making of this content!

In a twist that even the best mystery novels would envy, the very words you’ve just absorbed were crafted by lines of code and neural networks. It seems the AI uprising is not quite a Terminator-style apocalypse, but rather a friendly assistant eager to help create insightful, engaging content.

So, as you contemplate the fascinating relationship between AI and the art of blogging, take a moment to appreciate the irony that an AI has dissected the topic of its own influence. Remember, whether it’s AI or human creativity, the essence of a captivating blog post remains the same — a connection between the writer’s mind and the reader’s imagination.

Until next time, fellow enthusiasts of the written word and unwitting participants in the AI takeover — keep writing, keep reading, and keep those virtual cogs and gears turning!

As a developer, it’s important to stay sharp and continuously improve your skills. One way to do this is to practice solving algorithm and data structure problems, such as those found on LeetCode. Not only does this help you to improve your problem-solving skills, but it also has many other benefits. However, merely solving the problems may not be enough to truly master the concepts. That’s where keeping a coding journal comes in.

A coding journal is a personal collection of notes and solutions to coding problems, often stored in a notebook or a digital file. By keeping a coding journal, you can record your thought process as you work through a problem, document your solutions, and reflect on what you’ve learned. This process can help you to better understand the concepts and to reinforce your knowledge over time.

1. Write down your thought process: As you work through a coding problem, jot down your ideas, assumptions, and hypotheses. This will help you to organize your thoughts and to identify areas where you might be struggling.
2. Document your solutions: Once you’ve solved a problem, write down your code and any notes or insights that you gained. This will help you to remember your solution and to compare it to other solutions in the future.
3. Reflect on what you’ve learned: After you’ve solved a problem, take some time to reflect on what you’ve learned. This could include summarizing the key concepts, identifying common patterns or tricks, or thinking about how you could apply what you’ve learned to other problems. And spend some time to check out how other developers have solved the problem to gain new perspectives.
4. Review your journal regularly: Make a habit of reviewing your journal regularly to reinforce your understanding of the concepts and to identify areas where you might need more practice.

Here is the GitHub repository of my coding journal. In the repo, you can find some solutions and notes that I took.

GitHub - mitsinsar/TheJourney

And here are some of the gains you can experience from solving algorithm problems:

1. Improved problem-solving skills: Solving algorithm problems is an excellent way to improve your problem-solving skills. It teaches you to break down complex problems into smaller, more manageable pieces and to think critically about how to solve them.
2. Increased familiarity with common algorithms and data structures: By solving a variety of algorithm problems, you’ll become more familiar with common algorithms and data structures, which can help you to recognize patterns and apply them to other problems.
3. Sharpened programming skills: Solving algorithm problems requires you to write efficient and optimized code. By practicing this skill, you’ll become a better programmer overall and be able to write cleaner, more efficient code in other areas.
4. Improved performance in technical interviews: Many technical interviews for software engineering positions involve algorithm problems. By solving these problems regularly, you’ll be better prepared for technical interviews and more confident in your abilities.

By keeping a coding journal, you can improve your algorithm knowledge in a more structured and deliberate way. You’ll be able to see your progress over time, document your solutions and thought process, and reflect on what you’ve learned. And by regularly solving algorithm problems, you’ll improve your problem-solving skills, programming skills, and performance in technical interviews. So, start practicing today and see how your skills can improve over time!

Have you ever thought about what happens after we die? No one knows. But there is something we know: When an app dies, we lose state.

Unfortunately mobile devices don’t have unlimited battery or unlimited memory. That’s why when system needs more memory, it kills processes to make some room. So we should make sure that our apps are not effected by this process death. Although it is very important in terms of user experience, the solution is quite easy.

Let’s see an example; We have an application where we fetch user details when Get User button is clicked. This is the initial state of the application.

When we click on Get User button, we fetch user details from an API and update the UI.

We have a simple ViewModel that keeps the UI state;

And this is our UI state class, just a simple data class.

Since we keep the UI state reference in ViewModel, application will not lose state when we rotate the device or send the application to the background.

BUT if system kills the app when the application is on the background, user will see the initial/empty state when the app is reopened.

To simulate process death in Android Studio;
Go to Logcat -> Terminate Application

Or you can enable “Don’t keep activities” option in Developer Settings of the device.

So how do we prevent state loss in this situation? How do we save the state and how do we handle it? We use SavedStateHandle:

As soon as we update the UI state, we save it to the SavedStateHandle and when app is relaunched, we check if we have saved state or not. It is that simple!

There are some key points that we need to consider while applying this solution;

• Data we save in SavedStateHandle must be Parcelable so that we can write it to the bundle.
• The amount of data should be kept small because the system process needs to hold on to the provided data for as long as the user can ever navigate back to that activity. Android recommends that we should keep saved state to less than 50k of data.

You can check the sample application in the repo below:

• GitHub - mitsinsar/SavedStateHandleExample
• Who lives and who dies? Process priorities on Android

How to Handle Process Death on Android was originally published in Hipo on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been trying to customize MaterialTimePicker and couldn’t find proper documentation about it. So I decided to make one. I will try to explain as simple as possible.

If you find this blog post, I believe you already know about MaterialTimePicker. That’s why I am not going to explain what it is.

Still want to learn about more; overview documentation.

This is what we are going to build. You can find demo app here.

Customizing Clock Face

Name of the attributes are pretty self explanatory;

Customizing Keyboard Icon

This one is a button. You can change tint, ripple, shape and stuff.

Customizing AM/PM Selection

This one is also a button;

Background is a simple selector;

Customizing Title

Simple TextView

Customizing Chip

Pretty much everything is self explanatory. There is one attribute we don’t see too much;
elevationOverlayEnabled: This Boolean is being used to make elevation more noticeable for Dark Mode. For detailed explanation, check here.

Chip background color;

Chip text color;

For EditText border and CANCEL & OK button colors, I had to override colorPrimary attribute. I believe this is kind of bug or something. Couldn’t find better solution for them. Also for EditText color, I had to override textColorPrimary attribute.

For more information; https://material.io/components/time-pickers

Hipo/macaron

How can we make publishing a library as easy as possible?

That was the thought in our mind as we set out on this road. As Hipo, we decided to publish our Android libraries we use in our projects as open source and created Macaron. Macaron is a single repository that contains multiple open source library modules, like Retrofit. With this approach, libraries become easier to maintain and have a more organized structure. Also you can implement what you need. For example there are around 10 converters in Retrofit-converters package, but we need only Gson. So we can implement Gson only, without implementing any unnecessary converter.

Since multiple developers are involved in development, we had to make the process easy to understand, easy to develop and easy to publish. We decided to use Bintray like we did before and we also decided to use CI for Macaron. We are currently using Bitrise for CI in Hipo. For Macaron, we decided to follow the same pattern.

To publish the library — after everything is set up — only thing a developer needs to do is to add a tag and push it to GitHub. That’s it!

Last time, we talked about how to publish an open source library on JCenter. If you want to get more detail about JCenter and publishing single repo-single library, you can check the link below;

How to Publish an Open Source Android Library on JCenter

First we need to understand Bintray. What does Bintray need? We separate Bitray’s needs into 6 topics and created files for each of them.

• Bintray repository
• Developer properties
• Library properties
• License properties
• Local properties
• Repository properties

Bintray Repository

We are not able to push our packages if we don’t have a Bintray repository. It is pretty easy to create one;

Sign In -> Click Add New Repository on Dashboard -> Fill necessary fields.

Make sure to choose Maven for type. We will publish on Maven in this example.

Developer Properties

This file includes information about developer that developed the library module such as; Id, name, email and organisation.

developerId='[BINTRAY_DEVELOPER_ID]'
developerName='[DEVELOPER_NAME]'
developerEmail='[DEVELOPER_EMAIL]'
developerOrganisation=[DEVELOPER_ORGANISATION]

Library Properties

Bintray use these properties to create library package.

artifact=photocropping
libraryName=com.hipo.photocropping
libraryVersion=1.0.0
libraryDescription=Photo cropping library that uses PhotoView and has extensions for file provider

Here you can see what they are used for;

Do not confuse the library name with implementation parameter. It will be described in Repository Properties.

License Properties

Since we share all libraries with Apache-2.0, we didn’t separate license.properties file for each library module. These properties is being used to set library license;

licenseName = 'The Apache Software License, Version 2.0'
licenseUrl = 'http://www.apache.org/licenses/LICENSE-2.0.txt'
allLicenses = ["Apache-2.0"]

Local Properties

bintrayUser=YOUR_BINTRAY_USERNAME
bintrayApiKey=YOUR_BINTRAY_API_KEY

To publish without Bitrise, username and API key must be defined in local.properties to avoid from pushing it to GitHub.

Repository Properties

bintrayRepoName=Macaron
publishedGroupId=com.hipo.macaron

macaronSiteUrl=https://github.com/Hipo/macaron
macaronGitUrl=https://github.com/Hipo/macaron.git

Here we give our GitHub repository url and vcs url.

bintrayRepoName has to be same as name of the repo you’ve created on Bintray.

publishedGroupId determines what dependency parameter will be. For example we set our artifact as photocropping. Bintray will get this artifact name and combine with published group id and the result will be;

These are what Bintray needs.

How do we create pom / aar packages and upload them to Bintray?

First, we need a Gradle file! Let’s dive into our publish.gradle which is responsible of checking properties, installing pom&aar packages and uploading them to Bintray.

Defining property files

Here we just read files that we’ve created before. license.properties, developer.properties, library.properties, macaron.properties…

I want you to focus on if check on line 13. As we mentioned, we want Bitrise to publish our library. Since we keep our Bintray API key and username in local.properties, we can not push it to GitHub. So we have to check if we have local.properties on current environment or not. If we don’t have it, we use System.getenv() to get API key & username from Bitrise Secret Envs.

Checking if everything is OK

checkProperties reads every property in given files and throws exception if there is any missing one. If there isn’t a file called local.properties on current environment, it skips that file.

Installing POM / AAR packages

Install task is responsible of creating POM and AAR packages. It gets information it needs from files we’ve created before. We use Dcendents/Android-Maven-Gradle-Plugin for this task.

Uploading to Bintray

In bintray scope, we give what Bintray needs. Bintray repo, library name etc… They are also defined in files we’ve created before.

Reason of reading properties from files is to use only one publish.gradle to publish all libraries.

To make this happen, we get publish.gradle by adding the line below at the end of the build.gradle in library module.

This line makes build.gradle read publish.gradle from our GitHub repository.

You can see full publish.gradle below:

Hipo/macaron

DO NOT FORGET TO ADD PLUGIN DEPENDENCIES INTO YOUR PROJECT build.gradle

It’s time to set up Bitrise.

I won’t discuss how to add a new Bitrise app and what steps/workflows mean. Bitrise has pretty good documentation and UI.

• Bitrise Docs
• Bitrise Docs

Since we control everything from our GitHub repo, we decided to create a simple .sh script and let Bitrise run it for us, so we don’t have to update Bitrise workflows if we add new task to any of our gradle files.

Just remove default steps and add a script step to your deploy workflow and give your script path to Script Content. Bitrise also let you write your script into there.

Let’s add our Bintray credentials to Bitrise. Go to Secrets and add your Bintray credentials as shown below. Keys have to match with System.getenv() parameters in publish.gradle.

Since we use Gradle task in our bash script, we need to define Gradlew path in Env Vars. Make sure the key is GRADLEW_PATH;

Now, Bitrise knows how to check if there is any missing property, install packages and upload them to Bintray with our credentials. But, how does Bitrise know when to do these tasks? Triggers for the win!

We set our trigger tag as *.*.*-*, so whenever we push a tag which has the same pattern, our deploy workflow will run. By doing that we can choose which module to publish independently.

For example, there are 3 library modules but we want to publish only one of them. In this case, our tag will be 1.0.0-alpha03-photocropping. Bash script will parse module name and will call necessary tasks, like; photocropping:install.

Bitrise settings is done!

Last but not least: Project Structure

Project
...
 |
 +-- library_module_1
 |   |
 |   |-- library.properties
 |   \-- developer.properties
 |
 +-- library_module_2
 |   |
 |   |-- library.properties
 |   \-- developer.properties
 |
 +-- publish
 |   |
 |   |-- bintray-publish-script.sh
 |   |-- license.properties
 |   |-- macaron.properties
 |   \-- publish.gradle
 |
 +-- local.properties
...

This is our project structure for Macaron.

• Since license.properties and macaron.properties are the same for all library modules, we don’t need to separate them. But each library module has to have their own library.properties and developer.properties.
• As we mentioned before, they will all use same publish.gradle which was pushed to GitHub repository.
• Bitrise will check ./publish/bintray-publish-script.sh to run bash script. So make sure that you give the right path for the script.

That’s it!

Now you can create your open source project and give back to the community.

How to Publish a Single Repository — Multiple Libraries on JCenter using CI was originally published in Hipo on Medium, where people are continuing the conversation by highlighting and responding to this story.

This blog will be a kind of reminder about Android menus. I will try to summarize as much as possible. I will focus on what they are and how we implement them.

Menus can contain group or a submenu.

Group

You can have checkbox or radio button behavior by settingcheckableBehavior of group item.

• single Only one item from the group can be checked (radio buttons)
• all All items can be checked (checkboxes)
• none No items are checkable

By using group , you can;

• Show or hide all items with setGroupVisible()
• Enable or disable all items with setGroupEnabled()
• Specify whether all items are checkable with setGroupCheckable()

You can see group example in Option Menu as Option 1 & Option 2.

Submenu

You can create a submenu by adding menu item in your current menu.xml.

You can see submenu example in Option Menu as File — New & Open

There are 3 menu options;

• Option Menu
• Contextual Menu | Floating Context Menu — Contextual Action Mode
• Popup Menu

Option Menu

Xml

Code

Contextual Menu

Floating Context Menu

Xml

Code

We have to register our views which we want to show floating menu when they are long pressed.

Contextual Action Mode

Xml

Code

Popup Menu

Xml

Code

To get more details;

Menus | Android Developers

Belirli koşullar altında çalışmasını istediğimiz bir fonksiyon varsa ilk aklımıza gelen yapı JobScheduler olmalıdır. Örneğin uygulamamıza yeni bir versiyon çıktık ve bu versiyonun boyutu yüksek olduğu için sadece WiFi’a bağlı iken ve cihaz şarjda iken güncellenmesini istiyoruz. Bu ve benzeri durumlarda JobScheduler tam da aradığımız şey. Unutmamak gereklidir ki sadece API 21 ve üzerini desteklemektedir.

Nelerden oluşur?

• JobInfo: JobScheduler ‘ ın hangi koşullar altında gerçekleşeceğini belirlediğimiz konfigürasyon nesnesi. JobScheduler ‘ın çalışması için en az bir koşul gereklidir.
• JobService: JobInfo içerisinde verdiğimi koşulların sağlanması durumunda çalışacak olan servis.

JobService iki temel fonksiyondan oluşmakta;

• onStartJob: İstediğimiz koşullar sağlandığında çağrılan fonksiyondur. MainThread üzerinde çalışır. Boolean bir değer döndürerek yapılması gereken işin ayrı bir threadde devam edip etmemesi gerektiğini belirleyebiliriz.
  —true:Yapılan işin ayrı bir threadde devam ettiğini söylüyoruz. Bu durumda jobFinished() fonksiyonunu iş bittikten sonra bizim çağırmamız gerekiyor.
   — false: Sistem, yapılan işin onStartJob() içinde bittiğini, yani ayrı bir thread’e geçmediğini bilir ve jobFinished() fonksiyonunu kendisi çağırır.
• onStopJob: Sistem, jobFinished() fonksiyonunun çağrılıp çağrılmadığına bakmaksızın yapılan işin durdurulması gerektiğine karar verdiğinde çağrılan fonksiyondur.

Temel olarak yukarıda bahsettiğimiz yapılardan oluşmaktadır. Şimdi küçük bir örnek ile konuyu pekiştirelim;

Boş bir proje yarattıktan sonra, JobService extend eden bir sınıf oluşturalım. Bizim örneğimizde yapacağımız şey Toast göstermek olduğundan adını ToastJobService koydum.

showToast() fonksiyonu farklı bir dosyada oluşturduğum basit bir extension. JobService aslında Android’deki 4 temel bileşenden biri olan Service ‘i extend ettiği için direkt olarak context ‘e erişebiliyoruz.

Servis sınıfımızı oluşturduktan sonra, her serviste olduğu gibi JobService‘i de AndroidManifest.xml içerisine ekliyoruz;

Sonrasında örnek uygulamamızın arayüzünü oluşturuyoruz. Buraya sadece ekran görüntüsü ve temel fonksiyonların açıklamalarını ekleyeceğim. Uygulamanın kodlarına en altta paylaşacağım GitHub repo’sundan erişebilirsiniz.

Örnek uygulamada 3 farklı koşul belirleyebileceğiz. JobService’in bize sağladığı diğer koşulların neler olduğuna buradan bakabilirsiniz.

Öncelikle bir JobScheduler ve ContentName nesnelerine ihtiyacımız var;

Sonrasında, servisin hangi koşullar altında çalışacağını belirlediğimiz JobInfo nesnesi oluşturuyoruz;

• JOB_ID: Her JobInfo nesnesinin eşsiz bir id’si olması gerekiyor. Bu id sayesinde dilediğimiz vakit, programlanmış bir Job’u iptal edebiliriz.
• setRequiredNetworkType: Gerekli olan ağ durumunu belirlediğimiz fonksiyon.

— NETWORK_TYPE_NONE: JobService, cihaz internete bağlı olsa da olmasa da çalışacaktır. Default değer budur.
 — NETWORK_TYPE_ANY: JobService, cihaz internete bağlı olduğu durumda çalışacaktır (Hücresel ya da wifi olduğuna bakmaksızın).
 — NETWORK_TYPE_UNMETERED: JobService, cihaz sadece Wifi’a bağlı olduğunda çalışacaktır.
— NETWORK_TYPE_CELLULAR: JobService, cihaz hücresel ağa bağlı olduğunda çalışacaktır.
 — NETWORK_TYPE_NOT_ROAMING: JobService, Roaming modu olmadığında çalışacaktır.

• setRequiresCharging: Job’un çalışması için cihazın şarjda olup olmama durumunu belirlediğimiz fonksiyon.
• setRequiresDeviceIdle: Keza bu da Job’ın çalışması için cihazın uyku modunda olup olmama durumunu belirlediğimiz fonksiyon.
• setOverrideDeadline: Parametre olarak Long tipinde bir değer alır. Eğer belirlediğimiz koşullar, parametre olarak gönderilen süre içinde gerçekleşmez ise sürenin sonunda yine de servisin başlatılıp başlatılmayacağını belirlediğimiz fonksiyon.

Oluşturduğumuz JobInfo nesnesini JobScheduler nesnesinin schedule() fonksiyonuna parametre olarak veriyoruz ve Job’u programlamış oluyoruz.

Bu kadar basit! schedule() fonksiyonu çağrıldıktan sonra belirlenen koşullar sağlandığı takdirde ToastJobService içerisindeki onStartJob() fonksiyonu tetiklenecektir.

Iptal etmek istediğimiz durumda da iki farklı fonksiyon çağırabiliriz. Bunlar;

• cancel(jobId: Int): Sadece belirli JOB_ID’ye sahip olan Job’u iptal etmemizi sağlayan fonksiyon.
• cancelAll(): JobScheduler nesnesine bağlı olan tüm Job’ları tek seferde iptal etmemizi sağlayan fonksiyon.

mitsinsar/JobSchedulerDemo

Codelabs

Android JobScheduler was originally published in Kodluyoruz on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL:DR; You can check GitHub repository that I shared at the end of the story.

First let me show you what we are going to have at the end of this story;

There are;

• Different view types
• Different grid sizes
• Multiple item selection

in one recycler view. Yeap…
Not three, not two…
Just one recycler view!

So let’s get to work!

List Items

First of all we need a base class for list items for recycler view adapter. Which I called ListItem;

It is sealed class. So we will be able to use subclasses like enum classes.
In inner enum class, I defined all view types that I am going to use in adapter to create different ViewHolders. And of course every list item will have a type. So getType() will be useful here.

Some of these items will be selectable (Char and Digit). So would be better if we collect them under SelectableListItem which extends ListItem;

Now let’s create our list items;

As you can see, TitleListItem extends ListItem but other items which are going to be selectable extend SelectableListItem.

View Holders

Now it is time to create view holders. We are going to create three view holders and two of them will extend SelectableViewHolder. Why? Because they will be selectable;

We are going to use bind(isSelected: Boolean) function to be able to change background color without updating whole itemView. aka Payload.

This is our DigitViewHolder, it is going to hold simple TextView and ConstraintLayout as a root layout. As you can see we overrided bind function to handle item selection.

I will not copy-paste CharViewHolder because it is almost the same as DigitViewHolder. If you want to see what is inside of it, you can check GitHub repository that I am going to share at the end of the page.

TitleViewHolder is similar to DigitViewHolder, but it extends RecyclerView.ViewHolder. Rest of it is the same.

Adapter

I like to create new list for adapter to handle item changes in adapter. If you pass your list in the constructor and change something in the list outside of adapter, you should also call notify functions outside of adapter.

Simple mutable list that holds ListItem and its setter function to set items.

Let’s remove TODO’s in overrided functions;

• getItemCount() : Item count of list that we use in adapter.
• onCreateViewHolder() : This is where we create our view holder items and set their click actions. As you can see we are using viewType param. Where does it come from?
• onBindViewHolder() : In this method we update view holder’s item based on list item.

Here… viewType param comes from here. Since item list holds ListItem, that means we can simply call items[position].getType() and return ListItem.Type’s ordinal.

Different Grid Sizes

How do we achieve different grid sizes in one recycler view. There is a simple object called “mSpanSizeLookup” in GridLayoutManager (GLM). GLM updates every item based on it’s span size. If you use GridLayoutManager(context, SPAN_SIZE), there will be SPAN_SIZE items in every row. So we should set new “mSpanSizeLookup” for our GLM to achieve different item count in different rows.

in onAttachedToRecyclerView we can set new SpanSizeLookup for our GLM.

There are two important rules

• LayoutManager must be GridLayoutManager
• LayoutManager must be set before Adapter

First one is obvious, let me explain second one; onAttachedToRecyclerView is called when we set recycler view’s adapter. If we set adapter first, recyclerView.layoutManager as GridLayoutManager will throw NullPointerException, because we haven’t set layout manager yet. That’s why we need to set layout manager first. As an example;

Let’s go back to getSpanSizeLookup() function. It extends GridLayoutManager.SpanSizeLookup because type of our “mSpanSizeLookup” is SpanSizeLookup. *insert you don’t say meme*

The Int we return is the span size of a single view. In this example, I simply checked the view type and set span size based on view type. DEFAULT_SPAN_SIZE is 1 by the way. Default value of GLM’s SpanSizeLookup. SPAN_SIZE part is the overriden part.
In this example, SPAN_SIZE is 4 and DIGIT_SPAN_SIZE is 2. You can set however you want to.

Handling Selections

I’ve created two variables to hold selected item’s position. So in activity/fragment, we can get selected item.

Thanks to my colleagues, I’ve learnt that there is something called Delegates.observable. It is like overriding its setter.
*insert same but different meme*

If you want to learn more about Delegates.observable, click here.

When value of variable changes, observable function is being triggered and we call handleItemSelection;

It deselects old selected item and selects new item. We need to check if oldValue is RecyclerView.NO_POSITION or not. Otherwise when we try to deselect old item, we will get IndexOutOfBoundException. Because we set RecyclerView.NO_POSITION as first value of variables.
Remember Delegates.observable<Int>(RecyclerView.NO_POSITION)
You will understand why we will get IndexOutOfBoundException when you see setSelectedItem function.

If we don’t check if oldValue is NO_POSITION or not, items[NO_POSITION] will cause IndexOutOfBoundException. Because RecyclerView.NO_POSITION is -1.

In this function, we set selection status of item then trigger notifyItemChanged with position and payload.

And lastly we update our item in onBindViewHolder;

We overrided onBindViewHolder because we want to change only background of the item. If you call notifyItemChanged without payload, it updates whole item and it can cause undesired blink effect.

In this blog, you can see what I am talking about;

RecyclerView Trick: Selectively bind ViewHolders with Payloads

If you combine all of the stuff I explained above, you will have what you see in the first gif. Or you can simply check this GitHub repository to see source codes;

mitsinsar/medium_app_1

Thanks y’all!

Apps binaries that we deliver to the Play Store contain tons of libraries and resources. We can reduce the amount of unnecessary data to an extent with proguard but still we couldn’t generate device configuration specific APKs. You might think this has minimal impact, but there are lots of configurations:

• Processor types (arm based armeabi-v7a, arm64-v8a or intel based x86, x86_64…)
• Sreen resolutions (hdpi, xhdpi, xxhdpi…)

To be able to support all of these combinations, we used to include everything in the same package and deliver that to all users. This is where the new app bundles come in!

With app bundles, users get only what they need based on the device they are installing the app on, instead of having all possible combinations. If the device has a 32-bit processor, app bundle takes compatible APK from the package. Then looks at the screen size of the same device and takes the matching resources for that specific screen resolution. It does the same thing for locale and SDK version, prepares a new APK and makes it available for the user. This results in dramatically reduced download sizes!

As an example, we’ve recently generated an AAB for a project we have been working on, and there were 95 little APKs in it with a total size of 38 MB. My device needs only four of them, which is a total of 27 MB. The difference is huge: 11 MB! If we consider that my device’s screen resolution is xxhdpi, difference will be even more when target device’s resolution is lower than xxhdpi.

Where to start?

Assuming you are now sold on the benefits of app bundles, let’s see how we can switch to using them! Generating an app bundle is very similar to how you used to generate APKs:
Build -> Generate Signed Bundle/APK… And this screen comes up:

Choose App Bundle. And click next, fill the required fields:

You may want to check “Remember passwords”.

There is another checkbox about encrypted key. It creates .pepk file for Play Store. If you decide to use App Signing, you are going to need that .pepk file.

For extra information about App Signing, you can check here.

As last step, we will choose destination folder and build variants, then click finish.

Now you have a signed app bundle ready for Play Store! 🎉

In the destination folder, there should be an .aab file. It is your bundle file. Now you can upload and publish your bundle file on Play Store.

How to test?

Another thing you might want to do is to be able to locally test the app bundle and its outputs. Here is what you will need to do be able to do this:

• An android test device
• Bundletool
• Unzipping tools like Winrar or The Unarchiver (optional)

Let’s start!

First we need to download Bundletool. You can find the latest version on Google Bundletool Github repo.

After downloading bundletool, we are going to use the terminal. Hacker time!

Since I don’t use any helper tools like Homebrew, I will explain everything on a vanilla terminal setup.

First, we need to build an .apks file. .apks file is an APK set archive that contains all the APKs generated by bundletool. To build that file, we are going to use the build-apks command and some parameters.

These are the parameters we are going to use:

If you dont give keystore parameters like keystore file or pass, APKs will be signed with the debug keystore. Let’s give keystore parameters to generate signed APKs:

Lets combine all of them:

java -jar ~/Downloads/bundletool-all-0.12.0.jar build-apks --bundle=~/StudioProjects/MyApp/app/app-prod-release.aab --output=out_bundle_archive_set.apks 
--ks=~/StudioProjects/MyApp/keystore.jks 
--ks-pass=pass:mypassword123 
--ks-key-alias=MyKeyAlias 
--key-pass=pass:mypassword123

This single command will create an .apks file in our root folder.

There was an issue about installing device specific APKs with — connected-device command. It gives UnknownFlagsException. I believe they will fix this soon. If you don’t use — connected-device flag, bundletool generates APKs for all device configurations your app supports. This is basically like the legacy APK.

That’s why we are going to generate our device specific APKs and install them manually.

Generate device specific APKs

First we need to create json file that contains our device’s configs:

This is my device’s config json file. You should create your own test device’s config json. After creating json file, we are able to create device specific APKs. Now let’s call command below:

java -jar ~/Downloads/bundletool-all-0.12.0.jar extract-apks --apks=~/out_bundle_archive_set.apks 
--output-dir=~/apks/huawei 
--device-spec=~/huawei_spec.json

Now we have device specific APKs. Don’t try to install them individually, doesn’t work (I’ve tried). To install that APK we need to call:

./adb install-multiple 
~apks/huawei/base-tr.apk
~apks/huawei/base-arm64_v8a_2.apk
~apks/huawei/base-master_2.apk
~apks/huawei/base-xxhdpi.apk

Those are my device specific APKs and the folder is where I extracted my APKs. Yours will be different, so don’t forget to change them!

If you get adb command not found error, make sure that you are in platform-tools folder.
It is usually in ~/Libraries/Android/sdk/platform-tools/adb (Mac)

That’s it! Now you can test your app on your device!

Optional part

To see all the APKs that bundle generates, go to the folder where you extract your .apks file and extract it with unzipping tool. You will see splits folder and toc.pb file. splits folder contains all the APKs. You can try different packages, like re-install your app by choosing different language package etc.

Keep an eye on posts from Hipo by subscribing to our newsletter and following us on Twitter.

Android App Bundles & Local Testing was originally published in Hipo on Medium, where people are continuing the conversation by highlighting and responding to this story.

On one of our recent projects, we were faced with one of those seemingly simple but actually hard coding problems: Building a text input field that can automatically format and validate the input while the user is typing. After some trial and error, we ended up building an open source library to solve this issue: MaskedEditText.

Seasoned Android developers might be asking: Why do we even need a new library when there is a class called PhoneNumberFormattingTextWatcher? Our answer would be: Have you ever used it? Implementation is easy:

But let’s see how this works in a real world scenario:

Needless to say, that’s not good UX, and no self-respecting developer can ship with a solution like that. Default solution places parentheses when you don’t expect it and goes completely bonkers if you type more numbers than it expects. That’s why we need an extra library and this is how MaskedEditText came to exist.

How does it work?

It works as expected, no magic here, just good UX.

It has four options:

• Phone Number (###) ###-####
• Date ## / ## / ####
• SSN Number ###-##-####
• Custom (However you want it to be)

How to use it?

Define an edit text field in XML and its maskType. There is no default maskType, so it will give you a runtime error if maskType is not selected.

Caused by: java.lang.Exception: MaskedEditText: maskType must be selected

That’s it!

To use custom pattern you need to follow some rules;

• maskPattern and returnPattern must be defined
• Pound (#) count for maskPattern and returnPattern must be the same

Otherwise it will throw runtime exception with explanation.

Under the hood

It’s just an edit text field that doesn’t trigger itself when text is set by masker manually. And this edit text field uses a class called Masker to handle text changes. It accepts Mask (which is type of mask; date, ssn, etc.) and onTextMaskedListener. This listener is triggered when formatting is done.

Since we use kotlin, we can simply use it as below:

In MaskedEditText, when onTextChanged is triggered, we also trigger masker’s onTextChanged function. Then it triggers onTextMaskedListener.

Every mask type extends abstract Mask class.

As you can see, there is a field called returnPattern. Yes you can define your return pattern.

Phone and SSN returns only digits, date returns a string with YYYY-MM-DD pattern. You need to use fun getParsedText(maskedText: String): String? function to get parsed text. Why is return type nullable? To understand if return pattern and mask pattern matches or not. If user doesn’t fill the expected input, it returns null.

You can find whole project at the link below and all contributions are welcome!

Hipo/hipo-maskededittext-android

It is also in jcenter which means you can simply add it to your project as so:

implementation 'com.hipo.maskededittext:maskededittext:1.1.0'

Thanks!

Automated Text Input Formatting on Android with MaskedEditText was originally published in Hipo on Medium, where people are continuing the conversation by highlighting and responding to this story.