Friday, 26 June 2015

Postman pattern

Postman Pattern is a improved Observer pattern specially for mobile phones. It deals with the problem that from the mobile phone, the observer could be not in the foreground when the data is coming from observable.

For this case, the observable acts like the postman, leaving the data (package) in the observer. When the Observer became visible again, it will check if it has some data (package) to be processed. If so, the data will be processed.

It includes the implementation for Android and some highlight for the source code, which is stored in GitHub here:

Friday, 5 June 2015

Adding Floating action button from Android design support library

Google released the Android design support library last weekend. It comes with some nice features to work Material design principles. Here I am going to explain how to use the Floating action button.

The source code of this project could be found here:

1. Integration
To integrate the library to our project, we just have to add the follow line to our build.gradle file:

compile ''

2. Adding the icon to the layout
Once the project has been synchronised, it is ready to add the icon. Here is an example of layout:



There two important things:
1. The main layout must be RelativeLayout, a layout which extends from it or any layout which uses layers. The FloatingActionButton must be the last element in the layout. This is because by using layers, one above the another, the order they are written in the XML file determines the superposition of the elements. This is, the last element is always the one on the top.

2. FloatingActionButton has been extended from ImageView, so it accepts src as parameters. To make the life easier, Google has released a set of icons that could be useful. They could be find here:

Just download the project and use the color and the size you like most.

3. Changing the color of the icon (Optional)
By default, the floating action button get the color from the accent color in the style. In my case, I am using Indigo. For more colours, check the Google design guide for colours.

To do so, the first thing is add the colours and the styles in the resources:
    <!-- Base application theme. -->
    <style name="Indigo" parent="Theme.AppCompat.Light.DarkActionBar">
        <item name="colorPrimary">@color/primary</item>
        <item name="colorPrimaryDark">@color/primary_dark</item>
        <item name="colorAccent">@color/accent</item>

    <!-- Indigo -->
    <color name="primary">#3F51B5</color>
    <color name="primary_dark">#303F9F</color>
    <color name="accent">#FF4081</color>
    <color name="text_primary">#D9FFFFFF</color>
    <color name="text_secondary">#D9000000</color>

Note that I am using the support library as it. If your minimal API is 21, you could use "android:colorPrimary" or so.
For more information about the theming for pre-Lollipop, check the Theming part of this guide:

Once this is done, just use the theme Indigo as the default theme:
    android:theme="@style/Indigo" >

Source code

More information

Wednesday, 3 June 2015

Android Interview questions

Here are a list of questions and possible answers that could be useful for the interview for Android developer.

Feel free to share them. I will try to update them over time.

1. How do you check if a specific value has been updated/set in Shared Preferences
Answer: With a rooted device or in a emulator, becoming superuser and then, check the follow folder:


There will be a xml file with the name of the shared preferences with all the values.

2. How do you know if an app is based on WebView or it is native
Answer1: With a rooted device or in a emulator, becoming superuser and then, check the follow folder:


If it is a web app, folders related with Web app will appears there. (Cache, SQL, etc)

Answer2: In the options of the developer, activate the option to show the design limits. If the app is native, all the elements of ui will have its own limits. Otherwise, there will a whole block of limits in the WebView element.

Sunday, 3 May 2015

250.000 visits reached!

I have started this blog on 7th April 2010, 5 years ago. In that time, the idea was start something quick and dirty, some kind of notes online to be found later, because at that time I was trying to solve a lot of technical problems but after solving them, I almost forget them immediately. The problem is when I found the same problem later, I was unable to find the same solution.

Since then, I have been posting things I found and it seems people like it. Some posts are just some solutions from StackOverFlow, and some posts are my own research about Android because the official documentation is a bit messy. (Still today they are quite messy, because most of them are just java docs...).

So, thanks everyone who made this possible. I will continue posting things I found and researched.

Correctly implementing OnActivityResult for Android

When the an activity launch another activity and it want to know the result of such activity, the best way to do it is using startActivityForResult and then, override the method onActivityResult to handle the result.

onActivityResult has tree parameters:

  • requestCode: integer. It is the number used to launch the activity. It must be unique inside an activity.
  • resultCode: integer. The result returned by the launched activity. By default the class Activity comes with RESULT_OK, and RESULT_CANCELED. The launched activity could specify any another integer for the result.
  • data: intent. It is optional. It could be empty if the launched activity has not specify any data.
By using the inherence property of Object oriented language that Java is, more and more an activity is inherited by another activity. In this case, both parent and son could override the method onActivityResult. So, there is a chance they share the same requestCode and even handle the same result code.

For this case, here is what I consider correct implementation of onActivityResult:

    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        switch (requestCode) {
                switch (resultCode) {
                    case (RESULT_OK):
                        // Result is ok for the activity.
                        // Do things in accordance
                    case (RESULT_CANCELED):
                        // Result has been canceled (the activity could be finished without
                        // passing correctly the data
                    case (MyResultActivity.OTHER_POSSIBLE_RESULT):
                        // The activity could set special results that should be public static final
                        // Handle it here
                        super.onActivityResult(requestCode, resultCode, data);
                switch (resultCode) {
                    // Here goes the cases for the another activity id
                        super.onActivityResult(requestCode, resultCode, data);
                super.onActivityResult(requestCode, resultCode, data);

The special thing that it has is by each switch, it implements the default case when it called the onActivityResult of its parent. This is the same way as say if a certain case cannot be managed by the son, ask its parent to manage it.

More information