Installing Intl on PHP and MAMP

Compiling the Intl extension for PHP under MAMP is actually quite simple. I explain how and include a few solutions to “gotcha” problems along the way.

If needed, download the relevant ICU package, and extract it. Ensure your MAMP PHP binary is in your $PATH environment string. Snippet from StackOverflow:

Opening a Terminal to the extracted directory, I then compiled the code:

As I did not have autoconf, I installed it using Brew. Alternatively, you can compile it from source if you do not have Brew.

The next few steps are where I had some problems. I was getting strange errors:

fatal error: 'php.h' file not found
and
"ERROR: `phpize' failed"

Digging around, it turns out there’s a bit of a strange bug here. It can be quite simply solved by downloading/updating XCode from the App Store and symlinking the XCode SDK headers to the MAMP directory:

After this, simply install Intl using PECL:

If you’ve downloaded and installed XCode just now, you may get the error:

This is simply a MacOSX/XCode licensing issue. You can solve it by launching XCode or just typing:

to trigger the licence terms and agreements prompts. Afterwards, run the pecl install command again to install the extension.

Once that’s done, add the extension to your PHP config. In MAMP, this can be found under File > Edit Template > PHP > PHP 5.6.10. Add extension=intl.so to the list of loaded extensions.

MAMP should be restarted for this to take effect.

If you have any comments/questions, please leave them below!

Save Snapchat files (Android) – Part 2

SnapchatTake the headache out of saving your Snapchat files from Part 1 by automating the entire process using Tasker.

Edit: This post is now obsolete! Snapchat have upgraded their app, and since the time of writing, many free apps have appeared on the Google Play and Apple App Stores.

In the previous instalment, we set up our rooted device to save Snapchat files using a handy little script. Although this works, it’s quite tedious to repeatedly have to call the script whenever you receive a snap. To save ourselves some time, we’re going to set up our script to run automatically using Tasker.

What you’ll need

Set up
I recommend reading through this guide before starting. The process is rather long but quite simple.

  1. Open up Tasker. Click “+” to create a new Task and select the “Application” context option. Find Snapchat from the list and tap to select it. Click “App selection” in the corner to go back to the main screen once that’s selected.
  2. Now that we have a context specified, we need to tell Tasker what to do when the app launches. Click “New Task” to open up the task creator, then click “+” to add an action.

  3. From the popup, select “Plugin” from the list of available actions, then choose Secure Settings.
  4. We now need to configure exactly what our Secure Settings action is doing. Click “Edit”, then find “Run Command”. On the “Run Command” configuration screen, enter the path of your script from part 1. In my example, this is /data/snapchat.sh. Note: I’ve since updated the path due to some people having difficulties with /etc.

    DO NOT FORGET to check the box labelled “Use Root”, as this is responsible for ensuring that the script runs with the proper permissions (and actually does something). Also, I like to enable “Show Notification” so I know that the action is running.

    After naming the action, you can save your configuration by clicking the save icon (bottom left) or by tapping the “Run Command”/back header in the top corner and selecting the save option from the popup dialog.

  5. Click the headers in the corner to go back to the main screen. This will also serve to save your changes. Once this is done, you should be able to boot up Snapchat for a test run.

If you didn’t run into any trouble throughout the guide, Snapchat should now trigger your script, saving any downloaded snaps to your specified directory.

Tips
There is some weird behaviour that may pop up when using the script/Tasker combo. Here are some things I’ve encountered during my time with the script and how to work around them.

  • The script is not saving snaps
    This is either because 1) the script is faulty; or 2) Snapchat has not downloaded your files. As there is occasionally a delay, I like to load Snapchat, wait for the files to load, then check my gallery for the files. The usual culprit is poor phone reception.
  • The saved snaps are not showing in the gallery
    This is the most annoying “bug” that I encounter. Android caches the thumbnails for the gallery, and the script bypasses any media refresh hooks. You can manually refresh the gallery by rebooting the phone, taking a photo, or use an app. I used SD Card Rescan and it works amazingly. It can take a while to scan fully, depending on the size of your card, so bear that in mind.
  • SO MANY DUPLICATES
    Due to the nature of the script, it is very indiscriminate when it comes to saving files. It will always attempt to save whatever it finds, duplicate or not. I just delete them.

These are the three main things I run into regularly. I’m happy to investigate any other weird things posted to the comments.

Hopefully this guide made sense, and you are now happily (read: sneakily) saving your incoming Snapchats. Feel free to leave a note below if this worked/did not work for you.

Happy snapping!

Help! register_activation_hook isn’t working!

If you’re developing a plugin, chances are you’ve been caught out by the WordPress activation/deactivation hooks.

I’ve been working on an Instagram plugin for WordPress, and in doing so have needed to use the functions register_activation_hook and register_deactivation_hook.

However, I – like many others, it seems – can’t get the hooked functions to execute. They simply don’t fire. To illustrate the problem, here’s an example from the code:

I would fully expect the system to execute the functions hooked within the constructor. Had that been the case, I wouldn’t have lost a day debugging a non-existant problem.

Finding a solution

Of course, everyone’s setup is different. There were many suggestions for fixing the problem. For the sake of usefulness, here’s the other major suggestion:

Your global variables aren’t global

If (like me), your plugin is a global, you actually need to explicitly define it as such with the global keyword. For example, the snippet

should instead by written this way:

Why? Well, for this, we need to consider how the plugin has its code loaded. After installation, your plugin has its code included “normally” with standard includes. This creates the global scope that you would expect. However, when you register a function with register_(de)activation_hook, it is called from within another function’s scope, effectively hiding your non-explicit globals.

Confused? Consider the plugin example from earlier. The variable $my_instagram is declared in the global scope, with global visibility. When your code executes, your plugin is included at the same scope, meaning you will have access to the variable (as they share the same suitably-high scope). Due to the way the hook/filter system in WordPress works, your activation/deactivation hooks are executed within a localised (not global) scope.

Screen beans - the only thing worse than scope.
Screen beans – the only thing worse than scope.

This scope-confusion applies to all functions created using create_function, or (in our specific example), functions called with call_user_func (and call_user_func_array). These functions have their own scope and are thus shielded from the cheap-and-nasty pile of implicit “globals” that haven’t been properly declared as such.

You can find a suitably more technical (and probably correct) write-up at the WordPress Codex page for register_activation_hook.

tl;dr: Explicitly declare your globals if you want them to work everywhere.

Ok, that’s great, but what’s the answer?

After having accidentally (and rather unwillingly) been given a very rough refresher on scope, I found that this was not my problem at all. Even running proxy functions (which eliminates scope issues) failed to call the functions specified in the hook.

After much trial and error (and I mean much), I found that the paths within register_(de)activation_hook were not matching the path found in plugin_dir_path. In fact, __FILE__ was returning a completely different path.

The problem? I had symlinked the theme directory in my install, meaning that __FILE__ returned a different path to plugin_dir_path. This is especially important, as the file path specified by the first parameter of register_(de)activation_hook is included before the function specified by the second parameter is called. So, if the path in the first parameter is wrong, you probably aren’t going to be executing many functions today.

The Fix

This is always my favourite part. To fix the symlinking problem, you just have to be very specific when you’re asking WordPress to execute a hook for you.

Fixing the first example, we get:

The most important changes occur on lines 1, 16, and 17. The first line fixes the definition by manually specifying the path using the base plugin directory (instead of an automagic WordPress search). Lines 16 and 17 specify the main plugin file itself as the path (instead of relying on __FILE__).

This allowed WordPress to find the plugin files without a hitch, which is especially important in the installation/uninstallation phases.

Moral of the story? Check your paths first.

Paths

LinkedIn – Lesson #1

My battle against recruiters continues with a strange and random request from LinkedIn.

I consider rejecting unsolicited LinkedIn mail my sisyphean punishment for some mysterious crime I did not commit. An ever-present tide of human ignorance washing against the grainy shore of my day, snuffing out what little hope I had left that the entire population was not – at some fundamental level – simply a dipshit.

It is no wonder, then, that I grew weary of replying to people who couldn’t do their job. The ever-persistent advance of this multi-headed hydra was eroding my enthusiasm for being a twat. Apathy was winning.

Another day, another email, and I replied with a terse “contact the manager”. A little while later, I was surprised to find the following response:

> Who is the GM?

Now, I’m no expert on LinkedIn (hell, I rarely venture from my own profile), but I certainly know how to click a link when I see one. Several, in fact. Sometimes in a row. So when the information you’re after is fewer clicks away than finding your inbox, you should probably just take the easier option. But if this is something you need to be told, I guess there is probably a greater concern here, right?

Instead of giving him a real answer, I decided to be a complete dick about it and go ahead and create this handy little video tutorial. Take note, LinkedIn trawlers.

I think my passion has returned.

 

Modal View Controller Example – Part 2

In the first part of this tutorial, we set up a pair of simple views in Interface Builder that we switched between modally. In this tutorial, we’ll make them somewhat useful and pass data between them using delegates.

The concept of protocols and delegates is an important and somewhat complex one, but I like to think of it in these simplified terms:

Basically, the object that implements our protocol agrees to implement the methods of that protocol. In the case of this tutorial, we’ll be connecting the modal view with our main view using a delegate.

Firstly, we’ll create the interface elements for our project. Open the ModalViewExampleViewController XIB file and create a button and a label as shown.

Next, add those interface elements to ModalViewExampleViewController.h. We’re also adding the necessary IBAction also:

Be sure to include the necessary additions to ModalViewExampleViewController.m:

Jump to Interface Builder and be sure to link the new elements with the properties we defined. Refer to Part 1 of this tutorial for a guide on how to do that.

The next step is key. We will create a basic protocol and then assign a delegate. Open up ModalViewExampleViewController.h and add this:

We then tell ModalViewExampleViewController to implement this protocol:

We also need to add the protocol’s method to the main implementation:

Once we have these in place, the next step is to set up a reference between the two views. What we will do is define a delegate inside of SampleView so that we can send messages to it.
Include the protocol in ModalViewExampleViewController.h and add the reference:

Be sure to synthesize the delegate in SampleViewController.m, and include the necessary header files.

So far we have defined a protocol inside of our parent view, and defined a delegate in our modal view. The next step is to link them together and make them useful.
Firstly, we’ll write the functions that will handle the messages. Replace the original definition of didReceiveMessage with this:

And also add the following code to showWithDelegate:

What we’ve done is create a SampleView object and assigned its delegate to be the parent view. That is, the parent view will be handling messages sent by SampleView.
Open up SampleViewController.m and add the code to send the message.

Compile the app and run it. You should be able to see the text “Hello World” passed from one view to another once you dismiss your modal view with delegate. You can extend this any way you like with additional controls on the modal view, such as sliders or text input.

Download the source code for this project here.

Modal View Controller Example – Part 1

In your iPhone app, you’ll probably be spending most of the time pushing new view controllers to the stack in order to show screen flow. Sometimes, though, you just want to popup a screen for quick display or input.

Here’s a quick demo/tutorial on the different standard modal views offered by iOS, including a simple way of passing generic string data back to the parent view. I’m assuming basic knowledge of iPhone programming, so feel free to skim if you’re comfortable.

First up, create a new Xcode View-Based application. I named mine “ModalViewExample”. Open up the NIB file “ModalViewExampleViewController.xib” and drag four buttons onto the screen as shown.

Now, we’ll begin attaching the buttons created in Interface Builder to our View Controller code. Open “ModalViewExampleViewController.h” and declare your buttons as IBOutlets (Interface Builder Outlets):

Make sure you synthesize the outlets in ModalViewExampleViewController.m, and release them in dealloc

Ok, so now we have some buttons declared in our class, and some buttons dropped into the interface. At this point, your app has no idea what the relationship is. We’ll set these relationships in Interface Builder.

Switch back to your NIB file, and select “File’s Owner” in the NIB Object Window. Select the Connections Inspector tab, and drag a connection from the hollow point to the Button object in your View. You can see what I mean in the screenshot below. Repeat for the other buttons on the page.

Basically, what we’ve told Xcode to do is relate the code-based objects with the interface objects we created. This allows them to pass messages back and forth.

The next step is to actually assign methods to the click events. Go back to your ModalViewExampleViewController.h file and add these methods:

You’ll also need to implement them in ModalViewExampleViewController.m:

We now have definitions for buttons, and the actions to go with them. To connect them, go to Interface Builder. Select one of your buttons and drag a relationship between the “Touch Up Inside” event in the Connections Inspector and the First Responder in the Object Window. Select the name of the method you created.

After connecting all the buttons to their relative objects and actions, you’ll actually need to make the app do something. This is where we will define a modal view to present to the user.

Add a new UIViewController subclass with XIB to your project. I named mine “SampleViewController”. Open the XIB in Interface Builder and drag a new button onto the screen.

Once you’ve done that, create an IBOutlet for the button and define an action as above.

Be sure to go to Interface Builder and assign the connections as you did above. Once that’s done, you’ll need to synthesize and release the dismissViewButton object in SampleViewController.m as you did in ModalExampleViewController.m.

Assuming all your connections are in place, it’s time to actually do something with them. Switch to your ModalViewExampleViewController class and replace your previous method definitions with the following code. Also be sure to add #import “SampleViewController.h” to the top of your definition in order to expose SampleView to your class.

Let’s take a very quick look at what we’re doing. First, we define an instance of the new SampleViewController class. We then give it a modal transition style, based on the values found in the UIViewController documentation. Sending it to the front is as easy as using presentModalViewController:animated: Take note that you should probably use the navigation controller to push modal views if you have one. (i.e. [self.navigationController presentModalViewController:animated:]).

To finish up, we’ll need to code a way to dismiss the modal view once it’s presented to the user. Jump to the SampleViewController class and add this code:

Once that’s in place, build and run the project. You should be able to click through the buttons and check out the range of different modal views iOS has to offer. Note that the page curl only works in iOS 3.2 or greater. If you’re compiling for lower versions, you’ll just get the default slide up animation.

In Part 2, we’ll add a delegate in order to pass values between the modal and non-modal views.

Download the sample project from this tutorial here.