Serializable vs Parcelable

Passing around Strings and Integers in between activities can be done easily using Intents via the putExtras and getExtras methods, but if we need to pass object references we need to serialize them first.

Java offers a simple solution : Just implement the Serializable interface and Java will make its best effort to Serialize this class. This is simple and avoids a bunch of boilerplate code but is very bad for performance especially when we have 100’s of objects (A realistic case).  The reasons why are as follows :

  1. Serialization uses reflection to learn the variables and method names. Reflection tends to be slow.
  2. Serialization also creates a lot of temporary variables thereby necessitates garbage collection,  Which again will lead to noticeable jankiness in the UI based on when the GC is triggered.

Android decided this was too slow for the purposes of Android and implemented Parcelable which explicitly spells out how and which values need to serialized.

Advertisement

Android-Swipe to refresh layout

 

I always wondered how the pull to refresh feature worked but never actually got around to experimenting with it. Finally getting around to it, I was honestly a little underwhelmed seeing how easy it was to implement the feature.  Android Support Library to the rescue.

Most of the heavy lifting is taken care of  by SwipeRefreshLayout in the support library. It can be declared in the layout file using the following declaration : 

<android.support.v4.widget.SwipeRefreshLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/swiperefresh"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
.
.
.
</android.support.v4.widget.SwipeRefreshLayout>

Marshmallow – Grant and Revoke permissions with adb

With Marshmallow waltzing into our phones soon, it comes with a new permission model.

To test your application permissions programmatically, you can use adb to grant and revoke the permissions.

Grant Permissions :

adb shell pm grant app-namespace android.permission.CAMERA

Example :

adb shell pm grant com.tout android.permission.CAMERA

Revoke Permissions :

adb shell pm revoke app-namespace android.permission.CAMERA

Example :

adb shell pm revoke com.tout android.permission.CAMERA
db shell pm revoke com.tout android.permission.WRITE_EXTERNAL_STORAGE
adb shell pm revoke com.tout android.permission.READ_EXTERNAL_STORAGE

Android Marshmallow Permissions

This article is a list of questions that I asked myself/others while trying to implement the new permissions model on android.

1) Do I need permissions to access the database created by the application?
– The short answer is no. We are not trying to access any user content. Unless you are trying to specifically create a database on a sd card.

2) Do we receive any callbacks when the user dynamically revokes permissions?
– No. See the link for the answer

3) When trying to work with files, Can I write to my own folder without permissions?

Will look into it

4) Is there a way I can avoid the if check every time?
– No. we need to do the check every time. I am currently trying to look for a design pattern that can address this issue.

Custom Views part-1

I won’t be covering why custom views are important or why you should be using custom views there are many blogs that have done a great job doing that. In this blog, I want just get down to the essentials of what you need to get started writing a custom view.

In part-1, let’s get started with a hello world experiment and no I won’t extend an already existing widget for this example. I get so annoyed when people do that because almost always those examples don’t explain measuring or drawing.

The very first thing to do is your custom view has to extend the View- The building block of very thing android.

In this example, let’s draw a circle.

public class CircleView extends View {
   ...    
}

To extend a view, we have to implement the constructors and we have four options

public CircleView(Context context) {
    super(context);
}

public CircleView(Context context, AttributeSet attrs) {
    super(context, attrs);
}

public CircleView(Context context, AttributeSet attrs, int defStyleAttr) {
    super(context, attrs, defStyleAttr);
}

public CircleView(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) {
    super(context, attrs, defStyleAttr, defStyleRes);
}

So which one do we implement? I have never used the fourth one to date (was added with API 21), so I won’t be covering it. If you are just using the view for your own app and not building a library then you will be fine just implementing the first and second constructors.

That now brings us to the next question. What are the variables in the constructors. 

  1. Context: If you need explanation regard the context, then maybe custom views are not for you just yet.
  2. AttributeSet: According to google, controlling the view from XML is what separates the poorly written custom view from an exceptional one. AttributeSet lets you do exactly that. I will expand on this topic more in another blog post.
  3. defStyleAttr: more about this in the next post

So which constructor is called when?

Single-Parameter constructor: 

public CircleView(Context context) {
    super(context);
}

Called when we are trying to instantiate a view from the code. A typical example would look like the following:

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    CircleView circleView = new CircleView(this);
    ... rest of the method implementation. 
}

Two-Parameter constructor:

public CircleView(Context context, AttributeSet attrs) {
    super(context, attrs);
}

Called when we declare a view in the xml and instantiate it through the code. A typical example would look like the following:

<com.srikanth.CircleView
    android:id="@+id/customCircle"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content" /></pre>

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    CircleView circleView = findViewById(R.id.customCircle);
    ... rest of the method implementation. 
}

One interesting aspect to note is, when you are declaring the custom view in XML, you have to use the full path to your view. This is how we are telling the compiler where our view is located.

Async Task and Life cycle events

Async task is a way by which android enables off-loading long running tasks like accessing the network or writing to a db. The main purpose being to keep the main thread, which runs the UI,  as free as possible so that UI does not lag and feel janky.

How Async task works and the various methods of the Async task is covered by the android dev site in a great depth and I would like to cover how life cycle methods affect async tasks.

Consider the following scenario :

User wants to download a file from a server  and activity offers a minimalistic UI with just a button to start the download and a textview to update the current download status.

The activity spins off an async task to handle the download operation and the onPostExecute will update a textview with the result. After the download has started if the user rotates the screen (or any other significant event like changing the font size) , android will recreate the activity and the older activity runs through all its life cycle events and is destroyed. Now when the async task returns no longer has the right reference to either the activity which started it or a reference to the TextView where the result has to be populated.

This can lead to unexpected behavior like losing the progress of async task or even worse the recreated activity can start another async task with the same download.

The old way of addressing this problem :

Before API 13, overriding the onRetainNonConfiguration and getLastNonConfigurationInstance() did the trick. We save the reference to the async task in onRetainNonConfiguration() and return it in getLastNonConfiguration(). But these methods are now deprecated.

Recommended way of addressing the issue : 

We can manage the object inside the fragment by using the fragments method setRetainInstance(true).

The setRetainInstance method holds on to the reference of the fragment even if the activity is destroyed  and is managed  and guaranteed to work by the framework. This way we can create a view less fragment which spins off the Async task on behalf of the activity and has call backs to the activity. This way we do not hold on to any reference to the view that is being destroyed.

Pasting code in word-press is a pain, for now please check the github link for the code samples, while I look for alternate solutions.

https://github.com/srikanth569/AsyncTaskLifeCycle

SK

 

Work in progress

To start with one of my favorite quotes

A good programmer knows they are done, not when there are no more features to add but when there is no longer anything to strip out.

Don’t quite know the source of it but, I still remember it since I first read it 5 years ago, at least a variation of it.

So this blog, as the title reads is a work in progress narrative (rant mostly) of a programmer trying to improve his coding abilities. Over the course of time, will update this blog with some (hopefully) interesting code / articles.

SK