I’ve recently started building up CI settings for Android and have tested a few other CI technologies, however Circle CI seems to stand out owing to its simplicity. I’ll walk you through the steps to get this up in your app in no time.

Setup

To begin, you must register with Circle CI; I chose the github authentication option to make things easier for myself.

This made it easier to setup my projects as circle ci automatically pulled this info for me.

After getting access to your new dashboard, select the Android project (of course 😅) you want Circle CI to interact with. (you can skip this since you would still have access to doing this from the dashboard)

When this step is done, you would most likely see a hello world build already successful. Here is where the fun begins, head over to the projects tab then click the options (3 dots) on your project select configuration file and your main branch you want to set circle ci on. After doing this you should get a nice little dialog showing you some preset templates, just scroll down a little to see the android template and click then you should have a window that shows you the template where you can modify some of the commands if you want, else just click commit and run .

If all goes well with the previous step, you should have something similar to the image below.

Now head over to Github, merge your pull request, and voilà you have successfully integrated the CI.

WebHook & Triggers

Next fun part is creating a trigger for your pull requests to start a build and send a status before every merge.

Here are the steps on how to get this going:

1. Go to the settings page of your repo and under “code & automation” select webhooks.
2. Click “edit” you would then see various options for triggers, just confirm pull requests is enabled.
3. Head over to your circle ci projct and under project settings select advanced and enable “only build for pull requests” note all pushes and commits to default branches would still be built regardless of this option.

Head over to your project send a new pull request and test out your webhook and Circle CI build flow.

Thanks for reading and getting this far, that’s all you need to setup a Circle CI workflow.

For a visual representation, you can check out my video on how to setup Circle CI on Android click here

previously Android View State Machine Part 1

State representation is integral to our software systems/applications, but what’s more important is where this data comes from and the various transformations processes that occur before it gets to the final checkpoint, which could be the user interface or in other scenarios would be back to a data store for retrieval at a future time.

Something to note the term “state” is used freely here, where we associate the term state being a set of data going to be represented in a view i.e an error state would translate to the user seeing an error screen with texts gotten from the error state object

State Marker

I have this term I call a State Marker, which I describe as an indicator in your data object that is used to compute a state or represents the state itself. Let’s take a closer look at this.

Looking at this sample JSON data, the first represents a user without any transactions, and the second sample has a transaction list. If you had a screen that is supposed to show a list of user transactions, you would have a UI state machine that would either show an empty state when there are no transactions or show a list of user transactions. Now without any mapping, we know the transactions JSON key is our “State Marker” for this sample JSON. This is just a simple representation, and as we probably know there are lots of different ways in which we create State Markers, some representations deal with using things like enum or sealed classes, even boolean flags with specific keys. Now, this is using State Marker from the perspective of returning server data and identifying markers without post-processing.

In more real-world scenarios, we have state markers that would usually be a mix of different properties, and we would need to have multi-level checks, for available keys either in a server response or an object from an in-device database.

In these scenarios, we define our states as a combination of different data properties or the absence of certain values, and the processing of such data and the assigning or creation of embedded state data could be seen as a state pipeline.

Success and Error States

When you request data from a service, you usually expect one of two states a success when you receive a happy path data type or an error (not so happy path), regardless of the path this response is the start of your data pipeline process and would include certain markers for the state within the path flow.

The returned data path (happy or sad) would determine the type transformations to apply to said data till you get your final state data object.

Let’s talk about the error state, errors most times seem to always have the most obvious markers and their representation within a state machine to a view is almost always very straightforward. Let’s say you make a request from a mobile device and you get an Exception, Depending on the exception you would then know what error state to transition to.

Above we have 2 sub-states from an error we could map to any of them depending on a response i.e we could map to general error for any failures from the server or we map to connectivity for internet-related issues.

A straightforward approach on mapping the errors to an error ViewState, here we use the Throwable/Exception type as a StateMarker so a IOException would lead us to a ConnectivityErrorState while any other Exception would be seen as a GeneralError. These mappings are always application-specific and this is only shown as an example of how error markers can be translated into a StateMachine for a View. Unlike our happy path where we would generally look for markers within the data object such as an enum, boolean, int or a certain combination of string to determine what sort of state the user is in. For example, would incomplete details mean the data belongs to a new user?

State Pipeline Happy Path

If we are moving down the happy path where we receive a successful data response from a service typically our next step would be to clean up this data, re-map objects to something that's easier associated with your views. As a preference, I like to represent my state data using sealed classes and attach the associated data as a parameter, this makes it easier to switch through logic on what state is returned and pull the data out while only accessing specific fields I know are available, in more complex scenarios I prefer to do further processing in the pipeline into stateful widgets, were my sealed class children represent views and after mapping to these widgets, the emitted final object is just attached to a view.

Above we have a simple view state, that would represent an empty view and a data view, our expected illustration is to receive data, have an intermediary mapper convert it to one of the listed states, then consume the final object in the view.

Creating a mapper lets us make use of our supposed “State Marker” which in this case is the availability of the transactions list, when the list is empty we return an EmptyView state. In more complex applications, you could have one mapper feeding data into another mapper, till you get to your required data/assumed state, this is done usually because the state markers in those systems arise from the computation or separation of various properties.

Note: Creating mappers as objects, makes it easier to test these mappers, and check output without having to rely on adding lots of initial setups.

Generally, in terms of data mapping, most people would map across system layers, so from data -> domain -> presentation or data -> presentation, and only mapping to a domain when a cache is needed. This is subjective towards the application architecture, as it’s not uncommon to find domain objects being used in the view for presentation. Regardless of what step process is employed, always try to:

1. Identify the States in which a view or system could fall and create the necessary representation needed for handling this data.
2. Separate state logic in the presentation/view. This just helps to easily follow through the logic of state when coding and thinking of the data flow.
3. Don’t return data in objects that will never be used. Like in the above state example our EmptyState, would essentially be a screen with some sort of image/illustration, so our EmptyView object doesn’t need to return user data.

Our pipeline here sums to a group of mappers, or subprocesses taken on data to identify, assign and then emit or create a Stateful object that may contain associative data.

In a nutshell…

1. The transition between states for data is based on a series of transformations defined by various markers from the data object or set.
2. Identifying or conceptualizing a number of finite states (parent class with sub-classes being the states)inclusive of the happy-sad path (error & success responses) makes it easy to handle various transitions between states as well the addition of new states is simply adding a set of transformations to map to this new state to its respective view.
3. Having a single source for state data emission in your views helps to keep a clean logical representation for the view transitions.

Android View State Machine Part 2: State data creation and pipeline was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In software development one of the most prevalent things is state management or simply put, knowing what to do and when to do it. The main focus of this series would be the presentational layer of an app and devise modelling of received data into a state object and interpretation at the view i.e managing the view in correspondence to emitted state.

Every user interaction event triggers a process, this could be an HTTP request, a CRUD operation, a scroll action, or simply launching a new activity. It’s very important to note that each process can lead to a new state.

A state is the set of values of all variable aspects of the particular system under concern at an instant in time. i.e the remembered information is called the state of the system. “Stephen Kurtzman PhD”

A finite state machine is an abstract machine that can be in exactly one of a finite number of states at any given time. “Wikipedia”

It’s safe to say, that when building screens in our apps, whether we choose to define finite states for these screens or not they already exist and how we access them or group such state-based data is important to both the sanity of the app and that of other developers involved, as well as guarding against irregular transitions or leaks in state.

The above diagram shows a typical applications state lifecycle or as we like to call it a “flow”. Each state represents either the presence of a certain type of data or the absence of it, and we would have associative views to show the user the current state of the app, which could be a progress bar for the loading state, an error message/screen for error state or a scrollable list for depicting a successful data load. Representing this data in our code in concise and clear fashion is important as it helps us to successfully separate and group operations particular to each state.

The snippet above represents a general state overview of what our diagram tries to represent. Defining a class to represent finite states in our Views is important because this helps us group operations to perform on emittance of a particular object ViewState, rather than checking across wide form factors of data variables and have a “guess” as to what state the application is in.

After creating our Abstract state model, in our fragments or activities, we would have a resolver (usually a when or a switch case statement) that would match functions or grouped procedures to each emitted state. In other instances the states would be mapped to a Viewholder or widget and we would emit a StatefulViewObject and when resolving in the View we would just inflate the view object, we would take a look at this in the next part of this series.

Let’s see how we would put this above illustration into practice.

In the above sample, we have a method that loads a list of data characters the CharacterToUIMapper() is responsible for mapping the received object into the supposed ViewState for emission to the view. The function CharacterToUIMapper() would check the response gotten from the loadCharactersUseCase() and then push the relevant ViewState object into the liveData .

Subsequently after emitting our ViewState object, we would receive it in the view, and depending on the object the appropriate function would then populate the associated view.

Finally…

Managing states and view hierarchies are one of the things we find ourselves consistently doing in android app development, it’s better we define bounds and set rules to our views and what state would be associated with them. This not only makes debugging problems easier but also makes adding extra view logic/state a run in the park. Whether we choose to explicitly define our states, it doesn’t stop the states from being present.

Android View State Machine part 2: State Creation & Pipeline

Android View State Machine Part 1 was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

One thing about growth and learning is it takes a lot of effort to learn something new, we wake up with great ideas about things we want to be in life, things we would love to do but when the time comes to sit down and do the work, we easily find excuses to put it off. Most people would call this procrastination, but it most likely is a fear of success(Achievemephobia).

Now we can define success like many things :

1. We could say success is the completion of that which was aspired for
2. A feeling of self-fulfillment and peace.
3. Gratification in one’s life or career

So why then would we say someone is afraid of success when it is what we all want from life, or what most people want out of life I mean if we work hard every day what else would be the justification if not to achieve this?

Let’s retrospect a bit here, we have spoken about success so how can we then be afraid of it?

Procrastination is the fear of success. People procrastinate because they are afraid of the success that they know will result if they move ahead now — Denis Waitley

How can I be afraid of what I want? to be honest, fear of success is not about being afraid of what we want, it stems as being afraid of our inability to handle the state of success, the responsibilities that come of it.

Because success is heavy, carries responsibility with it, it is much easier to procrastinate and live on the “someday I’ll” philosophy”. — Denis Waitley

A human mind is a wonderful machine that lets us create glimpses of how our life could be by carefully grafted mind movies, imaginations or as some might say daydreaming. These dreams are what later on become desire turned passion and fuel our motivation to work, learn and build to achieve our goals and thereby achieving success but there’s a catch.

These same daydreams can as well end up putting pressure on us when our growth is slow and we see others moving to the levels we are only attaining in our mind’s eye, we get to a point where it’s easier to put off our tasks than to work on something that is no longer giving us that satisfaction of getting close to our dream. We become more comfortable living in our minds with the comfort of saying “someday I will have this” without actually putting any more effort.

The fear of success most times manifests as a feeling of not having enough skills to pull through our goals, we feel as though we only came this far because we were lucky or we had to work super hard, most times that’s not the case, this kind of manifestation leads people to not try to grasp their goals or aim too high, this fear keeps people working jobs they are not happy with simply because they think they don’t have the skills or brains to get or be somewhere better.

In mainstream media, this manifestation is known as imposter syndrome, where the individual no matter what has been achieved will always feel they have fewer skills or knowledge than they do.

Outlining and defining a section of the problems we may experience leads us to the 1%. Now the 1% is simply a method to help stave off procrastination and the subtle fear of us not being able to achieve our dreams which might be on top of a mountain of things to do.

Little bites of a cake will result in a finished cake

The 1% is doing the littlest or smallest possible task, within our goal or set of task, most times looking at a huge pile of work can create a sense of fearful apprehension to the point where we let go and do nothing, but when it seems small it’s easier to get it done, and we still get to feel good about it.

Every time we do 1% of the work required we get closer to our personal goals, it’s better to do a tiny piece of work or self-improvement than doing nothing at all.

How do we start?

1. Make a high-level list or write down what you want or what you aim to achieve
2. Create another list that would serve as a breakdown, all the steps that need to be taken to achieve this (if this is difficult or you find your self skipping it, you can add one item of the break down per day or 3 hours)
3. Now every time you take a task if it gives you that feeling of maybe I should do it later, then start thinking about the smallest piece of work you can do with that task and quickly do it, then set out what’s left. Now the piece of work you successfully did is your 1%.

Doing your 1% every day might not seem like much, but after a month looking back, you would have something to smile about instead of pushing it forward and looking back and have nothing to show.

Also, something very important to note, planning for your next day before you sleep, helps your brain prepare you mentally for the stress of the next day, this greatly reduces your chances of procrastinating towards tasks set out for the day.

Keeping a list of important things you need to get done for the day is super important even if it would include mundane things like laundry, dishes. Create these lists before going to bed or at least mentally make this list, every time you tick of an item the next day, you feel better than you did something of your day and finished what you planned for that day, I mean we still need our little wins.

After working on a multiplatform library which builds a .framework and .aar artifact, I came to the realisation that there are a lot of nifty things which are included for us in kotlin that most of us never really knew about.

One thing about working on a multiplatform project is you have to be careful about the libraries you use, and it is best to stick closely to what is offered by the kotlin team. So when I had a situation where I needed to serialize JSON which should supposedly be for the both platforms(android & ios) I had a problem on compiling my code for ios. That’s when I did a bit of digging around and found out about the Kotlinx Serialization library. To be frank I never knew about it, so this post is basically for people like me who didn’t know of it’s existence.

First of according to the kotlinx.serialization repo, this is a compiler plugin which produces visitor code for classes and has a runtime library which uses generated code to serialize objects without reflection.

The fact that this does not use reflection is a big plus in app performance, to learn more about reflection overhead you can checkout this excerpt.

Setting up your project to use the plugin is quiet simple, but I will include a complete setup for both android projects as well as multiplatform projects. But feel free to check out the Kotlinx.Serializer repo for instructions on this and more.

One small hiccup on the multiplatform serialisation setup is the need to add this dependency under the native dependecy section of your gradle script.

implementation org.jetbrains.kotlinx:kotlinx-serialization-runtime-native:0.9.1

SETUP GRADLE EXAMPLE

For multiplatform:

For Android:

Serialization

Serializing is done quite easily, for one you would need to annotate the intended class with the @Serializable annotation as below:

Note: This can as well work with data classes.

Now to actually use this in action let’s take an example of how to convert a JSON to object and back

The ease and simplicity which the kotlinx serializer helps us to convert objects in a clean way is absolutely amazing.

Two more annotations to note are transient and optional. Using transient will have the serializer ignore that field and using optional will allow the serializer not to break if a field is missing, but at the same time a default value will need to be provided.

Android Use Case for Retrofit

For those who would like to as well use this library in android, Retrofit 2 has an adapter for converting JSON responses to objects. The adapter can be found here. Some Sample code of adding the adapter

Assuming your class already has the required annotations, after making a request this should serialise your class into the required object.

All in all, the kotlin serializer is a wonderful addition to any project and makes serialization a painless process when you want to save objects as a string or parse them into other data structures. Here is a sample repo for the android setup with a small(non-architectural) working example:

smilecs/kotlinxRetrofit

Here is the official Serializer repo and as well the retrofit adapter

• GitHub - Kotlin/kotlinx.serialization: Kotlin multiplatform / multi-format serialization
• JakeWharton/retrofit2-kotlinx-serialization-converter

Kotlinx Serialization was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

While working with Architecture components, I noticed the great ease of getting a response from my repository(API) whenever data is available, but this breath of fresh air also brought about a bit of pollution.

Now for which ever architecture design be it MVVM or MVP, we usually would want our view to interact with the repository through the ViewModel so as deliver latest updates if something(configuration change) where to happen to our activity. The problem I noticed was I was having to do almost the same number of checks every time I received a response from the server. These checks include:

1. If response.body() is not null.
2. If no exception is thrown on the onFailure() method.
3. Having to do checks on my view if an exception was thrown so I handle it else I display my data.

Now if you come to think of it, these problems where already existing even before the conception of Architecture Components, but they just became more obvious I think. Also when I receive an update to my observer on the onChangeListener I ended up having to do so many checks within that listener or before I set the value to my live data, which still kept a hole on how do I retrieve my errors so I can give the user feedback on the view.

So I thought of abstracting the whole process from the network requests callbacks to even my data models to use a wrapper then also modified my Observer so it could return custom exceptions which I could use to notify the user of errors on their request.

Now note these are only done for long running network processes and probably this might not be the best approach for some other use cases.

API Concerns

So first of all I thought of simplifying my retrofit callback method by implementing the Callback<T> interface and providing my own implementation which would handle the error checks and make sure it only delivered actual processed data. To do that we need to first write a ApiCallback.java class which implements the retrofit Callback<T> class.

So this class handles error cases, success and exceptions then delivers a result depending on what method is executed. So invariably this reduces some “if checks” we would always have to repeat. Next we apply this class to our retrofit call. Note to make the error handling seem less I created a special model which I would use with my LiveData instance, this model has only two properties which are a Generic data type and an Exception.

public class DataWrapper<T> {
    private Exception apiException;
    private T data;
}

For brevity I used the lombok plugin which auto generates a getter and setter kind of like Kotlin. This above method is used as a wrapper for all my objects that will be observed for a change regarding api calls and feedback.

Now that we have our DataWrapper, let’s go on ahead and create a GenericRequestHandler to take care of logic which will be commonly used for api calls.

After creating this class, all we need to do is extend the class provide an implementation of the makeRequest() method, then call doRequest() which would return a LiveData of the Generic type passed into the class.

So now I extend my GenericRequestHandler and override makeRequest() to .return a retrofit Call, then the AuthRequest() method calls and returns a LiveData object gotten from the inherited doRequest() method.

Now we can see how abstracting our request logic gives us a cleaner code base, and keeps us from repeating the same things over again especially when it comes to error handling.

View Concerns

Now to make life easier for myself yet again I created a custom Observer which returns an exception or a success.

Now after defining our ApiObserver we can go ahead and put the pieces together in our view.

Now it may seem like a lot of code to write at first but the benefits accrue over time where you don’t have to repeat your self with mindless if checks and exception/error handling both from the retrofit calls all the way to displaying an error in the view.

Error handling is an important process in app development especially when it comes to api calls, but when you keep repeating multiple checks it can get tiring and most times we end up leaving important checks out.

Also as a jumper starter you can checkout this library I wrote that helps with error handling and returning LiveData together with exception propagation to the view as described in this post.

Thanks for reading do well to leave your comments on any questions you might have.

Concise Error Handling with LiveData and Retrofit was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some time back, I started working on an eccommerce app called shop440, so as usual the first choice is to define the architecture and I decided to go for MVP(Model View Presenter). I chose this architecture solely because it would allow me add new features without worrying about breaking existing code and changing the view just meant having to re-implement my interfaces and everything works as good out of the box. I chose to use Realm because of it’s reactive nature and pairing that up with LiveData gave me a true feedback centric app design, where I not only get notified when a retrieval from my db is completed but also when an insert operation is done. Also using Kotlin and experimenting with extension functions as a wrapper for RealmDb & LiveData seemed like a nice idea as well.

First off here’s an excerpt from their official site about Realm:

Realm Database is an alternative to SQLite and Core Data. Thanks to its zero-copy design, Realm Database is much faster than an ORM, and often faster than raw SQLite.

Firstly you need to setup your project to use Realm and LiveData I won’t be going into this with this post. But you these links to get detailed information on how to setup your RealmDb and Live Data. After installing realm you need to initialise it in your application file(if not already available, create a class and extend Application) then do Realm.init(this).

For me, one of the best defining features of Realm db is the fact that I can store my objects as is. So lets not go out of scope of our e-commerce “add to cart functionality”. First off we define our model that will be stored locally every time a user add’s an item to cart.

Now as you noticed this is a standard kotlin class with a few exceptions:

1. We had to declare the class as open because kotlin by default declares all classes as final, of which realm needs the classes to be public so it can inherit from it.
2. We are using a secondary constructor so realm will be able to create a default instance of this class without values.

If you noticed we are extending the RealmObject(), what this means is the class is managed by Realm and all write operations on the object after creation are persisted to the database.

Like I said earlier we will be using an MVP architectural pattern, so in the current project we have this file structure for the product section:

Don’t worry this file structure is not compulsory, it’s just easier to understand in an MVP perspective this is where we start getting technical. So our desired interaction is the user comes into the selects a product and wants to make a purchase or add to their shopping cart. They click a button saying add to cart, now the desired interaction on button click is for us to push the item into the database then update the UI with the changes, simple right?

For our Realm objects to work with LiveData we need to create a wrapper for our realm instance which would expose LiveData properties.

Now a distinct feature about Realm db is the fact that it was built to be reactive, so what we would normally do is to add ChangeListeners for every realm query so we could update our UI when the query is resolved. But with our LiveData wrapper all we need to do is to add a single ChangeListener to the current realm instance being used by the ViewModel (we’ll get into this shortly) then set the data to the LiveData instance so all components observing it will be notified and update themselves.

If you have gone through the android developer site on the architectural components you would be familiar with the ViewModel, a brief primer: The ViewModel manages and stores UI related data in a lifecycle conscious way. So we can safely update our UI’s without fear of the view being destroyed or no longer available when dealing with asynchronous processes, which is what you might experience when using the realm change listener and an operation returning after the view is no longer available in most cases this could be a source of memory leaks when the listener has a strong reference to the holding activity.

Before we proceed, with our structure we need to create a way to return our realm queries as LiveData() . Now when you run a query on Realm it returns either a RealmResults<T>() or E , what we need to do is convert those objects returned into a LiveData() object. Remember the wrapper we wrote? well we are going to use that but with a little bit of kotlin magic. So we are going to create an extension function off of a RealmResults<T>() object. Now if your not familiar with kotlin extensions check this link.

Create a class probably call it RealmDao, and add the snippet below. Note you don’t need to declare an opening class block, in reality these extension functions are similar to static methods but they are built of the calling object.

Now that being done we can create our KartDao (or CartDao but since it’s kotlin i’ll go with the “k”). So our KartDao is going to house all our realm queries which will be made via our ViewModel. For simplicity lets just do one query for now.

The above method makes a realm query to get all items in the cart and converts the result to LiveData using the extension function we created earlier. If you look closely you’ll see this query is asynchronous so anytime it returns it executes the ChangeListener then sets the value to LiveData which notifies all observers to update. If this seems a bit confusing take a step back and go over the extension function and look at how the ChangeListener is triggered.

Now we need to make our KartDao class an extension of the realm object so anytime we have an instance of the realm object we can easily access the db queries in the KartDao class.

For the KartDao for operation on the realm:

So our RealmDao class will look like the above. It’s not really a must to make our KartDao class an extension, but if it makes it easier it doesn’t hurt.

Now for our ViewModel which is practically the glue, take note we haven’t created our ViewContract which serves as an interface between the view and the presenter in terms of an MVP architecture, but we’ll get into that shortly. For simplicity it’s advised that all database operations including the realm wrapper and extension function to be place in a single package called dao, and each ViewModel depending on their use cases should be place in the activities respective package.

Now for our process I have a kart package which contains my ViewModel and the presenter/view contract for the activity.

Like I said earlier the ViewModel will manage it’s own instance of Realm so when the activity/fragment(lifecycle owner) is no longer available it will release it’s hold on the instance of that realm.

Another thing you need to take note of is adding the open keyword to the class because when creating an instance of this class an abstraction is created which tries to inherit from it, and kotlin classes being final by default will cause this process to fail. Our getKartData() method returns a LiveData object which will be observed by our presenter and when changes occur the presenter will alert our view and return data to it so our view can update its UI.

For our presenter we first define our Contract class which our fragment and presenter will implement. The contract serves as a basis of communication between the presenter and the view.

Now our Contract is created lets make our presenter and implement the specified behaviour.

If you look at the top part of the file we use a method from the view which returns an instance of the ViewModel for us that lets us make requests to our DAO.

Now lets look at our fragment(View) and see how this all fits into one place. I’ll break this into multiple parts so we can have context on all the moving parts.

The first part of the fragment has us implementing our KontractView, initialising our presenter and also creating our ViewModel.

This part overrides the onKartLoaded() interface which is called by the presenter when the LiveData observer returns data.

As per our implementation you can see that the ViewModel is created in the view(activity/fragment), the presenter holds an instance to the ViewModel returned by the view and uses that to make requests to our dao repository.

That’s a brief primer on using realm with mvp implemented with kotlin.

Using Realm with Kotlin and LiveData was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

When doing localisations for apps we have a couple of options which include

1. Screen size
2. Language
3. Mobile Country Code

The most common one’s ever used are Screen size(dp/sw) & Language(en,fr, etc), while Mobile Country Code can be a very efficient way to select resources based on what country the user is in. This allows you to tailor features to your users countries. Here’s a link to the android resource on localisation, there specifies a table which shows how resources are selected based on precedence.

According to the table above you can see that android takes the MCC(Mobile country code) & MNC(Mobile network code) into consideration first in resource selection before it takes other parameters into consideration.

Now you may be asking why you should consider using mcc or mnc when you can already use screen density pixels(dp) and region to define resources. Well using the mcc code allows you to target a particular resource or even feature(build flavours) by country since a countries mcc is unique to it. For me this just helps me with an easier way to segregate my resources and image drawables, incase am using an image that might be offensive in a particular country or I need to display various currency symbols, the possibilities are endless. Combining mcc and resource alias is a very beautiful way of segmenting your ui resources.

If for any reason you need to access the current mcc of a country you can easily do so using the TelephonyManager

TelephonyManager telephonyManager = (TelephonyManager) App.getInstance().getSystemService(Context.TELEPHONY_SERVICE); //gets the country mcc code                                    String countryISO = telephonyManager.getNetworkCountryIso();

/*gets the mcc appended with the mnc. Note that mcc is always the first 3 digits returned with this method so to get the mnc you can just split the String or get the chars from the 3rd index to the last.*/

String countryMnc = telephonyManager.getNetworkOperator(); 

Android Localisations with Mobile country code was originally published in AndroidPub on Medium, where people are continuing the conversation by highlighting and responding to this story.

CustomViews are always seen like a tailed beast, especially when you check the developer site on how you can create your custom view widgets, you see a lot of things that don’t really do what your looking for. Most of the tutorials on the developer site for creating custom views rely on you drawing your own layout which can be quiet confusing and difficult especially when you think of how to get a reference to the objects you draw. Here is an easier way to quickly get you through a custom view and still satisfy your ui concern.

One thing you need to know about creating a custom view is the FrameLayout is your friend. This ViewGroup isn’t commonly used by many developers especially since its hard to understand its role in the view heir achy well for one FrameLayout is one of the most convenient views to extend and start hacking away your custom widget. Below is an example of what we are trying to achieve.

https://youtu.be/PqYy0TG9_QY

STEP 1:

Create a new java file lets name it “Custom.java”, extend the FrameLayout and override the necessary constructors.

public class RevealView extends FrameLayout{
 protected boolean toggle;
 protected Drawable lessArrow =    getResources().getDrawable(R.drawable.ic_expand_less);
 protected Drawable moreArrow =  getResources().getDrawable(R.drawable.ic_expand_more_white);
 private FontTextView topBarText, bottomBarText;
 protected View topBar;
 protected ViewGroup bottomBar;
 protected ImageView toggleBottom;

    public RevealView(@NonNull Context context) {
        super(context);
    }

    public RevealView(@NonNull Context context, @Nullable AttributeSet attrs) {
        super(context, attrs);
    }

    public RevealView(@NonNull Context context, @Nullable      AttributeSet attrs, @AttrRes int defStyleAttr) {
        super(context, attrs, defStyleAttr);
    }
}

STEP 2:

Lets create our xml layout file, this is where all the construction will take place. So for this tutorial we will create an Accordion which reveals extra content on touch. So head over to the res folder and create our custom.xml layout file. Now before you add the xml code you need to download and add two icons to your drawable folder, 1. an arrow facing up and 2. the other facing down. You can get them from the google material design icon pack

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
              xmlns:app="http://schemas.android.com/apk/res-auto"
              android:orientation="vertical"
              android:layout_width="match_parent"
              android:layout_height="wrap_content">
    <RelativeLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:background="@android:color/holo_blue_dark"
        android:id="@+id/topBar"
        android:paddingTop="8dp"
        android:paddingBottom="8dp"
        android:orientation="horizontal">
    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:id="@+id/top_bar_title"
        android:layout_marginLeft="12dp"
        android:textSize="16sp"
        android:textColor="@android:color/white"
        android:layout_centerVertical="true"
        />
        <ImageView
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:id="@+id/toggle_button"
            android:src="@drawable/ic_expand_more_white"
            android:layout_marginRight="12dp"
            android:layout_centerVertical="true"
            android:layout_alignParentRight="true"
            />
    </RelativeLayout>
    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:id="@+id/bottomBar"
        android:visibility="gone"
        android:animateLayoutChanges="true"
        android:background="@android:color/holo_blue_light"
        >
        <TextView
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:layout_margin="12dp"
            android:id="@+id/bottom_bar_text"
            android:textColor="@android:color/white"/>
    </LinearLayout>


</LinearLayout>

If you look closely you will notice the last ViewGroup which is a LinearLayout we are hiding the view by setting visibility:gone just put this in your head as a side note we will come back to this view later.

STEP 3:

So here’s where the fun begins, you know all those properties you set on Views in your xml file? Well we are going to define some for our customView. To do that head over to the res directory then look for a folder called values there should be a file called attrs.xml in there if its not available then create it in other words the full path your looking for should be res/values/attrs.xml. Now add this block of code to the file to define each property we can set from any xml file where we use our customview.

<?xml version="1.0" encoding="utf-8"?>
<resources>

<declare-styleable name="RevealView">
    <attr name="colorBar" format="color|reference" />
    <attr name="contentBar" format="color|reference"/>
    <attr name="barTitle" format="string" localization="suggested"/>
    <attr name="message" format="string" localization="suggested"/>
    <attr name="showMessage" format="boolean"/>
</declare-styleable>

</resources>

Your file should look like the one above. So lets briefly go through the properties:

1. colorBar: Defines the color for the header
2. contentBar: Defines the color for the body/content(the part of the view that will be visible or hidden by user interaction.
3. barTitle: Title text that will appear on the view header.
4. message: Body text of the bottoview
5. showMessage: A value that determines if the view should show the body container or not.

STEP 4:

Lets head over to our Custom.java and initialise some variables we’ll use in constructing our view.

public class RevealView extends FrameLayout{

//init properties
 protected boolean toggle;
 protected Drawable lessArrow =    getResources().getDrawable(R.drawable.ic_expand_less);
 protected Drawable moreArrow = getResources().getDrawable(R.drawable.ic_expand_more_white);
 private   TextView topBarText, bottomBarText;
 protected View topBar;
 protected ViewGroup bottomBar;
 protected ImageView toggleBottom;

public RevealView(@NonNull Context context) {
        super(context);
    }

    public RevealView(@NonNull Context context, @Nullable AttributeSet attrs) {
        super(context, attrs);
    }

    public RevealView(@NonNull Context context, @Nullable      AttributeSet attrs, @AttrRes int defStyleAttr) {
        super(context, attrs, defStyleAttr);
    }
}

Now lets create our helper methods that will control the view. Add these methods to the bottom of the file.

i.e I know we haven’t initialised these properties yet don’t worry we are coming to that, we don’t want null pointers.

public void setTitle(String title){
    topBarText.setText(title);
}

public void setMessage(String message){
    bottomBarText.setText(message);
}

public void setTitleBarColor(int color){
    topBar.setBackgroundColor(getResources().getColor(color));
}

public void setBottomBarColor(int color){
    bottomBar.setBackgroundColor(getResources().getColor(color));
}

Lets create our onClickListener so ever time someone touches the top bar the bottom part of the view is either revealed or hidden. You can add this to the bottom of the file.

Remember that view we added visibility:gone to? this listener will take care of enabling or hiding it.

protected OnClickListener setToggle(final ImageView toggleButton, final View bottomBar){
    return new OnClickListener() {
        @Override
        public void onClick(View v) {
            Drawable drawable = lessArrow;
            int visibility = View.VISIBLE;
            if(toggle){
                drawable = moreArrow;
                visibility = View.GONE;
                toggle = false;
            }else {
                toggle = true;
            }
            toggleButton.setImageDrawable(drawable);
            bottomBar.setVisibility(visibility);
        }
    };

}

Alright so now lets wrap them all together in an init method that the view will call every time an action is performed on it.

public void init(Context context, AttributeSet attributeSet){
    inflate(context, R.layout.reveal_view, this);
    topBar = findViewById(R.id.topBar);
    bottomBar = (ViewGroup) findViewById(R.id.bottomBar);
    toggleBottom = (ImageView) findViewById(R.id.toggle_button);
    topBarText = (TextView) findViewById(R.id.top_bar_title);
    bottomBarText = (TextView) findViewById(R.id.bottom_bar_text);
    topBar.setOnClickListener(setToggle(toggleBottom, bottomBarText));
    if(attributeSet != null){
        TypedArray typedArray = context.obtainStyledAttributes(attributeSet, R.styleable.RevealView);
        try {
            toggle = typedArray.getBoolean(R.styleable.RevealView_showMessage, false);
            bottomBar.setVisibility(toggle ? View.VISIBLE : View.GONE);
            toggleBottom.setImageDrawable(toggle ? lessArrow : moreArrow);
            if(typedArray.hasValue(R.styleable.RevealView_barTitle)){
                topBarText.setText(typedArray.getString(R.styleable.RevealView_barTitle));
            }
            if(typedArray.hasValue(R.styleable.RevealView_colorBar)){
                topBar.setBackgroundColor(typedArray.getColor(R.styleable.RevealView_colorBar, getResources().getColor(R.color.top_bar_color)));
            }
            if(typedArray.hasValue(R.styleable.RevealView_contentBar)){
                bottomBar.setBackgroundColor(typedArray.getColor(R.styleable.RevealView_contentBar, getResources().getColor(R.color.bottom_bar_color)));
            }
            if(typedArray.hasValue(R.styleable.RevealView_message)){
                bottomBarText.setText(typedArray.getString(R.styleable.RevealView_message));
            }
        } finally {
            typedArray.recycle();
        }
    }

}

Now we need to call the init() in our constructors defined earlier. Note that whenever a view is updated the constructors are called hence our method will be called and we can perform actions on our view.

public RevealView(@NonNull Context context) {
    super(context);
    init(context, null);
}

public RevealView(@NonNull Context context, @Nullable AttributeSet attrs) {
    super(context, attrs);
    init(context, attrs);
}

public RevealView(@NonNull Context context, @Nullable AttributeSet attrs, @AttrRes int defStyleAttr) {
    super(context, attrs, defStyleAttr);
    init(context, attrs);
}

Now you can see how we reference the attrs.xml file we created earlier to see which value is set and modify our view based on that. So lets add our view to a layout file and see if we did good. So lets create reveal_tester.xml To add your view just call the class name of the custom view and android studio autocomplete should help you with the full package name.

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
             xmlns:app="http://schemas.android.com/apk/res-auto"
             android:layout_width="match_parent"
             android:layout_height="match_parent"
             android:background="#EEEEEE"
             android:orientation="vertical">

            <com.example.RevealExample.RevealView
                android:id="@+id/reveal_view"
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:visibility="gone"
                app:showMessage="true"/>
</FrameLayout>

Now if you notice a namespace is added automatically for use app: we use this to access our custom properties, and we set the showMessage property to true so the body can be shown on default.

So head over to main activity and set this layout as the layout for the activity so we can test what we’ve done.

setContentView(R.layout.reveal_tester);

thats all no need for extra inits since the view widget is already taking care of click/touch interactions.

Thanks for reading, hope this helps you when creating more complex custom views for your android apps.

Remember that you can set the color of the title and body through xml or your java code where you declared the view. The function is part of the attributes we set on the attrs.xml and also the methods we defined earlier to setTitle() and etc.

Custom Views: make your android app stand out was originally published in AndroidPub on Medium, where people are continuing the conversation by highlighting and responding to this story.

public class Urls {   
 public static String BASE_URL = "https://shop440.com";    
 public static String NEW_USER = "/api/new_user";    
 public static String PASSCODE = "/api/get_passcode";    
}

Here’s the kotlin equivalent :

object Urls {
    var BASE_URL = "https://shop440.com"
    var NEW_USER = "/api/update_name_and_email"
    var PASSCODE = "/api/get_passcode"
}

Now usually this would not be a problem because it works as it should but when checking the translated code after compile you will see alot of inefficiencies also unless you will be accessing this class from another kotlin class else if you try to use it from a java class you may run into problems because apparently kotlin sees the properties as private hence it restricts access.I cannot say for sure now why you can access them within a kotlin file and not java but I’ll dig deeper and find out. Now to solve this problem just put a “const” keyword in front of your property and all solved and change the var to val i.e its supposed to be immutable after all.

const val BASE_URL = "https://shop440.com"