The easiest way to display emoji icons in your app’s UI is to simply use a control that renders text, like a UILabel or a UIButton. Sometimes, though, you will want to render one of these characters into a UIImage so that you can manipulate the pixels somehow or simply to be able to show them in certain positions in certain controls that expect an image object.

In Speed Dialer Factory, I used emoji icons to make some options in table view cells a bit more recognizable:

In this particular case, I needed the emoji characters to be rendered into UIImages so that I could make them monochrome when the cells were disabled. In addition, using the image section of the table view cells allowed me to ensure that the labels of all of the cells were horizontally aligned.

Below you can find the source code for a UIImage category that I use for this. Here is an example how how I might use a method in this category to apply one of the above images into a table view cell:

And here is the source code:

UIImage+HGViewRendering.h:

UIImage+HGViewRendering.m:

Download the mode here: leg.xml

Note that since the leg syntax uses curly brackets ({}) to delimit actions in the grammar, and those actions are written in C (which also uses curly brackets a lot), the mode has to somehow be able to match a certain number of balanced pairs of these brackets. As far as I know this is not directly supported in the jEdit syntax highlighting mode system but I was able to use the “delegates” mechanism to implement support for two levels of matched brackets, which should be enough for any reasonable use (in any case, it’s easy to add further levels of such support to the mode).

To install this mode, add the following to the modes/catalog file in your jEdit user settings directory (select Utilities → Settings Directory in jEdit to find this):

Then copy the leg.xml file into the same directory with this file. See the Installing Modes section of the jEdit users’ guide for more information.

Since I don’t use the ProjectViewer plugin this macro has to have its own logic for determining where the “project root” is. The way it works is that it tries to find the root folder of the current project by way of searching for version control system folders (i.e. .git, .hg, .bzr, _darcs, .svn or CVS). The assumption is that as the script traverses the file system folder structure from the buffer’s location towards the root the first folder that has a Git, Mercurial, Bazaar or Darcs folder (or the last to have a Subversion or CVS folder) is the root. When the script finds the project root it switches the file browser to display it while keeping the UI focus in the editor field. If no project root can be found in this manner, the script sets the file browser to the directory that contains the currently open file.

Download the macro script itself here: Open_Root_of_Current_Project_in_File_Browser.bsh

You install it by dropping it into your jEdit user settings directory’s /macros folder (select Utilities → Settings Directory from the jEdit menu to find this location) and then running Macros → Rescan Macros. You can set a keyboard shortcut for this via the Shortcuts section of jEdit’s preferences and/or add a toolbar button via the Tool Bar section.

Here is the macro source:

This class is called CalStoreHelper and it provides you with two methods: one for getting events and the other for getting tasks. An example script shows you concretely how to generate different kinds of output. Below is a small excerpt that shows how to generate CSV output:

You can get the class by cloning the version control repository with Mercurial or by downloading an archive from the repository browser page (the bz2, zip and gz links at the top). Happy hacking.

Emoji and Unicode

Emoji is basically a Japanese term for emoticons used on mobile devices. The Wikipedia article has more information on the concept, but this part is the most interesting:

When transmitted, emoji symbols are specified as a two-byte sequence, in the private-use range E63E through E757 in the Unicode character space, or F89F through F9FC for Shift-JIS.

Now, that’s not true for Apple’s Emoji implementation — it’s apparently completely incompatible with the handsets from the Japanese carriers (see OpenRadar #6402446 for more info) — but the part about them being implemented as unicode symbols is still true in iOS, the code points used are just different.

I’ve made this demo page that lists unicode symbols and the hexadecimal code points for all the different Emoji that are available on my iPhone (iOS version 4). The demo page has a cache manifest so it should be available offline as well. If you’re currently on a desktop computer you won’t be able to see them so here’s a picture of what it looks like on the iPhone:

In order to be able to use these icons you need to have easy access to the hexadecimal unicode code points so this page should come in handy. If you instead prefer a native app for this, there are many you can choose from.

Using Emoji Symbols in HTML and CSS

User agent detection is usually cited as a bad thing, and with good reason — it’s often used when feature detection would be more appropriate, causing unexpected breakage in many edge conditions. When planning on using the iOS emoji on a web page, though, you really need to sniff the user agent in order to know whether the client is an iOS device and thus has a font that implements these unicode symbols in the expected way.

Here’s an example (in PHP) of how you’d detect iOS devices:

When you’ve detected the client to be an iOS device, you can offer them an additional stylesheet:

In this stylesheet you’ll then insert the Emoji symbols into whatever locations you’d like to use them in, and to do this you can use CSS2′s content generation mechanisms (in the examples below, we use code point E00E, which is the “thumbs up” Emoji):

Containing all the iOS-specific embellishments in one separate CSS file is, I think, the way to go, but if you want you can also insert these symbols directly into your HTML as special entities:

Big Caveats to Consider

This is a great way to add little graphical cues to your web app without having to deal with images (i.e. making or obtaining them, serving them, having the app load them, possibly caching them) but of course the downside is that they are only available on Apple’s iOS devices, which makes this trick quite useless unless you’re concentrating completely on the iPhone/iPad/iPod Touch axis.

The key takeaway from this should be that there’s this neat trick you can use but if you need your icons to be visible in all clients you should forget about these and just use images for everyone (it’ll be much easier).

Demo

Here’s a small demo where you can see the feature at work: Font List Example. The sources shown below are used in this demo.

Implementation

We need a small Flash app and some Javascript. Below is the source code for the Flash app.

Note that you don’t need the Flash authoring app from Adobe in order to compile this; you can simply use the mxmlc compiler in the Flex SDK (which is open source).

Notice how the Flash app calls a Javascript function populateFontList() via the ExternalInterface. Now we just need to implement that function in the page where we embed the Flash object:

It’s obvious we need a trash command that we can use instead of rm when we’re not 101% sure we need to actually remove these files, like, right now. Here are a couple of existing solutions I’ve found, my impressions of them, and then my version at the bottom:

osxutils’ trash by Sveinbjörn Þórðarson

This is what I’ve used up until now. It’s a small Perl script that simply manually moves the specified files into the trash folder under the current user’s home directory:

The biggest problem with this is that it moves all trashed files onto the same volume instead of using each volume’s own trash folders (this is not a good idea). It also deals with filename collisions manually, which is a bit volatile. The good thing about this is that it doesn’t follow “leaf” symbolic links, which is in my opinion the expected behaviour (what if I want to trash the link instead of its target?).

osx-trash by Dave Dribin

This one is a lot better. It’s a Ruby script that uses the Scripting Bridge to ask Finder to perform all the actual “heavy lifting” (e.g. moving the files to the trash) which means that each volume’s own trash folders are utilized properly and filename collisions are handled in a standard way:

It also allows you to list all the files that are currently in the trash and empty it (normally or securely). The few minor negative things are the fact that it follows leaf symbolic links and the fact that when you try to trash multiple files you don’t have access rights for, Finder will pop up an authentication dialog separately for each file.

my trash

Due to the few things that I wanted the trash command to do differently, I wrote my own. In order to make sure that filename collisions are handled in the standard manner and that each volume’s trash folders are properly used (just like with Dave Dribin’s script) this one first tries to use the standard system API for trashing files, and if that fails due to the user not having the correct access rights, then asks Finder to trash those files (Finder can authenticate the current user as an administrator and move the files into that user’s trash — if you simply run this program as root, the files will be moved to root’s trash, which is not what we want):

The difference is that this one doesn’t follow leaf symlinks, and when deleting multiple files that you don’t have access rights for, Finder will only show one authentication dialog (I had to implement this kind of “manually” because I couldn’t find any way to accomplish it with the Scripting Bridge). I also copied the idea and implementation of emptying the trash and listing its contents via the Scripting Bridge from Dave’s script. This trash is written in (Objective-)C, for all those extra milliseconds that are so goddamn important when waiting for files to be trashed.

You can go through my trash here.

The Application Kit additions to the NSAppleScript class provide an implementation of the syntax highlighting (which would be the hardest part in implementing something like this) and I already have the ANSIEscapeHelper class that provides the translation of an NSAttributedString to an ANSI-escaped NSString (which would be the second-hardest part in implementing something like this) so writing a command-line program around these two parts was quite simple in the end. The program is called asprint and it has its own page on this site where you can download it.

This is what using asprint looks like:

So I wrote a Quick Look plugin for just that. I call it ImageFolderQLGenerator and its results, when viewed within Finder, look like this:

Implementing the plugin itself wasn’t very difficult, even for someone as inexperienced in C as me, but the biggest headache has been something that I’ve yet to find a solution to: as you can see, Finder automatically wraps folder thumbnails into these “icon decors” with their page curls and drop shadows and whatnot — I haven’t found any way to prevent this from happening. As far as I know, Finder decides if it wants to do that based on the type of the content (in this case, folders) and there’s nothing you can do to influence its choice. If someone knows a cure for this, please let me know!

You can download ImageFolderQLGenerator here. I’ve released it under the Apache License version 2.0.

Like I’ve mentioned before in this blog, I develop Flex applications using the Flex SDK and jEdit instead of Adobe’s Flex Builder IDE. This setup has worked very well for me but one annoying issue I’ve had to deal with because of this is the slow compilation speed: every time I make a small change into one of my projects and recompile it, the mxmlc compiler (that my build scripts are calling) has to load the JVM into memory and recompile my whole project from scratch, which obviously takes a while. Compiling things in Flex Builder is a lot faster, and the reason for that is the Flex Compiler Shell, which it uses for compilation instead of mxmlc.

The basic idea behind the Flex Compiler Shell is that it would stay in memory between compilations (thus avoiding the cost of loading up the JVM every time you want to compile something) and use a technique called incremental compilation that, as the name suggests, is based on the idea of only compiling the parts of your project that have changed since the last compilation (thus making the process a lot faster). When you run the Flex Compiler Shell executable (called fcsh), you’re thrown into an interactive shell where you can run commands in order to compile your projects and control the operation of fcsh itself.

The Problem

When I found out about fcsh, tried it out and saw how much faster it was than mxmlc, of course I wanted to immediately start using it instead in my build scripts. The biggest problem with doing this, though, is the fact that the basic operation of these two programs is fundamentally different: when you run mxmlc, it compiles the project, prints some messages to standard output and then exits (with the exit status 0 if the compilation was successful or 1 if it wasn’t), which is perfect for integrating it into build scripts. Fcsh, on the other hand, throws you into a shell of its own and expects you to essentially operate it from within itself (instead of simply calling it with some arguments and then having it return with some standard output and an exit status like mxmlc).

The other issue that makes fcsh more difficult to use in general is that in order to use the incremental compilation feature, you have to first compile your project like you normally would (using the “mxmlc” command), then make note of the “compile target id” number that fcsh then assigns to this project and specifies in its output, and for future compilations use the “compile N” (where N is the compile target id) command.

The Solution

I tried to search for a solution to this problem that somebody else might have come up with but didn’t find an adequate one (a list of the ones that I could find is further down), so I decided to give it a shot myself. My approach, called fcshctl (short for “fcsh controller”), is basically a simple bash script that:

1. starts the fcsh process if it isn’t already running
2. forwards its arguments to fcsh as commands
3. reads the output of that command from the fcsh interactive shell and prints it to the standard output
4. exits with status 0 (success) or >0 (failure)

In addition to this, I also made the script automatically and transparently invoke the incremental compilation feature whenever applicable so that I wouldn’t have to worry about keeping track of the compile target ids and using a different command for the compilation whenever one had already been assigned.

Below is a summarization of the pros and cons of this solution:

Pros:

• It’s quite simple — just one shell script (a few others are included in the .zip that are only for convenience and not required)
• It runs the fcsh instance in a GNU screen session, which means that:
• The running fcsh instance is accessible to all user processes (i.e. not just within a single shell session, for example)
• It is possible for the user to enter the running fcsh interactive shell at any time (by attaching to the screen session via the command screen -r -S fcsh) and manually interact with it
• It automatically checks whether you’ve compiled a specific file before and keeps track of the compile target ids that fcsh assigns so that it can automatically and transparently invoke the incremental compilation feature and let you access the speed gains that are fcsh’s main offering without any additional work. This feature can also be turned off by setting an environment variable.
• A proxy script (called fcshctl-mxmlc) that can be used in place of mxmlc is provided. It simply calls fcshctl with “mxmlc” as the first argument, followed by all the other arguments you specify, so that you can simply use this script as a stand-in for mxmlc in any build scripts that you may be using without having to modify them any further.

Cons:

• It uses the GNU screen logging mechanism and polling for changes in the log file in order to catch the output of commands sent to fcsh, which is not very elegant and causes a slowdown of maybe about a couple hundred milliseconds before the output is printed to stdout.
• The output of the executed fcsh command is not printed to the standard output as it comes, but instead all at once when the command finishes (this is not a problem for me personally, but others might want to fix this).
• It’s implemented as a bash script, which means that it’s not the fastest monster out there (we’re talking about milliseconds here, though, so it doesn’t bother me at all).

Download

You can download fcshctl here:

• fcshctl-v0.5.1.zip (latest)
• fcshctl-v0.5.zip
• fcshctl-v0.4.zip
• fcshctl-v0.3.zip

fcshctl has been tested with fcsh versions 3.0.0 build 477 and 3.1.0 build 2710 on Mac OS 10.5.5. It is licensed under the MIT License.

The script requires the following to be in your $PATH: rm, mv, cat, ps, sleep, tail, head, grep, awk, screen, xargs and basename. You also need to have the FLEX_HOME environment variable set to point to the Flex SDK root path.

Example of use

fcshctl $ export FLEX_HOME=/Users/username/code/SDKs/flex_sdk_3.1
fcshctl $
fcshctl $ ./fcshctl

Usage: fcshctl <commands>

  Substitute <commands> with any commands you
  would like to send fcsh, just like you would
  enter them in the interactive fcsh shell
  session.

  To get a list of the available commands, run:

    fcshctl help

fcshctl $
fcshctl $ ./fcshctl help
List of fcsh commands:
mxmlc arg1 arg2 ...      full compilation and optimization; return a target id
compc arg1 arg2 ...      full SWC compilation
compile id               incremental compilation
clear [id]               clear target(s)
info [id]                display compile target info
quit                     quit
fcshctl $
fcshctl $ ./fcshctl mxmlc ~/code/Flex/projects/testbed/testbed.mxml
Loading configuration file /Users/username/code/SDKs/flex_sdk_3.1/frameworks/flex-config.xml
Recompile: /Users/username/code/Flex/projects/testbed/testbed.mxml
Reason: The source file wasn't fully compiled.
Files changed: 0 Files affected: 1
/Users/username/code/Flex/projects/testbed/testbed.mxml(28):  Error: Incorrect number of arguments.  Expected 2.

    func1("toka");

fcshctl $ echo $?
1
fcshctl $
fcshctl $

Other similar solutions

Below is a list of other approaches to the problem of integrating fcsh to non-standard (i.e. non-Flex Builder) workflows (roughly in order from most promising to least promising), and short lists of reasons why I personally didn’t want to use them. If my solution doesn’t seem good to you, you should maybe check some of these out.

fcsh tools by Mike Rowe

• Runs fcsh in a daemonized process, which means you won’t be able to enter the interactive shell of a running fcsh process and manually interact with it
• You can only specify the filename to compile; has no support for additional mxmlc arguments
• For GNU/Linux (but seems to work just fine on OS X as well)

flex-compiler-shell-daemon by Leonardo Soto Muños (also see his blog post about it)

• I couldn’t get it to work out of the box on OS X
• Runs fcsh in a daemonized process, which means you won’t be able to enter the interactive shell of a running fcsh process and manually interact with it

FCSH Wrapper by Mihai Vasilache

• For Windows
• Designed to be used with Ant
• A bit complicated

http://code.google.com/p/fsch/ by nimrod97

• For Windows

BigSource Zarkov by BigSource GbR

• For Eclipse & Ant