Tag Archives: ios

Google Mobile Ads SDK – A Note on Ad Click Events

When you make an ad request using the Google Mobile Ads SDK, you’re probably setting an AdListener or GADBannerViewDelegate to listen for ad events. The click events for these listeners are slightly different on Android and iOS, so today we’ll take a deeper look at what events get invoked when an ad click:

  • opens an overlay, for example an in-app browser
  • launches an external application, for example an external browser or app store

Ad Opens an Overlay

Here are the ad events that get called when an ad opens an overlay:

Event Android Callback(s) iOS Callback(s)
Ad Opens Overlay
onAdOpened
adViewWillPresentScreen
Ad Overlay is Closed
onAdClosed
adViewWillDismissScreen
adViewDidDismissScreen

These events are pretty straightforward. When the ad overlay opens, you get a single callback. When the ad overlay closes, Android notifies you the moment the event happens, while iOS notifies you right before and after the event happens.

Ad Launches an External Application

When an ad launches an external application, the ad events are slightly different:

Event Android Callback(s) iOS Callback(s)
Ad Launches External App
onAdOpened
onAdLeftApplication
adViewWillLeaveApplication
User relaunches App
onAdClosed
-----

Notice how on Android you still get the onAdOpened and onAdClosed events even if an ad leaves an application. But on iOS, the adViewWillPresentScreen and adViewWillDismissScreen/adViewDidDismissScreen events are only invoked when presenting and dismissing modal views.

So how do you know when the user returns to your iOS app? You can listen for the applicationWillEnterForeground delegate method that iOS provides.

Testing The Different Click Behaviors

Hopefully you’re already requesting test ads during application development. If you’re making test requests, you should already see these ads showing up in your development environment:



On iOS, you can use these ads to test both ad click behaviors. If you click the banner, the Google Mobile Ads SDK will launch an external web browser and call adViewWillLeaveApplication. If you click the icon in the bottom-left corner of the ad, the SDK will launch an overlay and adViewWillPresentScreen will get called.

Hopefully this clears up any confusion regarding any ad click events. If you have any additional questions, we’ll field them on our forum. You can also find us on Google+.

Announcing New Google Mobile Ads SDKs: 4.4 for Google Play Services and 6.9.2 for iOS

Today, we’re excited to announce a new release to both our Android and iOS Google Mobile Ads SDKs. The key new features added in these releases are in-app purchase ads for both platforms and new mediation APIs for Android.

In-App Purchase Ads

In this release we’ve added SDK-level support (front-end support coming soon!) for running house ads that can initiate an in-app purchase. In-app purchase ads require that you set an in-app purchase listener on your interstitial ad. If an in-app purchase ad is shown, it will present the user with an option to buy one or more items that you have configured:

When the user clicks Buy now, the SDK will invoke your in-app purchase listener with the purchase information necessary to start a transaction for that product. You are responsible for implementing the in-app purchase flow from this point. Full implementation details can be found in our Android and iOS documentation.

Note: Front-end support for this feature is not available yet, but is coming soon.

New Mediation APIs

As part of our Google Play services API revamp, we’ve added new mediation APIs (which we’re calling mediation v2) to make it easier for ad networks to create mediation adapters.

Don’t worry! We’re still supporting mediation adapters written against mediation v1 APIs. This change won’t require any immediate updates to your apps.

If you previously passed extra parameters to third party networks, note that this process has changed for mediation v2. You’ll now pass a bundle to the ad network, keyed by its mediation v2 adapter class. Here is an example of passing extra parameters to AdMob:


Bundle adMobBundle = new Bundle();
adMobBundle.putString("color_bg", "AAAAFF");
AdRequest request = new AdRequest.Builder()
.addNetworkExtrasBundle(AdMobAdapter.class, adMobBundle)
.build();

You can also use this snippet to check for the existence of mediation v2 support. If this snippet compiles, then the adapter supports mediation v2. If there is a compilation error saying that the arguments don’t match the arguments for addNetworkExtrasBundle(Class, Bundle), then that adapter class does not support mediation v2.

See the documentation for more information on passing parameters to mediation v2.

Dropped Support for iOS 4.3

The 6.9.2 iOS SDK release has dropped support for iOS 4.3. By dropping iOS 4.3, the SDK can take advantage of automatic reference counting (ARC) weak references to provide a more stable release. The SDK still supports iOS 5.0 and above.

Check out the downloads page to grab the latest iOS release. A new Google Play services revision will soon be available in Android’s SDK Manager.

For a full list of SDK changes, see the release notes. If you have any technical questions about these changes, we’re available on the forum. Finally, stay tuned for an update on front-end support for in-app purchase ads on our Google+ page.

Monetizing Unity Mobile Apps Just Got Easier

Calling all Unity app developers! We are excited to announce the launch of version 2.0 of the Google Mobile Ads Unity Plugin. The new version comes with a completely rewritten, but much more flexible, API. It includes the following new features:

  • A single package supporting both Android and iOS
  • Support for running apps in the Unity editor
  • Ability to create multiple banner instances
  • Ability to create banners of any size
  • Flexible ad request targeting
  • and much more!

Taking a closer look at how to integrate the plugin, a typical banner request in v2.0 looks like this:


BannerView bannerView = new BannerView(
"YOUR_AD_UNIT_ID", AdSize.Banner, AdPosition.Top);
AdRequest request = new AdRequest.Builder().Build();
bannerView.LoadAd(request);

For custom banner sizes, simply pass in an AdSize object into the BannerView constructor:


AdSize adSize = new AdSize(250, 250);
BannerView bannerView = new BannerView(
"YOUR_AD_UNIT_ID", adSize, AdPosition.Top);

Want to pass additional targeting parameters? No problem! Set your custom targeting when building the AdRequest:


AdRequest request = new AdRequest.Builder()
.AddTestDevice(AdRequest.TestDeviceSimulator)
.AddTestDevice("0123456789ABCDEF0123456789ABCDEF")
.AddKeyword("unity")
.SetGender(Gender.Male)
.SetBirthday(new DateTime(1985, 1, 1))
.TagForChildDirectedTreatment(true)
.Build();

Listening for ad events is also extremely straightforward. Register for the callbacks you care about:


bannerView.AdLoaded += HandleAdLoaded;
bannerView.AdFailedToLoad += HandleAdFailedToLoad;
bannerView.AdOpened += HandleAdOpened;
bannerView.AdClosing += HandleAdClosing;
bannerView.AdClosed += HandleAdClosed;
bannerView.AdLeftApplication += HandleAdLeftApplication;



public void HandleAdLoaded()
{
print("HandleAdLoaded event received.");
}

You can also manage the lifecycle of each BannerView by calling show(), hide(), or destroy().

To get access to these awesome features, check out the source code. Also stay tuned for upcoming support for interstitial ads.

If you have any feature requests or bug reports against the plugin, track it! If you have questions about how to use the plugin, speak up! And if you just want the latest news on what’s going on in the wonderful world of Google Ads, circle us!

Sun Surveyor shines with Street View

In this guest blog post, we hear from Adam Ratana, a hobbyist photographer and software engineer by day, and developer of the Android and iOS Sun Surveyor apps by night. In this tutorial, Adam talks about his creative implementation of custom polylines on Street View panoramas in the Google Maps SDK for iOS.

 As a photography enthusiast, I’m always looking to capture images at the magic hour. My goal when creating Sun Surveyor was to give users an immersive way of visualizing the location of the sun and the moon, making it easy for anyone to figure out when the natural lighting is just right for the perfect shot.

When I set out to build Sun Surveyor, I knew I wanted to give users an easy way of visualizing the location of the sun and the moon. Sun Surveyor has an augmented reality (AR) feature, which overlays sun and moon paths on top of the device camera’s view. This is useful for understanding how light will change over time at a particular location. While I also created a Map View to show the paths on a Google Map for remote locations, it was not as intuitive as augmented reality.

Visualizing the sun and moon paths in augmented reality and map views

When Street View launched in the Google Maps SDK for iOS in v1.4.0 (July, 2013), I couldn’t wait to visualize the sun and moon paths within an interactive panorama. Street View panoramas bridge the gap between Sun Surveyor’s Map View and AR experiences by giving users an augmented reality experience, wherever they want to go.

Sun and moon paths with Street View panoramas

Implementing a sun path Overlay on Street View
I took a creative approach to working with the Google Maps SDK for iOs.  While polylines can be implemented in Map View, this isn’t yet possible in a Street View panorama. To display paths and other items that move with the Street View panorama, I needed to:
  1. Create an overlay on top of the panorama upon which to draw the items
  2. Synchronize the positions of the overlay items with the panorama as it moves
  3. Determine which data are visible and where on the screen to draw them
For this tutorial, I have provided a sample project that will get anyone started doing the same. Let’s walk through the steps.

I. Creating an Overlay

In our main UIViewController, we add a subclass of UIView for the overlay, make its background color transparent, and place the GMSPanoramaView below it in the view hierarchy.


Representing Overlay Items
We represent the overlay items with a protocol having two methods: updateWithPanoramaView and draw. The updateWithPanoramaView method updates an item’s screen location geometry, while draw draws it to the current graphics context.

We store all items to be drawn in a collection, update their positions based on the panorama position, and draw the collection in our view’s standard drawRect method.

If we want to make sure these items are drawn in a certain order that might change based on the data, we can add z-indexes to them and then sort the collection by z-index after we update them and before drawing.

II. Syncing the Overlay with the Panorama
To make sure this overlay view stays updated as the panorama moves beneath it, we can update the view’s data in an implementation of GMSPanoramaViewDelegate’s didMoveCamera method. We can use a CADisplayLink to ensure the overlay view is redrawn at regular intervals, and use a flag to make sure it is only redrawn when necessary.


Optimization
CoreGraphics can be a bottleneck. [UIBezierPath strokePath] and [NSString drawAtPoint] are expensive as you can see by profiling with Instruments. For performance intensive applications, an alternative is to use OpenGL. Avoiding overdraw is always a good idea, so the first optimization, if needed, is to carefully examine what is being drawn to the screen, and draw only what is necessary.

III. Mapping data to the panorama view
The GMSProjection class has a pointForCoordinate method that returns the screen pixel location for a coordinate on the Map. This is useful for overlaying elements on top of a GMSMapView, and is used in the Sun Surveyor Map View to draw text related to sun and moon paths on top of the Map.

GMSPanoramaView has a similar method, pointForOrientation. This method allows us to query the panorama for a screen pixel location given a GMSOrientation (bearing and pitch tuple) relative to the panorama location, where the camera is stationed, at ground level. This is useful to make sure an item we overlay onto the view remains in the same location relative to the scene, even as the camera moves and the view shifts.

Because the camera has a Field of View that determines what is visible on the screen, some orientations are not visible (such as behind the camera position). pointForOrientation helpfully returns NAN (not a number) for such orientations, so we know the given orientation is not visible.

With sun path data already expressed in terms of orientation relative to the ground level of the viewer, drawing corresponding paths with screen pixel locations is easy. We map our data with pointForOrientation, and draw what is visible by checking the result for NAN.



The sample project uses a panorama of Sydney, Australia, looking west, with a sun path for 12/20/2013.


Bonus: altering the Field of View
Version 1.4.1 of the SDK added support for changing the GMSPanoramaCamera’s field of view (FOV). The field of view determines how much of the scene is visible on a device screen, as well as how much distortion around the edges of the view is present. Smaller values for FOV are the equivalent of having a telephoto lens on a real camera: it brings distant objects closer.


Left: FOV of 60 degrees. Middle: 90 degrees (default). Right: 130 degrees.


Street View Panoramas are awesome and easy
The Street View panorama viewer in the Google Maps SDK for iOS is an example of a great API. The GMSPanoramaView class is simple to understand and use. In the course of a weekend, I was able to deliver a fun, interactive and highly requested feature to Sun Surveyor’s iOS users. I can’t wait to see what people are able to do with this new Street View Panorama feature in my app, and I look forward to seeing all the other implementations that others develop!

Stonehenge, as seen from a Street View panorama in Sun Surveyor


Posted by Monica Tran, Google Maps API

Sun Surveyor visualizes the sun and moon in a variety of ways for photographers, filmmakers, solar industry professionals, architects, homebuyers, gardeners, and anyone needing to predict or understand the movement of the sun and moon.

Adam Ratana is a Carnegie Mellon University graduate living in, and loving, Pittsburgh, PA. He produces dance music as a member of Pittsburgh Track Authority, enjoys photography, traveling with his wife, and writing fun software in his free time. Adam also enjoys attending the Pittsburgh Cocoaheads chapter meetings.

Fab Friday is Summering

Author Photo

It’s been a while since we posted a Fab Friday post. Naturally, with it being summer and all, I was a little distracted. But it’s not summer in Sydney, and they’ve been busy! You may have seen that we launched Dynamic Maps Engine Layers in the JavaScript Maps API a couple weeks ago. Josh Livni hosted a Maps Live episode on it: Visualizing Maps Engine Data on JavaScript Maps. Check it out:


This week we launched version 1.4 of the Google Maps SDK for iOS. It includes cool new features like Street View, indoor maps, and an updated map style. Check out this Maps Live episode Luke Mahe and I did.


It’s shaping up to be a great summer in the Northern Hemisphere! Thanks Sydney!
Posted by Mano Marks, Maps Developer Relations Team

Street View, indoor maps, and an updated map design in the Google Maps SDK for iOS

Since the launch of the Google Maps SDK for iOS last December, we’ve brought over a dozen of the most requested features to the platform and today, alongside the update to the Google Maps for iOS app, we’re announcing v1.4 of the SDK. Download the SDK to add an immersive mapping experience to your app, powered by accurate data from Google Maps.

With this update, developers can write a few lines of code to access popular features of Google Maps including: Street View in 50 countries, more than one billion square feet of indoor floor plans, and an updated design of our map tiles. For an overview of the new features in this release, watch this introduction from Google Maps Developer Relations team, Mano Marks and Luke Mahe:



Street View
Why drive 5 million miles of roads when you can use a few lines of code to bring Street View to your app? Use Street View panoramas to give users additional visual cues about a location. Try embedding Street View alongside a map or business photos to give your app real-world context. Or find inspiration in some our creative Javascript Street View implementations: GeoGuessr, Driveway Decision Maker, and Converse Street Ready.


Indoor Floor Plans
Indoor floor plans let you bring your users one level deeper by giving them access to floor plans inside shopping malls, airports, train stations and more. In a store finder, imagine showing users the inside of the building where your store is located, rather than just street level.


Updated Map Design
One point of feedback that we’ve heard consistently is that you want a map that blends seamlessly with your app UI. This version of the Google Maps SDK for iOS includes an update to the map tiles, that draws design inspiration from the new Google Maps. We’ve removed the yellow roads, which gives the map a more neutral palette, so that your app’s colors, styles, and map markers can stand out.

The updated map design (right) is inspired by the new Google Maps and has a more neutral palette, so that your app UI can shine.

We’re continuing to iterate rapidly to add features that you want. Let us know what you’d like to see in the next release of the Google Maps SDK for iOS using the issue tracker, and if you have questions, post them to the Google Maps API Developer Community.

Posted by Daniel Schramm, Associate Product Manager, Google Maps.

New and improved Blogger mobile apps

Inspiration for a new post can happen at any place and time: on the couch, while shopping, at a game, or in the kitchen. Fortunately, mobile devices enable you to stay connected wherever you are.

With that in mind, we just launched updated apps for both Android and iOS. The updated apps include a visual facelift and other features which make it easier for you to create and share -- wherever your imagination runs wild. Some of the more notable improvements include:


  • Landscape support for composing posts
  • Sharing to Google+
  • Ability to view a scheduled post time
  • International support in 30+ languages
  • iPad support

We hope you enjoy these improvements, and keep writing great blog content on the go. 

Get Blogger in the Play store to get the latest on your Android phone or the App Store for iOS devices.

Source: Blogger Buzz