Raised center TabBar button in Cordova / PhoneGap for iOS

A popular pattern in iOS lately (especially in apps with a focus on photo taking) is the raised / highlighted middle TabBar button. It’s easy enough to get a native TabBar in an iOS PhoneGap app using one of the two popular plugins (NativeControls and TabBar). There is even a great article on getting a raised middle TabBar button on iOS.

But not everyone using PhoneGap can comfortably turn that article into a modified TabBar plugin. There was even a recent thread on this topic in the PhoneGap Google Group recently.

Since I have done this in one of my apps, I thought I might post a quick outline on how to use the code in the iDevRecipes article above to get one of these buttons into one of the plugins above.

The Button Image

aperture-tab.png

This is the button I created for my app Pixfor. It’s basically just a green tinted screenshot of the middle third of a standard TabBar with an Aperture icon and a subtle shadow. You certainly don’t need to have a tinted gradient as well as your larger icon or whatever. That’s just a design decision. The great thing about how this works is that the touch goes straight through the added UIButton, so the highlight of the TabBar still happens so if your button image has transparency, it will show through nicely.

The button image is named aperture-tab.png and also has a corresponding aperture-tab@2x.png image for retina devices.

Note: these images (unlike the icons normally used in the TabBar plugins as icons) are added to the project through XCode as a resource, not just copied into the www folder with the other PhoneGap assets.

The JavaScript Code

For the JavaScript code, all you really need to do is create a TabBar item with an empty label and an empty icon.

For example, in NativeControls:

window.plugins.nativeControls.createTabBarItem("takepix", "", "", options);

and in TabBar:

window.plugins.tabBar.createItem("takepix", "", "", options);

The Objective-C Code

Pixfor happens to use the NativeControls plugin, but the code below should work in both.

They both have a method in their respective .m files that creates the TabBar (create in TabBar and createTabBar in NativeControls). *

Both these methods end with

[self.webView.superview addSubview:tabBar];

What we are going to do is add the following code directly after this line before the closing brace.

This code will add a custom UIButton using our image centered on our TabBar. Note the file name aperture-tab.png in the first line. The retina @2x version does not need to be explicitly referenced.

Pixfor's raised middle button

And there it is! Our special TabBar button.









* Line numbers only used for illustration. Please find the methods above in the plugin’s latest version.

Announcing the Read it Later plugin for PhoneGap (soon also for Cordova)

One of the developers working on the new PhoneGap-based Wikipedia Mobile was having some annoying issues with the PhoneGap ShareKit plugin and decided he’d rather just put the Facebook and Twitter sharing in with their individual plugins. 

He was happy with the decision where Facebook and Twitter were concerned, but lamented that the decision would mean there would no longer be support for Read it Later (http://readitlaterlist.com).

I had a look at Read it Later’s API and iOS SDK and it looked fairly straight forward, so when he asked if I would like to write a plugin for it I took on the challenge.

Just two hours later I had a shiny new PhoneGap plugin!

https://github.com/devgeeks/ReadItLaterPlugin

If you wanna be as cool as Wikipedia, run over to GitHub and clone it into your app now! 

Installation

This plugin allows you to save a URL to Read It Later from your app.

Add the plugin much like any other:

  1. Add the ReadItLaterPlugin.h and VolumeSlider.m classes to your Plugins folder in Xcode (use “Create groups for any added folders”)
  2. Add the ReadItLaterPlugin.js file to your www folder
  3. Add the ReadItLaterPlugin.js to your html file. eg:<script type="text/javascript" charset="utf-8" src="ReadItLaterPlugin.js"></script>
  4. Add the plugin to the PhoneGap.plist under Plugins (key: “ReadItLaterPlugin” value: “ReadItLaterPlugin”)

Next, get the Read It Later API iPhone Library and add it to your project:

  1. Download the library from Read It Later
  2. Unzip the library and examples
  3. Copy these four files into your Xcode project under the Plugins folder (again, use “Create groups for any added folders”)
    • ReadItLaterLite.h
    • ReadItLaterLite.m
    • ReadItLaterFull.h
    • ReadItLaterFull.m
  4. Get an API Key from Read It Later for your app
  5. Add your shiny new API key to the top of the ReadItLaterLite.m file you copied in above
    • static NSString *apikey = @"<api key here>";
  6. Add the name of your app (as you entered it to get your API key above) as well
    • static NSString *nameOfYourApp = @"<name of your app here>";

Finally, call the saveToReadItLater() method using a success callback and an object containing a url and a title:

Example

function onDeviceReady()
{
    var readItLaterPlugin = window.plugins.readItLaterPlugin;
    readItLaterPlugin.saveToReadItLater(
        function(){
            console.log("Successfully saved to Read It Later");
        }, 
        { 
            url: "http://github.com/devgeeks", 
            title: "Devgeeks on GitHub"
        }
    );
}

PhoneGap / Cordova plugin devs and users are in for a bumpy ride

It looks like those of us who rely heavily on plugins are in for a bad time.

Cordova devs working on 1.4.x began the process of deprecating some classes a great many plugins used, now it looks like the work on 1,5 and beyond is going to make the plugin landscape even shakier.

The work on the new unified js will be a great boon to many end users making it easier to develop for multiple platforms. Unfortunately, it looks like it is also going to be only a partial implementation on 1.5 and one that not only might break things for existing apps and/or plugins… but might not even be the final API we see shipped with 1.6…

…we’ve made no commitment on the plugin api (its never been official) so I don’t feel we’re breaking any promises

…and concerns about it are being dismissed.

I don’t know about you, but I think I might stick with 1.4.x for now unless a bug comes up that will make it worth it to me to work around these teething issues in the coming releases.

I do know the PhoneGap Google group, IRC and StackOverflow are gonna get an influx of confused devs very soon. I’m bracing for it.

PhoneGap plugins in iOS complaining about deprecations and what you might be able to do about it

In PhoneGap (in reality Cordova) 1.4.x some classes were deprecated in the effort to make it play nice as a component in an otherwise native app (as opposed to only being able to be the primary controlling view). This is causing some confusion when developers using this version try to use plugins written using those classes. Xcode is giving them warnings about the deprecation and making them worry.

The plugins affected are mostly those that pop up an entire native view controller over the top of the PhoneGap/Cordova app - EmailComposer, SMSComposer, Twitter and worst of all ChildBrowser.

The important thing to remember is that for now (1.4.x), although the methods are deprecated, they should still work just fine. They will warn you, but as a good friend of mine was fond of saying: “a warning is not an error”. The point of deprecation warnings are to warn you that what you are doing might go away some time in the future and to start thinking about a new way to do it.

AFAIK, the issue will be with the coming releases when the methods are actually removed (there is debate on if this should be soon… like 1.5 or 1.6… or wait for a major release like 2.0).

I am happy to update plugins and submit pull requests to the phonegap-plugins repo if the plugin is not being actively maintained or not overly complex. I have already submitted a pull request for an update to SMSComposer after someone asked for help in the PhoneGap IRC channel. As for any of the others affected, it might be that they will just use the deprecated calls until the upcoming plugin upgrade guide is ready I believe with 1.5.x.

In the case of most of the affected plugins, really all you should need to do is in the plugins PluginClassName.m file add in this initialization method just after ‘@implementation PluginClassName’ (note: this one might be optional, but most of the modern plugins seem to initialize self this way):

-(PGPlugin) initWithWebView:(UIWebView)theWebView 
{     
    self = (PluginClassName*)[super initWithWebView:theWebView];     
    return self; 
{

Then, where ever the deprecated ‘appViewController’ appears… change:

[[ super appViewController ] presentModalViewController:picker animated:YES];

to:

[self.viewController presentModalViewController:picker animated:YES];

This will make most of the basic plugins compile quite happily without warnings. Unfortunately… ChildBrowser not so much, but that plugin is far from simple. However, it is very popular so I am sure it will get some love before the deprecations truly take effect.

If you have any questions about this feel free to shoot me a message:

tommy AT devgeeks DOT org