Viewing posts for the category Uncategorized
Learning Flex 4...
Posted by: mhughes in Uncategorized 3 years, 10 months ago
I've been learning some Flex 4 stuff over the past week. One word... wow. Even without Catalyst, this is going to speed up my development a lot. Things like skinning a button with a complex code generated skin is now easy. I've been working on a site for my Wife's budding photography business over at: Jessica Hughes Photography
It's still a rough site, but I figure Flex 4 took me about the same amount of time to make it as it would have in Flex 3, but that includes learning about all these new features.
Profiling experience
Posted by: mhughes in Uncategorized 3 years, 10 months ago
Today, I happened to have Activity Monitor open while I was working on AgileAgenda and noticed something peculiar. It was sucking up 200% of CPU time (multiple cores...)
So I fired up the application in the Flex profiler. Let it sit for a minute, clicked the "Reset Performance Data" button, waited another few seconds, and then clicked the "Capture Performance Data" button. The result was odd.
Nothing was actually in code I could touch and didn't explain why it was happening. There had to be something going on to peg out the CPU like that. So I hit up the Flex preferences panel and found something I had forgotten about.
By default, the profiler excludes a whole bunch of flex and flash related classes from the profiler. So I removed those exclusions and unchecked the box. Went back to my profile window and low and behold, this is what I saw:
So now I had an idea of what was happening. It looks like that indeterminate progress bar (which wasn't on the screen anymore by that point) was sucking up some render time.
So I peeked at the ProgressBar flex code. They've got a timer in there that gets started, and is stopped when the progress bar is set to invisible. But that doesn't end up accounting for cases where we just bump to a different parent object in a view stack. So that timer sits there, happily spinning and consuming resources.
I added some code in to manually set the visiblity of the 2 indeterminate progress bars I had and ran. Bamn, success.
So I learned (or re-learned?) two things today.
- When profiling, if you don't see anything happening check your filters.
- Be very careful with indeterminate progress bars in flex.
Nudger - my latest mini-project
Posted by: mhughes in Uncategorized 3 years, 10 months ago
A lot of times I find myself opening up Photoshop just so I can paste a screen shot of an application I'm working on in there and move some elements around to see where they look best. I might grab a button and nudge it over to one side until it lines up somewhere. And I use that info to go update my app.
Photoshop is way overkill.
So say hello to Nudger, a little AIR app I whipped up with ObjectHandles, Flex 4, and Moccasin
To use it, take a screenshot. I use Skitch on OSX and just hit Print Screen on my Windows machine. Then drop or paste that screenshot onto Nudger. It'll load up the image. From there you can click & drag to define an area to nudge. Then move it around with the handles that appear. You'll get feedback while you do it.
Here's some screenshots (I'm working with a screenshot of the Flash CS4 splash screen here)
Step 1, right after pasting it.
Next, I select an area of the image with the mouse.
And finally I move it around.
The grid below the selection tells me the original location/size of the selection, the new location/size, and how much that differs from the original. If this were an app I was working on, I'd know I need to bump those objects over by 221 pixels and down 5.
Of course you can make multiple selections and move lots of stuff around.
My wish: type Checking in CSS
Posted by: mhughes in Uncategorized 3 years, 11 months ago
I wish there was type-checking in CSS for Flex applications. Way too many times have I come across a style that either:
- Uses a style attribute that's not valid for the component type
- Uses a value for an attribute that's the wrong type
Hell, maybe I am really wishing for something other than CSS for flex apps. I wonder what a nice type-safe format for specifying style information might look like. It'd have to retain the centrally-located benefit of CSS, and probably not sacrifice much of the flexibility.
ByteArray writeUTF vs. writeUTFBytes
Posted by: mhughes in Uncategorized 3 years, 11 months ago
I just got bit by using writeUTF instead of writeUTFBytes, I knew they worked differently, but it took me a couple google searches to figure out why.
writeUTF appends a 16 bit length, and then your actual data writeUTFBytes simply appends your data
So why does writeUTF work like that?
When you read data back in, readUTF can get how long the string to read is, and then read exactly that much in. On the other hand, readUTFBytes just reads everything back. Seems like a minor difference, but imagine these two scenarios.
This works perfectly:
myByteArray.writeUTF("Hello World");
myByteArray.writeFloat(100);
...
a = myByteArray.readUTF();
b = myByteArray.readFloat();
This next example does not work because the readUTFBytes also reads in that float we wrote, so the readFloat call has nothing to retrieve:
myByteArray.writeUTFBytes("Hello World");
myByteArray.writeFloat(100);
...
a = myByteArray.readUTFBytes(myByteArray.length);
b = myByteArray.readFloat();
On the other hand, the writeUTF method can only handle strings up to 64k float. So if you have an arbitrarily sized string it'll eventually failed. This is what I ran into.
So here's a couple simple rules for choosing which to use:
1) If you need to write arbitrarily sized large strings, use writeUTFBytes, but don't write anything after it. 2) If you need to write multiple items to your byte array and read them back that way, use writeUTF, but don't exceed 64k strings 3) If you need to create a byte array with no "header" of that leading length, use writeUTFBytes (like if you're making a stand-alone file to inter operate with some other system)