Standard to have one or many instances of class that uses ThrowPropsPlugin?

[Big Bad Roo]

Hi

 

I've set up a class that uses the ThrowPropsPlugin - it accepts a movieclip for scrolling in an AIR  iOS project.

 

Currently I'm setting this class up as a new instance in every class I need scrolling in, but it seems wasteful.

 

Is there a standard way to have one such scrolling class, that all your classes send movieclips to for scrolling?

 

Is it a matter of having a var in a global model that all classes send movieclips to, and then that var dispatches the movieclip to the scrolling class?

 

Or is a better way to create the class once, and inject it into the constructor of every class that needs scrolling?

 

Cheers

[GreenSock]

Yeah, if I were you, I'd probably make a "Scrollable" class or something like that you can wrap around your MovieClips. Like:

var myScroller:Scrollable = new Scrollable(myMovieClip);

And of course add whatever parameters/options you want. 

[Big Bad Roo]

Thanks Jack

 

That's kind of what I've done, but what if you have many classes that you want to access the one instance of Scrollable?

 

My current problem is I have many screens I want to use in Scrollable (one displayed at a time), so I'm ending up with a huge class accomodating all these screens and their logic. I'd rather have many smaller classes, all able to send movieclips to one central Scrollable, but I'm unsure of the best way to set it up - have classes send their clips to a central model that talks to Scrollable, or create Scrollable, and inject it into the constructor of all the classes that need access to scrolling as in...

 

scrollable.scrollClip = null;

scrollable.scrollClip = _myMovieClipFromMyClass;

 

each time I want to remove the old scrolling clip and add a new one.

[GreenSock]

I may not be understanding your question properly (I'm super tired) but wouldn't you just do something like:

 

scrollable.setScrollClip(myClip); 

 

(or use a getter/setter). 

 

And that would unhook the old content and wire up the new stuff. 

 

In my head, it makes more sense to encapsulate the scrolling logic into its own class/instance, but maybe your project has some unique constraints/requirements that don't fit that model well. I don't think it makes as much sense to pass an instance into every MovieClip's constructor because what if down the road you don't want that particular MovieClip to scroll? Do you change the constructor? What if the API of your Scrollable class changes a bit? Do you go through all of those other classes and make edits? 

[Big Bad Roo]

I think I'm not understanding some class fundamentals.

 

To set up that scrollable.setScrollClip(myClip); scenario, wouldn't you need...

 

private var scrollable:Scrollable = new Scrollable();

 

...in every class that uses it, and therefore you'd have (if you have 30 classes controlling 30 screens), 30 separate instances of scrollable, ie 30 separate scroll screens?

 

How do I have just one Scrollable that all classes have access to using scrollable.setScrollClip(myClip);?

 

The only way I can see how is with a getter/setter, but then you'd have to inject the model with that G/S into all your classes that need scrolling.

[GreenSock]

Yeah, that doesn't seem intuitive to me (to only have one scrollable instance) - it'd be kinda like the browser having only one scrollbar when in reality, there are lots of things that may need scrollbars (the window, individual DIV content, textareas, etc.) so it'd make more sense (at least to me) to keep it modular. Kinda like having a "Window" instance where you can drop content into a container that handles scrolling. The content itself doesn't have to care about scrolling - its container does that. See what I mean? 

[Big Bad Roo]

Ahh - this is one instance for mobile that I can load MCs into and out of that is the scrolling area for the whole screen. I realised I really needed to have ALL of my screens be scrollable, and this would be better that having a scroll instance for each screen's class.

 

Cheers Jack