Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
GreenSock

NEED FEEDBACK: LoaderMax

Recommended Posts

LoaderMax is almost ready to be released into the wild and I wanted to solicit some specific feedback:

 


    [*:24dawszw] One of the design goals was to keep things relatively lightweight while delivering incredible convenience in a robust package. It's about 7k with the base classes and DataLoader, and if you do ALL of the loaders (video, image, swf, mp3, css, data, and xml), it's about 14.75k combined but that represents a pretty massive feature set considering the size. Of course the system is designed so that it only needs to compile the loader types you use, so if, for example, you only use ImageLoaders, it'd be 9.1k total. Are there any features that you think are wasteful at this point? Any pruning necessary?
     
    [*:24dawszw] Can you think of any way to make the API simpler and easier to use? Are the method and property names concise and intuitive (see the ASDocs)? Is the overall practical usage simple enough?
     
    [*:24dawszw] What do you think of the CHILD_* event names? Technically, the events cover all descendants, not just children of a LoaderMax, but DESCENDANT_* seemed too cumbersome. So if an ImageLoader dispatches a LoaderEvent.ERROR, for example, it will bubble up through not only its parent but also grandparent(s), etc. This behavior makes sense but I was just wrestling with the name of the events, that's all. Any better ideas?
     
    [*:24dawszw] Any glaring omissions? Key missing features?
     
    [*:24dawszw] Is there any reason you WOULDN'T use LoaderMax?
     
    [*:24dawszw] In your opinion, what's the best feature that sets LoaderMax apart?

 

Also, please make sure you download the latest version (posted EARLY this morning) and let me know if you can find any odd behavior or bugs. There were some significant changes to the way events are handled in the latest version (much improved in my opinion), FYI.

 

Thanks for your input!

Link to comment
Share on other sites

1. For my purposes, the weight isn't an issue and I don't see any obvious waste to cut. I think you've achieved your stated goal.

 

2. I don't think it's difficult to use at all and the naming seems logical and straight forward.

 

3. Please do not use DESCENDANT_ which, while accurate, is too long and something I'd be more likely to misspell. The current naming is fine even if potentially inaccurate.

 

4. Thanks to the addition of .parse(), nope. :)

 

5. I often work with data from outside sources that isn't structured conveniently for my use, so having a locked in XML structure was a bit of overhead that may have been enough to put me off. Now that you have .parse(), I can side step the XML and just throw what's needed into an array and run with it, so I don't have any compelling reason NOT to use LoaderMax.

 

6. It's simply the convenience of not having to worry about building out a custom loading system for each project. I no longer have to worry about what kinds of things I'm loading or building a system to handle the associated events. Thank you.

Link to comment
Share on other sites

1 - 7k min to 14.75k max is nothing in my opinion. I think that your goal of keeping things small is great, and should always be a consideration when developing for the web, but anything loaded in, is almost guaranteed to be larger than the library itself (mp3's, images..). This may be obvious, but percentage wise, your library is trivial in size compared to what it will be loading in. With your tweening libraries, size was far more important - because there is a good chance they would've been used in super small swf's such as banner ads, etc.

 

2 - No. Yes. Yes

 

3 - I think CHILD_ is fine, as ricewing said, DECENDENT_, I mean DESCENDANT_ will most likely lead to spelling mistakes. CHILD isn't too much of a stretch in terms of naming, although CHILD doesn't imply grandchildren, great-grandchildren, and so-forth. Personally I would much rather CHILD_ as it's quicker to type.

 

4 - Nope

 

5 - As long as it follows the same Terms of Use as the Tweening Platform (which I believe you said it will), no.

 

6 - It offers another level of abstraction that is built from the ground up for generic use. Developing my own loading procedures always ends up with the loading code becoming far too coupled to the main program for my liking. LoaderMax is coming from a proven coder (thanks to the Tweening Platform) so my own code can concentrate on doing its job, rather than checking is File1 loaded, oh is File2 loaded, oh and by the way is File3 loaded, etc.

 

Thanks

Link to comment
Share on other sites

1. I agree. Filesize is fine. Any smaller, and it wouldn't do anything :!:

2. Easy to use, docs are clear. More examples are always useful - shortens the learning curve for non-techies.

3. CHILD_* is fine (I can spell it, unlike DEESENDENTS_*)

4. I used this for a job and it does everything I need (and more)

5. No. Couldn't live without it.

6. I no longer worry about loading. Leaves more time for me to work on the interesting aspects of a job.

Link to comment
Share on other sites

1. Filesize is fine

2. it's pretty simple, I didn't have any problems with my initial tests.

3. child seems fine

4. nope, you added FLV Loading which was my one request

5. like cjke.7777 said, only if the licensing prevented me from using it on certain projects

6. not having to worry about memory management for loaded assets is nice

Link to comment
Share on other sites

first of all, Im italian, so my english is not where i shine... that being said:

 

1. size is not an issue as all of your classes, and no, no wasteful features, I think however you could add in the future the capability of loading an external SWF and extracting the font embedded inside making it available to use within the loader, that would be AWESOME!!!

 

2. No, yes,yes.

 

3. Im not crazy about flash events and the way they "communicate"... have you seen this project yet? http://flashblog.robertpenner.com/2009/09/my-new-as3-event-system-signals.html... but again, with a little help from a good AS editor constants names are just fine!

 

4. Ops, I wrote it in the point N.1, sorry, I couldn't wait!

 

5. Yes, the day I'll stop programming in AS3 ;)

 

Keep up the good work!!

Link to comment
Share on other sites

1. size is not an issue as all of your classes, and no, no wasteful features, I think however you could add in the future the capability of loading an external SWF and extracting the font embedded inside making it available to use within the loader, that would be AWESOME!!!

 

It should be pretty easy using the getClass() method of SWFLoader, like:

 

var FontLib:Class = myLoader.getClass("Verdana");
var font:Font = new FontLib () as Font;
Font.registerFont(FontLib);

Link to comment
Share on other sites

Here's my opinion: (I'm Italian too ;) )

 

1. I totally agree with you about the package size, sometimes, using your tween classes i was glad to have the nano and lite version to decrease the size of my projects: here in Italy the bandwith is still not so good as in USA so often clients complain about file size! So please go on designing that way.

 

2. The usage is pretty simple but: i am still debating about the use of vars object as constructor parameter, and the use of single parameters as vars: in the latter you always see all the parameters in the hinting while constructing but you are obliged to put all of them, in the former you can put the parameters you like leaving the others as default, but you cannot see parameters description in the hinting, so you have to see the ASDoc to remember all of them, loosing time. So i'm still asking which is the best solution.

 

3. I think it's a good solution.

 

4,5. YES. I still think that a parameter to automatically add a PRELOADER CIRCLE should be a very important feature, that's why I am still using my CustomLoader class instead of your (but i used your PreloadCircle to add the feature!). To minimize class size you could use the same ACTIVATION method you've already used in all your plugins package, i mean: if you set "preload" to true, you ACTIVATE the classes you need to use, otherwise you don't. You could put the x and y of the preloader at the center of the container object as a default. In my class the preloader color is the only significant parameter, all the others are default.

 

6. The best feature are: the queing possibility, the xml driven dynamic creation of loaders, the parse magic, but generally the best feature is the package itself ;) !

Link to comment
Share on other sites

1. no

2. no

3. CHILD_

4. no

5. no

6. I like how rizal72 puts it. :) Seriously this stuff is good. Disclaimer: I haven't tried video loading yet. If I can use VideoLoader with CDNs then no problem.

 

You know this lib is *almost* like loading content on a web page especially with the .parse() method. Give me this and put it there. And boom. there it is. Combined with your progress display classes.... whoo boy!

Link to comment
Share on other sites

1. The size is not an issue.

 

2. At the moment, the API naming isn't an issue. Pretty understandable so far, and I can always refer back to the ASDOCs.

 

3. CHILD is shorter and almost means the same thing to me.

 

4. After the new addition of LoaderMax.parse(), everything seems complete so far! Maybe a preloader animation interface class so we can build and plugin a custom preloader animation to get the loading status.

 

5. Nope.

 

6. Automatically creating Loaders from XML LoaderMax nodes. Automatically getting the base class from a swf helps a lot in my project as well.

Link to comment
Share on other sites

Maybe i haven't looked enough in to this, but it seems there is one glaring omission from the LoaderMax class : the ability to completely clear the queue. I can remove loaders, but that requires me to maintain references to the loaders i append/prepend. Is there something like a myloadermax.clear() that will effectively cancel() the load in progress and then flush the queue entirely, allowing me to append new stuff to the same loader instance?

 

I can get around this by creating a new instance each time, but that seems a little silly to me :)

 

If there's something in this package I've missed that will allow me to do this, please let me know what it is!

Link to comment
Share on other sites

LoaderMax has an empty() method that does exactly what you're talking about.

Link to comment
Share on other sites

I'm retarded -- thanks for the reply!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×