I fell in love with mobile development five years ago. I loved the excitement of working on an app, deploying it on your phone, and being able to show it to everyone right away. Android was my first love, but everyone knows the first love never lasts.

When I first started as an Android developer at Infinum having just finished Infinum Academy, I loved every part of Android. I didn’t have any professional experience at the time, so I wasn’t aware of other technologies that existed outside of the little Android bubble.

Being a junior, I had to focus on a single technology to learn the most I could, so I didn’t even consider other technologies at the time. As you gain more experience, you broaden your horizons. Little by little, you discover and learn about the technologies that exist outside of your bubble.

Also, as you become more proficient in your area, it’s smart to decide what to focus on. In my opinion, there are a couple of different paths to pursue:

When I had little experience, I thought the only way to progress was by becoming a team lead. “You gain recognition and get to influence others around you, I mean, what’s not to like?!” I thought to myself as I looked up to my team lead, imagining that one day I’d like to be like him.

As I got more experienced, I understood the biggest con of the team lead position that you have to spend a lot of time communicating with your team and making sure everyone is happy. To me, that was a deal breaker because I enjoy programming and learning new things every day, and it’s what drives me forward to this day.

Another possible career path was to try and become a technical lead. This position seems more alluring because you can focus mainly on your programming skills and lead the team by suggesting new ideas everyone can benefit from. Personally, I think the biggest flaw of the technical lead position is focusing only one area of expertise. If you don’t understand and know other areas, it can be hard to see the bigger picture, and this could potentially lead your team in the wrong direction.

I started my journey as an Android developer, I only knew Android development, so I thought that it was still too soon for me to try and become a technical lead as I still had a lot to learn.

In order to fill the knowledge gap, I was slowly leaning towards the diversity track. It all started on probably the happiest day of my life as a developer, with Google introducing Kotlin as the official Android programming language. Kotlin was a breath of fresh air compared to the outdated Java and consequently increased our team’s productivity and happiness.

But more importantly, it also made me curious to try out other new technologies and programming languages. Soon afterward, I started experimenting with Flutter, Dart, and JavaScript. I liked JavaScript and web development so much that I made a radical decision.

I wanted to change my area of expertise entirely and become a JavaScript developer.

The decision was not instantaneous. I thought about it and discussed the potential career switch with more experienced colleagues and superiors for several months, questioning whether it was worth it.

It isn’t that common for companies to encourage switching careers, but I was very lucky that my company was forward-thinking and supported me through the entire process.

Another important thing to take into account when thinking about career switch is the reasons you want to switch technologies. It’s highly important to understand that every technology has its flaws.

A career switch is a huge decision that literally changes your daily life, so don’t take it lightly. Take your time and decide whether the pros outweigh the cons.

Pros:

Cons:

On the one hand, changing your area of expertise puts you in the position of knowing little if anything at all. You literally go from a senior to a junior in a day. On the other hand, the learning process is also much faster compared to when you first started programming, thanks to the previously acquired general knowledge that can be applied to any programming language and technology.

Perhaps the biggest change you need to make is to your thinking process. Basically, ask whatever question comes to mind, be curious and research whatever doesn’t make sense. You should spend a lot of time researching and reading documentation and online resources to learn as much as you can.

In fact, this is exactly why switching technologies can get really exhausting, but it’s crucial to success and reaching that same level of knowledge you had previously reached in another technology.

You should also be aware that your previously gained knowledge can easily backfire. The more knowledge you gain, the more aware you become of everything from frameworks and cool language features to dependency injection etc. You’ll feel the urge to learn all of it at the same time because you kicked ass in your previous area of expertise, but I strongly advise against that.

If you try to process everything simultaneously, things will become chaotic and everything will mix together. You’ll end up with a mushy pile of confusion about what is in front of your screen and what you are doing with your life in general.

It’s important to decide which career path you want to take. If you decide to make a career switch and try a new technology or language, you must be 100% sure that you are ready to learn new things every day because it can become really exhausting over time. It is also important to understand the flaws of each technology you tackle and not expect everything to be ideal.

Finally, the most important switch you need to make is the one within your mindset. Ask stupid questions, make stupid mistakes, and learn something new every day. I promise that in time, you will grab the new technology by the balls and catch up with your senior colleagues. Just don’t do it the other way around.

Google released the new BiometricPrompt as a replacement for FingerprintManager last September. We decided to test out whether we would be able to integrate it in our Android library which simplifies fingerprint authentication, called the Goldfinger–and whether a library like Goldfinger would even be necessary with the new API.

During Google I/O ’18, Google announced BiometricPrompt which is used as a replacement for FingerprintManager. BiometricPrompt should choose the most appropriate biometric (fingerprint, face, iris) and display system dialog so that users have consistent behavior across all applications.

BiometricPrompt was introduced as an Android P feature, but Google also mentioned backwards-compatible BiometricPrompt, similar to how FingerprintManager and FingerprintManagerCompat behave.

Google finally released the first alpha version of androidx.biometrics library last September. While we expected the development of the library to be fast, it was stuck in the alpha version for almost a year. There was even an issue open!

At last, they released the beta1 version in August. We tested the beta1 version and were quite happy with how it works. There are several smaller issues, but those should be resolved by the time a stable version is released, hopefully.

Two years ago, we created an Android library that simplifies Fingerprint authentication called Goldfinger. Our library was using deprecated FingerprintManager to that point, so we wanted to test out if we would be able to integrate BiometricPrompt in it, and whether a library like Goldfinger would even be neccessary with the new API.

We came to the conclusion that BiometricPrompt and FingerprintManager APIs are almost the same. The biggest improvement over FingerprintManager is that you don’t even need to know what CryptoObject is if you need simple user authentication without data encryption.

All other complexities regarding user authentication are still there–CryptoObject creation if a cipher is needed, cancel dispatched as an error after the developer invokes cancel himself, save and restore initialization vector, and others. For all those reasons, we decided to refactor Goldfinger’s internals to use the new BiometricPrompt API.

Nowadays, Goldfinger API uses BiometricPrompt and has a new API that requires Goldfinger.PromptParams instance. Goldfinger.PromptParams are constructed via a builder pattern and you give it all values that are required for constructing BiometricPrompt. Afterwards, Goldfinger encapsulates all biometric complexities for you.

It creates CryptoObject asynchronously, starts biometric authentication, saves and restores initialization vector, handles weird edge cases introduced by on-screen fingerprint scanners, handles all system exceptions and returns them in a single callback, as well as offers you a separate Rx module.

The current version is still a release candidate so we are looking for potential improvements and suggestions from the community. We plan on releasing the final, stable version as soon as androidx.biometrics leaves beta–feel free to drop us a comment, suggestion or even a pull request so that we can prepare Goldfinger 2.0 to be the best possible.

As an Android developer, one of the worst phrases I could hear was, “We want a custom in-app camera.” If you’ve ever worked with Android Camera APIs, you probably know why almost everyone dislikes it. If you haven’t had to tackle this challenge, be grateful.

I recently worked with Android Camera APIs, and I think I’ve finally conquered them. In this blog post, I will discuss the behavior of the camera, which issues I had along the way, and how I solved them.

To implement a custom in-app camera, you have no choice but to use Android Camera API. Android Camera API has two versions: First, there’s the deprecated version (Camera1), which supports devices older than Lollipop. Then there’s the Camera2 version that is supported only on Lollipop and newer devices.

The main difference between these two APIs is that Camera1 is simpler, and in my opinion, more consistent. Camera2 offers more features, but in most cases these features are unnecessary. Both camera APIs have weird behavior and numerous edge cases, so let’s start with an issue that both APIs share.

When working with the camera API, the first thing you want to implement is the preview. It’s funny (or actually quite frustrating), because as soon as you start, Android stabs you in the back: the preview you are trying to display does not work as expected, and you see a preview that looks distorted like the image below.

Once you see the preview, you’ll probably wonder what you did wrong. Sadly, nothing. This is the default camera behavior, and now it is up to you to decipher what exactly happened. First, you need to understand how matrix transformations work—otherwise, you are screwed. Matrix transformations are used to rotate and scale the preview. When the camera is started, it automatically rotates the preview to be in sync with the camera’s orientation, and it scales the preview to fit whole view. The preview image is distorted because the X and Y axes are scaled individually—so while the X axis is scaled down, the Y axis could be scaled up to fit the view.

The camera has its own orientation, which is not the same as device orientation. The camera’s orientation is usually 90 degrees (regardless of device orientation), and that is why your preview is rotated. The first step to solving this is reversing the camera orientation. Here you can see the method that calculates the difference between camera and device orientation.

Step two is reversing the scaling of the X and Y axes. To reverse the process, first you need to reverse the matrix to get the original preview size and then apply your own scale depending on your end goal. Here is the method that calculates and applies the correct scale to the preview. The GIF below demonstrates what you have to do to create a nice-looking preview.

Camera1 API has been deprecated since Android Lollipop. We work on a lot of apps that must support older devices than Lollipop, so simply ignoring the deprecated API was a no-go. As Camera1 is supported on all Android devices, I decided to first dig into its API.

To configure the camera, you need to use Camera.Parameters object, modify it and then set it to the camera instance. Camera.Parameters object contains setters that can be used to change flash, focus, zoom, etc. Just from this explanation, you might think this process is all sunshine and rainbows. Not so much.

The issue with Camera.Parameters is not its complexity, but rather how invalid parameters are reported back to you. They are applied and validated after you execute Camera#setParameters(Camera.Parameters), and if any parameter is invalid, the camera just crashes with message – setParameters failed.

I could not find a more effective way to debug the issue than removing parameter by parameter until I figured out which one exactly caused the crash. My suggestion here is to wrap basically everything that communicates with the native camera API into try/catch blocks and implement better error handling. This allows you to handle all your errors in one place because the camera API is chaotic and unpredictable.

While the preview is active, almost all parameters can be dynamically updated except the preview and picture size. In case you need to dynamically change the preview and picture size, restarting the preview with new parameters should do the trick.

This was one of my favorite chuckle moments because the issue was easy to solve—but it was a clear indicator that you should not trust the camera API documentation. Camera API can return a list of sizes that can be used to set the preview and picture size—and I had to deal with two screw ups here.

The first problem arose because I assumed the API will be deterministic. The first three devices I tested with all returned a list in descending order, so I assumed the first element will always be the highest resolution available. This worked fine until I tested on a device that had a blurry preview. I was confused at first, but after some debugging I noticed this specific device returns a list of sizes in ascending order. To solve the issue, I manually sorted sizes in the same order.

The second issue I encountered was this: On Samsung S3 Mini, I received a crash with NullPointerException when trying to sort the list. The issue was clear: the map returned by the camera API was null. The funny part was what what Javadoc said:

The fix was to fallback to the list of preview sizes if the list of picture sizes is not available. Now that I’ve learned from my mistakes, I know to never trust the camera API documentation.

To take a picture, you call Camera#takePicture and pass two callbacks. When the picture is taken, you receive an array of bytes as a result. If you convert the array into a Bitmap and display the Bitmap, your picture will be rotated. The fix is similar to the preview: you must calculate the difference between the device and camera orientation and rotate the image yourself.

There is one small hidden issue that can happen if you are not careful with image manipulation. When working with Bitmaps and Bitmap transformation, always be aware of potential OutOfMemoryException.

The tap to focus functionality requires some mathematical skills because there are multiple conversions you must calculate. When you press on your screen, you receive a touch event with X and Y coordinates that correspond to your device’s coordinate system. When you want to tell the camera which area to focus on, you need to give it X and Y coordinates that correspond to the camera’s coordinate system. The mapping is not simple because you also need to calculate in the scaling.

I personally found the last step of implementing tap to focus amusing. This is taken from Javadoc:

In short, after you map everything into the camera’s coordinate system, you have to map it into this [-1000, 1000] coordinate system and pass it to the camera. Why? I honestly have no idea.

To be honest, after finishing the Camera1 wrapper, I figured Camera2 is newer, and thus, better. My assumption was incorrect. Understanding Camera2 API was much harder than I anticipated, and I found it much less intuitive than Camera1 API.

Camera2 API gives you more control over the camera, but at the same time it does not provide a concise API so you have to handle everything manually. In retrospect, Camera1 at least had the takePicture method, which was convenient to use. Camera2 API has multiple states, and you must handle those states manually and execute specific methods when the state changes.

I think a single look into this table is enough to see the complexity behind Camera2. Also, the issue was that some devices would lock into one state and it would never trigger the state to take a picture. Other devices would trigger capture state and record a blurry image. I feel like these states are something that should be handled by the API behind the curtains, the same way Camera1 handles it.

I also noticed that introducing flash mode into Camera2 picture taking just introduced more bugs and more mess because it added more states that you have to handle manually. Torch mode is also separate from all other flash modes, so when you want to turn on the torch, you must turn off flash and vice versa.

I used MediaRecorder class to record a video with both Camera1 and Camera2 API. I have to admit that out of all features, video recording was the easiest to implement. Even so, there are some potential traps you should avoid.

MediaRecorder works almost the same as Camera.Parameters. You have to initialize the whole MediaRecorder and when you want to start the video recording—it will crash if you set some unsupported parameter value. Also, just like Camera.Parameters, it does not tell you which parameter caused the crash. Most often, the MediaRecorder would crash because of either non-existent video resolution or video resolution that is too big for it to handle.

To configure MediaRecorder, you can use CamcorderProfile class. It contains a set of parameters that are automatically applied to the MediaRecorder when applied via the MediaRecorder#setProfile(CamcorderProfile) method. Be careful when using this method with Camera2 as some profiles returned by the camera API are false positives. To receive valid profiles, you should check that the returned profile contains the resolution that is supported by the camera.

When compared to Camera2 API, Camera1 API is awesome simply because of its consistency. It behaves oddly at times, but once you fix those weird edge cases, it mostly works.

Camera2 is difficult to use, has too many properties and states that must be handled by the developer, and it is not consistent between devices. Sometimes, for some reason, if you do not turn off property A when setting property B, the camera preview goes black without any error. It is discouraging when you have to work with that kind of an API with so many side effects.

I would suggest to use camera1 API even if you work on an application that is intended only for Lollipop and newer devices. Just be extra careful because Camera1 is deprecated and could be removed in the future.

Handling the Camera API is challenging, but you can learn a lot when you want to expose a simple and easy to use interface over something as complex as the Android camera API. Also, when you manage to tame the beast in the end, you’ll have a sense of satisfaction. Hopefully, Google is doing something regarding the camera API (CameraX). In the meantime, feel free to use our GoldenEye library and let me know what you think about the camera API.

Back in 2015, we published an article discussing the top five Android libraries we used at the time. However, the Android platform has grown rapidly since then. As you know, in the fast-paced field of software development, things change and evolve at lightning speed. That’s why we’ve decided it’s time for an updated list of the ultimate Android libraries.

Without further ado, let’s jump right into our list. We’ll kick off with one of the oldest, and I’d argue, one of the most useful Android libraries.

Retrofit is type-safe HTTP client that allows you to define your REST API as an interface. You can manipulate the API requests’ body, headers, query parameters, and much more via annotations, which makes everything clean and simple. Retrofit also allows synchronous and asynchronous API calls execution.

To top it off, Retrofit offers a separate Rx module. If you are using Rx, this module returns your API call as an Observable so you are able to chain it with the rest of your application. These are just a few of the many reasons we at Infinum still love and use Retrofit.

Moshi is a library that converts JSON into Java and Kotlin models. A lot of people refer to the Moshi as GSON 3.0. This library is superior to GSON in several aspects: [it’s faster](https://stackoverflow.com/a/43578738/3920456 “StackOverflow”), it includes Kotlin support, it’s maintained, it throws predictable exceptions, and it doesn’t use broken DateTime adapter by default. Plus, converting JSON to Java model (and vice-versa) is straightforward with Moshi.

We also admire Moshi for its JSON API support. JSON API is the specification for building APIs, and a lot of APIs we work with are written using that specification. Moshi JSON API makes our life easier because it converts JSON API responses into meaningful Java objects. Retrofit also has support for Moshi, and it all just clicks together.

Chuck is an HTTP inspector for Android that allows you to dig into your application’s HTTP history on your mobile phone. The HTTP log is displayed as a notification, which you can expand to open full Chuck UI. When you use Chuck, your quality assurance team will applaud you as they will be able to see whether an issue persists on Android or the backend side. This library is also sometimes more useful than logcat. That’s because your HTTP history persists even if the app is killed, while logcat sometimes cleans itself after the app is restarted.

As you probably know by now, Android image loading and handling API is terrible. It’s a nightmare to even resize an image without getting “OutOfMemoryException.” Glide is an image loading library that exposes a nice API, allowing you to transform your image however you want.

This library allows you to easily load a remote image into your ImageView, define fallback images, cache and scale your images, and much more. Try accomplishing all this without Glide, and you will quickly understand why this has become our core library. It even supports some common transformations like a circular image out of the box.

ThreeTen is a date and time handling library for Android. It is a backport of JSR-310, which was included in Java 8 as a standard “java.time.*” package. We love this library because the standard Android Calendar API is a nightmare to work with.

ThreeTen is much smaller than JodaTime in terms of method count and binary size. Its API is also more concise than JodaTime’s API. If you are currently using JodaTime, it is probably not worth the switch to ThreeTen. However, if you are starting a new project, I strongly suggest you try out ThreeTen instead.

Timber is powerful, yet simple, logging library built on top of Android “Log” class. It allows you to easily turn logging on or off. It also offers nice support for logging formatted strings and exceptions. Because of all these benefits, Timber is one of the core libraries we use on almost all our Android projects.

Room is an official Android ORM, and there are multiple reasons for that status. This library features a beautiful API that is similar to Retrofit. It also relies heavily on annotations and standard SQL syntax.

Additionally, Room includes out-of-the-box support for Rx and “LiveData,” so you can decide to use it however you like. The main benefit Room offers over other ORMs is its simplicity. Other ORMs come with much more complex APIs that require you to read all the documentation thoroughly before you can use them. Thanks to its standard SQL syntax, Room is incredibly easy to understand, allowing you to dive in without spending hours reading the documentation.

RxJava is a Java implementation of ReactiveX API that allows you to chain asynchronous tasks and events into observable sequences. Users expect modern applications to display data in real-time. In other words, they want to see data updated automatically. That’s where RxJava can help.

When fetching real-time data, it becomes extremely difficult to merge multiple API calls, switch threads, and handle errors. This is where RxJava shines, and it is the reason why we started using this library. I will admit that RxJava is confusing and hard to learn, but it is completely worth your time. Even after we switched to Kotlin, we continued to use RxJava because of its benefits. Together with Kotlin, the API is even better thanks to the additional extension functions.

Try accomplishing something similar to the above with plain Java. I dare you.

Android KTX is a set of Kotlin extensions that wraps Android API, making it more user-friendly. The whole purpose of this library is to make Android API more pleasant to use. It adds a lot of methods and cool new features of Kotlin, such as named parameters, lambdas, and default parameter values.

Android KTX features a lot of extension functions, and the only way to learn about them is by digging through library code to see how they improved Android API. This library changes the way we consume Android API—and for that reason, it should become the core of every Android application written in Kotlin.

Without Dagger, our Top 10 libraries list would be incomplete. Dagger is a fully static, compile-time dependency injection framework. Similar to RxJava, Dagger is really hard to understand (it took me a while to understand their CoffeeMaker example) but completely worth your time and effort.

Dependency injection is a way to provide smaller components to another model and glue them together with minimum effort. For example, if you have a Car model, you can provide tires to it and easily replace the tire implementation in the future—all without having to change a single line in your Car model.

When developing larger applications, you don’t want to handle dependency injection yourself because the code will grow quickly and become extremely difficult to maintain. Dagger helps you avoid this because it creates your dependency injection graph in compile-time via annotation processing.

In the last year, Google also included a separate Dagger Android module, which allows you to write less boilerplate code and inject dependencies easier.

So, there you have it: Our 2018 List of Top 10 Android Libraries. These ten superior options make Android development much more enjoyable for anyone who uses them. Looking for more options? It just so happens that we at Infinum have developed some Android libraries of our own. Check them out:

If you want to hear about newest Android libraries, subscribe to our weekly Android newsletter

Several weeks ago I was given a task to open an internal PDF file in any PDF reader application on an Android phone. I thought it would be straightforward, but things turned out to be complicated. Google’s documentation on FileProvider proved to be confusing and lacking concrete examples. Nevertheless, I knew I had to use ContentProvider to tackle the issue.

ContentProvider is an Android component which encapsulates data and provides it to other applications. It is required only if you need to share data between multiple applications. For example, the contacts data is shared with other applications using ContactsProvider which is a subclass of ContentProvider.

FileProvider is a subclass of ContentProvider. While ContentProvider is a component that enables you to securely share any kind of data, FileProvider is used specifically for sharing the app’s internal files. The FileProvider class is part of the v4 Support Library so make sure to include it in your project.

To make FileProvider work follow these three steps:

To define a FileProvider inside your AndroidManifest you need to be familiar with these attributes and elements:

If all of these seem extremely familiar, you’ll find your way around FileProvider a bit easier, otherwise I’ve prepared a detailed description of each attribute and its purpose.

You must define at least one unique authority. Android System keeps a list of all providers and it distinguishes them by authority. Authority defines the FileProvider just like the application ID defines an Android application.

In general, the Android System uses a specific URI scheme for ContentProviders. The scheme is defined as content://<authority>/<path> so the system will know which ContentProvider is requested by matching the URI’s authority with the ContentProvider’s authority.

This attribute can easily be misused because its name is misleading. To understand this attribute, think of your FileProvider as a room with locked doors. If you set the value to true, you’ve basically opened your doors to everyone. Everything will work from your point of view, but you’ve just created a huge security issue as every other app will be able to use your FileProvider without being given permission.

This can teach you to never program by coincidence and always be aware of the side-effects of your code. Also, always define this attribute because the default value on SDK 16 and lower is true.

If we continue thinking of a FileProvider as a locked room, then this attribute is used to give a temporary one-time key to an external app. This attribute allows you to securely share your app’s internal storage. All you have to do is add either FLAG_GRANT_READ_URI_PERMISSION or FLAG_GRANT_WRITE_URI_PERMISSION to the Intent that activates the component to open your app’s internal file. To use these flags set their value to true.

The <provider> element can also have <grant-uri-permission> subelements. The only difference being that by using the attribute you can share anything inside your app’s internal storage, while subelements allow you to choose a specific data subset for sharing. To use subelements instead, set the value to false.

This subelement must be defined when using the FileProvider. You have to define a path to the XML file which contains all data paths your FileProvider can share with external apps.

The XML file must have the \<paths> element as its root. The \<paths> element must have at least one subelement which can be one of the following:

You might have noticed that they vary according to the app’s directory which they define.

Each element must have a path and a name attribute. The path attribute defines the subdirectory you want to share and it does not support wildcards. The name attribute is used for security reasons and it will replace your subdirectory name with its value.

We set this value to android.support.v4.content.FileProvider.

Once you have defined a FileProvider in your AndroidManifest file, you are finally ready to use it. To share a file you have to create an Intent and give it a valid URI. The URI is generated using the FileProvider class.

Notice that I’m using the app’s ID for authority. That’s because I have multiple flavors in the project and they can be installed on the device at the same time. Android System won’t let you install multiple applications with the same FileProvider so each flavor needs an unique authority.

By defining paths like this, I allow the FileProvider to share all files that are inside the app’s internal cache and files directory.

Once you understand how it works, implementing your own FileProvider is truly simple.

The complexity of the problem is not the code itself, but the documentation and understanding of how everything is interconnected. I hope this article will help you implement the FileProvider for your own use case and make the official documentation easier to read.