The documentation is pretty clear that your table will get the swipe to delete behaviour if you implement the tableView:commitEditingStyle:forRowAtIndexPath: method in your UITableViewDataSource delegate.

So, in other words, implementing this one method in your data source should be enough to enable swiping to delete a row:

But this wasn’t working for me.

After a bit of digging, I found the problem. My table supports an edit mode that the user flips into by pressing an Edit button in the toolbar. When in edit mode, the user can tap on multiple cells and then tap a trashcan at the bottom to delete all the selected cells. This works nicely, but interferes with the swipe-to-delete gesture, in that swipe-to-delete isn’t supported when multiple selection is enabled in edit mode.

What I wanted was single selection when not in edit mode, and multiple selection when in edit mode. This was easy enough to achieve:

Make sure the table is set for Single Selection During Editing in Interface Builder, and that’s it.

The RTMP protocol was designed for streaming multimedia with the ability to interleave other kinds of content. It’s is a low-level binary protocol, so I’ve spent a lot of time over the last few months looking at dumps of bytes sent over the wire and decoding them to determine that we’re sending the right bytes and that they match what our other clients are sending and expecting.

For anyone else implementing RTMP, or just interested in it, I’ve cleaned up and annotated some parts of a typical RTMP session below for your reading pleasure.

This RTMP stream represents a client connecting to the server, and sending a request to subscribe to a messaging destination. This example is how a client would start a data feed from the Market Data LCDS sample. The subscribe message s an instance of “flex.messaging.messages.CommandMessage”, and looks like this:

And on to the protocol decoding. Bytes being sent to the server from the client are denoted with > (greater than) and bytes coming the other direction are denoted < (less than).

The first thing that happens is the client opens a socket connection to the RTMP server, and sends:

This is the client telling the server “I support protocol version 3″.

The client sends 1536 bytes of random data to the server. This is part of a sequence of exchanges that the server and client use to make a guess as to their available bandwidth.

This is the server responding with the protocol version that it is using. All is well; both report version 3.

The server also sends 1536 bytes of random data.

The server sends back the data that the client sent it. This gives the client a way of guessing not only at bandwidth but a pretty good measure of latency.

The client does the same.

Now the initial handshake is done and we can start talking RTMP.

Our goal is to request a subscription to an LCDS messaging destination, so we need to send the message to do this. This starts out with a chunk header (Type 0, section 6.1.2.1 of the RTMP spec):

This decodes as a timestamp of 0 (the first 3 bytes), message length of 61 bytes (next 3 bytes), message type ID 17 (decimal, 0×11), and a stream ID of 0 (the last 4 bytes). The message type is 17, which means an AMF3 encoded message follows.

Here’s what the subscribe message looks like:

Writing the CommandMessage object:

Next, internally we have a function that walks the object’s properties and serializes it. The object’s properties are written first, then the values. So here’s what the object’s properties look like on the wire:

This is a variable-length 29-bit integer encoding (see 1.3.1 in the AMF3 spec) of the value 147 (0×93) which is: 0×03 (U290-traits) | 0×08 (dynamic) | number of member names that follow (9 in this case).

Next we have the class name:

This is a string serialization of the 38 byte class name, “flex.messaging.messages.CommandMessage”.

Next we have the 9 property names, each represented as a UTF-8 variable length string:

Now that the 9 names have been written, the 9 values are written (in the same order).

0×05 is a double, always written as 8 bytes

Next up is ‘headers’, a map of name/value pairs that’s written as a custom object. This takes almost the same form as the object we’re currently in the middle of serializing, except that it’s an anonymous class.

Next the traits for the headers:

Next, the values for the headers:

DSMaxFrequency header. 0×04 is an integer, and the next 2 bytes are a UInt29 representation of the integer value 1000. 1000 is ((7<<7) | 0×68).

DSId header. 0×06 is a string; 0×49 is the length of the string << 1 with bit 0 unset. If bit 0 was not set, then it would be a reference into a string table. The string length is 36 bytes (it’s a GUID) << 1 | 1.

DSAddSub header. This is an array (0×09) of 1 element (bit 1 is always set, count is shifted left one), with no name (0×01 indicates a null string). The one element is a string (0×06) of length 7 (0x0f = 7 << 1 | 1), containing the bytes “ADBE_;_”. This is what we’re subscribing to.

DSEndpoint header. The endpoint name, “my-rtmp”.

(At this point we’re done with the embedded headers array and we’re back to serializing the properties of the CommandMessage, continuing with the ‘operation’ property).

The ‘operation’ property is an integer, value 11. Operation 11 is the multi-subscribe operation. (You can see the operations in the BlazeDS documentation for CommandMessage). http://livedocs.adobe.com/blazeds/1/javadoc/constant-values.html#flex.messaging.messages.CommandMessage.MULTI_SUBSCRIBE_OPERATION

The messageId is a GUID, sent similarly to the DSId header above.

timeToLive is of type double (0×05) value zero (doubles are always 8 bytes).

Finally, the name of the feed that we’re subscribing to, “market-data-feed”.

And that’s that.

As you can tell RTMP and AMF3 are incredibly efficient binary protocols – the decoded streams above show the efficiency of the protocol in general but don’t show one of the other big gains, the tables that the client and server maintain so that if a string or object has already been sent once during a session, all that needs to be sent over the wire is a reference to the string, not the string itself. This shaves many more bytes off the session.

And why is that important? Well, especially in mobile apps, users are paying for bytes. There is typically less bandwidth. And even if your clients don’t mind the traffic, think of the bytes you’re saving on the server side when you’ve got a few thousand clients connected and receiving streaming updates. It can be significant.

Looking for more information about RTMP? The spec is here. The AMF3 spec is here, and it builds on the AMF0 spec which is here.

It took me a bit of searching to figure out what the problem was, which means it’s worth posting the solution here.

Flex Builder’s design view is extensible. New components that you build can show up in the Components panel, and users can drag them onto the design surface. You need to do a few things for this to work.

First, you need a design.xml file in your SWC. This file tells Flex Builder about your component. Here’s an example:

I had that right in my SWC, but I was missing two things. The ant script that I was using for my command-line build wasn’t including the design.xml file. After adding that, here’s what the ant target for the SWC compile looks like:

Note the include-file line, which gives the name of the file and then the source path to it.

And the other thing that was missing was the namespace mapping. The compiler.namespaces.namespace argument identifies the namespace for the component (which has to match the namespace from the design.xml) and the manifest to use for the classes in that namespace.

The last piece is the manifest file. Here’s what that looks like:

With all this set up, dropping the SWC into a Flex project’s libs folder will immediately show the MyImage component in the Components panel ready to drag onto the design surface.

Windows 7 uses a different mechanism, and one I find far too subtle.

Looking at this, you’re probably thinking “hey it’s obvious, the orange one wants your attention”. And it does seem that way, but for some reason I find myself, with Windows 7, missing IM notifications and not responding to messages until hours later, because I just didn’t notice that I had a new message.

Maybe it’s because of all the additional noise in the taskbar – it’s harder to tell at a glance that an app wants your attention, so I don’t pick it up “out of the corner of my eye” the way I would with the XP style.

The Mac continues to animate icons that want your attention until you give in and click on it. Windows animates the icon for a few seconds and then settles on the orange look. One solution would be to change Windows 7 so that the animation continues until you respond.

Ctrl-3 – Brings up a way to search within the app for commands.
Ctrl-O – Navigate quickly within the current file (type to filter)
Ctrl-Shift-T – Open Type (filter for types using caps – BB for ButtonBar)
Ctrl-Shift-R – same thing but for non-code (resources, xml files, etc)
Ctrl-I – put cursor at right indentation for current line or reindent selection
Ctrl-D – delete current line
Ctrl-M – toggle maximize the editor

Also you can hold down the Ctrl key to turn any symbol in the editor into a hyperlink.

Some of these are Flex shortcuts and some are Flash Builder.

Here’s the video:

This is Kind of a Big Deal, because as far as I’m aware open-source code that handles text editing and display of Unicode text that supports right-to-left layout and editing is very rare.

I work on LiveCycle Designer, and because we made a commitment to a partner to support it, our XML editor lets you edit XML source that has HATV (Hebrew, Arabic, Thai, Vietnamese) text embedded in it. If you’re not familiar with these languages, in a nutshell, they’re read from right to left instead of left to right the way English is read. A text editor that supports these languages will understand that they’re edited from right to left as well, which changes how the editor behaves when the caret is in an RTL text run. For example:

This is some XML that might represent a button whose ID is “Button” in Hebrew. Drag-select over that text. Does your browser treat the Hebrew text differently than the surrounding English characters? It probably does.

When you’re editing, the typical behaviour is if the caret were on the equal sign and you hit right arrow a few times, the caret would move to the quote, then to the last character of the Hebrew text, then left, left, left, left, then jump to the closing quote. This is because the right arrow key is interpreted as “move to the next character”, not “move right”.

The TLF that Adobe is giving away comes with a TextEditor class that knows about all this. Copy that text and paste it into the TLF Sample and try editing it yourself.

The TLF supports a lot of other cool text features. Here’s a list:

• Selection, editing and flowing text across multiple columns and linked containers
• Vertical text, Tate-Chu-Yoko (horizontal within vertical text) and justifier for East Asian typography
• Rich typographical controls, including kerning, ligatures, typographic case, digit case, digit width and discretionary hyphens
• Cut, copy, paste, undo and standard keyboard and mouse gestures for editing
• Rich developer APIs to manipulate text content, layout, markup and create custom text components
• ActionScript-based object-oriented model for rich text layout enabling live updates

But the RTL text support is the one that affects me most since we’ve been looking for a replacement for what we currently use in Designer, and this might be it.

There are a lot of open-source text editors, but as far as I know the only one that supports this is the code editor in Eclipse, which is written in Java. The text input widgets on the major OS platforms support it, and now, so does Flash.

Normally when companies do this sort of thing – make changes that break another company’s product – they don’t brag about it. They say that it’s not a supported configuration and you’re left to wonder if it broke as a natural consequence of some changes they were making, when in fact they probably broke it on purpose.

But not this time. Apple specifically stated that the iTunes 8.2.1 update “addresses an issue with the verification of Apple devices”.

I don’t feel right about this one. On the one hand Apple is probably within it’s rights to do this. iTunes is free, supported by the money that the iTunes Music Store makes and some of the device revenues. Before the store, iTunes was completely supported by device revenues, and software tying itself to a hardware purchase is nothing new. CD Burner software, for example, has often checked that the manufacturer of the drive is the one that the software came bundled with.

What makes this feel different is that iTunes is middleware between my music and my device. I’m paying Apple for the music, so I feel like I should have the right to use iTunes to get that music onto my music player, whatever that player may be.

I support Apple’s right to do this, but I don’t think it’s very nice of them to do it.

John mentioned teams incorporating the shutdown into their scheduling. Isn’t that a radical idea?

It’s called FlexAccount, and there’s information and a download at that link.

I posted it yesterday and this article by Jeff Atwood made me think of calling it out today. One of my goals with FlexAccount was to create something that’s a reasonable representation of best practices, and that includes salting passwords in the database, using a unique, per-user salt.

If you start with FlexAccount, then you’re storing passwords correctly.