Sunday, December 6, 2009
timer
The timer cannot be started inside the actionPerformed method since it will work only once but have to be set in some external method so that once started it will call actionPerformed every time it changes to do the updates of the graphics values and manage the count by decrementing it.
Then if you create such external method like:
public void start() { if (count!=0) timer.start( ); }
then inside actionPerformed you need to have two conditions checked:
1. if ( src == “your button” ) then get the text, convert it into an integer count and issue:
start(); ( see the method above)
2. if ( src == timer ) , meaning that timer value has changed since it has been started AFTER the previous condition has been processed, then do the operations on count by decrementing it and updating values necessary for graphics.
Wednesday, December 2, 2009
About Project...
User view: visual quality, value-adding supporting services and user-friendliness.
Systems architect view: sophistication of the whole design, good project description (you understand what you did, what was valuable, and what can be improved in the near future).
Programmer view: technical level of implementation.
Therefore, it is up to you to see what level of quality you want to bring your project to. The more good stuff you put in your project the better.
Advice 1: after you have your project satisfying the completion requirements - save it and do not change. Make a copy and enhance the copy only in order to have a working version in case it will stop working during the improvements.
Advice 2 on advanced efforts that can give you some grade enhancement:
1. The design of the game itself. How interesting and user-friendly it is? Do you manage bets, win/loose statistic, other game supporting services?
2. Advanced use of classes (not only for pictures, but may be for separating some operations - like accounting, etc. into a separate class, which communicates with the main interface).
3. Advanced algorithm elements like some intelligence allowing the computer to play against human (just a bunch of IF-ELSE statements).
4. Threads, including animations.
5. Good user input validation (like what happens if instead of a number they type in a letter, etc.)
6. Visually nice layout of the playfield, buttons and other components.
7. Good internal structure of the program with methods representing logically separate parts of program logic and other methods calling them when necessary. Absence of repetitive operations that could have been done with loops. Sufficient commentary in the program text.
8. Good paper explaining your project, the game, the approach used, the advanced methods, etc. - showing all the best and important that you have and making your project well understood.
Friday, November 13, 2009
Grades for week 9
Although the minimal requirements were satisfied by all, as I said in the beginning of the course, the contenders for A-level grade should try to maximize the effect of every task (not just formally satisfy it). This week we saw how some students took the idea of size and color control to a higher level allowing to do it dynamically. This supports the dominant program development pattern: MVC (model-view-controller) where the way the user tries to control the systems behavior and the way the backbone model works (image in this case) are separated into different classes, allowing to change the model (images) without changing the way users interface with the system or change interface behavior on the same internal models.
Tuesday, November 3, 2009
Classes
The T9.3 task will not be checked (there are no points for it) but just to remind you that the described feature should be in your project. T9.2 is a simpler task dealing only with modification of the example. Of course, you could do it by changing your project (like having some graphics moved to another class), which is more than the T9.2 calls for. If you understand classes well then I would suggest to do T9.2 as it is required (will be a small piece of work for those who understands classes) and then without hurry redesign your project into may be several classes (the better use of technology - the higher the grade for the project will be). One class might handle the interface, another handles logic of the control panel, and the third one deals with the game engine (as game state generation, getting user input, and win/loose calculation with no connection to the GUI interface). But if you want to start with one class for now (like some graphics in your project) you can do it. The class design that I just described corresponds to the modern MVC pattern (read about Model View Controller pattern on the Web). The View here will be not just the picture but the whole layout (although art could be a small subclass). The picture will probably change in its implementation when we get to the threads (as another form of concern separation) anyway. The general rule is to keep something in a separate class (object-oriented design), which will have a life (changes) of its own. So if you plan to play with picture by changing it as a result of the event processing - then it should be another class serving the proper image based on the user choices and resulting system’s reaction.
A simple description of the typical class structure and a simple example are on pp.237-239.
If you want to know more about classes – read: http://java.sun.com/docs/books/tutorial/java/javaOO/classes.html . Somewhat more advanced tutorial is here: http://home.cogeco.ca/~ve3ll/jatutor4.htm . For deeper understanding of classes: http://leepoint.net/JavaBasics/oop/oop-10-intro.html see all pages and also the whole chapter 3 in http://docstore.mik.ua/orelly/java/javanut/ch03_01.htm .
Monday, October 26, 2009
Plan for exercise 12
5. Repaint
Saturday, October 24, 2009
Pseudocode use (example of Tic-Tac-Toe)
Now your programs are becoming bigger and you need to exercise some discipline by planning the structure of your program before rushing to code.
For example in Tic-Tac-Toe task the plan (sometimes called pseudocode) can be more or less detailed in the beginning but rather more detailed when you are approaching actual coding. Initially it might look like the following:
- Set up your JPanel with GridLayout
- Declare an integer counter variable
- Declare 9 JButtons (for example named b1, b2, etc.)
- Add ActionLiteners for all buttons in init() method and add each button to the display panel of the game field
- Add a listener method itself using actionPerformed(ActionEvent e)
- Add logic for each possible variation of clicked button along with the counter logic checking if it is an odd click or even when in one case use (for example if b1 is clicked) something like b1.setText(“X”) ; or setting the text to “O” and also add button logic like if(actionCommand==”1”){… where you will be setting text to the proper letter and incrementing the counter variable by one (so that next click will setText to a different letter).
Note1: the last logic assumes that you define buttons like: JButton b1=new JButton("1");
Note2: you can use actionCommand in your IF-logic, which uses the label that you gave the button (see Note1) or you can use the system name (b1 - this case) if you get it from a.getSource() method like in the Example 8-14, where a comes from actionPerformed(ActionEvent a)
Remember that if you need more info oin any method - use google.
If after this you have a clear understanding of your programming sections – start coding. If you need to iron out more details – add these details to the pseudocode.
Of course the program can be enhanced in many ways like detecting the winner or even playing against human, etc.
Friday, October 23, 2009
Week 7 problems
Here is the main challenge of teaching Java on a good level but from the very beginning (not as Java 1, Java 2 and further courses): you can do simple little exercises without any understanding of how the real working programs work, or you can have a workable environment where some things are not clear but they work and getting deeper understanding by the week with new learning. I chose the second approach. But… it is important that you realize what is happening. You play (modify) some working examples but if you decide in you projects to get into unchartered waters – the lack of really deep understanding will immediately popup in various strange behaviors and errors.
Advice: do not be afraid of suddenly exposed problems but stick closer to the textbook examples in your project development. Don’t run ahead of the train. With every chapter your knowledge (if you really apply yourself) will grow and you will be able to enhance your project more and more. I will be giving you simple tasks as well as tasks on adding new features to your projects. If you suddenly get into problems with more complex use of the material – simplify it in a way to be closer to the textbook (even if some parts and statements you do not deeply understand – just use them as shown).
Of course, if the problem is in the learned material you have to reread the textbook and, possibly, do the Google research on the problem in various online tutorials and explanations. But of you see that the problem involves some more advanced topics – just post your problem to Q&A and if nobody gives a SIMPLE answer – it means that the explanation will have to wait until you will be able to understand the answer based on newly-learned material.
As a result, if you see a GUI problem (like some form of instability) – try to use all learned knowledge and if still no success – post the problem to the Q&A and switch to the key tasks of the current chapter. Thus instead of some complex graphical behavior you can use more simple variations not to fight with what you will learn later but to use your time for learning and using the current material (like logical forks, events, and later loops).
In week 7 such knowledge enhancement of GUI handling (in addition to various event handling methods) is the use of the repaint method in section 8.3.
