From the docs, ScreenAdapter is convenience implementation of Screen. I am not sure when is it better to implement Screen and when extend ScreenAdapter. What are the specific benefits of doing it one way or another?
ScreenAdapter implements Screen, so the result in practice will be the same. The code will look a bit different though.
The convenience of ScreenAdapter is that it provides a default empty implementation. So you don't have to #override methods that you don't need, keeping your code cleaner.
However, java doesn't support extending multiple classes. For example you can't extend both ScreenAdapter and InputAdapter. In that case you'd have to choose which one to extend and you'd have to implement (write code even you dont need the method) the other.
Make sure to have a look at the source and see for your self, it's nothing magical:
https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/ScreenAdapter.java
That said; having the convenience of not having to implement the methods, might make you forget about those methods. For example, if you implement ApplicationListener then you are confronted with the life cycle of your application, but if you extend ApplicationAdapter then it can be easy to forget about e.g. the resize or dispose method. Therefor, personally, I usually use ApplicationListener when creating a tutorial and such. On the other hand when I need to write a quick test or alike, I use ApplicationAdapter.
Related
First off I apologize for the slightly vague question.
I'm a self-taught coder and the more I work, the more I find myself wanting to invest in the whole process (and God knows there is room for improvement).
I'm looking for very "basic" material (books recommendation if you can!) about things like how to structure code and comments to make things clear, how to structure a project directory (How far should I divide my stuff into packages? How to properly name classes, subclasses, make it all understandable and clear?), this kind of stuff. Not the actual how make things work, but rather how to make things clean, understandable and well structured.
I've been reading a lot on design patterns, good software design and things like that, but there is this "gap" in my knowledge where I can think of a good solution to my problems, but the execution itself is pretty messy and ugly.
I've always worked solo, and chances are I will soon be working with other coders on my projects. Right now I sometimes have trouble understanding my own code, so there is no way others could dive in and help me.
I'm coding in AS 3.0, should anyone wonder.
Thank you very much :)
Depending on how new you are to coding, I'd recommend looking into why 'encapsulation' makes sense.
When I was new to object oriented programming I couldn't understand the appeal of encapsulation, but now I see how it really can help keep your code 'clean' - and I strongly suspect it's fundamental to a lot of other object oriented concepts; Design patterns, avoiding 'tight coupling', composition, code reuse and so on.
Here's the wiki info on encapsulation...
http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)
..but here's my summary:
I've heard the analogy of a car used: The user doesn't need to know HOW the engine works; they just need to know that, when they turn the key, the engine WORKS. Encapsulation keeps the implementation of a class's methods secret. The methods themselves are public (to be accessible outside the class) but properties are private.
By making properties private and limiting the number of public-facing methods in your classes you can have your classes operate as independently as possible. It also means you can totally change HOW a method is implemented inside a class (so long as it retains the same name and argument signature) without anyone OUTSIDE of that class needing to know anything about it. Even if that 'anyone' is YOU it can still really speed up development because you're not having to track down multiple references to public variables of the class throughout your code.
So AIM to have your classes perform one function; Think about if a method would, in fact, be better 'hidden away' in another class. Even if you have multiple objects instantiated 'inside' another, your code will be much more clean and you can be more sure about WHERE that specific piece of code you're searching for is - if a class mostly has one function, it's easier to remember what it does.
Other than that, I'd also recommend using only shallow inheritance; Having a complex hierarchy of classes and subclasses can lead to objects that need to inherit from more than one class. Look into 'composition' and interfaces too. (Interfaces are kind of AS3's solution to not having multiple inheritance).
I've been working on the web for quite a long time and I saw the "best practices" evolve. I'm now fairly convinced separating HTML (Content), Javascript (Behavior) and CSS (UI) is the best thing to do.
A few months ago, I started using knockout.js . I did choose it among other similar frameworks like backbone or angular because a chapter in an MVC training I followed was about knockout, and the concept seduced me. Then after a quick comparison on the web it didn't look as a bad choice for my needs, and for a start.
But here's my problem : when I look at my HTML code now, after a few weeks of dev on a project, there's quite a lot of knockout bindings in it, and it makes me think a lot about the old times, when we (or at least I) used to put inline javascript event handling through onclick attribute and so on.
Therefore those 2 questions, which I'm not sure are 100% suited for SO, but I can't find any better StackExchange site to ask it :
Is using knockout (or the other frameworks as they all seem to basically work with the same pattern) contrary to the "separation rule" ? Or is it an acceptable small-step-out of this rule ? or is it even perfectly acceptable because it uses the "data-" attributes ?
In the case this would be a somehow bad practice, is there any possibility to do all the binding through a separate javascript file, using for example jQuery to select the controls and apply bindings to them ? If not possible in knockout, is it with another framework ? I must admit at the time I did my selection, I diddn't think about this kind of implications...
Thank you and sorry if this should be moved to another SE site.
I had the same initial reservations as you, but I have to say that having the bindings in the html and not hidden away in a JS file seems so much better to me, as the link between presentation and functionality is now completely obvious. It massively reduces the possibility of changing some HTML and breaking functionality because you weren't aware that someone had hooked up some javascript to an element using jQuery.
Also, as you point out, the use of the data-bind attribute does, I think, mean that it does adhere to the separation rule, though if you want to stick to it rigidly then make sure all bindings are to observables, computed or functions on your view model, don't use any code (i.e. a visible binding that checks the state of two observables). I'm not sure I'd take it that far though.
I guess everyone started to learn KnockoutJS have the same concerns.
IMHO, there must be some way that connects models(JS object) with views(HTML markup). Then we should have something that says:"When that button is clicked call this function with that arguments." or "Hide this element while you that JS array is empty" and so on. So how we can put/say/state that connection in a readable, reusable and clean way.
If you used another JS file to handle that connection, then you 'll have large lines of code just to put your connection logic and you need to know how to select the DOM element you are targeting. You 'll end up with massive code(probably lot of jQuery) just to make your HTML dynamic and alive(i bet most developers got into that many times). I haven't use other libraries or frameworks but i think they just make your massive code more organized.
On the other hand by KnockoutJS use Declarative Bindings, this is the link between models and views. It's more readable, easy to plug it in/out and it allow you to just focus on writing a good JS model object.
I guess to truly check separation think what if you sometime needed to change your model, how much changes you need to do to your view? and vice versa?
Adding to the rest of the answers, some tips:
Make sure there's no business logic in your bindings. Any logic (which should be minimal) should be "view logic": decisions that only affect how your view looks, not how it works. Deciding how many items to display per screen is view logic; deciding whether the user can add another item is business logic. It's perfectly OK to put view logic in your viewmodel rather than your view, and it's desirable if it involves lengthy expressions.
Keep "magic numbers" out of any view logic in your bindings. If it's a parameter that could be changed (e.g. number of weeks of results to show) as opposed to a true constant (e.g. number of days in a week), make it a property of your viewmodel and reference it in any expressions in your views.
It's been about 2 years since I built a component extending the fl.core.UIComponent class, so I figured I would refresh my memory a bit and review the docs. But the docs are not listing all the methods. I know that there are more functions then what is listed on the help page.
If you go to the adobe help for UIComponent page and scroll down to the protected methods I only see the getStyleVaue() method when I know there are more like the "draw" method is one for example.
How can adobe document a class and leave out one of the most important methods.
Is there a filter or something I am missing?
Note: This is fl.core.UIComponent, not the flex one.
You have encountered the wonderful game invented by Adobe called "guess the filter." Make sure you have Flash selected, and the appropriate version of the product.
I'm working on a project in Flash CS4/AS3 and I have a document class set up but I am wondering about using that, as opposed to frame-based scripting. Most of what I have seen so far deals with how to create them, but doesn't offer much about why or when to use them.
I know I can also pull in other classes beyond the document class but, again, why and when?
Could I get some input from you fine people out there on usage/best practice, etc?
Thanks
If this is just a simple demo or a movie, you can use the time line.
But if you're going to make a program, with classes, you should have a document class.
A document class is the main class of your programs. it's actually your initializer of all the program's processes and components, and it's simply more proper and similar to other programming languages.
Plus, it's in a different file, and it is easier to edit it this way.
Also, your doc-class will be a class and not just code in the air.. it also has auto-complete in CS5.
I am kinda new to AS 3 development.. and the thing is I am always getting into problems how to structure the different views of an application state?
Do you use a MVC framework for this? I have looked at some puremvc, robotlegs but our flash projects are usually relativly small so I wonder if it is not a overkill :)
Design patters are good as long as you don't try to use them for the sake of using them. I always have my views separate to model as it is, but rarely work on something big enough to warrant a flow blown implementation of something like PureMVC. On large projects then yes they can be beneficial. The hard part is deciding how "big" is big enough to use them. Probably comes down to experience to make that judgment.
Anyway just make sure objects are loosely coupled and that your model and view are not one and the same. Quite often instead of extending a MovieClip I prefer to use composition and have a class have a MovieClip. For me I think it helps separate visuals from the data.
To be honest I'm not a fan of applying traditional design patterns to Flash development. If you're writing pure classes then you can do anything you like, but if you're linking classes to visual elements (like MovieClips), I find that the proper way to structure things (i.e. the way that best avoids duplication of effort and preserves separation of concerns) winds up being dictated by how you need to stack and/or nest your display timelines.
In other words, I find it better to work out at the display level what things ultimately will need to be in the same or in different timelines, and what will ultimately need to be nested or not nested, and then work out which classes should extend or compose each other afterwards.
But note that this is all assuming you're making stuff where the logic is closely coupled with the display elements, which is what I consider the area where Flash shines. Naturally if you're making a loan simulator with no animations or skinning or whatever, it's sensible enough to just use an MVC pattern and then slap a static display layer on top, with each button pointed to a C and each text box pointed to a V. But then that's exactly what you'd do if you were making the same thing in Java, or as a JS-powered HTML form, or whatever else. The advice in this answer is what I find works best when you're making the sorts of heavily visual things that would be ill-advised to attempt in anything but Flash.
A framework can be particularly valuable if you intend on handing the code off to someone else. Whatever framework you choose, you'll introduce a common set of expected relationships from which someone can build an understanding of the codebase.
If the view logic is largely sequential, or at least modal, an easy non-framework mode of organization is to group your views into "pages" and have a single controller manage which page is on-stage at a time and feed in model data from wherever.
if you are really new to AS3 and are planning to do "pure" coding (neither using the graphical approach promoted by the Flash authoring tool, nor diving into the Flex world), i suggest you don't waste your time on AS3 and move on to Haxe ...
Haxe is not very well known, so the only opinions you'll get are from people using it ... there's a little bias of course, but you may read their statements here, here and here ...
now when it comes to patterns and framworks, there are many possibilities ... design patterns are solutions to a set of problems ... do not make the mistake of trying to transform all the problems you encounter into problems that fit the patterns you know ...
in my book, there is one fundamental principle for software design: DRY & KISS - I admittedly still have a lot to work on the latter ... :) ... for more concrete and guiding principles, I stick to SOLID and GRASP ... if your read them carefully and reflect upon the (good) patterns you know, you are likely to find out, that they incorporate said principles ... do not overuse patterns ... do not overuse any tools in fact ... use whatever tool is the best for the job ...
IMHO, pure AS3 is for geeks ... and I love doing pure AS3 ... or at least I did ... it is however uneffective and unrewarding over time ... it is good for developping frameworks and libraries ... but nor for apps ... Haxe is good for distributed cross-plattform apps (and for geeks), Flash Authoring approach for "fancy" visual apps, and Flex for classic apps featuring prevalant UI concepts ...