How not to be a commuting student

As a commuter, every day is a long hard struggle.

Especially when your bus is late or even worse you miss the bus by a couple of minutes, resulting in your being late by an additional 10 to 20 minutes. Your life is not the easy one, where you can roll out of bed 10 mins before a lecture and still be there on time.

You don't have to care about the road conditions, other road users or even number of stops. You just care about how long it takes to get from A to B.. and how possibly late that's going to make you.

The sense of a lack of control is infuriating when you know you can do nothing but sit around and wait..but the key here is to keep fighting. Buses exist to make your life a wait-filled misery but yet you strive harder, to be smarter and nail that timetable and it's daily fluctuations to a T.

I've also decided to make best use of my bus time by blogging in between naps, so expect more from me soon!

Hello again, world.

I'd like to start by saying Don't Panic. At this point, the world may well be your oyster or you may have some catching up to do. In any case don't panic is as sound advice as any, not my words but those of Douglas Adams.

I of course refer to the exam day results you may have just experienced, whether they were good or not is not of precedence. 'Do you know where you're going in life?' is a more valid question. I leave the answer to your discretion but I do offer a little of my own advice..

Define your goals early and set your bar high, because that's the only way you'll come close to achieving them.

My intention is to update this blog on a weekly basis, so please stay tuned for further postings :)

Beta Testing: Round Two

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.

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!

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.

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;

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.

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.