Application components are the essential building blocks of an Android application. These components are loosely coupled by the application manifest file AndroidManifest.xml that describes each component of the application and how they interact.
There are following four main components that can be used within an Android application −
Sr.No
Components & Description
1
They dictate the UI and handle the user interaction to the smart phone screen.
They handle background processing associated with an application.
They handle communication between Android OS and applications.
They handle data and database management issues.
Activities
An activity represents a single screen with a user interface,in-short Activity performs actions on the screen. For example, an email application might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. If an application has more than one activity, then one of them should be marked as the activity that is presented when the application is launched.
An activity is implemented as a subclass of Activity class as follows −
Services
A service is a component that runs in the background to perform long-running operations. For example, a service might play music in the background while the user is in a different application, or it might fetch data over the network without blocking user interaction with an activity.
A service is implemented as a subclass of Service class as follows −
Broadcast Receivers
Broadcast Receivers simply respond to broadcast messages from other applications or from the system. For example, applications can also initiate broadcasts to let other applications know that some data has been downloaded to the device and is available for them to use, so this is broadcast receiver who will intercept this communication and will initiate appropriate action.
A broadcast receiver is implemented as a subclass of BroadcastReceiver class and each message is broadcaster as an Intent object.
Content Providers
A content provider component supplies data from one application to others on request. Such requests are handled by the methods of the ContentResolver class. The data may be stored in the file system, the database or somewhere else entirely.
A content provider is implemented as a subclass of ContentProvider class and must implement a standard set of APIs that enable other applications to perform transactions.
We will go through these tags in detail while covering application components in individual chapters.
Additional Components
There are additional components which will be used in the construction of above mentioned entities, their logic, and wiring between them. These components are −
S.No
Components & Description
1
Represents a portion of user interface in an Activity.
UI elements that are drawn on-screen including buttons, lists forms etc.
View hierarchies that control screen format and appearance of the views.
Messages wiring components together.
External elements, such as strings, constants and drawable pictures.
Источник
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.
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.
Источник
Details about android applications
If you are an Android app developer, you can use the SDK that Oracle Mobile Cloud Service (MCS) provides for Android. This SDK simplifies authentication with MCS and provides native wrapper classes for MCS platform APIs.
Getting the SDK for Android
To get the MCS client SDK for Android, go to the Oracle Technology Network’s MCS download page.
To use the MCS SDK for Android, you should have the following software on your system:
Android Studio, or the standalone Android SDK Tools from Google.
See https://developer.android.com/studio/index.html for info on getting and using Android Studio.
Java Development Kit (JDK) 1.7.0_67 or compatible.
Contents of the Android SDK
The following SDK libraries (JAR files) are included in the Android SDK:
mcs–android-sdk-shared- .jar — The base library for the SDK, including functionality required by the other libraries as well as utility classes for accessing and authenticating with mobile backends.
mcs-android-sdk-analytics- .jar — The Analytics library, which lets you insert custom events into your code that can then be collected and analyzed from the Analytics console.
mcs-android-sdk-location- .jar — The Location library, which lets you access details about location devices that have been registered in MCS and the places and assets they are associated with.
mcs-android-sdk-fcm-notifications- .jar — The Notifications library for FCM, which lets you set up your application to receive notifications sent from your mobile backend. If your app still uses GCM, the SDK also includes /gcm/mcs-android-sdk-notifications- .jar . (The two notifications modules can’t be used at the same time.)
mcs-android-sdk-social- .jar — The Social Login library, which allows you to set up your app to use Facebook login.
mcs-android-sdk-storage- .jar — The Storage library, which lets you write code to access storage collections that are set up with your mobile backend.
mcs-android-sdk-sync- .jar — The Sync Client library, which allows you to cache application data when the device running your app is disconnected from the network, then sync up the data when the network connection is reestablished.
IDMMobileSDK.jar — The identity management library used by all applications.
The SDK also includes these tools and examples:
mcs-tools.zip — The MCS Custom Code Test Tools, a set of command line tools for debugging custom APIs that you have associated with your app’s mobile backend. Detailed instructions are located in the README file included in the zip.
mobile-log-download.zip — A command-line tool that allows you to download logs from MCS for viewing or archiving.
oracle_mobile_cloud_config.xml — A sample configuration file. You can adjust its properties based on the environment details of the mobile backend that your app will use and then copy the file to the assets folder you created when adding the SDK to your app.
examples.zip — Sample mobile apps that demonstrate how to use the SDK.
Javadoc.zip — Complete SDK API documentation. You can also reference the API documentation online: https://docs.oracle.com/en/cloud/paas/mobile-cloud/mcssa/index.html
Android SDK Dependencies
The SDK is modular, so you can package just the libraries that your app needs. Just be aware of the following dependencies:
Every Android application developed for MCS must have the shared ( oracle-mobile_android_shared- .jar ) and IDMMobileSDK.jar libraries.
If the Storage library is installed, the Sync Client library must also be installed.
Adding the SDK to an Android App
If you haven’t already done so, unzip the Android SDK zip.
Copy the SDK jars into the /libs folder in your app’s project. If this folder doesn’t exist, create it at the same level in your hierarchy as your /src and /build folders.
Decide which notifications library you need (FCM or GCM) and delete the .jar you are not using: mcs-android-sdk-fcm-notifications- .jar or /gcm/mcs-android-sdk-notifications- .jar . These modules can’t be used at the same time.
In the source tree for the application, create a folder called /assets (at the same level as the /java and /res folders).
In the SDK bundle, locate the oracle_mobile_cloud_config.xml file and copy it to the /assets folder.
In your app’s build.gradle file, make sure the following are among the dependencies registered so that the SDK libraries are available to the app.
Open /assets/oracle_mobile_cloud_config.xml and fill in the environment details for the mobile backend that the app will be using. See Configuring SDK Properties for Android.
Upgrading an Android App from SDK 17.x and Before
Unzip the new MCS Android SDK zip if you haven’t already.
Copy the new SDK jar files into the libs folder in your app’s project.
Decide which notifications library you need (FCM or GCM) and delete the .jar you are not using: mcs-android-sdk-fcm-notifications- .jar or /gcm/mcs-android-sdk-notifications- .jar . These modules can’t be used at the same time.
In your app’s settings.gradle file, make sure that IDMMobileSDK is NOT an include. (Remove it if it is.)
In your app’s build.gradle file, make sure the following is removed from the dependencies registered:
In your app’s build.gradle file, add the following to the dependencies registered:
So, the final dependencies should include:
Follow the rest of the instructions in this chapter to configure SDK properties and your Android manifest file.
Configuring SDK Properties for Android
To use the SDK in an Android app, you need to add the oracle_mobile_cloud_config.xml configuration file to the app and fill it in with environment details for your mobile backend. In turn, the SDK classes use the information provided in this file to access the mobile backend and construct HTTP headers for REST calls made to APIs.
You package the configuration file in your app’s main bundle in the assets folder at the same level as the java and res folders. For example, in the demo application FixItFast , it’s in /app/src/main/assets .
The following code sample shows the structure of a oracle_mobile_cloud_config.xml file.
Here’s a list of the file’s elements. The values that you need to fill in for a given mobile backend can be found on the Settings and Clients pages for that mobile backend.
mobileBackends — The config file’s root element, containing one or more mobileBackend elements.
mobileBackend — The element for a mobile backend.
mbeName — The name of the mobile backend associated with your app.
mbeVersion — The version number of your app (for example, 1.0 ).
default — If true , that mobile backend is treated as the default and thus can be easily referenced using the getDefaultMobileBackend(Context context) method in the SDK’s MobileBackendManager class.
appKey — The application key, which is a unique string assigned to your app when you register it as a client in MCS. This key is only required if you are using notifications. See Registering an App as a Client in MCS.
baseUrl — The URL your app uses to connect to its mobile backend.
networkConnectionTimeOut — (Optional) The connection timeout value in seconds. The default is 60 seconds. This element was added in 17.4.5.
enableLogger — When set to true , logging is included in your app.
enableAnalytics — When set to true , analytics on the app’s use can be collected.
authorization — Use the sub-elements of this element to define the authentication the app will be using and specify the required credentials.
authenticationType — Define the kind of authentication mechanism being used to connect your app to MCS. Possible values are oauth (for OAuth Consumer) , basic (for HTTP Basic), sso , tokenAuth (for SSO token exchange), and facebook (for logging in with Facebook credentials). If this element isn’t specified, OAuth Consumer is used. The other contents and sub-elements of the authorization element depend on the type of authentication.
oAuthTokenEndPoint — The URL of the OAuth server your app goes to, to get its authentication token.
oAuthClientId — The unique client identifier assigned to all apps when they’re first created in your mobile backend.
oAuthClientSecret — The unique secret string assigned to all apps they’re first created in your mobile backend.
The resulting authorization element might look something like this:
The resulting authorization element might look something like this:
SSO with a Third Party Token
If you are using JWT tokens and have integrated the token issuer by registering a configuration via a policy in MCS, you need to nest the mobile backend’s OAuth credentials. The resulting authorization element might look something like this:
If you have integrated the IdP token issuer by uploading certificates into MCS, you need to nest the mobile backend’s HTTP Basic credentials. The resulting authorization element might look something like this:
mobileBackendID — The unique identifier assigned to a specific mobile backend. It gets passed in an HTTP header of every REST call made from your app to MCS, to connect it to the correct mobile backend. When calling platform APIs, the SDK handles the construction of the authentication headers for you.
anonymousKey — A unique string that allows your app to access APIs that don’t require login. In this scenario, the anonymous key is passed to MCS instead of an encoded user name and password combination.
The resulting authorization element might look something like this:
facebookAppId — The Facebook application ID.
scopes — You can use this element to specify Facebook permissions (optional).
The resulting authorization element might look something like this:
Configuring Your Android Manifest File
Permissions for operations such as accessing the network and finding the network state are controlled through permission settings in your application’s manifest file, AndroidManifest.xml . These permissions are required:
permission.INTERNET — Allows your app to access open network sockets.
permission.ACCESS_NETWORK_STATE — Allows your app to access information about networks.
Other permissions are optional. For example, the Analytics platform API uses location to provide detailed information about the usage and performance of your app. If you’re including the Analytics library from the SDK, you’ll want to add these permissions as well.
permission.ACCESS_COARSE_LOCATION — Allows your app to access approximate location information, derived from sources such as wi-fi and cell tower positions.
permission.ACCESS_FINE_LOCATION — Allows your app to access precise location information, derived from sources such as GPS.
For more information about permissions in your Android application, see Android Manifest Permissions in the Google documentation.
Add the permissions at the top of your AndroidManifest.xml file, as shown in the following example:
Versions of the SDK before 17.4.5 used a NetworkHelper class that is no longer required. If your manifest file includes the following section, it can be deleted:
Adding the SDK to your application may require you to configure your AndroidManifest.xml file to add new permissions or activities. For example, if you add the Notifications individual SDK library, you may also need to add a new broadcast receiver. For more information, see Setting Up a Mobile App for Notifications.
Loading a Mobile Backend’s Configuration into an Android App
For any calls to MCS APIs using the Android SDK to successfully complete, you need to have the mobile backend’s configuration loaded from the app’s oracle_mobile_cloud_config.xml file. You do this using the MobileBackendManager and MobileBackend classes:
Authenticating and Logging In Using the SDK for Android
Here is some sample code that you can use for authentication through MCS in your Android apps.
First you initialize the authorization agent and set the authentication type to OAUTH .
Then you use the authenticate method to attempt authentication. The call includes parameters for Android context, user name, password, and a callback that completes the authorization process.
Here’s the definition for the callback.
First you initialize the authorization agent and set the authentication type to SSO . (For SSO third-party token exchange, see the next example.)
Then you create a thread to handle the authentication call and its callback.
SSO with a Third-Party Token
First, your app needs to get a token from the third-party token issuer. The way you can obtain the token varies by issuer. For detailed information on obtaining third-party tokens and configuring identity providers in MCS, see Third-Party SAML and JWT Tokens.
Once you have the token, initialize the authorization agent and use the token in your authorization call.
Here’s the callback:
SSO with a Third-Party Token — Staying Logged In
You can also code the app to keep the user logged in, even when closing and restarting the app.
In the above example, the authenticateUsingTokenExchange() method is called with the third parameter ( storeToken ) set to false . If you set this parameter to true and the token exchange is successful, the MCS token is stored in a secure store and the user remains logged in until the token expires.
You can then use the loadSSOTokenExchange method on the Authorization object to load the stored token. If a token can’t be retrieved from the secure store, the method returns false .
Here’s some code that tries to load a saved token and, if it fails, restarts the authentication process:
When you have the token stored in the secure store, it remains associated with the mobile backend that the app originally used. Therefore, if the app is updated to use a different mobile backend (or mobile backend version), you need to clear the saved token and re-authenticate.
The default expiration time for a stored token that was obtained through token exchange is 6 hours. You can adjust this time by changing the Security_TokenExchangeTimeoutSecs policy.
HTTP Basic Authentication
The code for handling login with HTTP Basic is nearly the same as the code for OAuth.
First you initialize the authorization agent and set the authentication type to BASIC_AUTH .
Then you use the authenticate method to attempt authentication. The call includes parameters for Android context, user name, password, and a callback that completes the authorization process.
Here’s the definition for the callback.
For Facebook login, you use classes in the oracle_mobile_android_social library.
First you initialize the authorization agent and set the authentication type to Facebook .
Using a CallbackManager object from Facebook’s SDK, initiate authentication.
Here’s code you can use for the callback that is passed above.
Override the onActivityResult() method to use the callback.
Calling Platform APIs Using the SDK for Android
Once the mobile backend’s configuration info is loaded into the app, you can make calls to SDK classes.
The root class in the Android SDK is the MobileBackendManager . An instance of MobileBackendManager manages one or more MobileBackend objects. A MobileBackend object is used to manage connectivity, authentication, and other transactions between your application and its associated mobile backend, including calls to platform APIs and any custom APIs you have defined. In turn, a MobileBackend instance manages instances of ServiceProxy . These instances correspond to platform services in MCS (for example, Analytics, Notifications, Sync, and so on).
The MobileBackend instance retrieves the information it needs about each mobile backend (the mobile backend name, version, and ID, as well as authentication information) from the app’s oracle_mobile_cloud_config.xml file.
Here’s an example of how you would use these classes to make calls into the Analytics API to create a new analytics event. The ServiceProxy instance created here manages calls to the Analytics platform API, including the constructing of the HTTP headers with the mobile backend credentials necessary to access the API:
Here’s how you could upload an image using the Storage API:
And here’s how you could retrieve an image using the Storage API:
For more information on the individual platform APIs, see Platform APIs.
Calling Custom APIs Using the SDK for Android
The SDK provides the CustomHttpResponse class, the GenericCustomCodeClientCallBack interface, and the invokeCustomCodeJSONRequest method in the authorization classes to simplify the calling of custom APIs in MCS. You can call a REST method (GET, PUT, POST, or DELETE) on an endpoint where the request payload is JSON or empty and the response payload is JSON or empty.
You use GenericCustomCodeClientCallBack to create a handler for the response (which is returned in the form of a CustomHttpResponse object.)
Then, to call the custom API, you call invokeCustomCodeJSONRequest(GenericCustomCodeClientCallBack restClientCallback, JSONObject data, String functionName, RestClient.HttpMethod httpMethod) on your Authorization object.
To make a call to a custom API endpoint, you could use something like this:
Video: Configuring an Existing Android App to Work with Mobile Cloud
For a demonstration on how to configure an Android app to use mobile backends and call MCS platform APIs, see this video on YouTube channel for the Oracle Mobile Platform:
