Category: Android

Android is an open source and Linux-based operating system for mobile devices such as smartphones and tablet computers. It was developed by the Open Handset Alliance, led by Google, and other companies.

Android programming is based on Java programming language so if you have basic understanding on Java programming then it will be a fun to learn its application development. Its applications are usually developed in the Java language using the Android Software Development Kit. Once developed, the applications can be packaged easily and sold out either through a store such as Google Play, SlideME, Opera Mobile Store, Mobango, F-droid and the Amazon Appstore.

Android Distribution

It powers hundreds of millions of mobile devices in more than 190 countries around the world. It’s the largest installed base of any mobile platform and growing fast. Every day more than 1 million new devices are activated worldwide.

This category will help you learn all the basics and advanced areas to enable you become a programming ninja.

Introduction to Flutter in Android

Introduction to Flutter in Android

Flutter is an open source beta framework by Google for mobile UI to build high-quality native (super fast) interfaces for both iOS and Android. Dart is used as a programming language inside Flutter. Dart is similar to other modern languages such as Kotlin and Swift, and can be transcompiled into JavaScript code.

Flutter allows for a reactive and declarative style of programming and as a cross-platform framework, Flutter most closely resembles React Native. Unlike React Native, however, Flutter does not need to use a Javascript bridge, which can improve app startup times and overall performance. Dart achieves this by using Ahead-Of-Time or AOT compilation.

Another unique aspect of Dart is that it can also use Just-In-Time or JIT compilation. JIT compilation with Flutter improves the development workflow by allowing hot reload capability to refresh the UI during development without the need for an entirely new build.

As you’ll see in this tutorial, the Flutter framework is heavily built around the idea of widgets. In Flutter, widgets are not used just for the views of your app, but also for entire screens and even for the app itself.

Today, we are going be properly install Flutter and its required components and also run a demo app on both the Android Emulator.

Setting Up Environment

Flutter development can be done on macOS, Linux, or Windows. We’ll use Android Studio for this tutorial.

Instructions for setting up your development machine can be found here. The basic steps vary by platform (mine = macOS), but for the most part are:

  • Clone the Flutter git repository
  • Add the Flutter bin directory to your path
  • Run the flutter doctor command, which installs the Flutter framework including Dart and alerts you to any missing dependencies
  • Install missing dependencies
  • Set up your IDE with a Flutter plugin/extension
  • Test drive an app

Using Android Studio

With Android studio, it is pretty easy and straight forward.

Open Android studio (This is me assuming you already have Android studio up and running on your computer)

Open Android Studio > Preferences.. > Plugins and select Browse repositories.

Here you are going to install 2 plugins: Dart and Flutter, so on the search bar type in “Dart

I already have it installed, so you would notice I don’t have regular green-issh “install” button. So you just click on install and wait out the process.

Then also on the search bar type in “Flutter

So just install and restart your IDE.

On restart you would notice that Android studio now has Flutter project as an option.

Select Start a new Flutter project > Flutter Application

You then proceed to this screen.

You don’t have the Flutter SDK installed, but Android Studio can help you with that. Just select the directory you want it installed in and click on Install SDK… Android studio will clone the repo into the specified directory and voila you have the SDK installed. You need to do one more thing, but go ahead and finish the project.

Locate the folder you specified for the Flutter SDK, then open a new terminal at that folder.

At this stage you can either temporarily set our PATH variable or permanently add Fluter to you PATH.

To add temporarily,

To add permanently,

then run echo $PATH to confirm if added successfully.

Next run the following command to see if there are any dependencies you need to install to complete the setup:

This command checks your environment and displays a report to the terminal window. The Dart SDK is bundled with Flutter; it is not necessary to install Dart separately.

The first time you run a flutter command (such as flutter doctor), it downloads its own dependencies and compiles itself. Subsequent runs should be much faster.

The following sections describe how to perform these tasks and finish the setup process.

Once you have installed any missing dependencies, run the flutter doctorcommand again to verify that you’ve set everything up correctly.

So you ready, thats all, all set up.

Lets return to the project we created on Android studio. We have a default project provided by Flutter.

You can either plug in your a mobile device, run on an Android emulator or iOS simulator. Locate the main Android Studio toolbar, select which you want and then click PLAY.

Flutter offers a fast development cycle with hot reload, the ability to reload the code of a live running app without restarting or losing app state. Simply make a change to your source code, tell your IDE want to hot reload, and see the change in your simulator, emulator, or device.

  • Change the string
    'You have pushed the button this many times:' to
    'You have clicked the button this many times:'
  • Do not press the ‘Stop’ button; let your app continue to run.
  • Click the Hot Reload button (the button with the lightning bolt icon).

You should see the updated string in the running app almost immediately.

Thanks for reading and hope you enjoy Flutter. Feel free to leave a comment below if you have any issues, suggestions, etc.

Happy Coding!

ButterKnife  – A Viewbinding library for Android

ButterKnife  – A Viewbinding library for Android

In this post, we will detailed look into ButterKnife, a viewbinding library for android. Also demonstrate how it’s work, how to integrate and use in your android app development to make your development faster.

Let’s get started!

What is Butterknife?

Butter Knife is small, simple and lightweight, and it makes life as a developer easier. It is developed by Jake Wharton. It makes your code less and more clear. It is time saving to write repetitive lines of code.

ButterKnife is a view binding library that uses annotation to generate boilerplate code for us.

It allows developers to perform injection on arbitrary objectsviews and OnClickListeners so they can focus on writing useful code. Consider Android Butter Knife a reduction library. It replaces findViewById with @BindView() and set^^^^Listener calls with @onClick() making code cleaner and more understandable. Butter Knife enables focus on logic instead of glue code and reduces development time by reducing redundant coding.

Getting Started

It is easy to use butterknife in your project. Just add the following dependencies in your build.gradle(module: app) and sync your project!

Butterknife supports Field and method binding for Android views which uses annotation processing to generate boilerplate code for you.

  • Eliminate findViewById calls by using @BindView on fields.
  • Group multiple views in a list or array. Operate on all of them at once with actions, setters, or properties.
  • Eliminate anonymous inner-classes for listeners by annotating methods with @OnClick and others.
  • Eliminate resource lookups by using resource annotations on fields.

All you need to write in these methods is the following:

Activities:

Fragments:

In both the cases Butter Knife binds to the specified Android Activity or Viewtargets to correctly act on the injections specified in these classes. All the view finding lines of code and the action listeners are implemented elsewhere, leaving these methods as clean as possible.

Binding Views, Resources and Event Listeners

Butter Knife replaces the standard findViewById call with @BindView, followed by a view ID and it automatically casts the corresponding view in the corresponding layout. This representation of the code makes it more compact and readable.

Here’s an example of this “injection”:

You can do the same with app resources like StringDrawable and dimensions (dimenvalue , etc).

Butter Knife also makes setting event listeners of Android layout Views easy and removes the listeners implementation from the key onCreate and onCreateViewmethods.

You can refer to the Butterknife Documentation on this link

Conclusion

Android Butter Knife helps you create cleaner and tidier code, handling a lot of the ugly boilerplate code that Android has become infamous for. Have you tried it in your projects? Thanks for reading this article. Be sure to share this article if you found it helpful.

Happy Coding!

Android Data Binding

Android Data Binding

Android provides data binding library that helps in creating apps with less glue code to bind application logic and layouts. With data binding, you don’t need to find views in activities or fragments, set view attributes to properties of data model object and add event handlers to views, all this is taken care of by data binding framework using the data binding component classes and data binding expressions that you define in layouts.

Data binding compiler tool generates necessary code to make the binding work using xml layout and data binding component classes defined using annotations.

Project Setup

The Data Binding Library offers both flexibility and broad compatibility – it’s a support library, so you can use it with all Android platform versions back to Android 2.1 (API level 7+). To use data binding, you need to enable it by adding below configuration to modulebuild.gradle file.

If you have an app module that depends on a library which uses data binding, your app module must configure data binding in its build.gradle file as well.

Data Binding

To use data binding framework, first you need to create data model object, then define your activity layout with data binding elements and expressions. Lets create a simple User Model.

Notice in the below example that layout’s root element is layout and data model object variable is declared using variable element under data element.

The user variable within data describes a property that may be used within this layout.

Expressions within the layout are written in the attribute properties using the “@{}” syntax. Here, the TextView’s text is set to the firstName property of user:

By default, a Binding class will be generated based on the name of the layout file, converting it to Pascal case and suffixing “Binding” to it. The above layout file was main_activity.xml so the generated class was MainActivityBinding. This class holds all the bindings from the layout properties (e.g. the user variable) to the layout’s Views and knows how to assign values for the binding expressions.The easiest means for creating the bindings is to do it while inflating:

If you run the above example, it will display data object value in UI widget. But using @{} expression as shown above will just bind the value of the property of data object to the attribute of View. But it won’t refresh the UI widget with the changed value of the property of the object and it won’t populate the data object with user entered or modified value into the UI widget.

Data binding does not support include as a direct child of a merge element. For example, the following layout is not supported:

Includes

Variables may be passed into an included layout’s binding from the containing layout by using the application namespace and the variable name in an attribute:

Here, there must be a user variable in both the name.xml and contact.xml layout files.

Conclusion

Data Binding is a powerful tool to reduce boilerplate code, when binding or referencing views that show data.  In heavy UI intensive application like Calculator, you will find yourself repeating almost the line of code over and over again. Data binding also offers Two Way Data Binding, which I will cover later. Remember to share and leave comments 🙂

I hope you start using Data Binding in your Android Apps 🙂

Happy Coding!

Setting up Travis CI in Android

Setting up Travis CI in Android

If you are developing using TDD you should run your tests to be sure that you don’t break something in every TDD phase. But we are not perfect and we can commit changes that break our system and we should have something that can alert us if we are doing something wrong asap. This is going to be a short guide on getting set and ready with Travis CI in Android. Before we continue, you need to have an Android Studio project already set up. Now let’s get down to business.

Prerequisites

  • Create a github repo for your project
  • Head over to the root of your project and create a .travis.yml (More on this later)
  • Still at the root of your project, create a folder/directory called licenses; this directory will help in exporting your license agreements such as sdk license agreement from your local machine to the build environment.
  • Now head over to your sdk location and locate a folder/directory called licenses, copy its contents then go ahead and paste them inside the licenses folder/directory you created previously at your project root.
  • You’re now set up, just do a git init, add all your files to git then push your code to Github.

Setting up Travis CI

Here is where Continous Integration comes into play. Every time that you push changes into a branch in your system you can check if everything is ok before you merge this branch into Master (assuming you are using git). What to check? Well, this is up to you and your team members to decide.

I keep my promises! , lets now talk about .travis.yml mentioned earlier. So this is just a file that tells your build machine how it should be configured and also provides the necessary tools and information to get your build system up and running.

So how does this file look like? Here’s the code, you can copy paste it but ensure you go through it to have a grasp of what’s going on.

You can decide to paste it directly to your code then commit and push the changes or paste it in your Github Repo then pull the changes, either of these two will work fine.

Travis provides the service for free but your repo in Github must be public and the free URL is different from the premium URL.

After visiting Travis, sign in with Github. Search for your Github repo then add it. Travis will go to your repo, locate the .travis.yml file and do the rest. Hopefully, if you followed every step correctly, your build should be successful and the repo should turn green with the badge at the top indicating build passing.

Bonus

It’s awesome looking at that badge from your repo. So to add it to your repo, go ahead and click on it. A pop up will show with the url of the badge. Copy the url then paste it in your README file. Here’s an example of how the file should look like inside your README file.

Hooray! Your CI should now be up and running. Thanks for your time.

Happy Coding!

Android Architecture Patterns : Model-View-ViewModel

Android Architecture Patterns : Model-View-ViewModel

Since joining Twiga Foods, I have been involved majorly in the development of our Android App. During the design and development of the first version of the app, there was really no Architecture Pattern that was followed. Many changes were made after deployment, and they learned one important lesson: They needed an architecture pattern that allows fast reaction to design changes! The solution we chose in the end was Model-View-ViewModel after some discussions. Discover with me what MVVM is; how we are applying it at Twiga Foods for our second version and what makes it so perfect for us.

I decided to share the Harvest and Scouting Process Image, above in the Featured Image 🙂 Courtesy Twiga Foods

The Model-View-ViewModel Pattern

The main players in the MVVM pattern are:

  • The View – that informs the ViewModel about the user’s actions
  • The ViewModel – exposes streams of data relevant to the View
  • The DataModel – abstracts the data source. The ViewModel works with the DataModel to get and save the data.

At a first glance, MVVM seems very similar to the Model-View-Presenter pattern, because both of them do a great job in abstracting the view’s state and behavior. The Presentation Model abstracts a View independent from a specific user-interface platform, whereas the MVVM pattern was created to simplify the Event Driven programming of user interfaces.

If the MVP pattern meant that the Presenter was telling the View directly what to display, in MVVM, ViewModel exposes streams of events to which the Views can bind to. Like this, the ViewModel does not need to hold a reference to the View anymore, like the Presenter is. This also means that all the interfaces that the MVP pattern requires, are now dropped.

The Views also notify the ViewModel about different actions. Thus, the MVVM pattern supports two-way data binding between the View and ViewModel and there is a many-to-one relationship between View and ViewModel. View has a reference to ViewModel but ViewModel has no information about the View. The consumer of the data should know about the producer, but the producer – the ViewModel – doesn’t know, and doesn’t care, who consumes the data.

Model-View-ViewModel using RxJava

The event driven part required by MVVM is done using RxJava’s Observables. Here’s how you can apply MVVM with the help of RxJava:

DataModel

The DataModel exposes data easily consumable through event streams – RxJava’s Observables. It composes data from multiple sources, like the network layer, database or shared preferences and exposes easily consumable data to whomever needs it. The DataModels hold the entire business logic.

Our strong emphasis on the single responsibility principle leads to creating a DataModel for every feature in the app. For example, we have a FarmerModel that composes its output from the API service and database layer. This DataModel handles the business logic ensuring that the latest farmers from the database are retrieved.

ViewModel

The ViewModel is a model for the View of the app: an abstraction of the View. The ViewModel retrieves the necessary data from the DataModel, applies the UI logic and then exposes relevant data for the View to consume. Similar to the DataModel, the ViewModel exposes the data via Observables.

We learned two things about the ViewModel the hard way:

  • The ViewModel should expose states for the View, rather than just events. For example, if we need to display the name and the phone number of a Farmer, rather than creating two streams for this, we create a DisplayableFarmer object that encapsulates the two fields. The stream will emit every time the display name or the phone number changes. This way, we ensure that our View always displays the current state of the Farmer.
  • We should make sure that every action of the user goes through the ViewModel and that any possible logic of the View is moved in the ViewModel.

View

The View is the actual user interface in the app. It can be an Activity, a Fragment or any custom Android View. For Activities and Fragments, we are binding and unbinding from the event sources on onResume() and onPause().

If the MVVM View is a custom Android View, the binding is done in the constructor. To ensure that the subscription is not preserved, leading to possible memory leaks, the unbinding happens in onDetachedFromWindow.

Testability Of The Model-View-ViewModel Classes

One of the main reasons why we love the Model-View-ViewModel pattern is that it is so easy to test.

DataModel

The use of inversion of control pattern, heavily applied in our code, and the lack of any Android classes, facilitate the implementation of unit tests of the DataModel.

ViewModel

We see the Views and the unit tests as two different types of consumers of data from the ViewModel. The ViewModel is completely separated from the UI or any Android classes, therefore straightforward to unit test.

Consider the following example where the ViewModel just exposes some data from the DataModel:

The tests for the ViewModel are easy to implement. With the help of Mockito, we are mocking the DataModel and we control the returned data for the methods used. Then, we make sure that when we subscribe to the Observable returned by getSomeData(), the expected data is emitted.

If the ViewModel needs access to Android classes, we create wrappers that we call Providers. For example, for Android resources we created a IResourceProvider, that exposes methods like String getString(@StringRes final int id). The implementation of the IResourceProvider will contain a reference to the Context but, the ViewModel will only refer to an IResourceProvider injected.

We are creating model objects to hold the state of the data. This also allows a higher degree of testability and control of the data that is emitted by the ViewModel.

View

Given that the logic in the UI is minimal, the Views are easy to test with Espresso. You can also using libraries like DaggerMock and MockWebServer to improve the stability of our UI tests.

Is MVVM The Right Solution?

We fully decided and agreed to use MVVM. We have seen that since the View is just a consumer of the ViewModel, it was easy to just replace different UI elements, with minimal, or sometimes zero changes in other classes 🙂

We have also learned how important separation of concerns is and that we should split the code more, creating small Views and small ViewModels that only have specific responsibilities. The ViewModels are injected in the Views. This means that most of the times, we just add the Views in the XML UI, without doing any other changes. Therefore, when our UI requirements change again, we can easily replace some Views with new ones. Super Cool!!!

Conclusion

MVVM combines the advantages of separation of concerns provided by MVP, while leveraging the advantages of data bindings. The result is a pattern where the model drives as many of the operations as possible, minimizing the logic in the view.

Now, we can be proud of an app that has proven its resistance to another redesign. We are finally close to being able to call our Twiga App [DMS] a mature app.

I would love to hear your views and opinions on the different Architecture Patterns you have used before, and why you chose them. Remember to share 🙂

Happy Coding!