Tag Archives: android

The Activity Lifecycle of Android

The-Activity-Lifecycle-of-Android_1

In Android activity lifecycle, there are four activities that permit the activity to know a state has changed. They include creating, stopping or resuming an activity or destroying the process in which the activity resides.

Through activity lifecycle concept, web developers and android developers can learn to understand how your activity works properly when the user leaves and re-enters the activity. This means each callback permits you to perform specific work that’s appropriate to a given change of state. Doing the right work at the right time and handling transitions properly make your app more robust and performant. By having good implementation of the lifecycle callbacks will ensure your app keeps away from several things bellows:

  • Consuming valuable system resources when the user is not actively using it.
  • Crashing or losing the user’s progress when the screen rotates between landscape and portrait orientation.
  • Losing the user’s progress if they leave your app and return to it at a later time.
  • Crashing if the user receives a phone call or switches to another app while using your app.

In the next section, we will discuss the lifecycle paradigm and then we will explain each of the callbacks.

Activity-Lifecycle Concepts

The Activity class offers a core set of six callbacks to navigate transitions between stages of the activity lifecycle, such as: onCreate(), onStart(), onResume(), onPause(), onStop(), and onDestroy(). The system navigates each of these callbacks as an activity enters a new state.

Figure 1 presents a visual representation of this paradigm.

diagram

diagram

The chart above shows the activity states, the activity will be more complex depends on your requests. If you only implement a simple activity state, you don’t need to implement all the lifecycle methods. But, you still need to understand all of the lifecycle and implement those that ensure your app runs the way users want.

Lifecycle Callbacks

This section provides conceptual and implementation information about the callback methods used during the activity lifecycle.

onCreate()

This callback is the first stage when the system first creates the activity. The activity enters the created state. You perform basic application startup logic that happens only once for the entire life of the activity, in the onCreate()method. For example, your implementation of onCreate()might bind the data to lists, initialize background threads, and instantiate some class-scope variables. This method receives the parameter savedInstanceState, which is a Bundle object containing the activity’s previously saved state. The value of the object is null, if the activity has never existed before.

To understand fundamental setup for the activity, such as declaring the user interface, defining member variables, and configuring some of the UI. In this example, by passing file’s resource ID R.layout.main_activity to setContentView().

TextView mTextView;

// some transient state for the activity instance
String mGameState;

@Override
public void onCreate(Bundle savedInstanceState) {
    // call the super class onCreate to complete the creation of activity like
    // the view hierarchy
    super.onCreate(savedInstanceState);

    // recovering the instance state
    if (savedInstanceState != null) {
        mGameState = savedInstanceState.getString(GAME_STATE_KEY);
    }

    // set the user interface layout for this Activity
    // the layout file is defined in the project res/layout/main_activity.xml file
    setContentView(R.layout.main_activity);

    // initialize member TextView so we can manipulate it later
    mTextView = (TextView) findViewById(R.id.text_view);
}

// This callback is called only when there is a saved instance previously saved using
// onSaveInstanceState(). We restore some state in onCreate() while we can optionally restore
// other state here, possibly usable after onStart() has completed.
// The savedInstanceState Bundle is same as the one used in onCreate().
@Override
public void onRestoreInstanceState(Bundle savedInstanceState) {
    mTextView.setText(savedInstanceState.getString(TEXT_VIEW_KEY));
}

// invoked when the activity may be temporarily destroyed, save the instance state here
@Override
public void onSaveInstanceState(Bundle outState) {
    out.putString(GAME_STATE_KEY, mGameState);
    out.putString(TEXT_VIEW_KEY, mTextView.getText());

    // call superclass to save any view hierarchy
    super.onSaveInstanceState(out);

You can create new objects in your activity code and build a view hierarchy by inserting new Views into a ViewGroup. You then use that layout by passing the root ViewGroup to setContentView(). To get further information about creating a user interface, you can see the User Interface documentation.

Your activity does not reside in the Created state. The activity enters the Started State, after the onCreate() method finishes execution. Then, the system calls the onStart() and onResume() methods in quick succession. The next section explains the onStart()callback.

  • onStart()

The system demands this callback, when the activity enters the Started state. In order to make the activity visible to the user, you can use the onStart()call as the app prepares for the activity to enter the foreground and become interactive.

Besides, it also registers a BroadcastReceiver that monitors changes that are reflected in the UI. The activity does not stay resident in the Started state, the onStart() method completes very quickly and, as with the Created state. The activity will enter the Resumed state, once this callback finishes, and the system invokes the onResume()method.

  • onResume()

The onResume() system invokes the callback, when the activity enters the Resumed state. The system will once again calls as onResume() method, if the activity returns to the Resumed state from the Paused state. For this reason, to initialize components that you release during onPause(), you should implement onResume(). For example, you may initializa the camera as follows:

@Override
public void onResume() {
    super.onResume();  // Always call the superclass method first

    // Get the Camera instance as the activity achieves full user focus
    if (mCamera == null) {
        initializeCamera(); // Local method to handle camera init
    }

Furthermore, to initialize components that you release during onPause(), you should implement onResume(). Then, perform any other initializations that must occur each time the activity enters the Resumed state.

  • onPause()

To pause operations such animations and music playback that should not continue while the Activity is in the Paused state, and that you expect to resume shortly. There are several reasons why an activity may end up in this state:

  • A new, semi-transparent activity (such as a dialog) opens. As long as the activity is still     partially visible but not in focus, it remains paused.
  • Some event interrupts app execution, as described in the onResume() This is the most common case.
  • In Android 7.0 (API level 24) or higher, multiple apps run in multi-window mode. Because only one of the apps (windows) has focus at any time, the system pauses all of the other apps.

For example, the onPause()method is a good place to release it, if your application uses the camera. The following example of onPause() is the same to the  onResume() example above, releasing the camera that the  onResume() example initialized.

@Override
public void onPause() {
    super.onPause();  // Always call the superclass method first

    // Release the Camera because we don’t need it when paused
    // and other activities might need to use it.
    if (mCamera != null) {
        mCamera.release();
        mCamera = null;
    }
}

  • onStop()

The Stopped state is when your activity is no longer visible to the user and the system invokes the onStop()callback. You can also call your activity as onStop() when the activity has finished running, and is about to be terminated. Below is how an implementation of onStop() that saves the contents of a draft note to persistent storage:

@Override
protected void onStop() {
    // call the superclass method first
    super.onStop();

    // save the note’s current draft, because the activity is stopping
    // and we want to be sure the current note progress isn’t lost.
    ContentValues values = new ContentValues();
    values.put(NotePad.Notes.COLUMN_NAME_NOTE, getCurrentNoteText());
    values.put(NotePad.Notes.COLUMN_NAME_TITLE, getCurrentNoteTitle());

    // do this update in background on an AsyncQueryHandler or equivalent
    mAsyncQueryHandler.startUpdate (
            mToken,  // int token to correlate calls
            null,    // cookie, not used here
            mUri,    // The URI for the note to update.
            values,  // The map of column names and new values to apply to them.
            null,    // No SELECT criteria are used.
            null     // No WHERE columns are used.
    );
}

  • OnDestroy()

This is the final call that the activity receives. Usually this activity exists due to someone’s calling  finish(), or because the system is temporarily destroying the process containing the activity to save space.

The system may also call this method when an orientation change occurs, and then immediately call onCreate() to recreate the process in the new orientation.

 Activity State and Ejection from Memory

Instead the system kills an activity directly; it kills the process in which the activity runs, destroying not only the activity but also everything else running in the process, as well. Basically, when it needs to free up the RAM, the system will kill process. Moreover, a user can also kill a process by using the Application Manager under Settings to kill the corresponding app.

Table 1 shows the correlation among process state, activity state, and likelihood of the system’s killing

Likelihood of being killed Process state Activity state
Least Foreground (having or about to get focus) Created
Started
Resumed
More Background (lost focus) Paused
Most Background (not visible) Stopped
Empty Destroyed

 

5 ways to Make Users Download Your Apps

5-ways-to-make-users-download-your-apps

Many people predict that mobile is the future of information media, this is because people tend to spend their time watching their smartphone rather than watching their television or PC. Due to this, anyone who wishes to expand their business should have their mobile presence in the market by doing mobile development and creating apps that can represent their business and make their business transaction becomes more efficient. If you are a mobile developer, you can try several ways below to help your apps get more download.

  1. Advertisements and Incentives

Developing a smartphone device only is not enough without having proper online marketing strategy, since there are so many smartphone devices out there who are available for so many different categories. Your app works the same with your devices, it can get hopelessly lost for so many different reasons. So how can you make your app stands out among so many different app every day? Strategic marketing technique is one of the solutions. Social media, testers, forums, and eMails are one of the best ways for expanding the user base or you can offer promotions, incentives, and giveaways to attract more users. You can also combine all techniques, such as SEO, posting contents on popular blogs, PR posts, and others for introducing, popularizing, retaining, and increasing consumers.

  1. User’s Experience

Since satisfying your users is the main goal for, therefore it is important for offering a device which is flawless and tested for bugs and other issues because you user will never offer you a second chance to impress them once you disappoint them. Remember, in order to make users want to download your app, you must have no faulty designs, features, and complications, also you need to prevent creating any slow and difficult to navigate apps.

  1. Updates and Push Notification

Mobile is the most dynamic technology nowadays; this causes many app trends and apps market continuously changing and frequently introducing many innovative features and designs, therefore, it is highly recommended to update your device regularly with these changes for continuous user engagement, and win the competition.  Other smart way is by using Push notifications to inform users with new updates. Push notifications are a way to interact, inform, and attract users.

  1. App Reviews

Generally, app users will use app reviews to inform the users about your device, and act accordingly to reviews, comments, and ratings. Therefore, bad reviews, negative comments, and low ratings will send users away from your device.  The only way to get good reviews, comments, and ratings is by producing apps which deliver values and offer useful and user-friendly features.

  1. Useful Retail Apps Feature

Placing useful features on your device is one of the great ways which can improve your customer engagement. Don’t forget to use Push notifications to offer coupons, deals, and gift vouchers and inform consumers about these offers, new deals, events, discounts, updates, and new arrivals. Barcode scanning feature in your device can also help you creating better customers’ in store experiences and engagements , this will help your customers in terms of making decision, since your customer will get some useful information on the availability of stocks, prices, colors, sizes, and reviews.

PICASSO VS GLIDE (Advantage and disadvantage)

picasso-vs-glide

Currently, mobile developers keep looking for a new method to make image loading run faster. Today, we are going to see the difference between the two most popular image loader library, Picasso and Glide. Both of them may have their own advantage and disadvantage, even though they may look 90% similar. In fact, some resources said that Glide is Picasso-clone. Anyway in details, it is quite different. Especially in several ways below:

Import to Project

dependencies {
 compile ‘com.squareup.picasso:picasso:2.5.1’
}

 

Glide

dependencies {   
compile ‘com.github.bumptech.glide:glide:3.5.2’   
compile ‘com.android.support:support-v4:22.0.0’
}

 

Glide also requires Android Support Library v4, so bear in mind to import support-v4 to your project like above as well. Frankly, you basically need Android Support Library v4 in every single new-age Android project, so it should not be kind of problem for you.

Image’s Quality in Details

The image’s quality between the two may not be too different, but Picasso is better known that is has better image quality. As you can see on the images below, Glide has some hard pixels and is not as smooth as the Picasso one and it is difficult to find the straight way to change image resizing algorithm.

picasso

Disk Caching

In terms of default disk caching concept, Picasso and Glide are quite different. In the experiment below, the same Full HD image is loaded into ImageView with Picasso and Glide. When I checked the cache folder, it appears that Glide cached the ImageView-size (768×432 pixels) while Picasso cached the full size one (1920×1080 pixels).

picasso

If you see closer on the picture above, you will see the hard pixels described above is also there. In addition, if image is loaded in RGB565 mode, the cached image will be also in RGB565.

Moreover, other difference occurs when you try to adjust ImageView to the different sizes. Picasso will cache only single size of image, the full-size one while Glide acts differently, it caches separate file for each size of ImageView. You also need to download an image that has already been loaded if you need to load another size the same image before be resized to the right resolution and then be cached.

Anyway you could use this command to adjust its behavior by let Glide cache both the full-size image and the resized one.

Glide.with(this)            
.load(“http://nuuneoi.com/uploads/source/playstore/cover.jpg”)             .diskCacheStrategy(DiskCacheStrategy.ALL)            
.into(ivImgGlide);

 

The full-size image would be loaded from cache, resized and then cached, the next time image is requested to show on any ImageView. Due to this, Glide can load and show image faster than Picasso, while Picasso may take longer time to load images since it needs to be resized first before it is set to an ImageView.

GIF

Compared to Picasso,  Glide also has an ability to load GIP animation to a simple ImageView which makes it more interesting. However, if you would like to use GIF, you should use it wisely, since it consumes quite a lot of memory. Glide is also able to decode any local video file to a still image.

Furthermore, you can configure the way image appears with an animator (R.animator) while Picasso could do only one animation, fading in.