9 Patch Images

9 Patch images are stretchable, repeatable images reduced to their smallest size.

A NinePatchDrawable graphic is a stretchable bitmap image, which Android will automatically resize to accommodate the contents of the View in which you have placed it as the background. An example use of a NinePatch is the background used by standard Android buttons — buttons must stretch to accommodate strings of various lengths.

A NinePatch drawable is a standard PNG image that includes an extra 1-pixel-wide border. It must be saved with the extension .9.png, and saved into the res/drawable/ directory of your project.
NinePatch is a resizable bitmap resource that can be used for backgrounds or other images on the device. NinePatch class permits drawing a bitmap in nine sections. The nine patch images have extension as .9.png. It allows extension in 9 ways, i.e. 4 corners that are unscaled, 4 edges that are scaled in 1 axis, and the middle one that can be scaled into both axes

Intent v/s PendingIntent v/s Sticky Intent

Intent: Intent is a message passing mechanism between components of android, except for Content Provider. You can use intent to start any component.

---

PendingIntent:

A PendingIntent is a token that you give to a foreign application (e.g. NotificationManager, AlarmManager, Home Screen AppWidgetManager or other 3rd party applications), which allows the foreign application to use your application’s permissions to execute a predefined piece of code.
If you want a foreign application to perform any Intent operation at future point of time, then we will use PendingIntent.
Example: If you building a SMS app and you want to open your application when new message notification come. In that situation you have to use PendingIntent.

Difference b/w getContext(), getApplicationContext(), getBaseContext() and “this”

There are different ways of getting a context:

• this / getActivity()
• getContext()
• getBaseContext()
• getApplicationContext()

Maximum memory limit of each Process in Android

Android is a full multitasking system so it’s possible to run multiple programs at the same time and obviously each one can’t use all of your device memory.
For this reason there is a hard limit on your Android application’s heap size: if your application needs to allocate more memory and you have gone up to that heap size already, you are basically going to get “out of memory error”.
Heap size limit is device dependent and it has changed a lot over the years, the first Android phone (the G1) has 16MB heap size limit, now we have devices which have 32 MB / 48MB/ 64 MB/ 192 MB/ 512 MB heap size limit.
The basic reason is that new tablets and new phones have an high monitor resolution so they need more memory in order to draw more pixels.
However this limit is also too tight for a new kind of application. For example, think about a photo editor that is really memory intensive, probably 48MB of heap space isn’t enough for that.
For that kind of application Honeycomb and later introduced an option in the Android Manifest: “android:largeHeap=true” that give you a big heap space limit.
You have to use this option only if you are going to build an application that is really memory intensive and you really need it.

Why we use ViewHolder Pattern?

The ViewHolder pattern is a pattern that a developer can use to increase the speed at which ListView renders data. (i.e. Smooth Scrolling)
Your code might call findViewById() frequently during the scrolling of ListView, which can slow down performance. Even when the Adapter returns an inflated view for recycling, you still need to look up the elements and update them. A way around repeated use of findViewById() is to use the “view holder” design pattern.
A ViewHolder object stores each of the component views inside the tag field of the Layout, so you can immediately access them without the need to look them up repeatedly.

Without the ViewHolder Design Pattern

1. The first time Adapter was loaded, convertView is null. We’ll have to inflate our list item layout and find the TextView via findViewById().
2. The second time it was loaded, convertView is not null, good! We don’t have to inflate it again. But we’ll use findViewById() again.
3. The following times it was loaded, convertView is definitely not null. But findViewById() is constantly called, it will work but, it slows down the performance especially if you have lots of items and Views in your ListView.

RecyclerView vs ListView

The RecyclerView is much more powerful, flexible and a major enhancement over ListView.

1) ViewHolder Pattern

In a ListView, it was recommended to use the ViewHolder pattern but it was never a compulsion.
In case of RecyclerView, this is mandatory using the RecyclerView.ViewHolder class. This is one of the major differences between the ListView and the RecyclerView.

It makes things a bit more complex in RecyclerView but a lot of problems that we faced in the ListView are solved efficiently.

RecyclerView

If your app needs to display a scrolling list of elements based on large data sets (or data that frequently changes), you should use RecyclerView.

The RecyclerView fills itself with views provided by a layout manager. You can use one of the standard layout managers (such as LinearLayoutManager or GridLayoutManager) or implement your own.

The views in the list are represented by view holder objects. These objects are instances of a class you define by extending RecyclerView.ViewHolder. Each view holder is in charge of displaying a single item with a view. For example, if your list shows music collection, each view holder might represent a single album.
The RecyclerView creates only as many view holders as are needed to display the on-screen portion of the dynamic content, plus a few extra. As the user scrolls through the list, the RecyclerView takes the off-screen views and rebinds them to the data which is scrolling onto the screen.

Activity A->B->C->D Problems

Problems 1: If you are going from Activity A->B->C->D then pressing back button on Activity D will take you to the Activity A and pressing back button on Activity A will exit the app.

Solution 1: (Best Solution)

Intent intent = new Intent(A.this, B.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NO_HISTORY);
startActivity(intent);

FLAG_ACTIVITY_NO_HISTORY : The new activity is not kept in the history stack.
For example in above, Activity B will not be put into the history stack. The same we will do with Activity C and D. So when we press back button from Activity D, it will take us to Activity A because in history stack only Activity A is exist.
It is the best solution of the above problem because it will save some process to insert and remove Activity from history stack.
You can perform the same by modifying AndroidManifest.xml

<activity android:name=".B"
    android:noHistory="true"/>

String vs StringBuffer vs StringBuilder

String

• String is immutable (i.e once created can not be changed) object.
• The object created as a String is stored in the Constant String Pool.
• Every immutable object in Java is thread safe, that implies String is also thread safe. Thread safe means two threads can’t call the String simultaneously.
  String once assigned cannot be changed.
• Example:
  String  demo = ” hello ” ;
  // The above object is stored in constant string pool and its value can not be modified.

  demo=”Bye” ;
  //new “Bye” string is created in constant pool and referenced by the demo variable
  // “hello” string still exists in string constant pool and its value is not overrided but we lost reference to the  “hello”string

StringBuffer & StringBuilder

StringBuffer:

A thread-safe, mutable sequence of characters. A string buffer is like a String, but can be modified.

String buffers are safe for use by multiple threads. The methods are synchronized where necessary so that all the operations on any particular instance behave as if they occur in some serial order that is consistent with the order of the method calls made by each of the individual threads involved.