Blog Archives

Basic Facebook Messenger Integration on iOS

Dude, it’s April 2015. What.

Hi everyone! I’m going to completely ignore the fact that I haven’t posted anything for 6 months. Let’s move on, shall we?

Today we’re going to demonstrate basic integration of Facebook’s new Messenger platform straight into your iOS app. What does basic mean? Well basically we have two options for sharing content through messenger:

1. Basic integration – This option is… pretty basic. It allows sharing images, GIFs, audio and video. People will see your app’s name and logo but the integration will not go as deep as the other form of integration which is:

2. Optimized integration – Gives you the opportunity to integrate your app with Facebook Messenger in such a way that you can generate engagement and user growth (content shared with your app will include an “Install” or “Reply” button which will transfer the user to the app store or back to your app, which is awesome). This option is a bit more tricky to implement and also requires submitting your app for Facebook to review but is probably worth the trouble.

Having said that, I will now demonstrate basic integration. Technically they aren’t very far apart and after you’ve understood basic integration, moving on to optimized integration is simple. For more information see Facebook’s official guide.

Introducing the Llama Generator™

I know that Llama sharing has been a widely controversial matter worldwide and while I don’t wish to create further conflict, I think it’s important to raise awareness. This is why I have created the Llama Generator app. What does it do? Well, it generates and shares Llamas straight into Facebook messenger. Let’s get started.

Step I: Download, install and integrate the Facebook iOS SDK

For basic (or any) Messenger integration, you are required to install and set up Facebook iOS SDK within your app. The setup is much more straightforward today than it used to be – basically all you need to do is:

  • Download and install the SDK
  • Drag the basic framework files into your project without copying (FBSDKCoreKit, FBSDKLoginKit and of course FBSDKMessengerShareKit)
  • Create a new Facebook app and get a Facebook app ID
  • Update your app’s bundle identifier on your Facebook app’s settings page:

  • Configure your info.plist with your app ID like so:

Note: If you get a build error while testing FB login, try changing the target setting of “Allow Non-Modular Includes in Framework Modules” to YES. (Source)

Step II: Set up content sharing easily

You won’t believe how easy it is to broadcast your content into Messenger now that everything is set up. Because we’re in the business of sharing Llamas, we’re going to demonstrate sharing UIImage content, though it is just as easy sharing GIFs, audio or video (all as NSData objects) similarly.

Our app’s only View Controller consists of 3 UIButtons, all hooked up to their respective outlets.

@property (weak, nonatomic) IBOutlet UIButton *btnShareDalaiLlama;
@property (weak, nonatomic) IBOutlet UIButton *btnShareDragonLlama;
@property (weak, nonatomic) IBOutlet UIButton *btnShareVikingLlama;

All three UIButtons are set to trigger the same IBAction on touch up inside:

- (IBAction)shareLlamaPressed:(UIButton *)sender
{
    /**
     First, let's determine which Llama we want to share.
     */
    NSString *imageName = nil;
    if (sender == self.btnShareDalaiLlama)
    {
        imageName = @"dalai_llama";
    }
    else if (sender == self.btnShareDragonLlama)
    {
        imageName = @"dragon";
    }
    else if (sender == self.btnShareVikingLlama)
    {
        imageName = @"viking";
    }

    /**
     Here we load the content into a UIImage
     */
    UIImage *imageToShare = [UIImage imageNamed:imageName];

    if (imageToShare)
    {
        /**
         Before calling the shareImage: method, we need to make sure we have image sharing capabilities.
         */
        if ([FBSDKMessengerSharer messengerPlatformCapabilities] & FBSDKMessengerPlatformCapabilityImage) {
            /**
             Now we share. For basic integration we need to pass in "nil" as options.
             */
            [FBSDKMessengerSharer shareImage:imageToShare withOptions:nil];
        }
        else
        {
            NSLog(@"Error - Messenger platform capabilities don't include image sharing");
        }
    }
    else
    {
        NSLog(@"Error - There was a problem loading image named %@",imageName);
    }
}

Now let’s launch the app and choose a llama:

Tapping on any of the buttons triggers shareLlamaPressed: which will load the proper UIImage and pass it on to Messenger. Messenger will present the content and ask you about the recipients. Choose. Send. Just like that. Now all that is left is to spread the joy (and the Llamas).

Enjoy!

The power of concurrency

Hi everyone, and welcome to Saturday night’s advanced session regarding concurrency in iOS.

We all know that some of Apple’s more powerful devices come equipped with multiple cores and we mostly just trust the operating system to utilize this advantage whenever possible, right? Well, turns out there are some cases where we need to explicitly tell the operating system – ‘hey, this code should be executed concurrently’ (iOS is great, but it’s not a magician). Today, we will discuss one of these cases – concurrent enumeration.

Let’s say we have a huge data collection of independent data points and that we wish to execute some heavy mathematical operation on each of them. Now the mathematical operation(s) we wish to apply on a single object is completely orthogonal to all other objects meaning – this is code that’s ideal for running concurrently between processor cores. The way to do this is to enumerate this data collection with the enumerateObjectsWithOptions:usingBlock: method, like so:

[[arr copy] enumerateObjectsWithOptions:NSEnumerationConcurrent usingBlock:^(NSNumber *num, NSUInteger idx, BOOL *stop) {
    //Do some heavy mathematical stuff with 'num'
}];

Just to emphasise the performance gain in using this method rather than fast enumeration, check out the output of running a similar scenario on the iOS simulator (yes, that’s why you see 4 cores):

Using simple, fast enumeration:

Simple

Simple enumeration – takes about 5 seconds to run 10000 iterations. You can see that operations run on one core, while the others are simply kicking back with a beer.

 

Using block enumeration with the NSEnumerationConcurrent option:

Concurrent

Now THAT’S team spirit! About 0.5 seconds to run 1000000 iterations. Unbelievable performance gain.

 

That’s it for today! Hope you find creative, safe ways to use this technique and remember – with great power comes great responsibility, so don’t abuse this API by running things in parallel that shouldn’t.

Quick tip: Bridging the gap between ARC and MRR

Since ARC was introduced, more and more developers have seen the light and joined the hype – it’s less prone to human error, it saves us a lot of code and of course it reduces the headache associated with manual retain-release or ‘MRR’. Of course I believe that a good Objective-C developer needs to be familiar with MRR just as any of us were back in 2011, though I always encourage starting new projects with the “use ARC” checkbox ticked on.

One of my favorite benefits of the way ARC does things is that it won’t let you call methods that aren’t visible / defined in your code. This means that there are naturally many less run-time exceptions of the all time favorite “unrecognized selector sent to instance” kind:

Thanks ARC! How responsible of you to say so…

But things weren’t always this convenient. Objective-C is known to be the relaxed stoner neighbour of programming languages. It lets you pass virtually anything to anything else, doing all the work dynamically at runtime and giving you a false sense of security while you write your code. In the pre ARC era if you weren’t careful enough, your app would have the potential to crash more frequently than an airline in southeast Asia during monsoon season:

Hey man relax, I mean come on… what’s the worst that can happen? Hey are you gonna finish those fries?

So what if we are still stuck on MRR? What if we’re working on an old project or simply want to leave memory management to ourselves? Are we doomed to work with this inconvenient disadvantage? Nope. Just add “-Werror=objc-method-access” to your “warning flags” section in the target build settings and this specific warning will turn into an error. Enjoy!

Quick Fix: Facebook release an iOS SDK update. Time for renovations.

Update: 

Looks like the people at Facebook are hard at work… a couple of weeks after writing this post, Facebook released yet another (pretty major) update to the SDK. Find out what you need to do here:

https://developers.facebook.com/docs/tutorial/iossdk/upgrading-from-3.2-to-3.5/

Since September 2012, Facebook has kept the iOS SDK on the down-low for some reason and the latest version of the SDK up until a few weeks ago was 3.1.1. This, in my opinion was a huge problem for developers that had to settle for a hybrid, half-baked SDK that used deprecated methods as a formal practice. For instance, in order to invoke facebook dialogs, you had to import the “Deprecated Headers” folder and utilize it’s methods. How lame.

Well, the good news is that 3.2 (and 3.2.1 following very shortly after) is out and it contains many improvements, better error handling and most importantly – uses blocks instead of delegation wherever it can. You will no longer find yourself importing the deprecated headers in order to open a web dialog and from now on you can use the new FBWebDialogs class to do your magic.

facebook__y_u_no____by_jaret246-d4arl9w

Natural response, I get it.

Alongside the SDK Facebook did some great work and released more useful tutorials to make sure the transition to the new SDK is smooth and clear:

I highly recommend taking a couple of hours to upgrade your code to support these API changes – you never know when deprecated methods will start breaking things…