I see your privates: How objects of the same class can share private variables in AS3

by Josh Tynjala

Today, I was surprised to discover something that I didn’t know about private variables in AS3. If an instance of class A has a reference to another instance of class A, then the second object’s private variables are accessible to the first object. No restrictions. No special tricks. You just use obj.variableName like any other property request. I’ll show you some example code, and you can try it yourself.

First, let’s set up the situation. Alice has a secret in her diary. Trudy wants to know Alice’s secret, so she’s going to sneak in and take a peek. Here’s a simple document class that presents our story in code:

package
{
	import flash.display.Sprite;

	public class ISeeYourPrivates extends Sprite
	{
		public function ISeeYourPrivates()
		{
			//the intruder
			var trudy:Person = new Person("Trudy");

			//the victim
			var alice:Person = new Person("Alice", "I kissed a girl, and I liked it!");

			//Trudy is curious, and she wants to read Alice's diary
			trudy.peekIntoDiary(alice);
		}
	}
}

Finally, this UML-like diagram below also shows what’s happening:

UML-like diagram. Alice and Trudy are instances of Person. Through peekIntoDiary(), Trudy can access Alice's private variable _secret.

Next, let’s look at the Person class and see how the peekIntoDiary() method works:

package
{
	public class Person
	{
		public function Person(name:String, secret:String = null)
		{
			this.name = name;
			this._secret = secret;
		}

		public function peekIntoDiary(target:Person):void
		{
			trace(this.name, "is looking at ", target.name + "'s secret:", "\"" + target._secret + "\"");
		}

		public var name:String;
		private var _secret:String;
	}
}

As you can see the secret value sent to the constructor gets stored in the private variable _secret. Another Person instance is passed to the peekIntoDiary() method. In this case, the Trudy object (this) now has access to the Alice object (target). The trace() output reads:

Trudy is looking at Alice’s secret: “I kissed a girl, and I liked it!”

Yes, Alice’s private variable _secret has just been accessed by Trudy. Bet you didn’t expect that to work. I know I didn’t. Don’t believe me? Try it yourself. The code above compiles and runs.

It makes some sense if you consider that the private access modifier is actually a namespace. Basically, behind the scenes, the compiler automatically creates a separate namespace for each individual class that it names private. This private namespace is only accessible to the one class for which it is defined. That’s why other classes and subclasses can’t access private variables. However, due to the scope of the namespace, all instances of the same class can access the private members of other instances. To be truly private, each individual instance of a class would needs its own namespace that other instances wouldn’t know about. I’m not even sure if that’s possible, but I have a vague idea of how it might work.

Does it matter? No, not really. You’ll rarely find yourself in an situation where this behavior can be useful (see the credited link below for one possibility). I can’t think of a case where this can be considered a security risk either. It’s not much different than using object["variableName"] to get at private variables in AS2. Mainly, I wanted to share because it’s somewhat unexpected behavior.

Credit: Thanks to Nick Bilyk for pointing this out in a post about cloning objects.

Presentation Slides from 360Flex San Jose 2008

by Josh Tynjala

At 360Flex San Jose 2008, I gave a session titled Polishing Components for the Unwashed Masses. In my talk, I covered all the important details around releasing a custom component to the community. Having built a few open source components on my own, and being a former member of the development team behind Yahoo! Astra, I’ve spent a lot of time focusing on how to create quality supplementary material to include along with the source code and the SWC. The four main topics were writing documentation, creating examples, making your components extensible, and encouraging a community.

Screenshot of the presentation slides

To some, my session seemed a little obvious. To others, it was a good checklist of what-to-dos before some code gets released. Personally, I’ve seen way too many half-finished, barely documented, almost unusable components that could use a little extra love (even before going up in a one-time blog post). It takes time to do a decent release, and yes, sometimes creating all this “extra” stuff is a little boring. However, basic polish can make the difference between a forgettable component that no one uses and something everyone in the community enjoys. To convince a random developer to use your custom component, you need to guide them and show them how easy they can get started, and that’s the message I tried to emphasize in my session.

Thanks to everyone who gave me feedback! I may do a version of this session again sometime, and I got some helpful tips for areas that could use a bit more detail or some supporting visuals.

Download Slides (PDF file)

Open Source Flex Component: HeatMap

by Josh Tynjala

Note: I no longer work for Esria. Some links here may be broken because I no longer maintain the community site there. Being an open source project, though, I still have the original source code, and I’ve made a copy available for download from my own blog for those interested.

Over the last week, I’ve been working on a new Flex component, a heatmap! For those unfamiliar, a heatmap is a form of data visualization that uses color on a two-dimensional plane to compare values. Most recently, in the Flex community, heatmaps have been made famous by Universal Mind’s Spatial Key application. After seeing that go live, I knew people would be interested in an open source heatmap component for Flex, so I put one together and dropped it on Esria’s open source and community site (broken link removed).

Screenshot of HeatMap component

Overall, I found the process of building this component very straightforward. There are many similarities to my treemap component, but the heatmap is a bit simpler in many regards. One thing I particularly enjoyed about building the heatmap was that it required some pretty heavy optimization. Since it could potentially display massive data sets, manipulating the data provider and extracting the required numbers needs to be fast. I spent a lot of time diving into Flex Builder’s profiler. By the way, Jun Heider’s profiler session at 360Flex has some great info that helped me understand the profiler’s numbers better. I highly recommend checking it out.

In particular, I made a few good optimizations in some functions that could potentially run hundreds of thousands to even millions of times when preparing the data (basically, sorting a huge list of items). First, I made sure to access member variables directly. Usually, I’ll just use the public getter if it’s available, but it actually became a bottleneck when Array.sort() needed make such a huge number of function calls. Next, since a sort function potentially has to access the same value over and over again, I set up Dictionary-based caches to retrieve an item’s position and weight without having to recalculate these values every time. Personally, I’ve always been a little wary of the Dictionary type, but lookups proved to be very fast. Finally, though it didn’t necessarily have the same impact as the other optimizations, I drew the heatmap using a Bitmap rather than a Graphics object.

In addition to raw code execution speed, I included a couple other features to aid in performance. First, a sampleSize property lets you use every nth item in the data provider instead of every item. This won’t provide a complete picture of the data, obviously, but it will certain speed up the analysis by using a subset. Additionally, you can specify a weightField or a weightFunction. Normally, every item has a weight value of 1 used to determine the color of a region. Differing weight values can allow for more complex data, certainly, but it can also be used to combine multiple points together to form a smaller data set. For example, if you are using a region size of 30 pixels, you can combine all the items in the same region together since the heatmap won’t need more per-pixel position data. If your raw data has an item for every pixel in that 30×30 region, you’ll reduce the number of items in that region from 900 to just 1, but still have the same overall weight for that region. That can be a huge performance increase when you consider that this sort of reduction might be happening in every region on the heatmap. Moreover, by doing this on the backend, you’ll send fewer bytes to the client. Reduced bandwidth usage is always helpful.

The source code for the Flex HeatMap component is available under an MIT license. Be sure to check out the HeatMap API documentation (broken link removed) and look at the examples to get started.

Introducing RokTok, a Flex mashup featuring particle systems, last.fm and Twitter!

by Josh Tynjala

Now that I’m settling in as the new R&D guy at Esria, it’s time to start showing people some of the cool stuff I’m doing. Part of my job is to work with and evaluate new technology, libraries, and tools. The best way to do that, in my opinion, is to use them by building “real-world” applications. So, in order to begin playing around with the Mate framework and the Flint particle system library, I decided to build an app that I call RokTok. This fun Flex app combines the top musical artists on Last.fm with the community conversations on Twitter.

Screenshot of roktok app

I started peeking into the Mate framework just before 360Flex, and it looked pretty cool. I got the chance to see Laura Arguello’s Mate session at the conference, and afterwards I had no doubt that this framework was worth a deeper look.

Mate works a bit differently than the traditional Flex frameworks like Cairngorm, and that’s exactly what I like about it. Most of your work with Mate will be in an EventMap, an MXML tag-based event wiring system. Personally, I think this is a great way to utilize Flex’s native markup language and binding system, and to keep much of the framework code in one place. To me, it felt like I spent less time making the framework do its thing because I wasn’t creating half a dozen different classes to get one minor action to happen, yet it still felt organized. On the other hand, I could tell that larger applications with many events being handled in one place could lead to a large and unwieldly event map. Thankfully, there’s nothing stopping developers from breaking up event maps into multiple parts with only related events appearing in the same maps. Still, though, some developers may find that Mate works best for smaller applications that could still use a framework.

I love particle systems, and I’ve done several little experiments with them in the past. RokTok will be the first time I’ve been able to use them as part of an app, and making them visualize data seemed like a great way to do it. Many folks first head to Flare for data visualization in Flash Player, but I recently discovered the Flint particle system library for AS3. It’s obviously geared specifically toward particle systems, but in that area, this library definitely shines. I found the API extremely intuitive and extensible (good architecture, yay!), and it was super easy to integrate it into a Flex application.

Having designed my own particle systems in the past, and having trouble making them easily customizable, I was excited to see the approach Flint took for extensibility. Using Initializers and Actions to define behavior, Flint makes altering the way particles interact possible through small pieces that are easy to write and reuse. Having a decent collection of Actions that already come with the library and cover many of the most obvious behaviors certainly helps too. If you check out the source code for RokTok, you’ll see a few extensions I made in the com.flextoolbox.flint.* package.

I had way too much fun building RokTok as one of my first Esria R&D projects. If you’re interested in how it was built, check out the source code. It is released under an MIT-style open source license. Stay tuned because I’ve got a lot more cool stuff planned for my R&D and community efforts at Esria.

Pages: Prev 1 2 3 ...6 7 8 9 10 ...46 47 Next