If you've been following our iOS news lately,
you've probably heard that we're now using CocoaPods
as our primary way of delivering our libraries to iOS
developers.
Hooray!
But you might have also noticed that there are sometimes
a bunch of different CocoaPods that all
refer to the same library.
For example, for Google Analytics,
there's Google Analytics iOS-SKD, GoogleAnalytics,
and Google/Analytics.
So what's the deal?
Are these any different and, if so, which one should you use?
Find out the answers to these questions
and many more of life's mysteries
on this episode of Route 85.
[MUSIC PLAYING]
Hi, there.
I'm Todd Kerpelman and let's go ahead
and review these three Google Analytics CocoaPods, shall we?
So this first one, GoogleAnalytics iOS-SDK
was created by a couple of loyal fans on the internet
back before Google start building its own CocoaPods.
Since then, it's been deprecated in favor of the Google one.
So I wouldn't use it if I were you,
unless you like deprecation warnings, I guess.
Weirdo.
That said, if you've got a project that's
been around awhile or are watching an older YouTube
tutorial, you might see this one mentioned,
so it's good to know what it is.
But you know what?
Let's remove this one from the running for now.
See ya.
[SCREAMING] [CRASH] That was unnecessarily violent.
So, as for these next two, you're
going to see this pattern happening
a lot in the CocoaPods that Google provides.
You're going to see GoogleAnalytics
and Google/Analytics.
Similarly, there's GoogleSignIn and Google/SignIn,
GoogleCloudMessaging and Google/CloudMessaging,
and so on and so forth.
You get the idea.
So what's the difference between these?
The short answer is that the Google/CocoaPods include
everything these other ones do, plus some utility
files to make your life a little easier.
Let me explain.
See, around the same time we introduced CocoaPod support
for iOS, we also announced this cool new configuration tool
designed to get you up and running really quickly
on a bunch of Google services.
Here, you can see it in action.
I'm creating a new iOS project and I'm
going to enable a number of services for it,
using this new configuration tool.
Here you can see that I'm enabling GoogleSignIn
and it's automatically setting up an OAuth client ID for me,
using sensible defaults for everything.
I can also create a new GoogleAnalytics property
without having to jump to the GoogleAnalytics page,
enable app invites for my app, and get some test ad
units from AdMob, without having to the AdMob site.
So on and so forth.
Normally, I'd have to visit like two or three consoles
to get all this work done but now
I can do it all in one place, which is nice.
And then you can see that, when I'm done here,
I have a p-list file that I can download.
What's that all about, you ask?
I'm glad you asked.
Good question.
See, this file contains a bunch of constants
I can use to configure these services that I'm setting up,
things like my GoogleAnalytics tracking ID, my OAuth client
ID, AdMob test IDs, and so on and so forth.
In the past, you had to copy and paste these constants
for all these various developer consoles
into your code, which left an awful lot of room for error.
But now, thanks to a nice little utility library we've created,
you can tackle a lot of these configuration steps
with one single configure with error call.
When you call this method, Google
will find p-list file that you've added to your project,
grab the constants from there, and configure your Google
libraries for you, using these constants.
But this only works if you have the Google/Analytics
pod installed.
You see, the Google/Analytics pod
is a superset of the GoogleAnalytics pod.
It contains GoogleAnalytics along
with some of the utility libraries
you need to do things like read in that p-list file.
If you were to just use the GoogleAnalytics
CocoaPod, the version without the slash,
it would give you GoogleAnalytics
without any of the utility libraries.
Now, that would still work too, as long
as you set up your tracker the old-fashioned way,
which means calling GAI sharedInstance tracker
with tracking ID and copying and pasting
that constant from the GoogleAnalytics console.
So which one should you use?
Well if you've got an existing project and you're just
looking to replace the old GoogleAnalytics
iOS-SDK CocoaPod with the official one,
you can probably get away with using GoogleAnalytics,
the version without all the helper libraries,
because you're already setting the tracker ID manually.
Now, granted, using the Google/Analytics CocoaPod
will also work.
It'll just give you a few libraries
you don't necessarily need.
Go on, get out of there, you crazy kids.
Now, on the other hand, if you're creating an app from
scratch, I would recommend using the Google/ version
of the CocoaPod and configuring everything up using the new
configuration flow.
So there you go, folks, mystery solved.
Give these new CocoaPods a try and, more importantly,
give this new setup flow a try.
It is the most fun you'll have all day configuring
API libraries.
And I will see you soon on Route 85.
[MUSIC PLAYING]