Android studio class application

Android Application Class

W hile Starting App development, we tend to miss out simple basic stuffs either by ignorance or by curiosity to build million dollar app. But, Hey! Why so serious !. Building a App is bit of Art ,bit of Engineering and frequently both.

Activity Life Cycle is stages of activity in run time, knowing these would save you from headaches while you dive deeper in development.

I have written a post that will help you to understand activity lifecycle in a practical approach. Check it out

Android Activity Lifecycle

Android activity lifecycle is first thing to be known as android developer. Here I’m sharing with you some facts and…

Application class is a base class of Android app containing components like Activities and Services. Application or its sub classes are instantiated before all the activities or any other application objects have been created in Android app.

You Don’t have to import or extend application class, they are predefined. We cannot change application class but we could give additional instruction to it by extending it. Refer here for more info.

Create a java class named SubApplication and Application as Superclass

By extending Application class you could get boilerplate code like this

Check in AndroidManifest.xml and set Application name to SubApplication that you created

Lets take a situation where we should know which activity is currently running and we have to use register network receiver in all our activities. To this we used to write same code in all the activities or write a base class and extend that class instead of extending AppCompactActivity.

We have Activity Life cycle in one hand and Application class in another, what sense they make? Well actually they do? Let’s look into it.

1. In application class create static Activity variable it is accessible from whole project.

2. Register Activity Life Cycle callback in onCreate method in application class. By this step we can get currently running activity in our app from mActivity.

3.Moving on to next, Create a Broadcast Receiver and write a method to check the internet connection. you can get the code here .

4. Register your broadcast receiver in Manifest File

But for SDK Above Nougat we need to register receiver and unregister in every activity we use programmatically or We can just register and unregister Commonly in Application class.

5. Create a Object for Broadcast Receiver in application class and Register it in onResume method and Unregister in onPause method.

Bit confused! Don’t Worry, Here is the Link to the files.

Thanks for reading out the article. Let me know if I have missed out something interesting so that I can be added. Be sure to clap/recommend as much as you can and also share with your friends.

Источник

Understanding the Android Application Class

The Application class in Android is the base class within an Android app that contains all other components such as activities and services. The Application class, or any subclass of the Application class, is instantiated before any other class when the process for your application/package is created.

This class is primarily used for initialization of global state before the first Activity is displayed. Note that custom Application objects should be used carefully and are often not needed at all.

In many apps, there’s no need to work with an application class directly. However, there are a few acceptable uses of a custom application class:

• Specialized tasks that need to run before the creation of your first activity
• Global initialization that needs to be shared across all components (crash reporting, persistence)
• Static methods for easy access to static immutable data such as a shared network client object

Note that you should never store mutable shared data inside the Application object since that data might disappear or become invalid at any time. Instead, store any mutable shared data using persistence strategies such as files, SharedPreferences or SQLite .

If we do want a custom application class, we start by creating a new class which extends android.app.Application as follows:

And specify the android:name property in the the node in AndroidManifest.xml :

That’s all you should need to get started with your custom application.

There is always data and information that is needed in many places within your app. This might be a session token, the result of an expensive computation, etc. It might be tempting to use the application instance in order to avoid the overhead of passing objects between activities or keeping those in persistent storage.

However, you should never store mutable instance data inside the Application object because if you assume that your data will stay there, your application will inevitably crash at some point with a NullPointerException . The application object is not guaranteed to stay in memory forever, it will get killed. Contrary to popular belief, the app won’t be restarted from scratch. Android will create a new Application object and start the activity where the user was before to give the illusion that the application was never killed in the first place.

So how should we store shared application data? We should store shared data in one of the following ways:

• Explicitly pass the data to the Activity through the intent.
• Use one of the many ways to persist the data to disk.

Bottom Line: Storing data in the Application object is error-prone and can crash your app. Prefer storing your global data on disk if it is really needed later or explicitly pass to your activity in the intent’s extras.

Источник

Android Application Class Example

Posted by: Archi Gupta in core February 1st, 2018 1 Comment Views

We all know there is an Application class in the Android API, that is usually used for maintaining global application state but how does it work? In this article, let’s explore it with the help of examples and discuss its advantages & disadvantages.

Table Of Contents

1. Introduction

Application class is a base class within an Android application, that comprises of different components such as Activity, Service, Broadcast Receivers & Content Providers. These components communicate with each other with the help of Intents, Callbacks & other methods. Often, components depend on other components, for eg: initiating an activity on a button click.

In an application, there is often a need of making data available to all the components. For example, data entered by a user, needs to exist somewhere to let other components consume it.

Now, where do we keep the data so that it’s globally available? One may use Intent to pass information between components, but it can’t be accessed by every component. Components go through a lifecycle, that means they are not always available to provide the data. We need something global, that can be accessed by any component at any time. The answer to the question is Application class , that serves the purpose of maintaining the global application state.

You can also create a custom application class and add it to Android Manifest file, that will instantiate the class when the application process starts. Let’s discuss this later in the article.

Now, its time to talk about the Callback methods available in the Application class.

2. Callback Methods

Here are the Callback methods:

onConfigurationChanged – void onConfigurationChanged(Configuration newConfig)
This method is called by the system when the device configuration changes, while running the application. When the configuration changes, only an Activity restarts ( OnCreate() is called, followed by OnStart() and OnResume() ), leaving the other components in the same state as they were before the configuration changed. The resource values are always up to date in this method, and can be retrieved by other components at any time.

See an example below where we check the device orientation.

onConfigurationChanged() example
onCreate – void onCreate()
This method is called when the application is starting, before any activity, service, or receiver objects (excluding content providers) have been created. Implementations should be as quick as possible (for example using lazy initialization of state) since the time spent in this function directly impacts the performance of starting the first activity, service, or receiver in a process. If you override this method, be sure to call super.onCreate() .

Signature of onCreate()

Put the logs in the OnCreate() method in Activity and Application Class. When you run the code, check the logcat and you will see that Application Class is called before any Activity.
onLowMemory – void onLowMemory()
This is called when the overall system is running low on memory, and actively running processes should trim their memory usage. While the exact point at which this will be called is not defined, generally it will happen when all background process have been killed. That is, before reaching the point of killing processes hosting service and foreground UI that we would like to avoid killing. You should implement this method to release any caches or other unnecessary resources you may be holding on to. The system will perform a garbage collection for you after returning from this method.

Signature of onLowMemory()

onTerminate – void onTerminate()
This method is for use in emulated process environments. It will never be called on a production Android device, where processes are removed by simply killing them; no user code (including this callback) is executed when doing so.

onTrimMemory – void onTrimMemory(int level)
When building the Android application, the one thing developer has to keep in mind is Memory. It is the most crucial part of the application process and a developer’s duty to check if there is any memory leak or if there is need to free up resources not used by application anymore. Denying this, may lead to unexpected killing of the application process by the system. This method is called when the operating system has determined that it is a good time for a process to trim unneeded memory from its process. This will happen for example, when it goes in the background and there is not enough memory to keep, as many background processes running as desired. You should never compare to exact values of the level, since new intermediate values may be added — you will typically want to compare if the value is greater or equal to a level you are interested in.

To retrieve the process’s current trim level at any point, you can use ActivityManager.getMyMemoryState(RunningAppProcessInfo) .

The different levels are:

TRIM_MEMORY_RUNNING_MODERATE level means the device is beginning to run low on memory but not killable.

TRIM_MEMORY_RUNNING_LOW level means the device is running much lower on memory and not killable. It is better to start releasing unused resources.

TRIM_MEMORY_RUNNING_CRITICAL level means the device is running extremely low on memory and the system will begin killing background processes.

TRIM_MEMORY_UI_HIDDEN level means the application’s UI is no longer visible, so this is a good time to release large resources that are used only by your UI.

TRIM_MEMORY_MODERATE level means the process is around the middle of the background LRU list and if the system further gives memory warning then there is a chance for your process to be killed.

TRIM_MEMORY_BACKGROUND level means the process has gone on to the LRU list and it’s a good opportunity to clean up the resources before user returns to the app.

TRIM_MEMORY_COMPLETE level means the process is nearing the end of the background LRU list, and if more memory isn’t found soon, it will be killed.

Note: This callback was added in API level 14. For older versions, you can use onLowMemory() .
registerActivityLifecycleCallbacks – void registerActivityLifecycleCallbacks (Application.ActivityLifecycleCallbacks callback). It allows you to handle state change of each activity in your program.

Signature of registerActivityLifecycleCallbacks
registerComponentCallbacks – void registerComponentCallbacks (ComponentCallbacks callback)
Add a new ComponentCallbacks to the base application of the Context, which will be called at the same times as the ComponentCallbacks methods of activities and other components are called. Note that you must be sure to use unregisterComponentCallbacks(ComponentCallbacks) when appropriate in the future; this will not be removed for you.

Читайте также:  Отправка смс расписанию android

Signature of registerComponentCallbacks
registerOnProvideAssistDataListener
Callback used Application.OnProvideAssistDataListener . You may know, there is a Now On Tap functionality in Android, that is visible by long pressing the home button. A small window from the bottom of the display, slides up to show you the relevant information. The information you get, depends on what you’re viewing on your screen at that time (for eg: Music app displays information about the song on the screen). To provide additional information to the assistant, your app provides global application context by registering an app listener using registerOnProvideAssistDataListener() and supplies activity-specific information with activity callbacks by overriding onProvideAssistData() and onProvideAssistContent() . It allows you to place anything, into the Bundle , you would like to appear in the Intent.EXTRA_ASSIST_CONTEXT part of the assist Intent.

In the example below, a music app provides structured data to describe the music album that the user is currently viewing.

onProvideAssistContent Example

unregisterComponentCallbacks – void unregisterComponentCallbacks (ComponentCallbacks callback)
The method removes a ComponentCallbacks object that was previously registered with registerComponentCallbacks(ComponentCallbacks) . The other callbacks unregisterActivityLifecycleCallbacks and unregisterOnProvideAssistDataListener does the same thing removing the corresponding object that was previously registered.

3. Creating the Application

Consider a scenario, where you have two screens that display the Game score. Up to date score has to be available on all the screens. This requires the Game score to be globally stored & available. In this example screens are two different activities: FirstScreen & SecondScreen; and the Application class (Global State) provides the most up to date score.

To create a custom application class, Application class needs to be extended and must be declared in the Manifest.

Let’s start building the application and see how code handles the application state.

3.1 The Activity File

This is the first screen.

This is the second screen.

This is the Custom Application class that extends Application Class .

3.2 The Layout File

These are the two layout files. I have used the recently added Constraint Layout for convenience. It allows flexibility in positioning and sizing widgets. For more info refer Constraint Layout.

Here we have the second layout for second screen.

4. Manifest

The manifest file provides the most important information about the application to the Android system, before it runs. It defines the structure and metadata of an application and its components.

5. Running the Application

See screenshots here. First Screen and Second Screen are the two game screens.

First Screen and Second Screen respectively

Now incrementing the score from First Screen and moving on to the next screen by pressing Next Screen button, will update the score on Second Screen.

Updated Score on Both Screens

6. Limitations

As we have seen above, putting the data in the Application class saves the overhead of passing it between objects. Besides this, if you store mutable objects in Application class, data might disappear or become invalid at any time. Also, there might be a possibility where your app may crash with Null Pointer Exception . The application object is not guaranteed to stay in memory forever, at some point in time, it will get killed. When the application restarts, it never gets restarted from scratch. Instead, a new Application object is created and starts the Activity , user was on before. It is better to store any mutable shared data using persistence strategies such as files, SharedPreferences , SQLite and so on.

To prevent data loss, use one of the following methods:

• Explicitly pass the data through Intents
• Store the global data in memory
• Perform Null check before retrieving the value of an object

7. Conclusion

We have now seen how to use global data in an application by using Application class. Despite of its usage, storing data in Application class is error prone and might crash your application, under certain circumstances.

Источник