Create custom event android

Android — Event Handling

Events are a useful way to collect data about a user’s interaction with interactive components of Applications. Like button presses or screen touch etc. The Android framework maintains an event queue as first-in, first-out (FIFO) basis. You can capture these events in your program and take appropriate action as per requirements.

There are following three concepts related to Android Event Management −

Event Listeners − An event listener is an interface in the View class that contains a single callback method. These methods will be called by the Android framework when the View to which the listener has been registered is triggered by user interaction with the item in the UI.

Event Listeners Registration − Event Registration is the process by which an Event Handler gets registered with an Event Listener so that the handler is called when the Event Listener fires the event.

Event Handlers − When an event happens and we have registered an event listener for the event, the event listener calls the Event Handlers, which is the method that actually handles the event.

Event Listeners & Event Handlers

This is called when the user either clicks or touches or focuses upon any widget like button, text, image etc. You will use onClick() event handler to handle such event.

This is called when the user either clicks or touches or focuses upon any widget like button, text, image etc. for one or more seconds. You will use onLongClick() event handler to handle such event.

This is called when the widget looses its focus ie. user goes away from the view item. You will use onFocusChange() event handler to handle such event.

This is called when the user is focused on the item and presses or releases a hardware key on the device. You will use onKey() event handler to handle such event.

This is called when the user presses the key, releases the key, or any movement gesture on the screen. You will use onTouch() event handler to handle such event.

This is called when the user selects a menu item. You will use onMenuItemClick() event handler to handle such event.

This is called when the context menu is being built(as the result of a sustained «long click)

There are many more event listeners available as a part of View class like OnHoverListener, OnDragListener etc which may be needed for your application. So I recommend to refer official documentation for Android application development in case you are going to develop a sophisticated apps.

Event Listeners Registration

Event Registration is the process by which an Event Handler gets registered with an Event Listener so that the handler is called when the Event Listener fires the event. Though there are several tricky ways to register your event listener for any event, but I’m going to list down only top 3 ways, out of which you can use any of them based on the situation.

Using an Anonymous Inner Class

Activity class implements the Listener interface.

Using Layout file activity_main.xml to specify event handler directly.

Below section will provide you detailed examples on all the three scenarios −

Touch Mode

Users can interact with their devices by using hardware keys or buttons or touching the screen.Touching the screen puts the device into touch mode. The user can then interact with it by touching the on-screen virtual buttons, images, etc.You can check if the device is in touch mode by calling the View class’s isInTouchMode() method.

Focus

A view or widget is usually highlighted or displays a flashing cursor when it’s in focus. This indicates that it’s ready to accept input from the user.

isFocusable() − it returns true or false

isFocusableInTouchMode() − checks to see if the view is focusable in touch mode. (A view may be focusable when using a hardware key but not when the device is in touch mode)

onTouchEvent()

Event Handling Examples

Event Listeners Registration Using an Anonymous Inner Class

Here you will create an anonymous implementation of the listener and will be useful if each class is applied to a single control only and you have advantage to pass arguments to event handler. In this approach event handler methods can access private data of Activity. No reference is needed to call to Activity.

But if you applied the handler to more than one control, you would have to cut and paste the code for the handler and if the code for the handler is long, it makes the code harder to maintain.

Following are the simple steps to show how we will make use of separate Listener class to register and capture click event. Similar way you can implement your listener for any other required event type.

Event Handler	Event Listener & Description
onClick()

Step	Description
1	You will use Android studio IDE to create an Android application and name it as myapplication under a package com.example.myapplication as explained in the Hello World Example chapter.
2	Modify src/MainActivity.java file to add click event listeners and handlers for the two buttons defined.
3	Modify the detault content of res/layout/activity_main.xml file to include Android UI controls.
4	No need to declare default string constants.Android studio takes care default constants.
5	Run the application to launch Android emulator and verify the result of the changes done in the aplication.

Following is the content of the modified main activity file src/com.example.myapplication/MainActivity.java. This file can include each of the fundamental lifecycle methods.

Following will be the content of res/layout/activity_main.xml file −

Here abc indicates about tutorialspoint logo

Following will be the content of res/values/strings.xml to define two new constants −

Following is the default content of AndroidManifest.xml −

Let’s try to run your myapplication application. I assume you had created your AVD while doing environment setup. To run the app from Android Studio, open one of your project’s activity files and click Run icon from the toolbar. Android Studio installs the app on your AVD and starts it and if everything is fine with your setup and application, it will display following Emulator window −

Now you try to click on two buttons, one by one and you will see that font of the Hello World text will change, which happens because registered click event handler method is being called against each click event.

Exercise

I will recommend to try writing different event handlers for different event types and understand exact difference in different event types and their handling. Events related to menu, spinner, pickers widgets are little different but they are also based on the same concepts as explained above.

Источник

Native ads custom events

Prerequisites

You may also want to first read about making an AdRequest and how mediation works.

Sample SDK

The code snippets in this guide are taken from our sample custom event project which includes a «Sample SDK». This mock SDK is used in our example of how to build a custom event that mediates another ad network’s SDK.

THe Sample SDK features classes similar to what you’d find in an ad network’s production SDK. There are request objects such as SampleNativeAdRequest , ad loaders such as SampleNativeAdLoader , and other classes, constants, and interfaces used to simulate a real network’s SDK. The ads that it produces are mocks, though, and no additional network traffic is generated.

Request a native ad

The requestNativeAd() method

Custom event classes must implement the CustomEventNative interface, which includes a method used by the Google Mobile Ads SDK to request native ads from the custom event:

Kotlin

When this method is called, the custom event should asynchronously request a native ad from the mediated network. The following parameters for requestNativeAd() carry information that the custom event can use in making its request:

• serverParameter — When adding a custom event to an ad unit’s mediation configuration, publishers can enter a string value to be passed along with each request. This parameter holds that value (typically another ad unit ID, which was issued by the mediated network).
• mediationAdRequest — A NativeMediationAdRequest object, which contains properties specific to a single request, such as which native formats are requested. NativeMediationAdRequest is a subclass of MediationAdRequest , so it also includes properties for other targeting information provided by publishers at request time.
• customEventExtras — A Bundle containing any extra information relevant to the request provided by the publisher. When creating an ad request, publishers can use the addNetworkExtrasBundle() method to include information for specific mediation adapters and custom events. Any extras included by the publisher for a given custom event class are found in this parameter.

In addition to the parameters carrying request information, there are two others:

• context — A Context object which can be used if the custom event requires one.
• listener — A CustomEventNativeListener object that the custom event should use to forward events.

The listener object is particularly important, as it’s used to report events to the Google Mobile Ads SDK. This guide covers how to do so in Forward events to the Mobile Ads SDK.

Here’s a code snippet from our example custom event project that shows an implemented requestNativeAd() method:

SampleCustomEvent (excerpt)

Kotlin

This is a sample custom event that mediates to an imaginary ad network via the mock Sample SDK. The custom event uses the information provided in the parameters of requestNativeAd() to build a SampleNativeAdRequest (a class provided by the Sample SDK), then uses it to request an ad from Sample SDK’s SampleNativeAdLoader . It also creates a SampleCustomEventNativeForwarder to handle forwarding events back to the Google Mobile Ads SDK.

NativeAdOptions

When making a request for native ads, publishers use a NativeAdOptions object to specify their preferences for that request, such as how image assets should be returned. Your custom event needs to examine those preferences and respect them. Custom events can retrieve a request’s NativeAdOptions object using the getNativeAdOptions() method provided by the NativeMediationAdRequest object:

Kotlin

After retrieving the NativeAdOptions , custom events can read its properties and act accordingly. For example, if the shouldReturnUrlsForImageAssets value is false in NativeAdOptions (which is the default), the custom event must return actual image assets rather than just the URLs. In this case, if the SDK being mediated only provides URLs for images, then the custom event must use those URLs to download the image files and make their data available to the publisher in its mapped native ads.

Forward events to the Mobile Ads SDK

A few things can happen when a custom event tries to load a native ad from its mediated network. The SDK could successfully return a native ad, it could come back with an error, or it might simply report that no ads are available. Similarly, when the user taps on an ad, the mediated SDK might open an overlay or leave the application entirely to start an external browser. It’s important for the Google Mobile Ads SDK to be aware of these events, so it provides a CustomEventNativeListener object as a parameter to the requestNativeAd() method.

It’s part of a custom event’s job to listen for events from the mediated SDK and map them to the appropriate CustomEventNativeListener callbacks. Your custom event needs to be aware of the following CustomEventNativeListener callbacks:

• onAdLoaded() — This method should be called when a custom event successfully loads a native ad. It takes a UnifiedNativeAdMapper , which maps your ad network SDK’s native ad to an object the Google Mobile Ads SDK understands. Map native ads covers how to create a UnifiedNativeAdMapper .
• onAdFailedToLoad() — When the custom event tries and fails to load a native ad, it should use this method to report the failure.
• onAdLeftApplication() — Invoke this method when the mediated SDK causes user focus to leave the publisher’s application (most commonly to open an external browser).
• onAdOpened() — If the native ad opens any overlay or separate activity that covers the interface in response to a user’s tap, this method should be invoked. This includes an external browser, in which case your custom event should call onAdOpened just before onAdLeftApplication .
• onAdClosed() — If an overlay or separate activity covering the interface is closed, this method should be invoked, signifying that control is being transferred back to the app containing the native ad.

The listener also offers methods for reporting clicks and impressions from custom events that choose to track clicks or impressions for themselves (see Override the default click handling and impression recording for details). One is for reporting a click to the Google Mobile Ads SDK, and one is for reporting an impression:

• onAdClicked() — This method should be called when a user clicks on a native ad.
• onAdImpression() — Similarly, this method should be called when an impression is recorded for the ad by the mediated SDK.

There are a number of ways to make sure events are forwarded correctly, but one of the simplest is to create a dedicated class to act as forwarder. Here’s one from our custom event sample project:

SampleCustomNativeEventForwarder

Kotlin

Notice that the class implements Sample SDK’s SampleNativeAdListener interface. In SampleCustomEvent (excerpt) an instance of this forwarder class was given to the SampleNativeAdLoader in its setNativeAdListener() method:

Kotlin

This ensures that Sample SDK calls the SampleCustomNativeEventForwarder object’s listener methods ( onNativeAdFetched() , onAdFetchFailed() , and so on) when it has an event to report. The forwarder then calls the appropriate method on the Google Mobile Ads SDK’s CustomEventNativeListener , forwarding the event. In short, the Google Mobile Ads SDK listens to the forwarder, which is listening to the mediated SDK.

The onAdFetchFailed() method above is a great example of how this works. When Sample SDK fails to load an ad, it calls the forwarder’s onAdFetchFailed() method and gives it an error code. The forwarder examines the error code and calls the onAdFailedToLoad() method of the CustomEventNativeListener with one of the error codes used by the Google Mobile Ads SDK. In this way, a Sample SDK event is turned into a Google Mobile Ads SDK event.

Map native ads

Different SDKs have their own unique formats for native ads. One might return objects that contain a «title» field, for instance, while another might have «headline.» Additionally, the methods used to track impressions and process clicks may vary from one SDK to another. It’s the job of the UnifiedNativeAdMapper to reconcile these differences and adapt a mediated SDK’s native ad object to match the interface expected by the Google Mobile Ads SDK. Custom events should extend this class to create their own mappers specific to their mediated SDK.

Here’s a sample ad mapper from our example custom event project:

SampleNativeAdMapper

Kotlin

Let’s take a look at the constructor method and some of the work it’s doing:

Hold a reference to the mediated native ad object

The constructor accepts SampleNativeAd and NativeAdOptions parameters. SampleNativeAd is the native ad class used by the Sample SDK for its native ads. The mapper needs a reference to the mediated ad so it can pass on click and impression events. NativeAdOptions contains publisher preferences about the native ad. Both parameters are stored as local variables.

Set mapped asset properties

The constructor uses the SampleNativeAd object to populate assets in the UnifiedNativeAdMapper . This code, for example, get the mediated ad’s price data and uses it to set the mapper’s price:

Kotlin

In this case, the mediated ad stores the price as a double , while AdMob uses a String for the same asset. The mapper is responsible for handling these types of conversions.

Map image assets

Mapping image assets is more complicated than simpler data types like double or String . Images might be downloaded automatically or simply returned as URL values. Their pixel-to-dpi scales can also vary. To help custom event developers manage these details, the Google Mobile Ads SDK provides the NativeAd.Image class. In much the same way that developers need to create a subclass of UnifiedNativeAdMapper to map a mediated native ad, they should also create a subclass of NativeAd.Image to help them map its image assets.

Here’s the code for the custom event’s SampleNativeMappedImage class:

Kotlin

The SampleNativeAdMapper uses its mapped image class in this line to set the mapper’s icon image asset:

Kotlin

Add additional fields to the extras Bundle

Some mediated SDKs may provide additional assets beyond those in the AdMob native ad format. The UnifiedNativeAdMapper class includes a setExtras() method that is used to pass these assets on to publishers. The SampleNativeAdMapper makes use of this for the Sample SDK’s «degree of awesomeness» asset:

Kotlin

Publishers can retrieve the data using the NativeAd class’s getExtras() method.

AdChoices

Your custom event is responsible for providing an AdChoices icon via the setAdChoicesContent() method on UnifiedNativeAdMapper .

Here’s a snippet from SampleNativeAdMapper showing how to provide the AdChoices icon:

Kotlin

Impression and click events

Both the Google Mobile Ads SDK and the mediated SDK need to know when an impression or click occurs, but only one SDK needs to track these events. There are two different approaches custom events can use, depending on whether the mediated SDK supports tracking impressions and clicks on its own.

Handle clicks and impressions with handleClick and recordImpression

If the mediated SDK does not do its own impression and click tracking but provide methods to record clicks and impressions, the Google Mobile Ads SDK can track these events and notify the adapter. The UnifiedNativeAdMapper includes two methods, recordImpression() and handleClick() , which custom events can implement to call the corresponding method on the mediated native ad object.

Here’s how the SampleNativeAdMapper handles this:

Kotlin

Because the SampleNativeAdMapper holds a reference to the Sample SDK’s native ad object, it can simply call the appropriate method on that object to report a click or impression. Note that the handleClick() method has a single parameter, which is the View object corresponding to the native ad asset that received the click.

Override the default click handling and impression recording

Some mediated SDKs may prefer to track clicks and impressions on their own. In that case, you should override the default click and impression tracking by making the following two calls in the constructor of your UnifiedNativeAdMapper :

Kotlin

As noted in Forward events to the Mobile Ads SDK, custom events that track clicks and impressions for themselves are required to report these events to the Google Mobile Ads SDK via the onAdClicked() and onAdImpression() methods.)

You should also override the trackViews() method and use it to pass the native ad’s view to the mediated SDK to track. The sample SDK from our custom event example project (from which this guide’s code snippets have been taken) doesn’t use this approach, but if it did, the custom event code would look something like this:

Kotlin

If the mediated SDK supports tracking individual assets, it can look inside clickableAssetViews to see which views should be made clickable. This map is keyed by an asset name in NativeAdAssetNames .

The UnifiedNativeAdMapper offers a corresponding untrackView() method that custom events can override for the opposite purpose (releasing any references to the view and disassociating it from the native ad object).

Use a custom event

To use a custom event, you need to add it to the mediation configuration for an ad unit. This is done in the AdMob UI. (Create a custom event provides detailed instructions for editing an ad unit’s mediation configuration).

When you add the custom event to an ad unit’s mediation configuration, you are asked for three pieces of information:

• Class Name — This is the class name of your custom event, with the full package name included.
• Label — This is the label you’d like AdMob’s interface to use to represent the custom event when it displays the ad unit’s mediation sources. It’s just for you, as it only ever appears on the AdMob UI.
• Parameter — This is a string value that is passed to the custom event whenever requests for this ad unit are made. Typically this value is set to an ad unit ID from the mediated network.

Here’s a screenshot of an example custom event entry:

That’s it! You now have everything you need to write your own Android custom events for AdMob.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Источник