CSS Tips CSS Tips

How to UIImagePickerController iPhone

These are notes from Lecture 16 of Paul Hegarty’s iPhone App Dev course.

UIImagePickerController is just a modal view controller to get media from your camera of photo library.
Modal means you put it up with presentViewController:animated:completion

Usage
1. Create it with alloc/init and set delegate.
2. Configure it (source, kind of media, user editability).
3. Present it.
4. Respond to delegate method when user done picking media.

In this example we are going to allow ourselves to take a picture and put it in our KitchenSink view.

Create a button to trigger taking a picture with an outlet called addImage.

ViewController.m

Then import the MobileCoreService library (click here for reminder on how to do this).

Note: UIImagePickerController is in fact a UINavigationController. And it has a property called delegate as well. It’s overloaded.

So when we implement the UIPickerControllerDelegate we also have to say we are a UINavigationControllerDelegate.

@interface KitchenSinkViewController()

Now do all the work to figure out what kind of device you are on, and what kind of pictures you can take:

Now need to implement the image picker delegate methods:

Can’t demo this because I build project against iPad and for some reason doesn’t work when I deploy to my iPhone.

How to import external libraries in XCode

Sometimes we need external libraries that don’t come by default with XCode (MobileCoreServices, MAPKit).

Here’s how to import them using XCode 4.2.1.

Click the blue folder at the top of your project:

Click the build phases tab button near the top

Expand the Link Binary with Libraries

Then add the libraries you want

Voila!

How to add an action sheet to your iPhone application

These are personal notes take from Lecture 16 of Paul Hegarty’s iPhone App Dev course.

Create a button and an outlet to your view controller to trigger the popping up of your action sheet.

Create a property for the action sheet (you pretty much want to do this for any popover as you will need to track whether it has already been created).

You can make the reference weak (would normally be strong for an outlet) because you only care if it exists or not.

Then in your button target create the action sheet, handling the case where the action sheet might already be created.

Implement the UIActionSheet interface:

Then react on action sheet button click:

Voila!

Couple of things to note about UIActionSheet

Special popover considerations: no cancel button
- action sheet in popover does not show cancel button
- doesn’t need because clicking outside popover dismisses it

Special popover considerations: the popovers passthrougViews
- if you showFromBarButtonItem:animated it adds the toolbar to popover’s passthroughViews
- this is annoying because repeated touches on the bar give multiple action sheets!
- something you just have to handle

Special popover considerations: bar button item handling
- have a weak @property in your class that oints to the UIActionSheet
- set it right after you show the action sheet
- Check that @property at the start of your bar button item’s action method.
- if it’s not-nil (since it is weak, it will only be non-nil if it’s still on screen), just dismiss it
- if it is nil, prepare and show your action sheet

ChiliStats – Free Simple and Open Source PHP Web Stat

Chilistats is a simple, fast and convenient PHP and mySQL statistic counter. You can view all your web stats info in just one view.

Segue delegation example using iPhone – KitchenSink

These are some notes on the KitchenSink example covered in Lecture 15 of Paul Hegarty’s iPhone course at Stanford. Go there to watch the video for the full story.

What’s going on

This example let’s a user click a button called ‘Add Label’ which then smooshes them off to a modal view controller where they are asked to enter the name of a label they would like to see appear.

This example shows how to make a model view controller (which is just a regular view controller with the transition set to ‘modal’ rather than ‘push’).

The more interesting bit is how the segue and delegate work.

Basically the ‘prepare for segue’ set’s things up that the view you are transitioning to needs. In our case we setup the question, and some answer text we’d like to display in the initial textfield box.

KitchenSinkViewController.m

Then in the view controller we are transitioning to, we read it off:

AskerViewController.m

To communicate back to the calling view controller we came from we use delegates. Asker sets up a protocol, which KitchenSink implements, and this is how to tell the caller what text the user entered in the textfield.

Then when the user finishing typing (or the textfield loses the caret) this gets called (because we implement UITextFieldDelegate).

If the textfield is blank, just dismiss the dialog. Else send our delegate a message containing the text the user entered and they will dismiss the dialogue.

KitchenSinkViewController.m

Here is the protocol we implement. And after grabbing the answer and creating a label, we dismiss the view controller ourselves.

That’s it! Great example of how to use delegates with model view controllers with a modal dialog thrown in.

Using CSS To Create a Fixed, Content-Overlapping Footer

In this tutorial, I demonstrate how to create a footer that features an image that is (1) always positioned on the bottom of the screen and (2) that slightly covers some of the content area to create a nice design overlay. Aside from the image creation in Photoshop, I only use CSS and HTML to create this page. This tutorial continues where the previous left off, with some minor formatting modifications. To see the previous tutorial, visit: www.youtube.com In the video, I mention that I will touch on why I use Portable Network Graphics (PNGs), but I forgot to mention it. Basically, the upsides to this image format are a relatively small file size and support for transparency. Please note that this tutorial features one of several methods available to create a fixed, overlapping footer. You will have to tailor your footer width, height, and position for your own needs.

How to Add Custom Post Type to XML-Sitemap Generator

The Problem

We recently released a new Pro Business Guide named Facebook Fan Pages for Business on our other site. We created a landing page using Premise. Premise allows for the creation of several types of landing pages with some cool features. Read more here.

The Premise landing pages are created as custom post types aptly named “Landing Page” and there are several types of landing pages to choose from. Because these are custom post types, they do not show up in your site feed (which is OK because we don’t want them to at this point), but they also do not show up in our XML Sitemap…and of course we DO want them there so search engines can easily index them and be updated of additions and changes.

We are using the XML-Sitemap Generator plugin (version 3.2.4 at time of writing). This plugin creates and updates your XML Sitemap whenever you add a new page or post BUT it does not account for custom post types.

We did our due diligence and read through the plugin documentation and forum threads, and even found a plugin that hooks into the XML-Sitemap plugin to include custom post types, but decided not to use it because of forward compatibility if the XML-Sitemap plugin gets updated to include custom post types.

The Fix

The solution to adding our custom post types to the XML-Sitemap plugin was simple, thanks to the forward thinking of the plugin developer. He included an option to add pages to the Sitemap manually by entering the URL to the page. It had been awhile since we visited the plugin settings, so we didn’t realize it was so easy right away.

Click to Enlarge

After entering the URL to our Premise custom post type page and configuring a few settings, all we had to do next was use the “Rebuild Sitemap Manually” link to rebuild our Sitemap so it would pick up our manually entered URL.

Click to Enlarge

The Result

You can clearly see in the image below that our Premise custom post type page has been added to our Sitemap.

Click to Enlarge

Update

The solution presented above worked great for our immediate needs, but what if you have dozens or even hundreds of Custom Post Types you need to add to your XML-Sitemap?

1. A function that specifically adds them:
http://www.getupandrunning.net/2010/06/adding-custom-content-types-to-the-sitemap/

2. Using Joost’s SEO plugin for WP which has this feature built-in:
http://yoast.com/wordpress/seo/#xml-sitemap

There is a plugin somewhere that hooks into the XML-Sitemap Generator plugin too, but I can’t seem to find it at the moment.

[css][tip] round corner of html element

Following is the css code for curving the html element corner:

It works in all commonly used browsers.

Enjoy CSS

jQuery vs MooTools: Choosing Between Two Great JavaScript Frameworks

The Mottos Say It All

If you go to the jQuery site, here’s what it says at the top of the page:

jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.

…and if you go to MooTools, this is what you’ll find:

MooTools is a compact, modular, Object-Oriented JavaScript framework designed for the intermediate to advanced JavaScript developer. It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API.

I think this really sums it up. If you ask me (and you’re reading this, so I’ll assume you just have), the question isn’t about which framework is better or worse. It’s which one of these things above do you want to do? These two frameworks just aren’t trying to do the same things. They overlap in the functionality they provide, but they are not trying to do the same things.

jQuery’s description of itself talks about HTML, events, animations, Ajax, and web development. MooTools talks about object oriented-ness and writing powerful and flexible code. jQuery aspires to “change the way you write JavaScript” while MooTools is designed for the intermediate to advanced JavaScript developer.

Part of this consideration is the notion of a framework vs a toolkit. MooTools is a framework that attempts to implement JavaScript as it should be (according to MooTools’ authors). The aim is to implement an API that feels like JavaScript and enhances everything; not just the DOM. jQuery is a toolkit that gives you an easy to use collection of methods in a self-contained system designed to make the DOM itself more pleasant. It just so happens that the DOM is where most people focus their effort when writing JavaScript, so in many cases, jQuery is all you need.

Most of the code you write when you write MooTools still feels like JavaScript. If you aren’t interested in JavaScript as a language, then learning MooTools is going to feel like a chore. If you are interested in JavaScript and what makes it interesting, powerful, and expressive, then, personally, I think MooTools is the better choice.
The Learning Curve and The Community

First, jQuery is, by and large, easier to learn. It has an almost colloquial style that almost doesn’t feel like programming. If all you want is to get something working quickly without learning JavaScript, jQuery is probably a better choice for you. It’s not that MooTools can’t help you accomplish the same things, but I’ll admit that MooTools can be a little harder to get the hang of if you’re new to JavaScript and also that there are just a lot of resources out there to help you learn jQuery – more than there are for MooTools at least.

If you compare the jQuery community (see the “Discussion” page on jQuery) and the MooTools community (irc, mailing list, and unofficial forum) you’ll quickly discover two things: 1) the jQuery community is far larger (I attribute this mostly to the point I made above about how easy it is to learn, but also because…) and 2) they are more active in promoting the library. If you measure jQuery and MooTools on metrics like the number of people using it, the number of search queries run on Google, the number of books sold, etc, you’ll see jQuery is ahead by a wide margin.

To tell you why you might consider MooTools I’ll first need to talk a little bit about what both the frameworks do. Ultimately which framework you choose is going to come down to what you want to accomplish and how you like to program (and maybe even if you like to program, at least in JavaScript).
What JavaScript Is Good For

Part of making this choice is asking what you want to do with JavaScript. Let’s consider vanilla JavaScript. No framework; just plain old JS. JavaScript gives you native objects like Strings, Numbers, Functions, Arrays, Dates, Regular Expressions, and more. JavaScript also gives you an inheritance model – a somewhat esoteric model called prototypal inheritance (which I’ll talk about more later). These building blocks and the concept of inheritance are the bread and butter of any programming language and they have absolutely nothing to do with browsers or the web or CSS or HTML. You could write anything you wanted to in JavaScript. Tic-tac-toe, chess, photoediting, a web server, whatever. It just so happens that 99% of all the JavaScript out there is run in browsers and that’s what we think of it as. The programming language for browsers.

Understanding that the browser, the DOM, is just where we happen to use JS most of the time but that it’s actually a very robust and expressive programming language will help you understand the difference between MooTools and jQuery.
More Than Just The DOM

If you think of the tasks that we want to accomplish in JavaScript strictly in terms of “get stuff on the page and do stuff to it” then jQuery is probably the best choice. It excels at offering a very expressive system for describing behavior on the page in a way that doesn’t feel like programming sometimes. You can still use the rest of JavaScript to do what you want to do, but if you’re focused on the DOM – changing CSS properties, animating things, fetching content via AJAX, etc – most of what you’ll end up writing will be covered by jQuery, and what isn’t will likely be plain-old JavaScript. jQuery does provide some methods that aren’t about the DOM; for example, it provides a mechanism for iterating over arrays – $.each(array, fn) – or, for example, it offers a trim method for strings – $.trim(str). But there aren’t a ton of these types of utility methods, which is fine because, for the most part, if you’re just getting stuff out of the DOM, iterating over them, and altering them in some way (adding html, changing styles, adding event listeners for click and mouseover, etc) you don’t need much else.

But if you think of JavaScript’s scope in its full breadth, you can see that jQuery doesn’t focus on things outside of the DOM. This is one of the reasons it is so easy to learn, but it also limits the ways it can help you write JavaScript. It’s just not trying to be anything other than a solid programming system for the DOM. It doesn’t address inheritance nor does it address the basic utilities of all the native types in the JavaScript language, but it doesn’t need to. If you want to mess around with strings, dates, regular expressions, arrays and functions, you can. It’s just not jQuery’s job to help you do it. JavaScript as a language is there at your feet. jQuery makes the DOM your playground, but the rest of JavaScript is just not in its scope.

This is where MooTools is vastly different. Rather than focusing exclusively on the DOM (though, as I’ll get into in a bit, it offers all the functionality that jQuery does but accomplishes this in a very different manner), MooTools takes into its scope the entire language. If jQuery makes the DOM your playground, MooTools aims to make JavaScript your playground, and this is one of the reasons why it’s harder to learn.
Inheritance with JavaScript

The JavaScript programming language has some really awesome things about it. For starters, it’s a functional language, which means that it treats functions as high-order objects that can be passed around as variables just like any other object – strings or numbers for example. It’s designed with this concept in mind and many of the methods and patterns in it work best when you write code this way. It’s the difference between:

for (var i = 0; i < myArray.length; i++) { /* do stuff */ }

for (var i = 0; i < myArray.length; i++) { /* do stuff */ }

and

myArray.forEach(function(item, index) { /* do stuff */ });

myArray.forEach(function(item, index) { /* do stuff */ });

JavaScript has an inheritance model that is not quite unique but at least rather rare in programming languages. Instead of classes that are defined that can be subclassed it passes along traits through prototypal inheritance. This means that objects inherit directly from other objects. If you reference a property on an object that inherits from another object, the language inspects the child object for that property and, if it doesn’t find it, looks for it on the parent. This is how a method on, say, an array works. When you type:

[1,2,3].forEach(function(item) { alert(item) }); //this alerts 1 then 2 then 3

[1,2,3].forEach(function(item) { alert(item) }); //this alerts 1 then 2 then 3

the method “forEach” is not a property of the array you declare ([1,2,3]), it is a property of the prototype for all Arrays. When you reference this method the language looks for a method called forEach on your array, and, not finding it, then looks at the prototype for all arrays. This means that the forEach method is not in memory once for every array in memory; it is only in memory for the prototype of arrays. This is incredibly efficient and ultimately quite powerful. (Side note: MooTools aliases the forEach method as each)
Self Reference

Javascript has a special word: “this”. It’s hard for me to succinctly define what “this” is all about but, by default, “this” is the object to which the current method belongs. It allows objects to refer to themselves within their methods as they would otherwise have no means to do so. This becomes important when you create children objects and have numerous instances of that object; how else could the method of an object refer to itself? When the actual copy of the method exists on the parent, not the child, the “this” keyword allows these instances to refer to their own state. (here’s a much more complete description of the “this” keyword, and another from Mozilla.)

The “this” keyword allows objects that inherit from other objects to refer to themselves, but there are times when you may want to reference something else through “this”. This is called binding, wherein you specify a different “this” for a method. The “each” method on Array allows you to specify the bound object with a second argument. Here’s an example of where you might want to pass in a different “this”:

var ninja = {
weapons: ['katana', 'throwing stars', 'exploding palm technique'],
log: function(message) {
console.log(message);
},
logInventory: function() {
this.weapons.each(function(weapon) {
//we want “this” to point to ninja…
this.log(‘this ninja can kill with its ‘ + weapon);
}, this); //so we pass “this” (which is ninja) to Array.each
}
};
ninja.logInventory();
//this ninja can kill with its katana
//this ninja can kill with its throwing stars
//this ninja can kill with its exploding palm technique

var ninja = {
weapons: ['katana', 'throwing stars', 'exploding palm technique'],
log: function(message) {
console.log(message);
},
logInventory: function() {
this.weapons.each(function(weapon) {
//we want “this” to point to ninja…
this.log(‘this ninja can kill with its ‘ + weapon);
}, this); //so we pass “this” (which is ninja) to Array.each
}
};
ninja.logInventory();
//this ninja can kill with its katana
//this ninja can kill with its throwing stars
//this ninja can kill with its exploding palm technique

In the example above, we bind ninja (which is “this” inside the logInventory method) to the method we pass to the array so that we can refer to the log property of ninja. If we didn’t do this, “this” would be window.

These are just some examples of the power and expressiveness that JavaScript has to offer – inheritance, self reference and binding, and efficient prototype properties. The bad news is that vanilla JavaScript doesn’t make these powerful things very useful or accessible, and this is where MooTools starts. It makes these types of patterns easy and rather pleasant to use. You end up writing more abstract code, and in the long run, this is a good thing – a powerful thing. Learning how these patterns are valuable and how to use them properly takes effort, but the up side is that the code you author is both highly reusable and much easier to maintain. I’ll talk about these two things a bit more in a minute.
MooTools Makes JavaScript Itself More Fun

Because MooTools focuses on making the JavaScript API itself more stable and coherent, it is focused less on giving you an interface that “changes the way you write JavaScript” and more on making JavaScript as a whole less frustrating; MooTools is an extension to the JavaScript language. MooTools tries to make JavaScript the way it is meant to be. A significant portion of the core library is spent on augmenting Function, String, Array, Number, Element and other prototypes. The other big thing it offers is a function called Class.

Now, Class looks to many people like it’s trying to recreate a more classical inheritance model that one might find in Java or C++, but that’s not the case. What Class does is make the prototypal inheritance model of JavaScript easier for you and me to access and take advantage of. I’ll note that these concepts are not unique to MooTools (other frameworks offer similar functionality), but both of these concepts are not present in jQuery. jQuery does not offer an inheritance system nor does it offer any enhancements to native objects (Function, String, etc). This is not a deficiency of jQuery as the authors of jQuery could easily offer these things. Rather, they have designed a toolkit with a different goal in mind. Where MooTools aims to make JavaScript more fun, jQuery aims to make the DOM more fun and its designers have chosen to limit their scope to that task.
jQuery Makes the DOM More Fun

And this is why jQuery is more accessible. It doesn’t ask that you learn JavaScript inside and out. It doesn’t throw you into the deep end with prototypal inheritance, binding, “this”, and native prototypes. When you get started with jQuery in its official tutorial, this is the first jQuery code example you find:

window.onload = function() {
alert(“welcome”);
}

window.onload = function() {
alert(“welcome”);
}

and here’s the third:

$(document).ready(function() {
$(“a”).click(function(event) {
alert(“Thanks for visiting!”);
});
});

$(document).ready(function() {
$(“a”).click(function(event) {
alert(“Thanks for visiting!”);
});
});

If you read the MooTools book or the MooTools tutorial (both of which I authored) they start in a much different place. While you can skip ahead and quickly learn about effects and the DOM, if you want to learn MooTools, you have to start with things like Class, and, I’ll admit: if you’re new to programming, or you just want to get something working on your site without having to learn everything about JavaScript, chances are jQuery is going to look a lot more friendly to you.

On the other hand, if you want to learn JavaScript itself, MooTools is a great way to do it. It implements a lot of things that JavaScript is going to have (many of the methods on Natives are just the JavaScript 1.8 spec and beyond). If you’re used to programming, especially both object oriented and functional programming, MooTools has a lot of design patterns that are very exciting and expressive.

Decision Time

jQuery focuses on expressiveness, quick and easy coding, and the DOM while MooTools focuses on extension, inheritance, legibility, reuse, and maintainability. If you put those two things on opposite sides of a scale, the jQuery side translates into something with which it’s easy to get started and see quick results but (in my experience) can turn into code that’s harder to reuse and maintain (but really that’s up to you; it’s not jQuery’s problem, per se), while the MooTools side takes longer to learn and requires you to write more code upfront before you see results, but afterwards is more reusable and more maintainable.

Further, the MooTools core does not contain every feature you can imagine and neither does the jQuery core. Both frameworks keep their cores rather lean, leaving it to you and others to write plug-ins and extensions. Their job is not to give you every feature you could want but to give you the tools so that you can implement anything you can imagine. This is the power of JavaScript, and of JavaScript frameworks in general, and both frameworks excel at it. MooTools takes a more holistic approach and gives you tools to write anything you can imagine beyond the scope of the DOM, but pays the price by having a steeper learning curve. MooTools’ extensible and holistic approach gives you a superset of jQuery’s features, but jQuery’s focus on a slick DOM API doesn’t preclude you from using the native inheritance methods of JavaScript or from using a class system like MooTools if you want it.

This is why I say that both frameworks are excellent choices. My effort here has been to highlight the differences in philosophies between the two codebases and highlight their advantages and disadvantages. I doubt I’ve been successful in keeping my preference for MooTools completely in check, but hopefully this has been helpful. Regardless of which framework you choose to work with, you now know a lot more about both, hopefully. If you have the luxury of time, I strongly recommend implementing a site with each. Then write your own review of them both and maybe your perspective will highlight some things I missed.