Basically each of them tries to build smaller manageable parts of an application, but now I'm getting a little confused. I've seen the Mate Framework which claims to be an eventbased framework, but somehow the new States feels like it's overlapping. Can someone more enlightened than me bring some light on the subject, please!!!
States and events are 2 things totally different.
States is something you use inside a component. It represents the different state a component can have depending of some variables. For example, a login box could have a signup state and a signin state.
Events are used to communicate between components in a decoupled way.
At the end, you use both in an application.
Related
So, I am thinking of creating a new app in RxJS / React -- "maybe" cycle.js but what is holding me up is the thought of sharing state for a single page app.
Usually, you can self contain a components state - but because of user interaction on various parts of the page, I am curious best practices for architecture.
Granted, my knowledge of RxJS on a deeper level is not currently there - so I might be missing some obvious 'state' management ability.
So, cascade the components so the state flows down from the parent container - seems the easiest, but now I have one giant component with a bunch of children.
Introduce reflux
Really what my question asks: best practice for using RxJS / React and share state.
sidenote: the common examples of "counters" are trivial and have not been much help. For example, my need would be for instance - click an arrow, a pane slides in, a different part of the page - a title fades in.
Not sure if you took a look at my Rx React boilerplate (it has just a counter though!)
To utilise animation into your app in React you could use a library like React-Motion
I think what might be an easier route is to look at Redux as I'm sure there will be animation examples out there which can help you.
But if you are really wanting to do it in Rx then take a look at this Gist and the post explaining how Redux can be implemented with Rx, by Justin Woo.
I know this isn't the immediate solution in terms of react.
In Cycle you can check out TylorS's Repo which has animation through out.
and if you are after routing and other concepts in Cycle I've built a boilerplate here
I'm developing my first Android game and I'm having a bit of difficulty making the UI as smooth as I would like. I've spent a couple of hours googling around with no luck, I'm probably just searching for the wrong thing.
I have two different XML layout resources where each layout contains just one SurfaceView subclass. When I call activity.setContentView(R.layout.second_layout) to transition from the first layout to the second layout there is a noticeable period of time where a black screen (with a small white bar along the top) is displayed in between the two views.
I've tried various things such as; constructing the second view manually at runtime (i.e not using a layout XML file), calling activity.overridePendingTransition(android.R.anim.fade_in, android.R.anim.fade_out) after activity.setContentView(R.layout.second_layout) and attempting to render to the canvas before the view has loaded (turns out the canvas is unavailable).
I don't see other games (or apps) having this issue so I presume there is a reasonably simple solution.
If you need some more information about my particular situation in order to help out then please let me know what information is missing. Any help would be largely appreciated.
Update: My answer below was written in 2010. Since then Fragments have become the norm, particularly since Fragment nesting was made possible and the support library allows this functionality to be used in a backwards compatible fashion. As such, instead of transitioning to a new Activity to perform a new "user task", you can use the one Activity and push and pop fragments within that Activity's view hierarchy. Animations can also be performed as a part of a fragment transaction (e.g. Fragment transaction animation: slide in and slide out).
This became pretty apparent not long after posting this question, however I thought I should come back here and make it clear to everyone else.
Activities are positively the way to go when developing for Android. Don't be put off by the fact that a transition may seem too minor for a separate Activity, the very foundation of Android is built around the idea of an Activity.
I'm going to be going to be meeting with a number of programmers and custom software companies to get bids on creating a website for a company that I'm involved with. My question is this: What should I prepare for the programmers so that they can give me an accurate bid, timetable, etc. for the development of the website? I have a clear picture of how I would like the site to work and the features that I would like to have included.
I'd suggest using something like balsamiq to put some simple sketches together as suggested elsewhere.
Quite often the act of putting your requirements down on paper in a way that represents the actual site will flush out all manner of issues you hadn't considered before, and will give you a much clearer understanding of what you're after.
Also consider the sources of the data you're displaying. From a functional spec aspect, simply saying something like 'show this figure here' is easy. From a programming point of view, coming up with the figure in the first place is often the hard bit.
The best you can do is to put the end-user's hat on and describe what you'd like the system to look like / work.
Imagine all pages and create a new frame for each one. Make as many annotations as you can so all bidders know exactly what you are expecting.
I'd also add at the end if it's likely the site's requirements to change during development, so everybody's warned in advance.
Details Details Details.
You might think you have a clear picture, you don't. You need to write every single step down no matter how trivial. You will see there are things you haven't thought of.
Try to write down as much information as you can think of. Go through all the scenarios a user would when using your site. Use steps such as
1) User clicks on Buy Button
2) Screen shows up with 4 items, Link to details, price, quantity and a 32x32 thumbnail.
2a) If User clicks on thumbnail full resolution image i s displayed
etc etc.
Don't try to gloss over the "simple" stuff and you will get the most accurate bid possible!
Basically draw out what you want (ie textboxes, drop down lists, controls, etc) in very simple manner. Then add little numbers around each area that has some functionality. In the margins or on another sheet, describe each point you numbered on the controls with simple instructions on how that functionality should work.
Think of it as a skeleton to describe the application you want.
Not a complete list, but here a couple of thoughts:
Do not forget the back button.
Back button behaviour is an issue on every site I've ever worked on. Specify exactly what you want to happen on every page if the user gets to that page by hitting the back button. Often it's easy, but sometimes it is not at all trivial.
Security:
Do people need to log on, how, how do you create accounts, reset passwords etc. What pages need you to be logged on, what happens if you hit those pages without being logged on.
You could read Joel Spolsky's Painless Functional Specifications for ideas, but I've just tried to summarise what that means for web software too.
I usually do this in 3 stages:
a list of contents, under the headings they'll appear on the site. Get this firmly agreed by all parties before doing any wireframes;
a greyscale functional wireframe in plain HTML/CSS, using examples of real-world content and dummy static pages for dymanic content, with everything where it should be. This is the first thing programmers want to see;
a purely visual graphic mockup of each type of page - this is the next thing programmers like to see, as in 'show me how you want it to look and I'll make it happen'.
I have to write a multiplayer pacman game in Java for a university assignment and I'm after some feedback for my design so far.
So I'm trying to go down an MVC style and this is what I've sketched out.
I've never designed anything using MVC, so my knowledge is really only from the pragmatic programmer and a short lecture so it's quite possible I'll have misunderstood or misinterpreted it slightly.
Also, most of the tutorials I've seen for designing simple games don't mention MVC at all so is this a case where MVC is not a good pattern to use?
My idea so far is that the Game State class would be the main source of data storage as it were, and would use a 2d array to store the state of the game, where the ghosts are, where pacman is etc.
The Game class would be the main controller class that would contain the main game loop and control all the interactions between the data (game state) and the view (probably a GUI representation - I just added text based really as an example).
After I've got the game working I'm going to have to split it out into client/server. It seems to me, by using this model, that it wouldn't be too hard to keep most of the the data and processing on the server and have the clients interact with the controller and draw their own views. I have no idea (yet) how this may effect the performance of the game over a network so I'll have to research into that further once the single player version is done.
Any tips or advice, based on my design so far, would be greatly appreciated - also bearing in mind that it will eventually have to be a multiplayer game.
Cheers,
Adam
On the contrary: MVC is actually a very good thing to use for this type of problem and the Swing framework does a really nice job at supporting it.
You should probably first read up on MVC. Just as an overview, you will be trying to separate how the game is represented internally (the model), from how it is drawn (the view) and how that state is to change (the controller).
First think about everything you need to model the current state of the game. Having an Entity that defines some basic behavior and subclassing it for the PacMan and Ghost like you do is probably a good way to start, but you'll probably want to call your Map a GameBoard or the like (giving things the same name as library classes is generally a bad idea: you don't want to confuse it with java.util.Map). To wrap up the model section, you probably want to wrap them all up in one class who 'knows' the entire state of your game. Since this is your GameState class, you probably want to redraw your arrows.
Since determining the view is likely to be fairly easy, you can go there. You can give your GameState a draw(Graphics) method and invoke this from whatever your view is (which you'll decide later). This might in turn delegate do each of your Entities, who might in turn delegate it to a Sprite or Image object that they have. Now your view, who's likely to be a JPanel or the like, can just call draw() using its own Graphics object from within its paintComponent() method.
Now you still need a controller to actually make stuff happen. This is likely to be some object with a KeyListener hooked into the view as well as an InputStream and an OutputStream to handle communication with the other player (it probably also needs to be the one to worry about synchronizing the game state). It also needs to also have a timer so that it can tell the units to update periodically. You do need to decide who makes the decisions on whether the moves are legal: the controller could do it, the GameState could, or it could just give the Entities the information they need and let them do it themselves.
Once you have all of these parts, you can wrap them up in one final class who knows everything and gets it all set up and such. There's a lot more that I'm glossing over and several more decisions that you have to make, but it should get you going.
I agree with James entirely, and would like to add that you might also want to make sure that this 2d array of yours for the game state can handle some edge cases like multiple ghosts occupying a tile, a pacman and ghost in the same tile (depending on how you handle it in your code), the pacman's food dots, etc.
Good planning more often than not makes the best programs, I'm glad to see you have started off with a diagram.
Is there some standard way to make my applications skinnable?
By "skinnable" I mean the ability of the application to support multiple skins.
I am not targeting any particular platform here. Just want to know if there are any general guidelines for making applications skinnable.
It looks like skinning web applications is relatively easy. What about desktop applications?
Skins are just Yet Another Level Of Abstraction (YALOA!).
If you read up on the MVC design pattern then you'll understand many of the principles needed.
The presentation layer (or skin) only has to do a few things:
Show the interface
When certain actions are taken (clicking, entering text in a box, etc) then it triggers actions
It has to receive notices from the model and controller when it needs to change
In a normal program this abstraction is done by having code which connects the text boxes to the methods and objects they are related to, and having code which changes the display based on the program commands.
If you want to add skinning you need to take that ability and make it so that can be done without compiling the code again.
Check out, for instance, XUL and see how it's done there. You'll find a lot of skinning projects use XML to describe the various 'faces' of the skin (it playing music, or organizing the library for an MP3 player skin), and then where each control is located and what data and methods it should be attached to in the program.
It can seem hard until you do it, then you realize it's just like any other level of abstraction you've dealt with before (from a program with gotos, to control structures, to functions, to structures, to classes and objects, to JIT compilers, etc).
The initial learning curve isn't trivial, but do a few projects and you'll find it's not hard.
-Adam
Keep all your styles in a separate CSS file(s)
Stay away from any inline styling
It really depends on how "skinnable" you want your apps to be. Letting the user configure colors and images is going to be a lot easier than letting them hide/remove components or even write their own components.
For most cases, you can probably get away with writing some kind of Resource Provider that serves up colors and images instead of hardcoding them in your source file. So, this:
Color backgroundColor = Color.BLUE;
Would become something like:
Color backgroundColor = ResourceManager.getColor("form.background");
Then, all you have to do is change the mappings in your ResourceManager class and all clients will be consistent. If you want to do this in real-time, changing any of the ResourceManager's mappings will probably send out an event to its clients and notify them that something has changed. Then the clients can redraw their components if they want to.
Implementation varies by platform, but here are a few general cross-platform considerations:
It is good to have an established overall layout into which visual elements can be "plugged." It's harder (but still possible) to support completely different general layouts through skinning.
Develop a well-documented naming convention for the assets (images, HTML fragments, etc.) that comprise a skin.
Design a clean way to "discover" existing skins and add new ones. For example: Winamp uses a ZIP file format to store all the images for its skins. All the skin files reside in a well-known folder off the application folder.
Be aware of scaling issues. Not everyone uses the same screen resolution.
Are you going to allow third-party skin development? This will affect your design.
Architecturally, the Model-View-Controller pattern lends itself to skinning.
These are just a few things to be aware of. Your implementation will vary between web and fat client, and by your feature requirements. HTH.
The basic principle is that used by CSS in web pages.
Rather than ever specifying the formatting (colour / font / layout[to some extent]) of your content, you simply describe what kind of content it is.
To give a web example, in the content for a blog page you might mark different sections as being an:
Title
Blog Entry
Archive Pane
etc.
The Entry might be made of severl subsections such as "heading", "body" and "timestamp".
Then, elsewhere you have a stylesheet which specifies all the properties of each kind of element, size, alignment, colour, background, font etc. When rendering the page or srawing / initialising the componatns in your UI you always consult the current stylesheet to look up these properties.
Then, skinning, and indeed editing your design, becomes MUCH easier. You simple create a different stylesheet and tweak the values to your heat's content.
Edit:
One key point to remember is the distinction between a general style (like classes in CSS) and a specific style (like ID's in CSS). You want to be able to uniquely identify some items in your layout, such as the heading, as being a single identifiable item that you can apply a unique style to, whereas other items (such as an entry in a blog, or a field in a database view) will all want to have the same style.
It's different for each platform/technology.
For WPF, take a look at what Josh Smith calls structural skinning: http://www.codeproject.com/KB/WPF/podder2.aspx
This should be relatively easy, follow these steps:
Strip out all styling for your entire web application or website
Use css to change the way your app looks.
For more information visit css zen garden for ideas.
You shouldn't. Or at least you should ask yourself if it's really the right decision.
Skinning breaks the UI design guidelines. It "jars" the user because your skinned app operates and looks totally different from all the other apps their using. Things like command shortcut keys won't be consistent and they'll lose productivity. It will be less handicapped accessible because screen readers will have a harder time understanding it.
There are a ton of reasons NOT to skin. If you just want to make your application visually distinct, that's a poor reason in my opinion. You will make your app harder to use and less likely that people will ever go beyond the trial period.
Having said all that, there are some classes of apps where skinning is basically expected, such as media players and imersive full screen games. But if your app isn't in a class where skinning is largely mandated, I would seriously consider finding other ways to make your app better than your competition.
Depending on how deep you wish to dig, you can opt to use a 'formatting' framework (e.g. Java's PLAF, the web's CSS), or an entirely decoupled multiple tier architecture.
If you want to define a pluggable skin, you need to consider that from the very beginning. The presentation layer knows nothing about the business logic but it's API and vice versa.
It seems most of the people here refer to CSS, as if its the only skinning option.
Windows Media Player (and Winamp, AFAIR) use XML as well as images (if neccesary) to define a skin.
The XML references hooks, events, etc. and handles how things look and react. I'm not sure about how they handle the back end, but loading a given skin is really as simply as locating the appropriate XML file, loading the images then placing them where they need to go.
XML also gives you far more control over what you can do (i.e. create new components, change component sizes, etc.).
XML combined with CSS could give wonderful results for a skinning engine of a desktop or web application.