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.

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.

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.

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).

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.

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.

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.

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.

Test Plan - progress

I have completed the logical testing aspect of the Test Plan. I have created test data to test the main comparison method that calculates and decides which card wins the round. I have also detailed expected outputs for Round and Game events.

I have not detailed a plan for testing the acceptance side of the testing as of yet. But this is currently the next item on the agenda. This will detail exactly what the acceptance testing will achieve and what is required to perform the testing. The plan will also include a rough draft of the user questionnaire that will be completed after testing to provide feedback for the project.

Test Plan - started

Today I worked on the Test Plan in school, mainly due to not being able to bring a working copy of my project in. While working to resolve this issue, I have decided to complete a test plan foremost.

The test plan has made me think about how specific data will be accessed by each device and as a result, updating my pseudocode portion via an iterative process.

Implementation - started

I have started churning out code for the implementation side of the project. My approach is to start outlining the interface including links and view transitions primarily, then flesh it out with more fundamental code.

So far when trying to compile, the usual errors are produced which I am in the process of working out. Hopefully the process will go according to schedule dispute early signs of error.

Design - completed

At long last the Design work has come together and can now be considered complete. It was difficult finding an ending point for this part of the development process as more and more components of the program needed to be documented in pseudocode. I believe the Design work I have completed will be sufficient to write the program and if parts are lacking they can be updated in an iterative manner.

Design - started & progress

I have started working on the main Design of my project. I have decided to detail the design of the project using pseudocode. I have chosen this method due to the nature of the application in being event-driven based. Pseudocode allows for various routines to be written for each event seperately and for subroutines to be seperately detailed from the main routine which fits the nature of the project.

I am currently designing the main game functionality and the use of the 'Resume Game' function. I have realised for it to be possible to resume a stranded game, the host and client devices must have a local instance of the data being shared between them.

User Interface Design - completed

The UI Design is finally completed after much delay.

The reasons for the delay are numerous but mostly down to using Interface Builder in designing only the UI and not in the implementation of the project. This resulted in specific elements not responding to cosmetic changes within Interface Builder and therefore not suitable for UI Design.

I then had to mockup my design which meant further delay to having to find similar elements in mockup form similar to those within Interface Builder.

During the mockup design I had a thought of where to display the configurable parts of the application which I primarily had within the application itself but which I thought would be more suitably located within Apple's own 'Settings' application on the iPhone device as there are very few preferences that can be changed by the end-user.

Due to the change in the location of the Options screen there was also limited use in including a tab bar at the bottom of the three Options, Help and About screens to navigate to each of those pages easily. Therefore the mockup designs for the remaining two pages needed to be altered to reflect this design update.

These changes and the additional time to annotate the new design contributed to the delay of the User Interface Design.