Easily place Ads in your Flutter app
This article will review the new functions and features now available with the latest version of the library package, Ads. It’s for developers who want Ads in their app. We’ll quickly review its new named parameters and error handling.
Of course, I’ll suggest you first read the last article that covered this library package, Add Ads to your App in a Snap!, and get a good introduction.
Screenshots Only. Click For Gists.
As always, I prefer using screenshots over gists to show code in my articles. I find them easier to work with, and easier to read. However, you can click/tap on them to see the code as a gist or in Github. Ironically, it’s better to read this article about mobile development on your computer than on your phone. Besides, we program mostly on our computers; not on our phones. For now.
Learn By Example
A gist example accompanies this article to highlight the new features showcased here. Below is a screenshot of that example code. More specifically, it’s a screenshot of the initState() function where the Ads class is instantiated and, in this case, where all three types of Ads are then defined. Also, it’s here where a number of ‘event listeners’ are defined, and where the Banner Ad is displayed. Of course, you’re free to instantiate the Ads object elsewhere in your app. It just happens, in this example code, it’s defined in a State object’s initState() function.
Construct Your Criteria
Looking closely at the initState() function, you can see there continues to be an array of options available to instruct Google Admob as to what sort of Ads you‘d like presented in your app. You can see the Video ads are assigned a different set of criteria than those passed to the Ads object’s constructor. And so, unlike the Banner Ad and the Interstitial Ad (Full Screen Ad), the Video Ad will use the keywords, ‘dart’ and ‘java’, will acquaint Ads from the content scraped from the website ‘publang.org’ and will be directed to children. The Ads package allows different criteria be applied to each of the three types of Ads.
Replace With Nothing
Let’s change the example code a little bit to demonstrate a new trait available in the latest version of this library package. In the screenshot below you’ll see, unlike the rest of the Ads, the Banner Ad is not given any keywords. Now originally, by design, if no keywords at all were specified in the function, setBannerAd(), that Banner Ad would acquire the keywords passed to the constructor.
Of course, there may be times where you don’t want that to happen. And so, to provide no keywords, the named parameter, keywords, is now explicitly supplied an empty List. The named parameter, testDevices, in the function, setVideo(), listed further along is also passed an ‘empty’ value. Hence, the device, ‘Samsun_Galaxy_SII_API_26:5554’, supplied to the constructor is not considered a ‘test devices’ to the Video Ad. You may not perform such things often (passing ‘empty’ values), but you’ve now got that option.
Construct Your Ads
Again, when it comes to working with Admob Ads, you’ve got to register with Google to get the appropriate id’s. In particular, you’ve got to get the unique id that’s assigned to your app. It is that id that’s used to initialize an instance of the plugin, firebase_admob. And so, when using this library package, it is that id that must be supplied to its constructor. See the screenshot below. Note, the red-bordered inset reveals the plugin being instantiated deep in the constructor taking in that id.
Further, the screenshot below demonstrates, if it’s not the constructor specifying the criteria, you’d have to individually specify the criteria to each type of Ad you’re presenting in your app — likely resulting in repeated code. Hence, more often than not, you’d enter the criteria once at the constructor.
Compound The Event
In review, the constructor can define the criteria for all the type of Ads you’ll be using in your app, and yet particular options can be added to a specific type of Ad. Doing so overrides any options supplied to the constructor. However, this is not the case when it comes to event listeners. For example, they are not overridden but are instead added on to those already supplied to the constructor. You’ll find a great number of events are triggered when dealing with Admob Ads.
In the screenshot below, the Interstitial ad will, in fact, fire two event listeners when it’s Ad is opened up. When it’s tapped on, first the listener in the constructor is fired, and then the listener defined in the function, setFullScreenAd() is fired — in the order in which they were defined.
Looking back at the example code, you’ll see how a developer can define a great number of event handlers in their app with their Admob ads. For example, the code here defines no less than 28 event listeners to address a long list of triggered events. We’ll examine that fact shortly, but for now, let’s look at the event listeners currently defined in the example’s initState() function. They all pertain to the event that occurs when a user taps on the Ad and ‘opens it up’ to view its full advertisement.
As you may have already realized, there’s a named parameter called, listener, found in the constructor, in the setBannerAd(), in the setFullScreenAd(), in the setVideoAd() as well as their corresponding ‘show’ functions. In the example code below, if the Banner Ad was tapped on and the advertisement opened, three event listeners defined in the following would fire: in the Ads() constructor, in the function, ads.setBannerAd() and in the function, ads.showBannerAd() — in that order.
In Moving Pictures
Below are two gif files depicting the three event listeners fired in turn. Again, they occur when the Banner Ad is explicitly tapped on by the user.
Called With Every Open
Remember, however, the consistent factor here is that the listener defined in the constructor will ‘always’ be called. And so in the example code, regardless if it’s a Banner Ad, an Interstitial Ad, or a Video Ad, when it’s tapped opened the print() function passed to the constructor will be called. In other words, you can have specific listeners for a particular type of Ad, but the listener defined in the constructor, regardless of the type of Ad, will always fire.
Advertise The Event!
I would suggest you use your IDE’s debugger and ‘step through the code’ in the example — placing breakpoints throughout the setEventListeners() function to get a better understanding of the ‘event handling’ offered to Admob Ads. A lot happens when your users interact with your Ads.
It’s Nothing New
Such event handling is not new to this library package. It worth mentioning however as a reminder that such an extensive feature offered by Admob itself is available to you. Both the Banner Ad and Interstitial Ad note the following events when a user ‘acknowledges’ one of your Ads:
As it happens, the Video Ad has a separate list of events.
A screenshot of the setEventListeners() function is displayed below. Placing breakpoints at every print() function will give you an appreciation to the ‘series of events’ that literally happens when your user taps on one of your Ads.
Set Specific Events
Note, you could forego all those case statements and if statements if you like and define a Lambda for a specific type of Ad and event. Why would you use such setters? Why not?! The more options, the better — I always say. Again, nothing new, but I wanted it emphasized again here in this article.
Show Your Errors
What is new is how the library package has the means for you to address any and all errors that may occur with the plugin, firebase_admob. It’s still in beta after all, and so there may be times where you’ll encounter errors for no apparent reason. This library package now provides a means to at least try to notify the developer of such exceptions.
There a new named parameter available called, errorListener. Like most of the other named parameters, you can choose ‘to what degree’ you wish the error listener to cover errors that may occur as it too is found in the constructor, in the setBannerAd(), in the setFullScreenAd(), in the setVideoAd() as well as their corresponding ‘show’ functions.
You can define an error listener for all the Ad types by supplying it to the constructor, or as you see in the screenshot below, define an error handler to cover any errors that may occur only when you show the Banner Ad.
Make An Error
The example code includes a bug. Well, an exception. Tapping/Clicking on the Banner Ad will throw an exception. And so, in this example, there’s a little routine below that collects the error and, with the help of the defined ‘error listener’, displays the error message on the screen. Of course, as a developer, you yourself may wish to be ‘more subtle’ in your handling of such instances if they occur in your App. Admob may not be working as you would expect — this is a means to notify Admob of such instances.
Don’t Advertise Your Errors
There is a number of getter’s and functions that will notify you if an error occurred when dealing with Admob’s ads. In Life, errors happen. In this case, you can collect such errors and notify the Admob team of your concerns.
Below is a screenshot demonstrating how you would use these getter’s and functions to address any such errors. Collecting any information that may help you and the Admob team determine what may be the problem.
Again, if you haven’t already done so, the article, Add Ads to your App in a Snap!, provides a further overview.
As you can deduce, this library package continues to be improved — reflecting the changes made to the underlying plugin, firebase_admob. It has become one of my more popular library packages, and I gladly keep it up-to-date for the benefit of our Flutter community.
Other packages by the author found on Pub.dev