Friday's testing session was just as successful as Thursdays. I was slightly more nervous giving the presentation this time around. I'm not sure why but I got the job done.
There were many more suggestions and criticisms this time around, one of my favourites being to have information about the current card located within the data view.
A significant bug I spotted was when one tester completed a game and immediately started a new one resulting in a crash. This bug was replicated with the aid of Mr Rainey. This is most likely due to the gamemanager being initiated at program launch, released after the game is finished and not initialised on a new game starting.
Saturday 20 March 2010
Thursday 18 March 2010
Beta Testing: Round One
Beta tested my application in Computing Club. There were several things I learnt at the session and a few bugs I picked up on.
At the beginning of the session with the presentation, I did not explain adequately what I was intending to do about the 'Resume' function to the testers. I will make sure to explain this clearly tomorrow.
A few users complained the picture of the Ferrari Enzo was wrong, this has been corrected.
For most users there is a crash at the end of the game instead of the Win/Lose message, this is yet to be resolved but will be done soon.
On the Mac Mini (and possibly Mr Smith's laptop if he brings it in), the resume game function does not work as the file is not written properly, need to explore this issue.
A lot of users complained the game was too long and that it was not possible to see which card the opponent had. This is a flaw that has carried over from the original multiplayer specification. It was my intention to have a suitably lengthly game that exploits the advantages of multiple person play. The other person aspect also helps in determining which card you lost against as it is visible on the opponent's device. I am not sure what I can do about these issues, will talk to Mr Smith.
Update: Another problem I picked up on was displaying the text in the documentation view (before the web pages are loaded). It's actually editable which I don't want, have fixed this.
Update 2: Crashing was due to memory leak (again!) was releasing cardPointers after dividing the deck and then releasing again when releasing everything. Everything is AOK for tomorrow now!
At the beginning of the session with the presentation, I did not explain adequately what I was intending to do about the 'Resume' function to the testers. I will make sure to explain this clearly tomorrow.
A few users complained the picture of the Ferrari Enzo was wrong, this has been corrected.
For most users there is a crash at the end of the game instead of the Win/Lose message, this is yet to be resolved but will be done soon.
On the Mac Mini (and possibly Mr Smith's laptop if he brings it in), the resume game function does not work as the file is not written properly, need to explore this issue.
A lot of users complained the game was too long and that it was not possible to see which card the opponent had. This is a flaw that has carried over from the original multiplayer specification. It was my intention to have a suitably lengthly game that exploits the advantages of multiple person play. The other person aspect also helps in determining which card you lost against as it is visible on the opponent's device. I am not sure what I can do about these issues, will talk to Mr Smith.
Update: Another problem I picked up on was displaying the text in the documentation view (before the web pages are loaded). It's actually editable which I don't want, have fixed this.
Update 2: Crashing was due to memory leak (again!) was releasing cardPointers after dividing the deck and then releasing again when releasing everything. Everything is AOK for tomorrow now!
Tuesday 16 March 2010
Memory Management is powerful
One wrong release can send your entire app to the graveyard. I'll explain why;
In a lot of areas of my program I invoke the use of class methods. Class methods are different from instance methods in that they are not applied to an instance of a class but to the class itself.
If you invoke class methods on your own custom classes, an instance of the class is required. However this is not the case with Foundation classes, don't ask me why.
Now when a Foundation class method is called you do NOT release that class afterwards, doing so will result in a crash of epic proportions.
I have now learnt this lesson for the umpteenth time and have implemented the save and load features successfully.
While testing the application, a local copy needs to be maintained on the test machine to ensure file creation functions correctly. I will need to load local versions of the project on beta testing machines.
In a lot of areas of my program I invoke the use of class methods. Class methods are different from instance methods in that they are not applied to an instance of a class but to the class itself.
If you invoke class methods on your own custom classes, an instance of the class is required. However this is not the case with Foundation classes, don't ask me why.
Now when a Foundation class method is called you do NOT release that class afterwards, doing so will result in a crash of epic proportions.
I have now learnt this lesson for the umpteenth time and have implemented the save and load features successfully.
While testing the application, a local copy needs to be maintained on the test machine to ensure file creation functions correctly. I will need to load local versions of the project on beta testing machines.
Sunday 14 March 2010
iDevice says: Zzzzzzz
Today I came across a piece of powerful code that will be very relevant to my project but that I did not take into consideration;
What this bit of code does is stop the screen of the device from disappearing during the game. As the user will be concentrating hard during the game, obviously, there may not be a user interaction for a period of time and the screen will power down. This code prevents this interruption from occurring.
I came across this code while trying to implement GameKit into the project. What I discovered that understanding and utilising the intricacies of GameKit is a whole project to its self and not something that can be implemented and tested within two weeks.
Therefore I am now thinking that I'll have to abandon this feature of the project for now. However I will discuss it with Mr Smith first.
application.idleTimerDisabled = YES;
What this bit of code does is stop the screen of the device from disappearing during the game. As the user will be concentrating hard during the game, obviously, there may not be a user interaction for a period of time and the screen will power down. This code prevents this interruption from occurring.
I came across this code while trying to implement GameKit into the project. What I discovered that understanding and utilising the intricacies of GameKit is a whole project to its self and not something that can be implemented and tested within two weeks.
Therefore I am now thinking that I'll have to abandon this feature of the project for now. However I will discuss it with Mr Smith first.
Saturday 13 March 2010
Implementation - "Finished"
Yesterday I made significant progress in the project, implementing features like;
Correcting player queues. Once I realised NSMutableArray works like a normal queue this was simple to resolve.
Including winner and loser handling:
- returns user to menu after game
- plays sound to indicate win or loss
- displays notification to the user
Removing the setup screen. This was done to simplify the UI. The deck is now automatically shuffled.
A Documentation browser that displays helpful web pages. It uses UIbuttons to switch between pages rather than a UITabBar.
Features I still wantto implement include;
Saving and Resuming a single player game.
Getting a multiplayer game working. This will be more difficult to test. It cannot be done without deploying to device.
Beta Testing will take place on device so I'd also like multiplayer to be tested.
Correcting player queues. Once I realised NSMutableArray works like a normal queue this was simple to resolve.
Including winner and loser handling:
- returns user to menu after game
- plays sound to indicate win or loss
- displays notification to the user
Removing the setup screen. This was done to simplify the UI. The deck is now automatically shuffled.
A Documentation browser that displays helpful web pages. It uses UIbuttons to switch between pages rather than a UITabBar.
Features I still wantto implement include;
Saving and Resuming a single player game.
Getting a multiplayer game working. This will be more difficult to test. It cannot be done without deploying to device.
Beta Testing will take place on device so I'd also like multiplayer to be tested.
Friday 12 March 2010
Card Images - corrected
I have properly assigned the correct pictures to their respective cards. I did this by checking the order the cards were in compared with the order the pictures were in. This proved to be an entertaining exercise considering my lack of car knowledge. However I eventually managed to correct this irritating issue.
Currently I am working on the crash problem that occurs during gameplay. I have made progress in that the app crashes significantly longer into the game than it did so before. However I believe this is because a different issue entirely. I am now in the process of diagnosing why exactly the crash occurs. It appears to be due to a random element as I cannot pinpoint if it occurs after obtaining, or losing, a specific number of cards.
Currently I am working on the crash problem that occurs during gameplay. I have made progress in that the app crashes significantly longer into the game than it did so before. However I believe this is because a different issue entirely. I am now in the process of diagnosing why exactly the crash occurs. It appears to be due to a random element as I cannot pinpoint if it occurs after obtaining, or losing, a specific number of cards.
Wednesday 10 March 2010
User & Tech Guide - iPhone web pages
I have just finished implementing the User and Technical Guide pages as iPhone compatible web pages into my native application.
I essentially did this by coding the raw html for these two pages, substituting the required text into the respective html files. I added meta data so that the text would be displayed at 480 pixels wide (the iPhone resolution).
I then created a separate style sheet to style the different elements of the page. Namely the 'div' tag, adding a nice rounded rectangle effect, and the 'p' tag to style the text as Helvetica and of 18px, to give a more iPhone feel.
Testing that these files worked as expected in the simulator I then wanted them to load natively within the application. I added them into the Xcode project where they appeared under Resources. I then looked up the corresponding view controller for the views I wanted to display the web pages into.
Using this approach the web pages successfully rendered. However they couldn't be styled by the separate style sheet due to addressing issues. I therefore had to include the stylings in both web pages locally.
I essentially did this by coding the raw html for these two pages, substituting the required text into the respective html files. I added meta data so that the text would be displayed at 480 pixels wide (the iPhone resolution).
I then created a separate style sheet to style the different elements of the page. Namely the 'div' tag, adding a nice rounded rectangle effect, and the 'p' tag to style the text as Helvetica and of 18px, to give a more iPhone feel.
Testing that these files worked as expected in the simulator I then wanted them to load natively within the application. I added them into the Xcode project where they appeared under Resources. I then looked up the corresponding view controller for the views I wanted to display the web pages into.
Using this approach the web pages successfully rendered. However they couldn't be styled by the separate style sheet due to addressing issues. I therefore had to include the stylings in both web pages locally.
Monday 8 March 2010
Implementation
Progressed significantly in the implementation today. The cards and deck now initiate correctly.
Stumbled across a brilliant website called http://www.iphoneexamples.com/ which has some great algorithms which I am tempted to implement.
Priorities:
High:
Get the game working by modifying the IBOutlets for selfTurn which return int values. I think I can implement this a different way.
Medium:
Get the picture of the cards to show up
Low:
Test the activity notifier
Currently the game part of the program is completely broken and non-operational. Need to find some way of correcting a lot of flawed logic (maybe remove the disputed cards concept).
Stumbled across a brilliant website called http://www.iphoneexamples.com/ which has some great algorithms which I am tempted to implement.
Priorities:
High:
Get the game working by modifying the IBOutlets for selfTurn which return int values. I think I can implement this a different way.
Medium:
Get the picture of the cards to show up
Low:
Test the activity notifier
Currently the game part of the program is completely broken and non-operational. Need to find some way of correcting a lot of flawed logic (maybe remove the disputed cards concept).
Friday 5 March 2010
Implementation extended
The implementation stage of my project has officially been extended. The reason for this decision was due to the huge amount of runtime errors that were occurring.
I have spent the last week trying to resolve these issues. By consulting the Cocoa Memory Management guide for iPhone I have been able to resolve a lot of these issues.
One of these problems was the use of convenience methods in the init methods of my custom classes.
However, while resolving these issues I have spotted further potential problems in more code which now needs resolving.
All in all, I have made significant progress but there is still more debugging and a little coding to be done.
I have spent the last week trying to resolve these issues. By consulting the Cocoa Memory Management guide for iPhone I have been able to resolve a lot of these issues.
One of these problems was the use of convenience methods in the init methods of my custom classes.
However, while resolving these issues I have spotted further potential problems in more code which now needs resolving.
All in all, I have made significant progress but there is still more debugging and a little coding to be done.
Wednesday 17 February 2010
Implementation - completed
All errors have now been resolved and coding is completed. However, I am unable to commence testing until an oddity in the application presenting a white screen on startup, and nothing more, is resolved.
There are a few features that have been looked over in this implementation of the project. This includes the gamekit multiplayer aspect of the game which I feel I can't include until the code implemented so far is seen to be meeting specifications.
Further documents are in the process of being updated for the draft deadline tomorrow which include; the project plan - which needs to be updated with the latest entries, the test plan - which is not complete but need to be updated to include a user feedback form, and the project document which needs to be reviewed before submission.
There are a few features that have been looked over in this implementation of the project. This includes the gamekit multiplayer aspect of the game which I feel I can't include until the code implemented so far is seen to be meeting specifications.
Further documents are in the process of being updated for the draft deadline tomorrow which include; the project plan - which needs to be updated with the latest entries, the test plan - which is not complete but need to be updated to include a user feedback form, and the project document which needs to be reviewed before submission.
Friday 15 January 2010
Implementation - progress
Made significant progress by getting the file reading operations to work!
The process within Xcode and Objective-C 2.0 is to incorporate the files to be read from into the project within Xcode, usually within the 'Resources' folder. You then assign a string with the full path of the file to be read by applying a method onto the project's bundle object. It is then possible to read from the file.
A few problems associated with file reading and data management remain. Such as, assigning attribute names to an array of string objects and arranging the card objects into a 'random' order.
Next on the agenda is performing research into the implementation of the GameKit framework and then implementing the multiplayer aspect into the game.
The process within Xcode and Objective-C 2.0 is to incorporate the files to be read from into the project within Xcode, usually within the 'Resources' folder. You then assign a string with the full path of the file to be read by applying a method onto the project's bundle object. It is then possible to read from the file.
A few problems associated with file reading and data management remain. Such as, assigning attribute names to an array of string objects and arranging the card objects into a 'random' order.
Next on the agenda is performing research into the implementation of the GameKit framework and then implementing the multiplayer aspect into the game.
Friday 8 January 2010
Implementation - progress
After coming back from the winter break I have cleared all occurring errors from the implementation. Some errors were caused by incorporating cyclic links within different class files which I therefore decided was not necessary for the implementation nor required by the specification. Further errors included improper definition of an array.
With these errors resolved I am ready to move onto incorporating the file reading capabilities of the program in order to read in data corresponding to each individual card.
With these errors resolved I am ready to move onto incorporating the file reading capabilities of the program in order to read in data corresponding to each individual card.
Subscribe to:
Posts (Atom)