DataGrid Reminder: Item Renderers Don't Trigger Events Until They're Visible

Ran into this recently; no code, since that's not really necessary. But this info is pretty valuable imho. I've seen tons of info on the net in all the forums that work around this every which way without every actually stating the precise issue.

Say you've set up the following:

- A datagrid with a dataprovider (say, XML).
- One of the columns in the datagrid has a custom renderer.
- You need to update a model (say, processed XML you will send to a service after the user is done with the grid) with some data that is automatically populated in that renderer's UI field (like a default value).

For instance, say you have this:

<item>

<itemdata>Hello</itemdata>

</item>

You use this as your dataprovider. Your custom renderer has a textfield. You write Hello into the textfield on dataChange. Nice nice so far.

Now, when that textfield changes, you want to update a model of XML, or trigger some other event, whatever. You add the textfields change handler, you see it work, you breakpoint the code that updates the model, and you see the info added. Nice.

Then you say, "let me blow it out to 20 rows". You add them all, you breakpoint the model code, and it works...up to a point. For some reason, 7 or so of the pieces of data you want in the model are there, but then it just stops, as if the data is getting skipped or just not sent.

You fiddle with it...sometimes 7, sometimes, 5, sometimes all 10. WTF is going on?

If you know the answer already, raise your hand...but I bet you don't (I looked and asked around for a week before figuring it out).

Drum roll...

...datagrids only render visible rows. If you had to scroll to see any of your rows, then those renderer's events never fired (like it's textfield change event). Which means that the events never dispatch, so your model, or whatever, never gets the message.

So, if you're counting on events from a renderer events to update a model or trigger some other action when all the data is initially loaded into the datagrid based on a value set in a renderer, don't dispatch the events from the renderers, because if they aren't visible, they'll never send their messages.

Perhaps a datagrid creationPolicy of "all" would be useful under certain circumstances.

As always, thanks for visiting.

Passing Simple QueryString Data from SWF to SWF using SWFLoader

Lot of posts out there with people trying to get around this one. It's a pain; under certain (most) conditions, if you try to simply load a swf into a swfLoader, and pass parameters by appending the path to the swf, when you test the parameters in the loaded swf, you get nada.

Ugh.

Easy workaround; use this in the LOADED swf (so in the code of the swf you loaded):

Application.application.loaderInfo.loaderURL

That reveals the entire path the loader of that swf used. After that, parse out your values and off you go. Not as nice as if they appeared as neatly packaged object properties, but it works, and parsing a querystring is 101 stuff anyway.

Easy one, but effective.

As always, thanks for visiting.

Adobe CS5 iPhone building is "*Subject to Apple's current requirements and approval."

If you read my last post, you know that Apple altered their licensing agreement for applications. Not only is apple telling you how you can distribute them, but now they are telling you how you can build them.

Here's the meat of the matter:

"3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."

It's corporate control at it's worst. Apple has surpassed Microsoft in terms of "evil empire". Microsoft may be berserk with their licensing pricing and enforcement, but one thing is true, they NEVER told me that I couldn't use my computer whatever way I wanted as far as a developer. As long as the binary output runs, I can install it, for FREE. Apple, however, has decided that's not enough money or control. Now they want to specify the language you write in, how it should be compiled, and all the rest of it, AND get a fee JUST so you can put an app on an iPhone, iPod Touch, or iPad. The more I look at it, the more I see corporate, hysterical paranoia. Apple simply wants to own and control all content distribution on the web.

Apple = Open Web? No, they do not. They = closed devices supporting the technologies they choose, the way they specify. They are doing evil; they could learn a lot from Google.

What evil?

The change has affected numerous small development shops that were counting on Adobe's Release of Flash CS5, as well as shops working on compilers for various dev technologies. Apple is taking every step they can to keep anything other than Apple licensed developers, and Apple licensed tools, out of the realm of Apple mobile development, in particular, the petulant snubbing of Adobe's Flash. They offer all kinds of weak, easily repudiated reasons for not allowing the technology to be installed in their Safari browser on the iPad and the iPhone, or as a runtime that can support Air apps. I won't rehash these, other than to say, if a $250 netbook can run Flash and Air, then there's no reason in the universe that the iPad shouldn't be able to, unless all it really comes down to is that the iPad is a glorified iPod Touch without the camera. I mean...no USB port...no Flash...no multitasking yet...come on. Has Apple forgotten that technology isn't just about designing cool looking things?

Anyway, Adobe has added this little quip to the pre-release announcement of the CS5 Master Suite, due for release in mid-May:

"Publish content virtually anywhere, using Adobe AIR® for desktop applications and mobile platforms including the iPhone®*, or Adobe Flash Player for browser-based experiences.
*Subject to Apple's current requirements and approval."

Notice that last line. This means that, Adobe may give you a tool that can build iPhone apps from Flash/ActionScript...but you may never be able to use it. All Apple has to do is keep modifying the license agreement to shut Adobe out forever, and as they clearly show by the new 3.3.1 paragraph, they're more than willing to do it.

For shame Apple. You're supposed to enfranchise developers, let us create tools to work with your platform. But instead, you react by putting more mortar on the walls around your mobile platform, paid for by developers that just want to put an app on an iPad.

HP Slate for me (google it), and depending on how Android 2 goes over the remainder of my iPhone contract, it's a distinct possibility I'll abandon Apple's mobile platform altogether. My whole perception of what I see when I look at my iPhone has changed, and I don't like it. Sure, this may only matter to developers, but developers build the apps you love. Historically, where the developer goes, the consumer follows. If Apple keeps heading this way, it's just a matter of time until people start jumping ship.

Is this all written in stone? Hard to say. But it is indeed written, at least for now.

Apple tightens control over development...again.

Take a look at this: Before today, the Apple License Agreement for apps read like this:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

As of today, it looks like this:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Now, I don't think this necessarily means the Flash CS5 is torched (if you didn't know Flash CS5 has the ability to compile ActionScript apps to run on iPhone). The only thing it MUST do is, it must appear to the external eye that the app was written in C (objective, C++, etc.). If there is a compiled binary that speaks to the iPhone API through an intermediary layer, it's out of license.

Whatever the case, this is going too far. Not only does Apple want to specify how you can distribute your apps, they want to tell you exactly how to write and compile them. I'm reasonably confident this won't stop Adobe, as they wouldn't have gone this far without understanding Apple's probable reaction to their iPhone compiling tools, but it will certainly torch a number of efforts underway to get iPhone dev into general development, like Java, etc; I know for sure the .Net->to->iPhone effort is now out of license, as it uses an intermediary layer (or did anyway).

C'mon Apple. You've got your distro lock, for pete's sake if home engineers can come up with another way to put it on wax, and it passes your already existing restrictions, back the hell off.

Text Layout framework for Flash/Flex (Player 10)

Like many of you I'm sure, I've struggled with text in Flash/Flex more than once. For the most part, I've learned to get it to do what I want, but, there's still some things missing, especially when it comes to allowing users to manipulate text, an easy way to integrate robust HTML text for formatting, that sort of thing.

I haven't played around with it enough to write anything useful, but this looks very promising:

http://labs.adobe.com/technologies/textlayout/

The gist is, the text framework is getting a complete overhaul; we'll have it Gumbo, and it's already in CS4, all targeted at Player 10 (which is a significant evolution, what with the ability to save files locally and such as well).

Summary of highlighted features, this is interesting stuff:

- Bidirectional text, vertical text and over 30 writing systems including Arabic, Hebrew, Chinese, Japanese, Korean, Thai, Lao, the major writing systems of India, and others
- Selection, editing and flowing text across multiple columns and linked containers, and around inline images
- 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.

Interesting stuff.

March Edition of Flash Flex Dev Mag is out.

The March Edition of this mag is available now, with my article, "Dynamic Views and Mediators in PureMVC".

Check it out at:

http://ffdmag.com/download-2-2010

This blog has moved

This blog is now located at http://tcoztechwire.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://tcoztechwire.blogspot.com/feeds/posts/default.

My Comments on Steve Job's attacks on Flash technology: C'mon Steve, it's about money and control.

Recently, Steve Jobs has escalated his war on Flash technology. You can read about it here:

http://gawker.com/5474900/what-steve-jobs-said-during-his-wall-street-journal-ipad-demo

There’s so much contrary info available to me about Steve Jobs’ war on Flash that I can’t find his position credible. It’s amazing that anybody would take it seriously.

I’ve been a Flash dev for a long time. Flash hasn’t crashed my computer in years. Browser now and then, yes, computer, never. And I run three macs, and do all my development on them. Steve is telling a half truth here; if he was being accurate, he would say that POORLY WRITTEN flash apps take down BROWSERS. That is the fact.

This is no less true of a poorly written iPhone app. Go to the forums, bad iPhone apps take down iPhones all the time; memory allocation, lockups, you name it.

Steve Jobs is being dishonest about his motivation for his attack, and it’s obvious to anybody that knows how iPhone content distribution works; this is entirely about control, and money, that’s it. If you allow Flash on the iPad/iPhone, people will be able to write games, audio/video experiences, and deliver them to the iPad, without the deathgrip approval process Apple has over applications (you must submit your app to Apple, and get approval, before distributing to the iPhone via iTunes; Apple gets a distribution fee, AND you have to pay every year to be a registered developer to be allowed to submit apps at all) . Apple won’t make the money on the app distribution, and won’t have to force you to go through the app approval process.

That’s the real issue. I am confident that an army of Flash/Flex devs, and Adobe, as well as any legit third-party evaluation process, would state that there is no technical reason that an iPad can’t support Flash.

It is also interesting that, for video solutions, he points to h.264 video (quicktime), which is a patented and privately licensed technology. And guess who owns it. Sure, cheap now...but when people start depending on it, watch Apple change that for "enterprise content distribution" or some such.

Finally, Steve says Flash is on the way out; that statement, more than any other, I just can't fathom. Flash is in no way dying at all, in fact, as a developer using it for years, I have never seen so much Flash/Flex work. I turn down good work all the time because I’m far too busy. 3d advancements and other useful technologies are allowing Flash to go where it has never gone before.

Apple was heavily vested in Flash technology for years; shortly before the release of the iPhone, they ripped it all off their website; I happened to notice this, and was suspicious of the motivation. A few months later, they announced the app store, and the model for development and distribution; then it became clear to me why you would never see Flash on the iPhone.

Apple can’t control content delivered via Flash.

Folks, people say Microsoft is the evil empire, but one thing for sure, they never tried to control the content you see and use on your devices to the extent Apple is currently enforcing. They should call the device the iCensor.

Me, I’m not getting an iPad. If I buy a device of this nature, I want the entire web experience, not some dumbed-down version Apple is foisting off to enforce control and print more mountains of money. A phone, alright…Flash does take CPU cycles and may not be ideal for a phone (though I don’t have enough info to know this for a fact), and dumbed-down versions of Flash for mobile don’t appeal to me. But there is no excuse for the iPad, unless that device is technically just a big iTouch, in which case, imho, it’s a waste of money. I'll buy a device that doesn't tell me "we don't like it so you can't have it".

Watch out Apple, you're creating a real mud-slinging marketing opportunity for Microsoft here. Windows 7 is on the rise and people are fast forgetting Vista.

Flash Builder BUG: Services failing, SWF trying to load crossdomain.xml from localhost:37813?

Oh man this one cost me some time.

I have a swf loading data from some services at IP yadayada. It's working fine, both from the FB IDE, and when I copy the bits to the remote server, pull up a browser, and hit the remote IP.

Then I try it from another machine, same browser, same FP version, same IP address. I see this gobbledy gook:

Warning: Failed to load policy file from http://localhost:37813/crossdomain.xml
*** Security Sandbox Violation ***
Connection to http://localhost:37813/?q=services/amfphp?hostport=[ipommitted]&https=N&id=-1 halted - not permitted from [myswf]

WTF, why, why, why is that request trying to load the crossdomain file from localhost:37813, screwing up everything on all but my dev machine? Yes, I know dev machines aren't the acid test, but I'm not running the project from the IDE, or even the browser the IDE uses, I'm pulling up an "off to the side" browser and hitting the remote address, exactly as I am on any other computer.

I went through all the security settings, found posts directing me time and again to the new meta policy and socket policy documents and white papers: I've read them all, several times in the past, I'm good with Flash security, I KNEW I was doing all this correctly.

So, I abandoned Flash security, assuming I had everything correct. Where else had I seen URLS redirected to localhost:port?

HTTP Sniffers, like Fiddler. They intercept HTTP traffic, channel it to a local port, trace the data, and forward the request along.

Was I running one? No...oh wait, yes.

THE NETWORK MONITOR IN FLASH BUILDER.

IT COMPILES THE REDIRECT INFO INTO YOUR SWF.

So, if you compile your swf with the network monitor active, which you may not realize is the case, you have just told your swf to redirect all traffic to localhost:37813. So you'll deploy it, and guess what? Because no other machine is running the FB network monitor, the calls will fail. GAH.

Turn network monitor off. Recompile your swf. Redeploy. Voila.

GAH. What a pain. Anyway, if you have this problem, hopefully this saves you from the frustrated grumbling and cursing I spent a few hours going through.

As always, thanks for visiting.