We as developers are always in the search for better ways to build our apps. The need to build flexible to adapt high quality software usually comes from constantly changing business requirements. To do that our goal should be to write decoupled, maintainable and testable code as much as we can. That depends a lot on how we organise our code base, what architecture we use.

Prototype app

To accomplish discussed goal we can combine Model-View-ViewModel (MVVM) software architectural pattern together with the concept of Clean Architecture. Applying clean architecture concept is much better way to develop apps. With it changes can be done quickly, code can be understood better as its readability improves and development costs are reduced. Testability improves drastically. It becomes easy to find bugs.

To study this concept I have build a simple single screen demonstration native Android app based on Clean Architecture with MVVM written using Kotlin programming language.

It’s on GitHub

VenuesNearby — is a demonstration app that allows a user to enter a place name, submit, and then view the recommended venues nearby. The venues are provided by the Foursquare API which you can integrate with. You will need to sign up as a Foursquare developer and create an app in order to use their services.

What is MVVM architecture?

MVVM is a software architectural pattern. It stands for Model-View-ViewModel.

• Model: This represents the data and business logic of the app. It cannot directly talk to the View. Generally, it’s recommended to expose data through observables to be decoupled completely from ViewModel.
• View: It represents the UI of the application. The view role in this pattern is to observe (subscribe to) a ViewModel observable to get data in order to update UI elements accordingly.
• ViewModel: It acts as a link between the Model and the View. It’s responsible for transforming the data from the Model. It provides data streams to the View. It also uses hooks or callbacks to update the View. It will ask for the data from the Model. ViewModel should not be aware about the view who is interacting with.

MVVM pattern is recommended one by Google as it is supported by Android Jetpack Architecture Components.

What is Clean Architecture?

Clean Architecture exists at a higher abstraction level than the MVVM presentation architecture pattern. Usually MVVM is enough to use for small projects, but when our project codebase expands and becomes huge we need something better for separating all the responsibilities. Clean Architecture is enforcing separation of concerns and SOLID principles. Actually these principles is core concept for Clean Architecture. Check out my previous article about SOLID.

Clean Architecture describes the overall application architecture: how the various layers of an app (business objects, use cases, presenters, data storage, and UI) communicate with one another. With it, code is separated into layers. The layers should not know anything about the outer layers. They can depend only on other inner layers for them.

Following Clean Architecture idea all project code should be separated into different layers such as domain, storage, presentation. However the architecture doesn’t strictly define exact layers and you should adapt the number of layers to your needs.

My demo project VenuesNearby was separated to these six layers — packages:

Domain — a layer to store the business logic of your app. Here we have our Use Case classes — the operations which your app can perform. This layer also contain Unit tests for these classes.

Data — a layer which is used to control the flow of data between the remote (external data) and cache (local data) layers through to the Domain layers operational requests. This layer contains Unit tests to ensure that this control of data is operating as intended.

Remote — a layer which contains all of the remote operations with the third party API that is used for the project. Unit tests here to ensure that these operations are working as intended.

Cache — a layer which stores our applications data in a local database using the Room architecture component. This allows our app to appear working at all time even while being offline.

Presentation — a layer to house the presentation logic of our application. MVVM pattern is used in this layer and built with lifecycle-aware architecture components such as ViewModel, LiveData. Also view model class is covered by own tests.

UI — a layer contains the user interface for our mobile application. Here an activity is used to display the data. Espresso tests ensures the operation as intended.

Clean Architecture is the most modulated app development architecture which is perfect for continuously developed app and team work. Besides it allows to build on top on other efficient architectures such as MVVM.

Advantages:

• Clear separation of concerns.
• Decoupled responsibilities good for team work.
• Easier to maintain.
• Code more testable.
• Works well for large complex projects so it can scale.

Final words

In this article I have just quickly covered the concepts of Clean Architecture with MVVM. Please understand that we don’t necessary need to have any architecture at all for our apps development. The app can be completely made without it and the end user wont notice any visual difference. But I hope that when your boss, your client or your colleague will ask whats the point of it, you won’t doubt, be confident and explain all the benefits it brings. The biggest difference here is always going to be the long-term effect architecture it gives. At last in Android development word we have not only the professional tools provided but also matured blueprint for building highest quality apps. There have been no better time to try building such one by your own.

Ačiū! Thanks for reading! I originally published this post for my personal blog www.baruckis.com on December 22, 2019.

These days almost every Android app connects to internet to get/send data. You should definitely learn how to handle RESTful Web Services, as their correct implementation is the core knowledge while creating modern apps.

This part is going to be complicated. We are going to combine multiple libraries at once to get a working result. I am not going to talk about the native Android way to handle internet requests, because in the real world nobody uses it. Every good app does not try to reinvent the wheel but instead uses the most popular third party libraries to solve common problems. It would be too complicated to recreate the functionality that these well-made libraries have to offer.

Series content

• Introduction: A roadmap to build a modern Android app in 2018–2019
• Part 1: An introduction to the SOLID principles
• Part 2: How to start building your Android app: creating Mockups, UI, XML layouts
• Part 3: All about that Architecture: exploring different architecture patterns and how to use them in your app
• Part 4: How to implement Dependency Injection in your app with Dagger 2
• Part 5: Handle RESTful Web Services using Retrofit, OkHttp, Gson, Glide and Coroutines (you’re here)

What is Retrofit, OkHttp and Gson?

Retrofit is a REST Client for Java and Android. This library, in my opinion, is the most important one to learn, as it will do the main job. It makes it relatively easy to retrieve and upload JSON (or other structured data) via a REST based webservice.

In Retrofit you configure which converter is used for the data serialization. Typically to serialize and deserialize objects to and from JSON you use an open-source Java library — Gson. Also if you need, you can add custom converters to Retrofit to process XML or other protocols.

For making HTTP requests Retrofit uses the OkHttp library. OkHttp is a pure HTTP/SPDY client responsible for any low-level network operations, caching, requests and responses manipulation. In contrast, Retrofit is a high-level REST abstraction build on top of OkHttp. Retrofit is strongly coupled with OkHttp and makes intensive use of it.

Now that you know that everything is closely related, we are going to use all these 3 libraries at once. Our first goal is to get all the cryptocurrencies list using Retrofit from the Internet. We will use a special OkHttp interceptor class for CoinMarketCap API authentication when making a call to the server. We will get back a JSON data result and then convert it using the Gson library.

Quick setup for Retrofit 2 just to try it first

When learning something new, I like to try it out in practice as soon as I can. We will apply a similar approach with Retrofit 2 for you to understand it better more quickly. Don’t worry right now about code quality or any programming principles or optimizations — we’ll just write some code to make Retrofit 2 work in our project and discuss what it does.

Follow these steps to set up Retrofit 2 on My Crypto Coins app project:

First, give INTERNET permission for the app

We are going to execute HTTP requests on a server accessible via the Internet. Give this permission by adding these lines to your Manifest file:

Then you should add library dependencies

Find the latest Retrofit version. Also you should know that Retrofit doesn’t ship with an integrated JSON converter. Since we will get responses in JSON format, we need to include the converter manually in the dependencies too. We are going to use latest Google’s JSON converter Gson version. Let’s add these lines to your gradle file:

As you noticed from my comment, the OkHttp dependency is already shipped with the Retrofit 2 dependency. Versions is just a separate gradle file for convenience:

Next set up the Retrofit interface

It’s an interface that declares our requests and their types. Here we define the API on the client side.

And set up the data class

Data classes are POJOs (Plain Old Java Objects) that represent the responses of the API calls we’re going to make.

Create a special interceptor class for authentication when making a call to the server

This is the case particular for any API that requires authentication to get a successful response. Interceptors are a powerful way to customize your requests. We are going to intercept the actual request and to add individual request headers, which will validate the call with an API Key provided by CoinMarketCap Professional API Developer Portal. To get yours, you need to register there.

Finally, add this code to our activity to see Retrofit working

I wanted to get your hands dirty as soon as possible, so I put everything in one place. This is not the correct way, but it’s the fastest instead just to see a visual result quickly.

You can explore the code here. Remember this is only an initial simplified implementation version for you to get the idea better.

Final correct setup for Retrofit 2 with OkHttp 3 and Gson

Ok after a quick experiment, it is time to bring this Retrofit implementation to the next level. We already got the data successfully but not correctly. We are missing the states like loading, error and success. Our code is mixed without separation of concerns. It’s a common mistake to write all your code in an activity or a fragment. Our activity class is UI based and should only contain logic that handles UI and operating system interactions.

Actually, after this quick setup, I worked a lot and made many changes. There is no point to put all the code that was changed in the article. Better instead you should browse the final Part 5 code repo here. I have commented everything very well and my code should be clear for you to understand. But I am going to talk about most important things I have done and why I did them.

The first step to improve was to start using Dependency Injection. Remember from the previous part we already have Dagger 2 implemented inside the project correctly. So I used it for the Retrofit setup.

Now as you see, Retrofit is separated from the activity class as it should be. It will be initialized only once and used app-wide.

As you may have noticed while creating the Retrofit builder instance, we added a special Retrofit calls adapter using addCallAdapterFactory. By default, Retrofit returns a Call<T>, but for our project we require it to return a LiveData<T> type. In order to do that we need to add LiveDataCallAdapter by using LiveDataCallAdapterFactory.

Now we will get LiveData<T> instead of Call<T> as the return type from Retrofit service methods defined in the ApiService interface.

Another important step to make is to start using the Repository pattern. I have talked about it in Part 3. Check out our MVVM architecture schema from that post to remember where it goes.

As you see in the picture, Repository is a separate layer for the data. It’s our single source of contact for getting or sending data. When we use Repository, we are following the separation of concerns principle. We can have different data sources (like in our case persistent data from an SQLite database and data from web services), but Repository is always going to be single source of truth for all app data.

Instead of communicating with our Retrofit implementation directly, we are going to use Repository for that. For each kind of entity, we are going to have a separate Repository.

As you notice in the CryptocurrencyRepository class code, I am using the NetworkBoundResource abstract class. What is it and why do we need it?

NetworkBoundResource is a small but very important helper class that will allow us to maintain a synchronization between the local database and the web service. Our goal is to build a modern application that will work smoothly even when our device is offline. Also with the help of this class we will be able to present different network states like errors or loading for the user visually.

NetworkBoundResource starts by observing the database for the resource. When the entry is loaded from the database for the first time, it checks whether the result is good enough to be dispatched or if it should be re-fetched from the network. Note that both of these situations can happen at the same time, given that you probably want to show cached data while updating it from the network.

If the network call completes successfully, it saves the response into the database and re-initializes the stream. If the network request fails, the NetworkBoundResource dispatches a failure directly.

Under the hood, the NetworkBoundResource class is made by using MediatorLiveData and its ability to observe multiple LiveData sources at once. Here we have two LiveData sources: the database and the network call response. Both of those LiveData are wrapped into one MediatorLiveData which is exposed by NetworkBoundResource.

Let’s take a closer look how the NetworkBoundResource will work in our app. Imagine the user will launch the app and click on a floating action button on the bottom right corner. The app will launch the add crypto coins screen. Now we can analyze NetworkBoundResource's usage inside it.

If the app is freshly installed and it is its first launch, then there will not be any data stored inside the local database. Because there is no data to show, a loading progress bar UI will be shown. Meanwhile the app is going to make a request call to the server via a web service to get all the cryptocurrencies list.

If the response is unsuccessful then the error message UI will be shown with the ability to retry a call by pressing a button. When a request call is successful at last, then the response data will be saved to a local SQLite database.

If we come back to the same screen the next time, the app will load data from the database instead of making a call to the internet again. But the user can ask for a new data update by implementing pull-to-refresh functionality. Old data information will be shown whilst the network call is happening. All this is done with the help of NetworkBoundResource.

Another class used in our Repository and LiveDataCallAdapter where all the "magic" happens is ApiResponse. Actually ApiResponse is just a simple common wrapper around the Retrofit2.Response class that converts each response to an instance of LiveData.

Inside this wrapper class, if our response has an error, we use the Gson library to convert the error to a JSON object. However, if the response was successful, then the Gson converter for JSON to POJO object mapping is used. We already added it when creating the retrofit builder instance with GsonConverterFactory inside the Dagger AppModule function provideApiService.

Glide for image loading

What is Glide? From the docs:

Glide is a fast and efficient open source media management and image loading framework for Android that wraps media decoding, memory and disk caching, and resource pooling into a simple and easy to use interface.

Glide’s primary focus is on making scrolling any kind of a list of images as smooth and fast as possible, but it is also effective for almost any case where you need to fetch, resize, and display a remote image.

Sounds like a complicated library which offers many useful features that you would not want to develop all by yourself. In My Crypto Coins app, we have several list screens where we need to show multiple cryptocurrency logos — pictures taken from the internet all at once — and still ensure a smooth scrolling experience for the user. So this library fits our needs perfectly. Also this library is very popular among Android developers.

Steps to setup Glide on My Crypto Coins app project:

Declare dependencies

Get the latest Glide version. Again versions is a separate file versions.gradle for the project.

Because we want to use the networking library OkHttp in our project for all network operations, we need to include the specific Glide integration for it instead of the default one. Also since Glide is going to perform a network request to load images via the internet, we need to include the permission INTERNET in our AndroidManifest.xml file — but we already did that with the Retrofit setup.

Create AppGlideModule

Glide v4, which we will be using, offers a generated API for Applications. It will use an annotation processor to generate an API that allows applications to extend Glide’s API and include components provided by integration libraries. For any app to access the generated Glide API we need to include an appropriately annotated AppGlideModule implementation. There can be only a single implementation of the generated API and only one AppGlideModule per application.

Let’s create a class extending AppGlideModule somewhere in your app project:

Even if our application is not changing any additional settings or implementing any methods in AppGlideModule, we still need to have its implementation to use Glide. You're not required to implement any of the methods in AppGlideModule for the API to be generated. You can leave the class blank as long as it extends AppGlideModule and is annotated with @GlideModule.

Use Glide-generated API

When using AppGlideModule, applications can use the API by starting all loads with GlideApp.with(). This is the code that shows how I have used Glide to load and show cryptocurrency logos in the add crypto coins screen all cryptocurrencies list.

As you see, you can start using Glide with just few lines of code and let it do all the hard work for you. It is pretty straightforward.

Kotlin Coroutines

While building this app, we are going to face situations when we will run time consuming tasks such as writing data to a database or reading from it, fetching data from the network and other. All these common tasks take longer to complete than allowed by the Android framework’s main thread.

The main thread is a single thread that handles all updates to the UI. Developers are required not to block it to avoid the app freezing or even crashing with an Application Not Responding dialog. Kotlin coroutines is going to solve this problem for us by introducing main thread safety. It is the last missing piece that we want to add for My Crypto Coins app.

Coroutines are a Kotlin feature that convert async callbacks for long-running tasks, such as database or network access, into sequential code. With coroutines, you can write asynchronous code, which was traditionally written using the Callback pattern, using a synchronous style. The return value of a function will provide the result of the asynchronous call. Code written sequentially is typically easier to read, and can even use language features such as exceptions.

So we are going to use coroutines everywhere in this app where we need to wait until a result is available from a long-running task and than continue execution. Let’s see one exact implementation for our ViewModel where we will retry getting the latest data from the server for our cryptocurrencies presented on the main screen.

First add coroutines to the project:

Then we will create abstract class which will become the base class to be used for any ViewModel that needs to have common functionality like coroutines in our case:

Here we create specific coroutine scope, which will control the lifetime of coroutines through its job. As you see, scope allows you to specify a default dispatcher that controls which thread runs a coroutine. When the ViewModel is no longer used, we cancel viewModelJob and with that every coroutine started by uiScope will be cancelled as well.

Finally, implement the retry functionality:

Here we call a function marked with a special Kotlin keyword suspend for coroutines. This means that the function suspends execution until the result is ready, then it resumes where it left off with the result. While it is suspended waiting for a result, it unblocks the thread that it is running on.

Also, in one suspend function we can call another suspend function. As you see we do that by calling new suspend function marked withContext that is executed on different thread.

The idea of all this code is that we can combine multiple calls to form nice-looking sequential code. First we request to get the ids of the cryptocurrencies we own from the local database and wait for the response. Only after we get it do we use the response ids to make a new call with Retrofit to get those updated cryptocurrency values. That is our retry functionality.

We made it! Final thoughts, repository, app & presentation

Congratulations, I am happy if you managed to reach to the end. All the most significant points for creating this app have been covered. There was plenty of new stuff done in this part and a lot of that is not covered by this article, but I commented my code everywhere very well so you should not get lost in it. Check out final code for this part 5 here on GitHub:

View Source On GitHub.

The biggest challenge for me personally was not to learn new technologies, not to develop the app, but to write all these articles. Actually I am very happy with myself that I completed this challenge. Learning and developing is easy compared to teaching others, but that is where you can understand the topic even better. My advice if you are looking for the best way to learn new things is to start creating something yourself immediately. I promise you will learn a lot and quickly.

All these articles are based on version 1.0.0 of “Kriptofolio” (previously “My Crypto Coins”) app which you can download as a separate APK file here. But I will be very happy if you install and rate the latest app version from the store directly:

Get It On Google Play

Also please feel free to visit this simple presentation website that I made for this project:

Kriptofolio.app

Ačiū! Thanks for reading! I originally published this post for my personal blog www.baruckis.com on May 11, 2019.

How to handle RESTful web Services using Retrofit, OkHttp, Gson, Glide and Coroutines was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dependency injection will significantly improve your code. It makes your code more modular, flexible and testable. Actually its name sounds more complicated than the idea which stands behind it.

In this part of the series we are going to learn about dependency injection. We will then implement it in “Kriptofolio” (previously “My Crypto Coins”) app. We are going to use Dagger 2. Dagger 2 is the most popular open-source dependency injection framework for Android. This is a valuable skill to have for creating modern apps, even thought the learning curve is hard enough.

Series content

• Introduction: A roadmap to build a modern Android app in 2018–2019
• Part 1: An introduction to the SOLID principles
• Part 2: How to start building your Android app: creating Mockups, UI, XML layouts
• Part 3: All about that Architecture: exploring different architecture patterns and how to use them in your app
• Part 4: How to implement Dependency Injection in your app with Dagger 2 (you’re here)
• Part 5: Handle RESTful Web Services using Retrofit, OkHttp, Gson, Glide and Coroutines

What is Dependency Injection?

To explain dependency injection first we have to understand what dependency means in programming. A dependency is when one of the objects depends on the concrete implementation of another object. You can identify a dependency in your code whenever you instantiate an object within another. Let’s take a look at a practical example.

As you see from this example your class MyAppClass will depend directly on concrete configuration and implementation of your library class MyLibrary. What if you would like one day to use a third-party library instead? What if you would like to have another class where you would like to use exactly the same library configuration? Every time you will have to search through your code, find exact place and change it. It’s just a few examples.

The idea is that this tight coupling between the components of the application will make your development work harder as your project grows. To avoid any problems, let’s use dependency injection for loosening the coupling described.

That’s it, that’s a very primitive dependency injection example. Instead of creating and configuring a new MyLibrary class object inside your class MyAppClass, you just pass or inject it into the constructor. So MyAppClass can be totally irresponsible for MyLibrary.

What is Dagger 2?

Dagger is a fully static, compile-time, open-source dependency injection framework for both Java and Android. In this article I will be talking about its second version which Google maintains. Square created its earlier version.

Dagger 2 is considered to be one of the most efficient dependency injection frameworks built to date. Actually if you compare Dagger 1, Dagger 2 and Dagger 2.10 you would discover each implementation is different. You need to relearn it each time as there were significant changes done by the authors. When writing this article I am using Dagger 2.16 version and we are going to focus only on it.

As you now understand about dependency injection, our classes should not create or have dependencies. Instead they need to get everything from outside. So when using Dagger 2, this framework will provide all the dependencies needed.

It does this by generating a lot of boilerplate code for us. That generated code will be fully traceable and will mimic the code which a user may write by hand. Dagger 2 is written in Java and the code generated by its annotation processor will be Java code too.

However it works with Kotlin without any problems or modifications. Remember that Kotlin is fully interoperable with Java. If compared to similar frameworks, Dagger 2 is a less dynamic one. It works at compile time rather than at run-time with reflection. There is no reflection usage at all. All that means is that this framework will be harder to set up and to learn. It will provide performance boost with compile-time safety.

Manual Dependency Injection without tools

You may have noticed in the My Crypto Coins app source code from the previous part that there is a piece of code for injecting objects without using any dependency injection tools. It works fine, and this solution would be good enough for such a small app like this. Take a look at the utilities package:

As you see this class will do all the work. It will create ViewModel factories for activities or fragments that require them.

Then you use InjectorUtils class like this where you need to get a specific ViewModel factory:

As you see our MainListFragment class don’t even know about CryptocurrencyRepository or AppDatabase. It gets a successfully constructed factory from InjectorUtils class. Actually this is one simple way to do it. We are going to get rid of it and learn how to setup Dagger 2 tool for advanced dependency injection. If this app would expand in functionality and code, I don’t doubt we would start seeing benefits really fast of using a professional dependency injection framework over a manual solution.

So let’s delete InjectorUtils class right now and learn how to setup Dagger 2 in My Crypto Coins app source code.

Dependency Injection for MVVM with Kotlin

How to setup Dagger 2 with ViewModels, Activities and Fragments

Now we’ll go through the Dagger 2 step by step setup on the My Crypto Coins app project.

To begin, you should enable Kotlin’s own Annotation Processing Tool (kapt). Then add special Dagger 2 dependencies.

You can do this by adding these lines to your gradle file:

Kapt plugin will enable the compiler to generate stub classes required for interoperability between Java and Kotlin. For convenience we will define the concrete Dagger 2 version in a separate gradle file, as we do that with all our dependencies.

To find the latest version available check the releases at Dagger 2's official repository on Github.

Now, create your application App class.

Skip this if you already have this class set. After you’ve done that, we will leave it as it is for a while, but come back later.

For My Crypto Coins app, we already have created the application class earlier.

Next, update your manifest file to enable your App class.

Skip this if you have already done that before.

For My Crypto Coins app, we’ve also already set the App class in the manifest earlier.

Now let’s create a new package called dependencyinjection.

Here we are going to keep all the files related to Dagger implementation.

Create AppModule class module which will provide dependencies all over your application.

As you see, to create a Dagger module we need to annotate it with the special @Module annotation. Projects usually have multiple Dagger modules. It is typical for one of them to provide app-wide dependencies. This AppModule will be used to initialize objects used across our application, such as Room database, Retrofit, Shared Preference, etc.

As an example, we could discuss a very common scenario for AppModule to provide a Context object in case we need it to get access to it anywhere in our app. Let’s analyze the code to see how to do that.

We need to use a special Dagger annotation @Provides. It tells Dagger that the method provides a specific type of dependency, in our case, a Context object. So when somewhere in the app we request to inject a Context, AppModule is the place where Dagger finds it. And it does not matter the names of our methods, as Dagger cares only about the return type. It is only common practice to name the method with provide prefix, but it can be anything you want.

The @Singleton annotation which you see applied to the same method is not part of the Dagger annotations. It is contained inside the javax package. This annotation tells Dagger that there should only be a single instance of that dependency.

You don’t need to write the boilerplate code to check if another instance of the object is already available. When generating the code Dagger will handle all that logic for you because of this annotation. Notice that our AppModule includes another module ViewModelsModule. Let’s create it now.

Create a ViewModelsModule class module. This module will be responsible for providing ViewModels all over your application.

This module uses Dagger 2 feature map multi bindings. Using it, we contribute objects of our choosing into a map that becomes injectable anywhere in our app. Using the combination of Dagger annotations @Binds, @IntoMap and our custom annotation @ViewModelKey(this one we are going to create), we create an entry inside our map with key MainViewModel::class and value MainViewModel instance. We bind specific factory with the help of some common ViewModelFactory class. We need to create this class.

Create a custom annotation class ViewModelKey.

This class is used for binding ViewModels in the ViewModelsModule. The specific annotation @ViewModelKey represents the key of our map. Our key can be only a class that inherits from ViewModel.

Create the ViewModelFactory class.

This ViewModelFactory is a utility class which helps you dynamically create ViewModels. Here you provide the generated map as an argument. The create() method will be able to pick the right instance from the map.

Create the ActivityBuildersModule class module.

This module is responsible for constructing all your activities. It will generate AndroidInjector for all Activities defined in this class. Then objects can be injected into activities using AndroidInjection.inject(this) in the onCreate function from the activity lifecycle. Notice that this module also uses another separate module responsible for fragments. We will create this module next.

Create the MainListFragmetBuildersModule class module.

This module will build all your fragments related to MainActivity. It will generate AndroidInjector for all Fragments defined in this class. Objects can be injected into Fragments using AndroidSupportInjection.inject(this) in the onAttach function from the fragment lifecycle.

Create the AppComponent interface component.

Component is a very important interface. It will enable all the above to start working together. It does this by connecting objects to their dependencies. Dagger will use this interface to generate the code necessary to perform the dependency injection.

To create a component class you will need to use Dagger annotation @Component. It takes a list of modules as an input. Another annotation @Component.Builder allows us to bind some instance to component.

Then generate a graph object.

At this moment you have all your modules and your component setup. You can generate your graph object by selecting Build -> Make Module inside your Android Studio IDE. We will need this generation for future steps.

Now create an Injectable interface.

This will also be needed for future steps. Injectable interface should be implemented by activities or fragments which we want to be injectable automatically.

Create a new helper class named AppInjector.

It is just a simple helper class to avoid calling the inject method on each activity or fragment.

Next, setup the App class which we already created before.

Because the application has activities, we need to implement the HasActivityInjector interface. If you see an error called out by Android Studio on DaggerAppComponent, it is because you have not generated a new file, as was pointed out in the previous step.

So, setup MainActivity to inject the main ViewModel factory and add a support for fragment injections.

Because our activities have child fragments we need to implement HasSupportFragmentInjector interface. We also need this because we plan to make injections into our fragments. Our activity should not know about how it is injected. We use the AndroidInjection.inject(this) code line inside overriding onCreate() method.

Calling inject() method will cause Dagger 2 to locate the singletons in the dependency graph to try to find a matching return type. However we don’t need to write any code here because it’s done for us by previously created AppInjector helper class which we initialized inside our application class.

Then, setup MainListFragment to inject the main ViewModel factory.

Similar to activities, if we want our fragment to be injectable, then into its onAttach method we should write the code AndroidSupportInjection.inject(this). But again this is a job done by the AppInjector helper, so we can skip that. Just notice that we need to add the Injectable interface which we created earlier for the helper to work.

Congratulations, we’ve implemented Dagger 2 in the My Crypto Coins app project. Of course this article is a quick guide to deploy Dagger 2 in your app straight away, but not deep coverage of it. I recommend that you continue researching this topic if you feel lost on the basics.

Repository

Check out the source code of the updated “Kriptofolio” (previously “My Crypto Coins”) app on GitHub.

View Source On GitHub

Ačiū! Thanks for reading! I originally published this post for my personal blog www.baruckis.com on October 7, 2018.

How to implement Dependency Injection in your app with Dagger 2 was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kriptofolio app series - Part 3

The most important thing to focus on when starting to build a new app is architecture. The biggest mistake you can make is to go with no architecture style at all.

The topic of architecture choice has been quite controversial for the Android community in recent years. Even Google decided to get involved. In 2017 they proposed their own approach of standardized architecture by releasing Android Architecture Components. It was intended to make developers’ lives easier.

In this post, I am first going to discuss why we need to architect our apps. We will cover what options we have. Then we are going to learn how to do that. Rather than reinventing the wheel, we will use guidelines provided by the Android team.

This post was the hardest one for me to write because of my own lack of knowledge about it. First I had to study the topic of architecture really well to see the bigger picture. Now I am ready to share my findings with you.

Series content

• Introduction: A roadmap to build modern Android app in 2018–2019
• Part 1: An introduction to the SOLID principles
• Part 2: How to start building your Android app: Mockups, UI, XML layouts
• Part 3: All about that architecture: exploring different architecture patterns and how to use them in your app (you’re here)
• Part 4: How to implement Dependency Injection in your app with Dagger 2
• Part 5: Handle RESTful Web Services using Retrofit, OkHttp, Gson, Glide and Coroutines

Why should you care about app architecture?

Usually when you start working with Android you end up writing most of the core business logic in activities or fragments. This happens to all new Android developers, including myself. All short tutorials and all samples suggest doing that. And actually, for small apps created for explanation, that works good enough.

However, try to do that on a real app which is constantly changing according to the users’ needs and expanding it with new features. Soon you will see that your coding experience is getting more and more painful. Everything becomes managed by so-called “God Classes” like activities or fragments. These have so many lines of code that you get lost easily.

Basically all your code starts to look like spaghetti where everything is mixed up. All the parts depend on each other. Then when new changes are required by the business, you are left with no choice but to rebuild the entire project. Also that’s the point where architecture questions start to appear.

Is there a better way to structure your code?

Of course there is! The key for high quality code is to follow the SOLID principles. I talked about this in my previous post (not without a reason). You should also apply some architecture pattern for separation of concerns. In fact, separation of concerns should be your ultimate goal. It is the most significant point which indicates code quality. There are quite a few patterns out there for app architectures. The most well known are the classic three tier architectures such as:

• MVC: Model-View-Controller
• MVP: Model-View-Presenter
• MVVM: Model-View-ViewModel

All these patterns represent the main similar idea — to structure your project’s code in a way that it is separated by the different generic layers. Every layer has its own responsibility. That’s why your project becomes modular: separated code parts are more testable, and your app is flexible enough for continuous changes.

If we talk about each pattern individually, the topic becomes too broad. I am only going to introduce you to each one just so you can understand main differences.

The Model-View-Controller (MVC) pattern

This pattern was the first iteration Android app architecture took back in the old times. It suggests that you separate your code to 3 different layers:

Model — the data layer. Responsible for handling the business logic and communication with the network and database layers.

View — the user interface (UI) layer. It’s a simple visualization of the data from the Model.

Controller — the logic layer, gets notified of the user behavior and updates the Model as needed.

This is the MVC schema. In it we can see that both the Controller and the View depend on the Model. The Controller updates the data. The View gets the data. However, the Model is separated and could be tested independently of the UI.

There are a few approaches of how to apply the MVC pattern. It’s quite confusing.

One is when activities and fragments act like the Controller. They are in charge of processing the data and updating the views. The problem with this architecture approach is that activities and fragments can become quite large and very difficult to test.

Another approach which seems more logical (and correct) is where activities and fragments should be the Views in the MVC world. The Controllers should be separate classes that don’t extend or use any Android class. Same for the Models.

Anyway if you investigate more about MVC, you will find out that when applied to an Android project, even in the correct way the code layers depend on each other. That’s why I would not recommend that you use it anymore for your next Android app.

The Model-View-Presenter (MVP) pattern

After the first approach, which didn’t work, Android developers moved on and tried to use one of the most popular architectural patterns — MVP. This pattern represents a second iteration of architecture choice. This pattern became widely used and is still a recommended one. For anybody who starts Android development, it is easy to learn. Let’s have a look at its 3 separate layers roles:

Model — the data layer, which is the same as on MVC pattern. Responsible for handling the business logic and communication with the network and database layers.

View — the user interface (UI) layer. Displays the data and notifies the Presenter about user actions.

Presenter — retrieves the data from the Model, applies the UI logic and manages the state of the View, decides what to display, and reacts to user input notifications from the View. This is essentially the controller from MVC except that it is not at all tied to the View, just an interface.

MVP schema shows that the View and the Presenter are closely related. They need to have a reference to one another. Their relationship is defined in a Contract interface class.

This pattern has one significant but controllable disadvantage. The Presenter tends to expand to a huge all-knowing class if you are not careful enough and don’t break your code according to single responsibility principle. However, generally speaking, the MVP pattern offers a very good separation of concerns. It could be your main choice for your project.

The Model-View-ViewModel (MVVM) pattern

MVVM pattern is the third iteration of the approach. It became the architecture pattern recommended by Android team with Android Architecture Components’ release. That’s why we will be focusing on learning this pattern most of all. Also I will be using it for “My Crypto Coins” app. As before, let’s take a look at its separate code layers:

Model — abstracts the data source. The ViewModel works with the Model to get and save the data.

View — that informs the ViewModel about the users’ actions.

ViewModel — exposes streams of data relevant to the View.

The difference compared to MVP pattern is that, in MVVM, the ViewModel does not hold a reference to the View as it is with the Presenter. In MVVM, the ViewModel exposes a stream of events to which various Views can bind. On the other hand, in the MVP case, the Presenter directly tells the View what to display. Let’s take a look at the MVVM schema:

In MVVM the View has a reference to ViewModel. ViewModel has no information about the View. There is a many-to-one relationship between View and ViewModel.

Comparison of MVC vs MVP vs MVVM

Here is a table which sums up all the patterns I talked about:

As you may have noticed, MVC is not so good compared to MVP and MVVM when building a modular and testable modern app. But each pattern has its own advantages and disadvantages. It is a good choice if it exactly fits your needs. I suggest that you investigate and learn more about all these patterns as it is worth it.

In the meantime, I will continue my project with the trending pattern in 2018, which is also pushed by Google — MVVM.

Android Architecture Components

If you’re familiar with the Android application lifecycle, you know what a headache it can be to build an app that avoids all data flow problems and persistence and stability issues which usually appear during configuration change.

In 2017, the Android team decided we’d struggled enough. They assumed responsibility and introduced the Android Architecture Components framework. This finally lets you solve all these issues without complicating your code or even applying hacks to it.

Android Architecture Components is a collection of libraries that helps you design robust, testable, and maintainable apps. At the current moment when I am writing this blog post, it consists of these components:

• Data Binding — declaratively bind observable data to UI elements
• Lifecycles — manage your activity and fragment lifecycles
• LiveData — notify views when underlying database changes
• Navigation — handle everything needed for in-app navigation
• Paging — gradually load information on demand from your data source
• Room — fluent SQLite database access
• ViewModel — manage UI-related data in a lifecycle-conscious way
• WorkManager — manage your Android background jobs

With the help of the Android Architecture Components we are going to implement MVVM architecture pattern in My Crypto Coins app following this diagram:

It’s a recommended architecture by Google. It shows how all the modules should interact with one another. Next we’ll be covering only the specific Android Architecture Components that we will use in our project.

Organizing your source files

Before starting development we should consider how we should organize our project’s source files. We can not leave this question unanswered, as later we would have a messy structure hard to understand and modify.

There are several ways to do it. One is to organize by component category. For example, all activities goes to their own folder, all adapters go to their folder and so on.

Another way would be to organize everything by app features. For example, search and add crypto in all crypto currencies list feature goes to its own addsearchlist folder. The main idea is that you need to do it in some specific way instead of having everything placed randomly. I use some kind of mix of both of these.

Besides the project’s folder structure, you should consider applying some rules for naming project files. For example, when naming Android classes you should define the class purpose clearly in the name.

ViewModel

For the start of our app architecture development, first we are going to create the ViewModel. View models are objects that provide data for UI components and survive configuration changes.

You can use a ViewModel to retain data across the entire lifecycle of an activity or a fragment. Activities and fragments are short-lived objects. They are created and destroyed frequently as a user interacts with an app. A ViewModel is also better suited to managing tasks related to network communication, as well as data manipulation and persistence.

As example now lets create a ViewModel for MainListFragment to separate the UI data from it.

Then obtain the ViewModel with single line of code.

Basically that’s it, congratulations! 🙂 Let’s move on.

LiveData

LiveData is an observable data holder class. It follows the observer pattern. LiveData is lifecycle-aware. This means that it only updates app component (activity, fragment, etc.) observers that are in an active lifecycle state.

LiveData class returns the latest value of the data. When data changes it returns the updated value. LiveData is best suited with ViewModel.

We will use LiveData together with ViewModel like this:

Observe data on the ViewModel, exposed as LiveData:

Browse the repository at this point in the history here.

Data Binding

Data Binding Library was created to remove boilerplate code needed to connect to XML layouts.

To use Data Binding in your Kotlin projects, you will need to turn on support for annotation processors with the kapt compiler plugin. Also add data binding block to the Android configuration gradle file:

To use data binding generated classes, we need to put all the view code in <layout> tags. The most powerful concept of data binding is that we can bind some data class to an xml layout and item properties to fields directly.

RecyclerView adapter with data biding will look like this:

At last no more writing findViewById 🙂 Browse the repository at this point in the history here.

Room

Our app needs to store persistent data of different cryptocurrencies that the user holds. This should be stored inside the local database that is kept inside the Android device privately.

For storing structured data in a private database we will use a SQLite database. This is often the best choice.

In order to create the SQLite database for our app we will use Room. Room is a persistence library made by the Android team which is a wrapper above SQLite. It is an abstraction layer that removes much of the boilerplate code you need to interact with SQLite. It also adds compile-time checking of your SQL queries.

The best way to think of it is as an ORM (Object Relational Mapper) tool designed to automatically generate glue code to map between your object instances and rows in your database.

There are basically 3 major components in Room:

1. Entity — this component represents a class that holds a database row. For each entity, a database table is created to hold the items.
2. DAO (Data Access Object) — the main component which is responsible for defining the methods that access the database.
3. Database — a component which is a holder class that uses annotation to define the list of entities, the list of DAOs, and database version and serves as the main access point for the underlying connection.

Let’s follow these simple steps to setup Room in our My Crypto Coins app:

1. Create an Entity.

Add some extra information to tell Room about its structure in the database.

2. Create the DAO.

For the start, we are going to create a DAO which only allows us to retrieve records from the table that we have created with Entity and also to insert some sample data.

3. Create and setup the Database.

It is important to say that the Database instance should ideally be built only once per session. The one way to achieve this would be to use a Singleton pattern.

As you see on initial run, the database will be prepopulated with some sample data just for testing purposes.

4. EXTRA step. Create the Repository.

The Repository is not part of the Architecture Components libraries. It is a suggested best practice for code separation and architecture.

It stands as a single source of truth for all app data in case you have to manage multiple data sources.

We are going to use this repository in our ViewModel.

Our Fragment code also evolves.

Because our ViewModel class now has a constructor which is not empty anymore, we need to implement a provider factory pattern. This will be passed to the ViewModelProviders.of() method as the second parameter.

Browse the repository at this point in the history here.

Final thoughts

Design architectures, that we discussed in this part, should be used as informed guidelines but not a hard rules. I did not wanted to go too much into detail on each topic. With Android Architecture Components we had a look at the coding process. Have in mind that there is lot more to learn on each component individually and I advise you to do that.

Let’s summarize everything that we manage to make already:

• In My Crypto Coins app, every separate screen has its own ViewModel. This will survive any configuration change and protect the user from any data loss.
• The App’s user interface is a reactive type. This means it will update immediately when the data changes in the back-end. That is done with the help of LiveData.
• Our project have less code as we bind to the variables in our code directly using Data Binding.
• Finally, our app stores user data locally inside the device as a SQLite database. The database was created conveniently with the Room component. The App’s code is structured by features and all project architecture is MVVM — a recommended pattern by Android team.

Repository

Now, as you’re seeing the “Kriptofolio” (previously “My Crypto Coins”) app is really starting to take shape. With the latest repository commit for this part 3, you can find it nicely showing prepopulated database data for the user with the total holdings portfolio value calculated correctly.

View Source On GitHub

Ačiū! Thanks for reading! I originally published this post for my personal blog www.baruckis.com on August 22, 2018.

All about that architecture: exploring different architecture patterns and how to use them in your… was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

So how do you actually start to build a new app? What should be your first move? If you think we just need to launch Android Studio and jump directly to the code, think again. That’s exactly the thing I would advise not to do as it can do more damage than good. But it is so tempting to start writing your first lines of code as soon as possible.

Instead I would suggest focusing on making a wise plan with UI mockups. Remember that every good new app project should start with that. With this approach you will not loose a lot of time and will be able to build high quality products from the beginning.

So in this part of the series, I will present “Kriptofolio” (previously “My Crypto Coins”) app mockups and discuss how to create them. Also we are going to build all the UI layouts. These layouts will become our solid foundation indicating clearly what to code. Finally we will localize our app to different languages and learn how to handle the ones which are written from right to left.

Series content

• Introduction: A roadmap to build modern Android app in 2018–2019
• Part 1: An introduction to the SOLID principles
• Part 2: How to start building your Android app: creating Mockups, UI, and XML layouts (you’re here)
• Part 3: Architecture patterns MVC, MVP, MVVM with Android Architecture Components — ViewModel, LiveData, Data Binding, Room
• Part 4: Dependency Injection with Dagger 2
• Part 5: Handle RESTful Web Services using Retrofit, OkHttp, Gson, Glide and Coroutines

Mockups

There are various ways you can create your project mockups. The simplest one is to take a pencil and a sheet of paper and start drawing on it. The best part is this way doesn’t cost you anything and you can start immediately. Oh and I almost forgot, you should also get yourself an eraser as there will not be any undo function. 🙂

If you, like I, feel that you need more functionality, then consider using special software for creating detailed mockups. I prefer using software instead of pencil & paper, even if it requires you to invest your money to buy it and your time to learn how to use it.

There are various software options on the market to choose from. You will have to do your own investigation into which one best fits all your needs. For all my projects mockups right now I am using Balsamiq Mockups for Desktop app. Balsamiq is rapid, effective and very easy to use wire framing software. As I am rather happy with it, I recommend it for creating Android apps, so please feel free to try.

I started My Crypto Coins app project by creating well thought-out and very detailed mockups. I thought to myself that if I create everything in a very detailed way, than I will avoid mistakes. I will also not waste time for suddenly changing functionality during the development process. If you put a lot of effort in creating good mockups, than, with a little bit of imagination, you can see and feel the final product.

My goal was to have everything defined in the mockups like it should look in the end product. For that I tried not to rush but to spend as much time as I needed. Here are my final mockups for My Crypto Coins app:

Stock design — Material

Another important thing to talk about is the app’s visual design. At the time of this writing, Material Design is the stock visual design recommended by Google for all Android apps. And guess what — you can’t go wrong with stock design.

For My Crypto Coins app we will be using Material Design. The app follows the best practices defined in the detailed online guidelines.

Material.io/guidelines — official material design living specs document which will be our design guidelines for this project.

Layouts

Now when we already have wireframes of our app prepared, it’s time to build real UI. Again we could jump into writing code, but why rush? Instead I would recommend concentrating on building all your XML layouts. My advice here would be that the more you manage to put into XML the less code you will need to write.

The Android team constantly improves the way you can build your UI by adding new features to XML layouts. Sometimes it’s so tempting to write few lines of code to reach a desired look. But it’s better to investigate the topic more deeply to find if it is possible to do without code. Remember: less code makes your project look cleaner. It will also be more understandable for other developers and easier to maintain.

Finally when you create all your XML layouts, you will feel like you have your app made. You will be able to launch it and see how it feels for the end user. It doesn’t matter that it is showing some fake data and does nothing. Now you have the last chance to make some drastic changes.

If you are building an app for somebody else, it’s such a good time to present it. Maybe you will be asked to make some surprising last minute changes. That way you will avoid writing code for functionality that will never be used. A lot of people don’t have enough imagination and they need to see and touch first to decide if it is what they want. So don’t leave your layouts for the last step in your work process.

For this app I will be using various components that are common in all modern Android apps:

• CoordinatorLayout — a super-powered FrameLayout, the main appeal of which is its ability to coordinate the animations and transitions of the views within it.
• AppBarLayout — a vertical LinearLayout which implements many of the features of material design’s app bar concept, namely scrolling gestures.
• Toolbar — a generalization of action bars for use within application layouts.
• CollapsingToolbarLayout — a wrapper for Toolbar which implements a collapsing app bar. It is designed to be used as a direct child of a AppBarLayout.
• ConstraintLayout — a ViewGroup which allows you to position and size widgets in a flexible way. Imagine a RelativeLayout on steroids.
• SwipeRefreshLayout — the widget which allows the swipe-to-refresh user interface pattern to be implemented entirely. It detects the vertical swipe, displays a distinctive progress bar, and triggers callback methods in your app.
• FloatingActionButton — a circular button that triggers the primary action in your app’s UI.

For the main screen we will use a combination of all these components to create nice UI/UX. Users can expand and collapse the top part of the layout to find the total value of all their cryptocurrency portfolio. They can check any change in value during the last 24 hours and change selected fiat currency.

Of course there are other components besides these nine. It is very important to master the whole component palette to know which one to use in any particular case. With the mobile trends changing from time to time the palette will expand too.

I am not going to talk about every component, but my advice is to investigate that on your own. For me the best way to understand them is by trying to build XML layouts manually instead of using automatic drag & drop tools in Android Studio.

Styles, Colors, Dimensions, Strings, Icons

At first glance, the things mentioned in this section title may appear not to be important ones. However, I ask that you to put in effort when creating them in any app if you want to make it modern and exclusive. Remember this blog posts series is how to build a MODERN Android app! No matter how wrong it is, people will usually judge your app by its looks first, not its functionality.

So here is a perfect chance to earn new users love from the beginning. These are my tips:

• When building your XML layout files, you should recognize where you repeat some common attributes for the views. Move them to be defined as separate XML styles. That way you will have shorter XML layout files. You can control all the app styling aspects from a separate place. Imagine what benefit it will give you. For example, you could allow the user to choose the app skin (bright, dark, etc.).
• Define all your app colors in a separate file too, and enjoy ability to experiment with the look by changing them immediately. Sometimes the same product can be given new life and engage users again by simply refreshing with new colors. There are quite a few websites that can help you choose nice colors, but my favorite one is MaterialPalette.com, so take a look.
• Define your app dimensions in a separate file. This will allow you to adjust your app to look good on different size screens.
• All your strings should not be hard-coded, and Android Studio will inform you if you forget. Do not ignore that. The best part when your strings are separated is you can translate your app to different languages.
• When using icons for your app, always prefer an XML vector drawable format. That’s the new recommended standard and a clever way to go to avoid any pixelation. To find many professionally made material design style icons from the community, please check out MaterialDesignIcons.com. I used this website to get icons for My Crypto Coins app.

RecyclerView

The main screen of My Crypto Coins app will consist of a list of cryptocurrencies that the user holds. For this purpose the RecyclerView widget is the best fit. It is a widget that displays a scrolling list of elements based on large data sets (or data that frequently changes).

Because of its advantages, RecyclerView is the recommended component for creating any list screen. It is a more advanced and flexible version of the simpler ListView component. We will talk about it later too. In this part we are creating just layouts. We are not concentrating on coding.

To see our app visually, we will have to implement RecyclerView by writing some code. These are the steps to implement RecyclerView:

1. Add a RecyclerView component.

Our MainActivity layout is activity_main.xml. This layout includes content_main.xml layout which is a fragment. This MainActivityListFragment layout inflates fragment_main_list.xml. So you should add RecyclerView component here.

As you see we configure our RecyclerView to leave some padding space at the bottom. We do this to avoid covering the last list item with the FloatingActionButton. Also we turn on the vertical scrollbar so it’s available.

2. Create RecyclerView row layout.

For our initial purpose we will only set the item name for each row. Our simplified layout should look like this.

3. Create data adapter class.

Our adapter for now will accept string data. Later we will need to create a separate class data model. We will need to pass more information than only one string.

4. Connect RecyclerView to custom adapter.

Done! Now our main screen looks like this:

ListView

In this project, we will use ListView for the screen where you can add crypto coin(s) which you already hold. Because of its shortcomings in recent years it is hardly used anymore.

So I guess a lot of you at this moment are wondering why I decided to use it in My Crypto Coins app when we could create the same functionality easily with RecyclerView.

Remember, though, that this project was created for training purposes first. I thought it would be beneficial to gain insights into ListView and how it works. Any developer may run into ListView in legacy code, and it’s best to know how to work with it. Besides, the list we will be creating is so simple that ListView’s technical limitations won’t cause us any problems.

Let’s follow the very similar steps needed to implement ListView:

1. Add a ListView component.

The first thing to do is to add a ListView to AddSearchActivity. Open the activity layout file activity_add_search.xml and you will see that it includes content_add_search.xml. There we will add the ListView component.

2. Create ListView row layout.

As before, just for initial purposes, we will only set the item name for each row. Here is the simplified layout:

3. Create data adapter class.

Like RecyclerView our ListView adapter for now will accept only string data to get the item name and show it on screen. Later we will use a separate class data model. As for this part, we want to build a very simple list displaying only cryptocurrency titles. Instead of creating our custom adapter we could use the default, ArrayAdapter.

As you see in the adapter code, by creating CustomViewHolder object I use the ViewHolder pattern. It stores list row view references. Calling the findViewById() method only occurs a couple of times. It allows us to make our list scrolling act smoothly and efficiently.

The ListView doesn’t require us to use the ViewHolder pattern. The RecyclerView’s adapter gives us that kind of protection by default, as it forces us to use it.

4. Connect ListView to custom adapter.

With default ArrayAdapter it could look like val adapter = ArrayAdapter(this, android.R.layout.simple_list_item_1, data). That’s the beauty of the ListView component. If you want, you can create a simple list really fast without building your own adapter or row layout (skip steps 2 and 3).

ListView setup is ready!

SearchView

In the same screen with all cryptocurrencies listed, we also need to add SearchView. Search will be a useful functionality to have for any user who wants to find a specific cryptocurrency by typing its name. For this part we will not build functionality fully but just implement its visual part. Follow these steps to add SearchView to the project:

1. Declare the searchable configuration in XML.

The searchable configuration file should be added in your res directory named xml. Here you can specify attributes for your SearchView component which define how it behaves.

2. Create new activity which will become our searchable activity.

We are going to create new blank activity which extends AppCompatActivity(). We will name it AddSearchActivity.

3. Specify newly created activity in Android manifest file to be searchable.

We will let the Android system handle the search process. That’s why we add the intent action search and meta-data in the activity element of the AddSearchActivity. The meta-data has name and resource which is linked to the searchable configuration file located in the res/xml folder.

4. Create search menu.

Inside the res/menu folder we are going to create a menu resource file.

5. Add search menu to activity.

We will add the Android search widget as a menu action view.

Now the SearchView is added to the activity. Still the search functionality is not working. But we have it implemented as we wanted for this part.

Settings

If you want to create a modern Android app, I recommend that you include a settings screen and give access to app settings for the user. Including settings in your app gives your users the power to control some of the functionality of your app which makes them happier. They are now in control of how the app behaves. So we are going to create a settings screen for My Crypto Coins app too.

You can create a settings screen with Android Studio template and it will generate all the code you need. By default at the time of writing this blog post, settings activity is generated with preference headers. That’s not what we want for such a small app where we plan to have only few settings at first.

Therefore we are going to build everything manually. Settings screen is designed with an XML-like layout. Let’s go step by step to create again only the visual part for this blog post:

1. Create preferences screen XML file.

We are going to create the preferences screen XML file which should be placed in the res/xml directory.

2. Create preferences fragment.

Then we should create a simple blank fragment — SettingsFragment, which should extend PreferenceFragment(). This fragment will create preferences from the XML resource that we created. In the future this fragment will contain all the necessary methods to inflate the XML settings. It will also provide callbacks when the settings are changed.

3. Create preferences activity.

With the settings fragment ready let’s create new activity — AppCompatPreferenceActivity, which extends PreferenceActivity(). This class provides compatibility across all the devices and versions.

4. Create settings activity.

5. Add settings item to main menu.

6. Launch newly created settings activity when the settings is selected from overflow menu.

7. Specify newly created settings activity in Android manifest file.

Congratulations, you can finally launch the settings from the toolbar’s menu item.

Using 3rd party libraries — Gmail style flip circle button-view

OK, there are various opinions about using 3rd party libraries — code created by a developer other than the original vendor of the development platform. Some people avoid them as it is never clear how long and how well they will be supported. Meanwhile others use them as they can accelerate the development process.

Your decision to use them should depend on your particular case. You should do your own investigation of the library and determine if it flexible enough to fit all your requirements.

For My Crypto Coins app, there is a situation where I would like to create a circle image view. This image should show a specific cryptocurrency icon inside a circle shape. But if the icon doesn’t exist, then I would like to show the first three letters of the cryptocurrency code.

Besides all that I would like to be able to select images by clicking them. Selection should be presented as a short flip view animation.

All this UX that I described was not originally invented by me. You can find similar behavior on the Gmail app and it looks really good.

But how do we create it? In fact, circle image view is not even a default component which you can find in the Android Studio components palette.

You could go the hard way and try to create everything yourself, but this could waste time and energy. Instead, you could choose to implement one of the many open source libraries created particularly for that.

For my UI/UX requirement, I found a library on GitHub davideas/FlipView. After some investigation I decided that it was really professionally made. It is easy to implement and supported long enough to give it a try. So to start using it, we’ll follow these easy steps:

1. Add dependency.

Import the library into your project.

2. Use it.

Configure FlipView with Android’s usual and custom app attributes. Isn’t that easy?

So don’t reinvent the wheel. Always consider using some library first to deliver results faster. And if you project becomes messy, it’s not the old libraries to blame but how well you structure your code. If your project is modular enough there won’t be problems. But that’s a separate topic and I am going to talk about project architecture in later blog posts.

Localization with RTL support

When I decided to create this app, I set myself a goal not only to create it with a default English UI, but also to translate it to my mother tongue, Lithuanian, from the start of development.

This goal lead me to learn about localization in Android. What I have found is that to add support for multiple languages is very easy. As I mentioned before, first you need to separate all your strings to the strings.xml file. Then you can launch the Translations Editor tool inside Android Studio. This will allow you to add new languages support.

You will see that the interface is very intuitive. Now you need to translate each string from your strings.xml file to a new language. A new file will be generated by the IDE in separate directory. For example, for Lithuanian language, it’s values-lt/strings.xml. That’s it! 🙂

If you switch your Android device system language to the one you just translated to and then run your app, all the UI will be automatically updated to your translations. Moreover, for My Crypto Coins app, later I plan to add the ability to switch languages at run-time. That’s why you will notice the language switcher inside the settings screen.

Translating your app to different languages will definitely widen your audience. Why not go further by adding support for a few special languages that are written from Right to Left (RTL) — like Arabic, Hebrew or Persian.

Actually to add RTL support is not difficult at all. Just add the support attribute to your manifest file:

Congratulations, your app now supports RTL. However you can’t trust blindly that everything will work correctly straightaway. You should check how well it is supported yourself. To do that select one of the RTL languages as your primary device language.

A few tips for RTL:

• In all your layouts you will need to replace all Left and Right layout properties with Start and End equivalent. For example android:paddingLeft should be replaced with android:paddingStart.
• If you don’t have a special drawable for RTL, perhaps you would like to mirror your current ones with a special autoMirrored attribute.

• If there are certain places where you need to have LTR instead of RTL, you can do that too. For example to force any layout to LTR just add android:layoutDirection="ltr" to that view. If you need to force text direction inside text view than use android:textDirection="ltr".

By the way, when using Translations Editor, there is a very useful feature to order a professional translation service. Even if I personally don’t know anything about the Hebrew language, I still set myself a goal to add support for it as an example RTL language for My Crypto Coins project. So this feature seemed like a really good idea to try. I ordered the translation successfully from English to Hebrew directly from the IDE with just a few clicks.

Final thoughts

In this second part of the series, we created all the UI layouts with some initial code based on detailed mockups. I did not want to go into too much detail on each topic so as not to confuse you. My goal was to show you how to see a bigger picture, how to focus on small details first, and avoid costly mistakes later.

If you find something not covered well enough, use it as a jumping off point to do your own research. There are always plenty of good resources around the web to learn from. 😉

Repository

You can find all the XML layouts and code created for this part here:

View Source On GitHub

Ačiū! Thanks for reading! I originally published this post for my personal blog www.baruckis.com on May 14, 2018.

How to start building your Android app: creating Mockups, UI, and XML layouts was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

Software is always in a state of change. Each change can have a negative impact on a whole project. So the essential thing is to prevent damage that can be done while implementing all new changes.

With “Kriptofolio” (previously “My Crypto Coins”) app, I will be creating a lot of new code step by step and I want to start doing that in a good way. I want my project to be solid quality. First we need to understand the foundation principles of creating modern software. They are called SOLID principles. Such a catchy name! 🙂

Series content

• Introduction: A roadmap to build a modern Android app in 2018–2019
• Part 1: An introduction to the SOLID principles (you’re here)
• Part 2: How to start building your Android app: creating Mockups, UI, XML layouts
• Part 3: All about that Architecture: exploring different architecture patterns and how to use them in your app
• Part 4: How to implement Dependency Injection in your app with Dagger 2
• Part 5: Handle RESTful Web Services using Retrofit, OkHttp, Gson, Glide and Coroutines

Principles slogan

SOLID is a mnemonic acronym. It helps to define the five basic object-oriented design principles:

1. Single Responsibility Principle
2. Open-Closed Principle
3. Liskov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

Next we are going to discuss each of them individually. For each, I am going to provide bad vs good code examples. These examples are written for Android using the Kotlin language.

Single Responsibility Principle

A class should have only a single responsibility.

Each class or module should be responsible for one part of the functionality provided by the app. So when it handles one thing, there should be only one main reason to change it. If your class or module does more than one thing, then you should split the functionalities in separate ones.

For a better understanding of this principle, I would take as an example a Swiss Army knife. This knife is well known for its multiple functions besides its main blade. It has other tools integrated inside, such as screwdrivers, a can opener, and many others.

The natural question here for you is why am I suggesting this knife as an example for single functionality? But just think about it one moment. The other main feature of this knife is mobility while being pocket size. So even if it offers a few different functions it still fits its main purpose to be small enough to take it with you comfortably.

The same rules go with programming. When you create your class or module, it has to have some main global purpose. At the same time you can’t overplay when trying to simplify everything too much by separating functionality. So remember, keep the balance.

A classic example could be the often used method onBindViewHolder when building RecyclerView widget adapter.

👿 BAD CODE EXAMPLE:

🙂 GOOD CODE EXAMPLE:

Code specifically designed with the Single Responsibility Principle in mind will be close to the other principles that we are going to discuss.

Open-Closed Principle

Software entities should be open for extension, but closed for modification.

This principle states that when you write all the software parts like classes, modules, and functions, you should make them open for extension but closed for any modification. What does that mean?

Let’s say we create a working class. There should be no need to tweak that class if we need to add new functionality or do some changes. Instead we should be able to extend that class by creating its new subclass where we could easily add all new necessary features. Features should always be parameterized in a way that a subclass can override.

Let’s take a look at an example where we will create a special FeedbackManager class to show a different type of custom message for the user.

👿 BAD CODE EXAMPLE:

🙂 GOOD CODE EXAMPLE:

The open-closed principle summarizes the goals of the next two principles that I talk about below. So let’s move on to them.

Liskov Substitution Principle

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

This principle is named after Barbara Liskov — an accomplished computer scientist. The general idea of this principle is that objects should be replaceable by instances of their subtypes without changing the behavior of the program.

Let’s say in your app you have MainClass which depends on BaseClass, which extends SubClass. In short, to follow this principle, your MainClass code and your app in general should work seamlessly without any problems when you decide to change BaseClass instance to the SubClass instance.

To understand this principle even better, let me give you a classical, easy to understand example with Square and Rectangle inheritance.

👿 BAD CODE EXAMPLE:

🙂 GOOD CODE EXAMPLE:

Always think before writing down your hierarchy. As you see in this example, real-life objects do not always map to the same OOP classes. You need to find a different approach.

Interface Segregation Principle

Many client-specific interfaces are better than one general-purpose interface.

Even the name sounds complicated, but the principle itself is rather easy to understand. It states that a client should never be forced to depend on methods or implement an interface that it doesn’t use. A class needs to be designed to have the fewest methods and attributes. When creating an interface try not to make it too big. Instead split it into smaller interfaces so that client of the interface will only know about the methods that are relevant.

To get the idea of this principle I have created again bad vs good code examples with butterfly and humanoid robots. 😉

👿 BAD CODE EXAMPLE:

🙂 GOOD CODE EXAMPLE:

Dependency Inversion Principle

One should “depend upon abstractions, [not] concretions.”

The last principle states that high-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

The main idea of the principle is not to have direct dependencies between the modules and classes. Try to make them dependent on the abstractions (e.g. interfaces) instead.

To simplify it even more, if you use a class inside another class, this class will be dependent on the class injected. This violates the principle’s idea and you should not do that. You should try to decouple all classes.

👿 BAD CODE EXAMPLE:

🙂 GOOD CODE EXAMPLE:

To sum up briefly

If we think about all these principles, we can notice that they are complementary to each other. Following the SOLID principles will give us many benefits. They will make our app reusable, maintainable, scalable, testable.

Of course it is not always possible to follow all these principles completely, as everything depends on individual situations when writing code. But as a developer you should at least know them so you can decide when to apply them.

Repository

This is the first part where we learn and plan our project instead of writing new code. Here is a link to Part 1 branch commit, which basically is “Hello world” initial code of the project.

View Source On GitHub

I hope I managed to explain SOLID principles well. Feel free to leave comments below.

Ačiū! Thanks for reading! I originally published this post for my personal blog www.baruckis.com on February 23, 2018.

An introduction to the SOLID principles was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome to this series of blog posts where I will be creating a modern Android app. I will use the best tools and practices available in the year 2018–2019. I am doing this because I want to cover all the hottest topics in the Android world and acquire knowledge in them by teaching you.

If you follow this series, you will learn how to develop the app from scratch. Each blog post from this series will cover some specific development topic which I want to talk about. I will try to do my best to create a good quality app and explain the development process. This first blog post from the series is a project’s roadmap of what we are going to do.

Series content

• Introduction: A roadmap to build a modern Android app in 2018–2019 (you’re here)
• Part 1: An introduction to the SOLID principles
• Part 2: How to start building your Android app: creating Mockups, UI, XML layouts
• Part 3: All about that Architecture: exploring different architecture patterns and how to use them in your app
• Part 4: How to implement Dependency Injection in your app with Dagger 2
• Part 5: Handle RESTful Web Services using Retrofit, OkHttp, Gson, Glide and Coroutines

The app: “Kriptofolio” (previously “My Crypto Coins”) idea

At first it was hard to think of a plan to showcase all Android development trends, but finally, I found one which I liked. It is related to my huge interest area — blockchain and cryptocurrencies. I decided to create an app which would contain your cryptocurrencies portfolio and let you know how much they are worth converted to fiat money.

The important thing for the user is that this app is going to ensure 100% trust. It will not require any login/registration process. It won’t collect users’ data by sending it to the server. I guess nobody would feel comfortable sharing information online about owned money.

Users’ provided data about cryptocurrency investments will be only stored inside a local database that is kept inside an Android device. However, to know the portfolio’s value converted to the fiat money, the app is going to use the Internet to get the latest conversion rates.

So as you see for training purposes, this app idea is great. It is technically challenging you to try different approaches to work with data. This is one of the most important skills to know to build modern apps. The topic of money for people is so sensitive. To ensure even more trust, I will be developing this app openly by creating this blog posts series and making the project code available so everyone can see that there is nothing to hide.

What are we going to use?

First, to create this app, we need to know about various cryptocurrency prices at the current moment. This data will be provided from the Internet as it is continually changing.

Data API:

CoinMarketCap — one of the most popular websites for getting an overview of the cryptocurrency market. This website offers a free API that anyone can use and it fits perfectly for us as a data service provider.

Next, I made a list of my most significant trending things in the Android world that fit this project and should be used in it.

Programming language:

Kotlin — an official language on Android. It is expressive, concise, and powerful. Best of all, it’s interoperable with existing Android languages and runtime.

This new language introduction was one of the hottest topics in 2017 for Android. Our app needs to be written in it. I also talk about Kotlin and its features in my past blog post “Let’s learn Kotlin by building Android calculator app”.

Integrated development environment (IDE):

Android Studio — the official IDE for Android. It provides the fastest tools for building apps on every type of Android device. There are no better alternatives for developing native apps. It’s our main choice for an IDE without any question.

Project build management system:

Gradle — is an advanced general purpose build management system based on Groovy and Kotlin. It supports the automatic download and configuration of dependencies or other libraries. It is the recommended build system by Google. It is well integrated inside Android Studio so we will be using it.

Architecture:

Android Architecture Components — a collection of libraries that help you design robust, testable, and maintainable apps.

Model–View–ViewModel (MVVM) — an architectural pattern. The concept is to separate data presentation logic from business logic by moving it into a particular class for a clear distinction. The Android team is pushing this pattern as the default choice. Also, it’s an alternative to MVC and popular MVP patterns.

I’ll be talking separately in this series about this pattern choice, other architecture options and how to organize our code well in general. It is essential if we want to build an easily maintainable solid project.

Coroutines — a concurrency design pattern that you can use on Android to simplify code that executes asynchronously.

Data persistence:

SQLite Database — it is an open source SQL database that stores data persistently to a text file on a device. Android comes in with built-in SQLite database implementation. SQLite supports all the relational database features.

Shared Preferences — an API from Android SDK to store and retrieve application preferences. SharedPreferences are merely sets of data values stored persistently. It allows you to save and retrieve data in the form of key value pairs.

Libraries:

Android Jetpack components:

AppCompat — it is a set of support libraries which can be used to make the apps that were developed with newer versions work with older versions.

Android KTX — a set of Kotlin extensions for Android app development. The goal of Android KTX is to make Android development with Kotlin more concise, pleasant, and idiomatic by leveraging the features of the language such as extension functions/properties, lambdas, named parameters, and parameter defaults.

Data Binding — is a support library that allows you to bind UI components in your layouts to data sources in your app using a declarative format rather than programmatically.

Lifecycles — for managing your activity and fragment lifecycles.

LiveData — is an observable data holder class which was designed to help solve common Android Lifecycle challenges and to make apps more maintainable and testable.

Room — it provides an abstraction layer over SQLite to allow easy database access while harnessing the full power of SQLite.

ViewModel — designed to store and manage UI-related data in a lifecycle conscious way. The ViewModel class allows data to survive configuration changes such as screen rotations.

Other:

ConstraintLayout — for building flexible and efficient layouts. The Layout Editor uses constraints to determine the position of a UI element within the layout. A constraint represents a connection or alignment to another view, the parent layout, or an invisible guideline.

CardView — element which represents the information in a card manner with a drop shadow (elevation) and corner radius which looks consistent across the platform.

RecyclerView — a flexible and efficient version of ListView. It is a container for rendering large data set of views that can be recycled and scrolled very efficiently.

Third-party:

Dagger 2 — this is an entirely static, compile-time dependency injection framework for both Java and Android.

Retrofit 2 — an open source type-safe HTTP client for Android and Java. With Retrofit, we can compose the HTTP connection easily through a simple, expressive interface just like an API document.

OkHttp — an open source modern, fast and efficient HTTP client which supports HTTP/2 and SPDY.

Gson — an open source Java library to serialize and deserialize Java objects to and from JSON.

Glide — a fast and efficient image loading library for Android focused on smooth scrolling. Glide offers an easy to use API, a performant and extensible resource decoding pipeline and automatic resource pooling.

Configuring a new project

We will create this project from scratch. So I’ll launch Android Studio, create a new Project, name it “My Crypto Coins” and select “Basic Activity”. At this point, there is nothing special to discuss. Our goal is to make a fresh, clean start and avoid any complexity in our minds by adding additional features (e.g., instant app support). We can add anything later if we want during the development process.

For a start let’s include Kotlin language support and target API 23: Android 6.0 (Marshmallow).

Why am I not targeting a lower or higher API? Let’s face it. It’s nice to cut the support for some older devices and not worry about any compatibility issues during development. Also, I am a proud owner of an old Nexus 7 (2013) tablet, which is running Android 6.0.1. I hope to test my app live on it. 🙂 So for this individual project that impacted my minimum SDK choice.

Also as you’ve noticed, I am going to ask IDE to add automatically generated basic activity with fragment support and a floating action button. I feel all that could be useful for our project.

GitHub — one of the most popular web-based hosting service for version control. This is an open source project, and of course, I will be using it.

All the blog posts from this series will have its commits made as separate branches and the master branch for the latest source code version. Here is a link for you to the repository.

View Source code on GitHub

That’s it for the start. If you have any questions, suggestions, remarks to make, please feel free to do that in comments. And now let’s learn together! Part 2 is up next…😉

Ačiū! Thanks for reading! I originally published this post for my blog www.baruckis.com on February 12, 2018.

A roadmap to build a modern Android app in 2018–2019 was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.

I want to talk about optimization. This is very important topic for all us, IT developers, which we face when we are creating software. I bet you agree that programmers are tend to be lazy people, that’s why they always look for the best way to do something with minimum effort, they try to automate all they can and use lowest computing power possible. Of course there can be some exemptions when we rush to deliver as we are short on time, but in general we try to optimize our code and our daily tasks to the maximum efficiency. We all understand and agree that we need to allocate some extra time if we want to create easily maintainable, extendable, clean and high quality code. We need time because we can not rush as we need to experiment, educate ourselves in order to use best strategy and tools. Usually we ask our team leaders, managers, boss for that and we are angry if they don’t understand us. And at this point of agreement I want to stop and ask you, when the last time do you allocated some similar time to optimize your life? When have you made a pause for all your daily routine just to think about your goals, do unfinished things you always wanted and perhaps apply some better strategy for your career or personal life like you apply design patterns for your code. And I am not talking just about few hours of thinking in the silence while relaxing after the good party, but the time period (month, year) big enough actually to do something real. If you can confirm for yourself that you done that recently or you even do that regularly than let me congratulate you. You can skip this post. However if you are not sure or you don’t understand what I am talking about I invite you to continue reading.

Busy developer picture

So let me try to draw the picture of you, which could be more precise especially if you are IT developer. So first of all you love technology and you are really busy with constantly learning new IT skills. You feel that you are always chasing and trying to catch up. The more your learn the more you feel that you don’t know. Time after time you change companies and jobs as you want to improve, you want to be up to date while working on new latest technology projects. You do that because if you want to be IT developer you have to learn constantly. So it’s really hard. But you know because it’s hard you get paid well, really well (or that’s what you think). After work you are tired and you just don’t have time. You don’t have time for anything else serious. Yes you have weekends left but when they start you have so many gathered daily life issues to solve, and also you want to relax and entertain yourself. And if at that daily constantly repeating circle that you live in you come up with some crazy creative new ideas that you would like to try guess what happens? You just think about it, usually talk about it and never do that. Why? Let me repeat myself, because you don’t have time left for anything serious and abstract. Do you see what I mean?

It’s a loop.

If we want to optimize our lives we need to break that loop. To do that we need to identify why it’s continuing. In my opinion the reason is simple to see, it is related with money and fear. We all fear to loose money. Actually I got really disappointed inside when I had read one blog post where a programmer says that for him every day is money, big money earned and that even to be sick is not worth it because you just loose money. Just think about this opinion for a while. On the one hand people dream and talk about businesses they could create, interesting things they could do, adventures that they would have and on the other hand they refuses all that for their greed, greed for money. Money which when you think about it are really not big enough, but just comfortable to live with and gives you imaginable safety. If you now start wondering what’s wrong to live comfortable life let me stop you right now. Let’s discuss the benefits of breaking that loop and making strategical pause in life.

Benefits of breaking the loop

What is strategical pause? What do I mean? As I said previously it’s similar to code optimization, just here you optimize your life. First you step out of your daily routine and suddenly you have plenty of time for everything. Remember you need to think that you stepped out for unlimited time to get that feeling. It’s not a holidays, not a long break between changing jobs or contracts, you don’t have to feel a pressure to come back anywhere. When you do that you immediately notice that you have so many small things gathered up that you need to solve and do. These small things bothered you for a long time, maybe even a years, but now you have time for them. Best part here is that you will solve all these annoying things faster as you thought, because you can concentrate to them fully each every day without interruption. Just imagine that good feeling when you finish the last one and feel free again. With freedom will come back the joy. Finally feeling free again you will get some time to entertain yourself by concentrating to abandoned hobbies. Read popular book you always wanted, learn to play guitar, finish all the levels of a computer game that you love… It’s just examples, and again if you do that full time each day, it won’t take so long as you think. You don’t believe me? How about eating the cake every day? It can be the most delicious cake in world but do you think you will want to eat it after a week, two weeks, a month? Just relax, dive deep to your hobby and enjoy that time. I tell you it won’t continue too much long until you get bored.

So what’s next?

I bet you will start noticing more small details of the world we are living in. Just imagine ordinary Monday when everybody is rushing to their workplace, and you can enjoy your long walk in the park, breath fresh air, listen to the birds, feel the nature and relax. It’s a brilliant feeling which we loose because of a rush every day. Also I think that you will start to care your physical body shape much more, because that is going to happen naturally. While having so much free time and seeing sun shining you instinctively will go outside for training, running, biking, swimming, playing football, basketball, tennis and so on. If compared to the time when you work, usually you leave any sports for the end of the day when you go to some enclosed gym. Natural daylight is getting over or completely finished, you feel less energetic, just more stressed after long day at work. Just imagine what a good feeling is to go outside when you are really in the mood and the weather condition is at it’s best instead of sitting near computer screen in the office until the momentum is lost. Let me ask what impact do you think all these experiences will make on you? I promise it will be the best soul and body healing time of your life. The good news is that when your body and soul is healed your brain will start to work. Your inner creativity will be turned on. When you step out from your daily routine, you will start seeing bigger picture. Finally you will have time to analyze, experiment, educate yourself. That will be a best quality time when you will question yourself about everything: which people do you need keep in your life, connections you need renew, actions you need to take to fix your health, what worthless habits you need to remove and what new useful ones to add. At this time new business, projects ideas will be born. But the best part here is that you can try to implement all your ideas immediately. Not next week, month or year. No more excuses that you are busy, just actions.

Strategical pause idea

Have I intrigued you with the benefits of strategical pause idea? I hope so. 🙂 So your next question is how to do it? Simple answer would be just do it. But I know that the more comfortable life you live the more complicated it will sound to you. Please understand that here the only thing what separates you from doing it is money. And money is complicated thing. I know that you may have many questions, like how about my all liabilities to my daily job, to my family, even to myself. Simple solution is to save some money or create passive income source (advanced level solution) and than try to make a pause. Basically you will buy time for your money. You will only know if it was worth it if you try to buy it. Remember you can not assert that it is not worth it if you never tried. The secret here is that you don’t need to win a million in the lottery just to try. When you try for the first time you will learn a lot from such situation. Also there is another popular opinion how to reach your goals without loosing money. Some say that when you really really want you can allocate some time after your work with serious time management involved. But I repeat to you, trust me, it’s different because when you make a pause as I recommend, you step out of your comfort zone, feel insecure and than you brain feels the danger, starts to work 110% and that’s where the magic happens.

Be brave, be free

OK I am happy if you managed to reach this post point. Let’s finish this abstract topic. I hope you found my own life experience of making strategical pauses worth to read. Remember we all humans are intelligent species and we are natural creators, that’s why we are happy when we dream, plan, do, build something what we personally want. That only comes with freedom. So be brave and give yourself even just a short moment of freedom with strategical pause in life. 😉

Ačiū! Thanks for reading! I originally published this post for my personal blog www.baruckis.com on January 31, 2018.

One of the biggest news of Android world in 2017 definitely became Kotlin. This is new programming language from JetBrains which has been announced as official Android development language during Google I/O 2017 event. So there are no more excuses to make for not learning it. In this post I will share my findings on Kotlin and show you how to build small Android calculator app using this new language.

Why should you want to switch to Kotlin?

But first lets talk about any questions or doubts that could developer have to start using Kotlin. I won’t lie, I had all these myself, but after some research managed to find all the answers. Main question for me was why the hell do we need Kotlin when we have already reliable and one of the most popular language in the world Java? Answer here is so predictable. We all know that Java is already old language which is not changing a lot and fast enough, so it don’t have modern programming language features compared to other languages. Meanwhile Kotlin is really modern, with it you can write more safer and more functional code which besides being shorter manages to do more than written in Java. It is is designed with the idea to be just a better language than Java. Sounds good? Another question that comes to my mind is if Kotlin is already finished language, can we trust it to use in real life projects? You know sometimes to rush and chase the latest technology is not the best idea while it’s just half-baked. However Kotlin language first appeared on 2011. First stable Kotlin version was released only on 2016, so as you see it was developed for really long time until matured to reliable complete language. Finally I bet you would like to know how easy is to start using Kotlin in your Android projects? After trying myself I was really surprised to find out how many effort is made to have as easy transition from Java as possible. Most amazed I was with the fantastic feature inside Android Studio, our daily IDE used for Android development work, to convert from Java to Kotlin code automatically. If you are new to Kotlin this will be really helpful during your first steps while you get used to the language. Besides Kotlin is fully interoperable with Java code, which means that you can create mixed projects with both Kotlin and Java files coexisting. So you can start gradual migration from Java to Kotlin with your projects. Also please think about the idea that you can confidently expect best compatibility for Kotlin language with Android Studio and always up to date support. Why? Because Kotlin is designed by JetBrains, company known for creating IntelliJ IDEA, a powerful IDE for Java development. And Android Studio is based on IntelliJ. Moreover Google announced first-class support for Kotlin on Android, which means all their libraries, frameworks, features should work smoothly with the new language.

First Kotlin project — simple calculator app

Ok do you recognized my idea of importance to switch from Java to Koltin as soon as possible? Are you already motivated to try Kotlin building real app? For my first experiments with Kotlin I decided to go with the plan of creating simple calculator app. It’s one of my most often used applications whether it would be a personal computer or mobile phone. Actually between all these different platforms that I use, my favorite representation of calculator is on Windows 10. What I like in it that it shows nicely your recent actions and then stores your history.

So I decided to recreate it’s standard version on Android using Kotlin with all these my mentioned features included, which became more challenging than I thought at first time, but after all I reached nice result that I share with you.

You can dive to the code directly on GitHub to check it out how it was done.

Kotlin differences and advantages over Java

Kotlin language comes with many differences and advantages over Java that you will notice. Let’s have a look to some of them that I have faced immediately while working on my calculator app project:

• We don’t use semi-colons at the end of the sentences anymore. This is simple one and the first thing I noticed instantly. 😉 Also it is recommended practice by IDE which warns about that.
• When extending a class or implementing interface, you replace Java’s extends or implements with a colon, and then attach the name of the parent class or interface. Also classes are final by default, and can be extended only if it’s explicitly declared as open or abstract.

• In Kotlin defining parameters is vice versa to Java. Here first we write the name and then its type.
• Variables defined by two different keywords var which means variable value can be changed and val which means that value cannot be changed. Also compiler is smart enough to recognize type of variable without declaring it as Kotlin is a strongly typed language that supports type inference.

• Functions are defined using the fun keyword instead of void. Function’s name comes before its type, which is opposite to Java.
• Kotlin is null safe. You decide whether an object can be null or not by using the safe call operator — question mark. By default it cannot. We avoid a lot of defensive code which we used in Java just to check whether something is null before using it just to avoid unexpected NullPointerException.

• Has lambda expressions which allows reducing the amount of code needed to perform some tasks. The common example is adding a click listener to a button with one line instead of multiple lines in Java.

button1.setOnClickListener {onNumberButtonClick(ONE)}

• Newly introduced property modifier lateinit identifies that the property should have a non-nullable value and its assignment will be delayed. This is very handy when we need something else to initialize a property, but we don’t have the required state available in the constructor or no access at that moment.

• Meanwhile also new keyword lazy means that your variable should not be initialized unless you use that variable in your code. Have in mind that it would be initialized only once and after that always the same value used.
• Kotlin has extension functions and properties. This adds new functionality or properties to a class even we don’t have access to modify the source code of that class. So if you ever wished that a class should have a function or a property that was not available, now you are free to create one. This is such a nice feature clearly showing that it is a modern programming language. 🙂

• Statement if..else is also as an expression in Kotlin as it has the ability to assign a variable from the returned value of the statement.

• As a replacement for the familiar switch statement Kotlin offers new expression when which has more powerful features and is more concise.

• Kotlin has string templates.

• Kotlin doesn’t have checked exceptions but instead all exceptions are unchecked. That’s the main difference between Kotlin and Java exception mechanisms. Exceptions are not explicitly declared in the function signatures, as they are in Java. If we feel that exception might arise even if it is not enforced by the Kotlin compiler, we should handle it by surrounding the method with with a try...catch block. Useful annotation called @Throws in Kotlin might come in handy when you still want to add the possible exceptions that might be thrown to a method signature.

Where to learn

Here I pointed out just a few things, but there are so much more new features in Kotlin that makes this language different from Java and really modern one. To find out all of them and to learn Kotlin in general I would like to recommend amazing book which I have read myself — “Kotlin for Android Developers” by Antonio Leiva. If you feel that reading a book is too slow and too boring for you than any online course could be best alternative. You could try one from my favorite provider Pluralsight called “Kotlin Fundamentals” by Kevin Jones. After watching it I found out this to be made really professional with deep language coverage, and also as a great addition to reading a book.

My advice

I hope you will find this small Android calculator app code useful while exploring various Koltin language projects over internet. But remember that really to learn new language you need to start building something by your own. Happy learning and coding in Kotlin! Don’t forget to share your projects too.

Check out project on GitHub

Ačiū! Thanks for reading! I originally published this post for my personal blog www.baruckis.com on November 7, 2017.

Let’s learn Kotlin by building Android calculator app was originally published in MindOrks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you ever got an offer to work in startup? What’s work at startup like? Offered to work for equity and asked yourself what that actually means? Should you rush to accept that offer as it is so unique opportunity? Or is it just a fool’s gold and sounds too good to be true? With this blog post I want to try to clear your confusion by sharing with you my own story about one longer part of my life which I feel can be interesting for other IT developers to read about and perhaps learn something from my experience. 🙂

A lot of us after finishing university usually starts searching for a job and joins matured profitable companies where you just do your daily tasks, get fixed salary and try to go up career ladder in time. Sometimes we go for smaller companies sometimes for big international ones, but usually we join a group of people who are already working together, have goals set up, have own team leaders and managers distributed. That exactly was my experience as described, before I was invited to join at that moment young startup company — Better Day™ Health — my new adventure career wise about which I want to tell you here. But first things first, let me tell you why and how I left everything behind and opened new blank page in my life. For that I created separate story blog post — “Never be afraid to change technology“.

About the company

So what is Better Day™ Health? I would like to give a credit and introduce this promising company as I worked there for more than 4 years and chosen to believe in its idea.

Better Day™ Health was founded by Peter Ragusa, MD, MPH and a group of dedicated healthcare & technology professionals from the US & Europe around a single, unifying purpose: to create innovations that drive dramatic improvements in the way medicine is practiced that lower costs, save lives, extend resources and facilitate closer patient-provider relationships.

Better Day™ is a web-based software platform that uses predictive modeling and 3rd-party applications & devices to turn data into action and, in doing so, actively facilitate patient-provider collaboration in order to proactively manage health, fitness & chronic disease. It is focused on providing a first-of-breed ‘smart’ electronic health record (EHR) platform to facilitate the highest quality of care in a highly-complex healthcare system.

So to say in short and in simple human words, it’s just innovative company with really modern ideas to drastically improve healthcare software using latest technologies and its trends. Being only Android developer there I worked on creating Better Day™ Pro app.

What it is like to work in startup?

Now let’s come back to the main question: so what it is like to work in startup and even get some equity for that? The answer is that actually it is a mixed feeling as it has its own advantages and disadvantages which I want to talk about here in this post. I believe this information could be especially helpful for someone who is trying to decide between startup over corporation, if startup could be the right choice and what to expect.

Disadvantages

To mess up your mind let’s start with the hard things you can expect to experience when joining any startup. These things I experienced myself when joining this particular organization. Of course hard not necessarily means bad but it’s challenging. Depending on your attitude to life and values that you prefer these things can be counted as disadvantages or just be ignored, acceptable to you.

Here they are:

1. You are suddenly left alone to work almost completely on your own! For startup it is natural to count money and hire as little as possible new people until some progress is made. This means that you can’t get any help from anybody as you alone are responsible for some specific area. All that really professional colleagues who lead you by example and was always around you to help now are gone and you have to solve all the problems just by using your own head and Google of course. 🙂 Are you ready for such challenge?
2. You need to learn how to communicate well. You can be the best specialist in your area, but that’s not enough, you need to know how to present your work. By saying present I mean explain it so clearly like you would do for a child. There is no more producers, managers, team leaders or any other middleman between you and your boss. Company CEO usually has only generic knowledge in all areas, so you can’t expect him to understand your technical language and challenges you face every day. And actually it is normal, you need to be less geeky while communicating and understand importance of that. You can even lose your job if don’t learn this advice. Believe me as I saw that happening in my own eyes. 😛
3. You need to deliver! Results is the only thing that matters in startup environment. If working in bigger company you could avoid personal responsibility for some time, here you can’t hide.
4. You can be asked to use your personal devices, like laptop, monitor, phone, tablet for work. Why? Because it’s just too big investment for startup at first to buy everything you need and they try to save money as they can.
5. You lose a lot of perks that big companies offer as competition for IT workforce is so tough these days. Most valuable ones are company contributions to your pension, healthcare insurance, various paid memberships. Also you need to forget about free snacks, drinks, fruits, pizza at work. If your startup company does not decide to rent some brand new co-working space and starts everything in house environment like we did at first than you definitely feel the difference. For us who work in IT area good work conditions an modern environment became so natural that sometimes we do not even evaluate that and accept as a normal thing. What happened to me was that big comfortable office with good quality professional chairs, wide desks, dual monitors’ setup, pool table, wending machines, clean restrooms had been suddenly changed to small dark private apartment with old uncomfortable tables, my personal laptop and mobile phone for development. It was miserable and funny at the same time.
6. You are naturally forced to become “jack of all trades” — a person whose expertise spans a significant number of different subject areas. If you are a programmer than expect to be a designer for some time too and computer repair technician if needed, and anybody else based on demand when special work situation arise.
7. Personal training? Sorry, but there is no time for this! Never, as there is always rush to deliver to secure new money injection from investors. Forget such things like paid tech conferences. Also don’t expect a lot of training from other team members, not because they don’t want to, but because everybody has special role assigned for building product and not for training somebody. If they are going to do it, it will be just a minimal introduction to avoid wasting their time.

Advantages

However working in startup has many own advantages too. Let’s try to list them all here:

1. Most important one is that you get tons of priceless experience. Just think yourself a minute about it. You do work from day one, you actually build product. You do that through the trials and errors, you constantly challenge yourself every day. It’s like next level. You learn effectively create added value and that is most important to any business. Every future employer will understand how valuable such experience is without much explanation.
2. Naturally such experience working in startup is one of the best ways to boost your career as a developer. With challenging tasks and responsibilities assigned you learn a lot new skills fast which makes you better developer. Experienced developers earns more and are always on demand.
3. It’s interesting and fun to work in startup. Until now I just emphasized how hard and challenging work in startup is, but with all that it also becomes interesting. No more boring repetitive tasks every days. You are involved in almost all stages of product development, not just in specific ones.
4. You all become really close like a family working towards one goal. In startup there are no job titles. You know CEO personally, you can chat with him anytime you want because he is sitting next to you. It’s not some big corporation where you don’t even understand who is responsible for what, or where you never talked with the main boss.
5. Freedom. Compared to corporations in startup you get much more flexibility. There is no employees tracking or managing, no strict rules, no need to ask for special permissions. You can dress as you want, go out when you want. You feel that you control your day and you don’t get that prisoner’s feeling. In general people are clever creatures and it’s not natural for them to be controlled by others that’s why freedom feeling is so important. Usually even without a control everybody still does a good job as they feel responsible.
6. If startup is going to be successful and to grow, you can confidently expect to get a leading position and much more money easy. Most important people will always be the ones who were the core of the company when it was created.
7. You have opportunity to see and experience company’s growth from inside and learn from true innovators. Behind every successful startup there is entrepreneur. Entrepreneurs approach problems differently, are constantly finding solutions and demonstrate original way of thinking. That’s why they are some of the best people to learn from. After working in startup and seeing how it’s done, you can get inspired to start your own adventure.
8. Working in startup will give you personal ownership feeling, pride that you created something by your own, you are representing the company and the product. This is difficult to understand, but can become big inspiration for you to do your daily job.
9. To avoid loosing best employers during the time and keep them more motivated, it’s very common practice to offer them participation in company’s equity earning program. That can become huge advantage over the time.

Work for equity?

My mentioned the last one advantage, equity offer, is worth separate discussion as it is tricky one. It is also a reason why I decided to write this blog post in the first place as I got my own life lessons with it. What does it mean? In short, having equity in a company means that you have a stake in the business. From the first look it sounds like a clear winner. Finally you think that you have a chance to earn real money if the company does well. And people are usually optimistic about the companies in which they work. First of all if you have chosen to join particular organization because you already believe in its idea and future success. That’s normal and that’s how it should be. Also a lot of inspiration comes from massive media where you read success stories of various startups every day. However you need to understand that the value of equity is neither certain nor fixed. The difference between the worst case and best case scenarios can be huge. Remember that the huge amount of startups around the world fails constantly and only the best one succeed, but nobody talks about the losers. In order to get some equity you will need to sign a contract to stay in the company for certain time. And time is definitely the most valuable thing you have in life. Even if you done everything correctly by agreement (stayed with the company for set time, worked hard on creating product, respected the confidentiality orders, et cetera) are you sure that you can trust these people when it comes to money. Are they going to pay you without going to the court? Does that contract document which you signed years ago really means something? What if company suddenly becomes not so friendly towards you when you decide to leave and you will have to fight for your equity part? Are you ready for that and you have enough willpower to do it as every fight can be so tiring and time wasting? My goal by modeling these scenarios is not to say that equity offers are worthless, not at all, but what I want to explain you that you shouldn’t overemphasize it when deciding over on getting a new job. It’s a good bonus to have if it’s offered next to your salary, but to go and work only for equity instead of real money is too much risky, and I would not recommend such crazy idea. In my opinion the advantages disadvantages I listed above but not the equity offer should impact your decision to join startup over corporation or not.

Sum up

To sum up everything I would like to say that I had amazing life and developer experience when joining a startup over the corporation, and if I could rewind back the time I would probably do that again. 🤔 If you never worked in “real” startup (apartment based) definitely try that. You can expect to get motivation boost, learn how to learn new things fast, how to control your time wisely, become responsible and self-confident in doing everything by your own, learn how to lead and teach others instead of expecting to be trained by someone and I could go on.

Ačiū! Thanks for reading! I originally published this post for my personal blog www.baruckis.com on October 23, 2017.