Author Archive

Object Oreinted Programming for IOS

26 November 2011 Leave a comment



Michael Khan

Department of Electronic and Computer Engineering

University of Limerick

Limerick, Ireland


With the recent innovations in hardware mobile devices have become increasingly powerful and therefore software options for these mobile devices must also advance. Only a few years ago most mobile phones, mp3 player and other mobile devices had very low processing power, small low-resolution black and white screens and limited sound capabilities. The only software used was a small operating system with very little functionality and almost always coded in Assembly language or C.  With the new modern devices there is a lot more functionality to be explored and with the amount of people who own devices like the iPhone and Android phones a vast market for software for these devices was created. To create software that can use the functionalities of these new devices operating systems like Android and the Apple iOS have incorporated Object Oriented-Programming capabilities for third party developers to create their own applications or “Apps” as the have become so widely known. In this paper I will discuss how Object-Oriented Programming (OOP) is used to develop applications for the iPhone and other iOS devices.


The mobile software market share has over 6% of the overall software market share, which is significant since it was just over 1% in October 2 years ago. Apple’s iOS is the leader in the mobile operating systems with over 54% of the market share. This is why iOS development has become so widespread and why today you can find over 425000 applications on the App Store.

The official concept of objects in programming was introduced in the 1960’s in Simula 67. As the name suggests Simula 67 was a programming language designed for discreet event simulation. Simula 67 introduced the concept of classes, subclasses and instances of objects; the language also used automatic garbage collection. Object-oriented programming became the dominant programming methodology in the early to mid 1990’s when languages supporting the method became readily available, including C++ and Delphi. Its dominance was further increased with the rising popularity of graphical user interfaces (GUI). Mac OS X and iOS have a dynamic GUI library found in the Cocoa framework, which was written in Objective-C.

In mid 2008 with the launch of the iPhone 3G Apple also announced that they would be making releasing a software development kit (SDK) so that 3rd parties could create their own applications and sell them on their new App Store. In this software development kit Apple decided to use the Objective-C programming language for the development of iOS applications. Brad Cox and Tom Love created the Objective-C programming language in the early 1980s. They added on Object-Oriented capabilities from the Smalltalk language and added it on to the C language, C was chosen because it was such a widely used language and familiar to most people. Apple adopted Objective-C when they acquired NeXT in 1996, NeXT was Steve Job’s company that licensed Objective-C and boosted its popularity. Since then Apple has made Objective-C the official language for development on Mac OS X operating system and its derived version for portable devices iOS.

In the rest of this paper I will explain different parts of object-oriented programming and show how they apply to programming in Objective-C for iOS devices.


Inheritance is quite possibly the most Important and recognized of all attributes of object-oriented programming. I like to think of inheritance like this: the easiest way to describe something new is to use something that is already know in your description, for example if I want to describe a baseball it is easier if the person that I am trying to explain it to already knows what a ball is. The same holds true to programming, if you want to define a new of object it is easier it is easier if you can start from the definition of an existing object. Objective-C and other objective-oriented programming languages allow you to base the definition of a new class on the definition of an existing one. The new class then is known as a subclass and the class it derived from is its superclass. In Objective-C a superclass can have multiple subclasses but a subclass can only inherit from one superclass

Figure 1 An Inheritance hierarchy

In iOS programming the NSObject class is the root of most class hierarchy. NSObject objects only inherit a basic interface to the run time and the capacity to behave as an Objective-C object.

In Objective-C inheritance is declared in the header file (.h file) using this syntax:

In this example CalculatorBrain is the subclass and NSObject the superclass, the @interface tag is how classes are defined in the header file.

Inheritance in Objective-C is very similar to Java. You can overwrite methods of the superclass by having the same name on the method in the subclass. One difference is that you need to make the constructor of the superclass return the special type id, which I will talk about later if you want to be able to use it to create objects of its subclasses.


Polymorphism is the ability of different objects to reply, each in its on way to the same message. It originates from the fact that each class has its own namespace meaning that the names allocated inside a class do not clash with names allocated anywhere outside it. This is true for both instance variables and methods in the class.

An example that shows Polymorphism is an Animal class that has 2 subclasses called Dog and Cat. A method talk() is specified on the animal class and it prints the string “An animal does not talk” on the screen. Both Cat Dog classes inherits this method from animal but they do not print the same string they instead prints ”Meow meow” and “Woof woof” respectively because that’s the sound those animal make. Polymorphism is used here so that the Animal, Cat and Dog classes can have a method called talk().

Overloading and Polymorphism refer essentially to the same thing, but from slightly different points of view. Polymorphism points out that a several classes can have a method with the same name. Parameter overloading takes the view that a method can have different effects depending on the parameter that are passed to it. Operator overloading is similar, it allows an operator in the language (like + or ==) to be turned into a method and have completely different functionality depending on the type of object it is applied to. An example is using the ‘+’ operator to add an integer into an array or using the ‘+’ operator to concatenate strings. Operator overloading is common practice in C++ but it is not considered good programming practice by many programmers, as it can be confusing to know what meaning the operator is taking in certain parts of the code. Objective-C supports polymorphism of methods names, but not parameters or operator overloading.

Even without supporting parameter or operator overloading Objective-C is still considered one of the most polymorphic of all compiled languages because of the dynamic nature of its method lookup. Dynamic binding is the biggest difference between Objective-C and other object-oriented programming languages like Java and C++. This is where the type id is very important.

id is a pointer to an object of unknown type.  Both of the above pieces of code mean the same thing at runtime since in iOS programming using Objective-C the decision about what code to run on a message send happens at run time. So in the above example ‘s’ is created as a pointer to an object but the decision of what kind of object ‘s’ will be is not done until runtime. The top piece of code uses static typing which is only different at compile time, in this case the compiler can help the programmer look for problems in the code. An example of how static typing can be helpful is that if you try to send ‘s’ a message that can not be used on NSString object the compiler will warn you at compile time that it can not be done but the decision as to what code will be executed is still done at runtime no matter if you use NSString or id.

To accommodate this dynamic binding Objective-C has a feature called Introspection.  Introspection allows the programmer to send messages to and object to check if it is a certain class or if it responds to a given method. There are 3 introspection methods available in the NSObject class, which is inherited into most classes in iOS development. These methods are: isKindOfClass which returns whether an object is that kind of class or (including inheritance), isMemberOfClass which returns whether an object is that kind of class (without inheritance) and respondsToSelector whether an object responds to a given method. The programmer can use these methods; to check and decide what methods can be used with an object.

In the above code example the programmer first checks that ‘obj’ is of class NSString with the if statement before then casting ‘obj’ to be an NSString object. The Objective-C compiler will not provide warning when casting is used therefore it should only be used with a check like in the above example or when you are absolutely sure that the type the object is being casted is its actual type otherwise the program will crash at runtime with no warning from the compiler.


Encapsulation is another important concept of object-oriented programming. It allows the programmer to select what kind of access they give of the value of variable to the users of their class. Encapsulation is important so that a user can’t set a value to a prohibited value. A trivial example is when performing division, if a user changes the value of an integer ‘d’ to ‘0’ and the integer ‘d’ is then used as the divisor in a calculation you will get an error. This is a simple example of a use of encapsulation but there are many reasons why you would want to protect the value of your variables with encapsulation.

Objective-C uses 3 keywords for encapsulations, they are: @private, @protected and @public. @private means that the instance variable can only be accessed inside its class. @protected means that the variables can be accessed from inside its own class and from its subclasses only. @public means that the variable can be accessed form anywhere. In Objective-C, by default instance variables are set to @protected.

In the above example ‘foo’ and ‘bar’ are both protected access,  ‘foo’ is protected by default, as there is no keyword to specify its access above it in the code. ‘forum’ and ‘apology’ can both be public accessed as all variables declared under the keyword have that type of access. It is recommended to set all instance variables to private to avoid problems when programming.

Because most instance variables are set to private there has to be a mechanism to allow for access to these variables in an other more secure way. For this setter and getter methods are used. Setter and getter methods are used in most programming languages. The big difference in Objective-C is that the compiler can generate the code for the getter and setter methods for you.  The keyword @property declares the getter and setter methods in the header file and the @synthesize keyword synthesizes the setter and getter methods on the ‘.m’ file.

            Header file (.h)

Implementation (.m)

This example shows the use of @property and @synthesize.

The @property and @synthesize can be changed to allow read only access and the setter and the getter can be overwritten to provide extra security to the setter method. An example where you would use this is in the previous example of dividing by zero. You could have the setter method check when the user tries to set the variable that it is not set to ‘0’ so you don’t get an error.


This paper presented many of the object-oriented aspects used for programming in iOS. These aspects include Inheritance, Polymorphism and Encapsulation. Inheritance is the ability of starting a class from the description of an other. Polymorphism is the ability of methods in different classes to have the same name and different implementations. Encapsulation is the ability to stop the user from changing the value of variables that could be set out of its range.

Finally I should note that there is a new iOS coming out in the next month, iOS 5 there are some new features added to but the object-oriented programming aspects of it should remain the same.


  1. Market share for mobile, browsers, operating systems and search engines | NetMarketShare. 2011. Market share for mobile, browsers, operating systems and search engines | NetMarketShare. [ONLINE] Available at: [Accessed 12 October 2011].
  2. Apple – iPhone 4S – See apps and games from the App Store.. 2011. Apple – iPhone 4S – See apps and games from the App Store.. [ONLINE] Available at: [Accessed 12 October 2011].
  3. Objective-C 2.0 Essentials – Techotopia. 2011. Objective-C 2.0 Essentials – Techotopia. [ONLINE] Available at: [Accessed 12 October 2011].
  4. Downloads (2010-2011 Fall) | CS 193P iPhone Application Development. 2011. Downloads (2010-2011 Fall) | CS 193P iPhone Application Development. [ONLINE] Available at: [Accessed 12 October 2011].
  5. Apple Developer. 2011. Apple Developer. [ONLINE] Available at: [Accessed 12 October 2011].
Categories: Uncategorized

Line Drawing Method – Bribery

29 November 2009 Leave a comment

The engineering profession is a very important one to the development of society in present times. When people think of Engineers they automatically think of problem solvers with great technical knowledge. For engineers to be effective they must have confidence in them not only their own but also other people’s. For this confidence to exist an engineer should keep him self out of cases where there is a conflict of interest. Getting involved in situations where there are conflicts of interest can undermine the confidence in the engineer. The code of ethics mentions: 1.1 …behave with integrity and objectivity and 1.7 …with impartiality, uninfluenced by any personal considerations . These parts of the code of conduct are places where you would use the line drawing method. The line drawing method is a way for engineers and other professionals to stay out of cases where there is a conflict of interest and therefore keep confidence in them.


The line drawing method involves a few short steps and it is very simple to use. The first step is to look at a paradigm case of your problem and a paradigm case of when the problem does not occur. A paradigm case is one that serves as a model of the problem you are trying to solve. When coming up with the paradigm case a person should think of the worst possible case of the problem they are trying to solve and a case where this problem does not occur and come up with relevant features to judge the problem. The next step is to draw a table with the paradigm case of the problem on one side and the paradigm case where this problem does not occur on the other side under the relevant features you chose leaving a space in the middle like in the fig1. The next step is then to decide where in between the two cases your case is and mark that on the table for each the features of the problem. The next and last step is to draw a line where you marked each of the features of the problem and finally to make a decision.  The decision making part is still the most important one.


In this paragraph I am going to use the case study we were given for our presentation to further explain the line drawing method. In the case study I was given, the problem was to identify if something was a bribe or not. The problem states:

John is employed at Bluestone Ltd. as the senior engineer. He regularly meets with vendors who offer to supply Bluestone with their ongoing needed services and parts.  John discovers that one of the vendors, Peter, is an avid golfer like himself. They begin comparing notes on their favourite golf courses. John says that he has always wanted to play at the Cherryvale Golf Resort but has never had the opportunity because it is a private club. Peter says that his company have a corporate membership there for years and he can arrange a guest visit for John for that weekend, “I can easily organise for us to have a game on the company, we’ll even get a steak and few pints afterwards out of it”.  Should John accept this offer?

The problem for John is that he is offered to play a game of golf and because his company is buying from the company that is supplying him with this opportunity it could cause a conflict of interest for John. The line drawing method can be used in this case for John to make his decision. The first step is to come up with the paradigm case of bribery and the paradigm case of not bribery and the features of bribery. The next step is to draw the table and then the line and finally make the decision. The table we drew as part of this problem is shown in fig1.

drawing the line                                                                                             fig1

The gift size in our problem was quite small so the slider is close to the not bribery paradigm. The timing in this problem is after the decision, Johns company already is already supplied by the company making the offer. The reason for him to accept the gift is personal only. The responsibility for the decision regarding this company supplying John’s company is not solely Johns and when they were to renew the contract John would not be able to make this decision on his own. The product quality and product cost are irrelevant min this case as Johns company is already buying these products.


When drawing the line in this case study you find that the line is closer to the paradigm not bribery thus we advised John that it would be ok to take the gift but he must be careful if the company wants to change suppliers or they want to redo the contract John should act impartially to avoid conflict of interest. The line drawing method is an effective one when making these kinds of decisions. It is important though that you are honest when positioning the sliders between the two paradigm cases as if you are not honest this method could give you any answer you want and that is not the point of this method. 

Categories: Uncategorized

Use of human corpses in crash tests

22 November 2009 Leave a comment

Crash tests now a days are not conducted solely with crash test dummies. For some crash tests full human cadavers or parts of human cadavers are used. The use of cadavers for crash tests is a controversial topic all over the world. When people donate their bodies to science the do not know where their body will end up. Bodies donated to science are used for many different purposes for example bodies are used in the training of doctors, training of forensic investigators and crash tests. This fact left people who’s relatives donated their bodies to science in distress as their bodies could have been used in crash testing.

There are many arguments for the use of human cadavers in crash tests. The main argument for it is utilitarianism. Utilitarianism is the idea that the moral worth of an action is determined only by its contribution to utility. Meaning that if an action is going to help society it should be judged as that. Looking at the utilitarianism point of view it is right to use human cadavers for crash test as the action of using these cadavers benefits society in the way that because of the use of the cadavers more realistic dummies can be made and cars will become safer. It is said that with every cadaver used in crash tests up to 60 lives are saved. Looking at these figures it looks fair to use a cadaver to save up to 60 lives. An other argument to use cadavers is that crash test dummies are not developed enough at present time to be sure using them in crucial tests. New more realistic crash test dummies can be created by using the research conducted with cadavers by making them more like human bodies and placing sensors in the right areas. Once more efficient dummies are created less and less human cadavers will be used in crash tests.

There are also many arguments against using human cadavers for crash tests. The main argument against it is respect for the dead. Respect for dead is the belief that even after people are dead they should still be respected. Even though the person is no longer alive they legacy of their lives and their families should be respected. This means that the bodies of the deceased should be treated with respect and not be placed in cars for crash testing. This is a major problem for families of people who donate their bodies to science. These families want to know that the body of their loved ones is being respected. The families of people who donated their bodies to science had been distressed when they discovered that bodies donated to science could be used in crash tests. The use of these bodies in crash tests is not clearly shown in the consent form. An other argument against the use of human cadavers in crash testing is that there is a better use for those cadavers. Most bodies that are donated to science are used in the training of doctor, surgeons and forensic investigators. Some people believe that with the limited amount of bodies available the training of doctors and surgeons is more important than the use of cadavers in crash tests. These people believe that the cadavers that are being used in crash tests could be substituted by crash test dummies and there for there would be more bodies available for the training of doctors and surgeons.

In conclusion it is the use of cadavers to help training doctors and surgeons and in crash tests is important as it can save lives of people with the training and research they provide. If I were to produce a solution that would seek to please both side in this argument I would choose to keep using human cadavers in crash testing but to give a bigger percentage of the available cadavers to medical training and research and I would also put into the consent form that bodies donated to science may be used in crash tests.  

Categories: Uncategorized

The concept of responsibility in engineering as interpreted through the Challenger disaster

27 October 2009 Leave a comment

The engineering profession is a very important one to the development of society in present times. When people think of Engineers they automatically think of problem solvers with great technical knowledge. But that is not all engineering is about. The modern day engineer must have the welfare of the society as their top priority. Engineers should always make sure that all products they produce are safe to be used by anyone and wont harm people as well as not harm the environment. These responsibilities are outlined in the Charted engineering regulations and the Engineers Ireland Code of Ethics. These Ethics are not just written documents, they are also personal Ethics and the law. Each person has their own ethics and beliefs and these carry over to their professional lives. The law is the highest part of the ethics of engineers as it has to be obeyed. A lot of the times these three sources of Engineering Ethics overlap in certain aspects.


In this entry I am going to use the Challenger Disaster to demonstrate the importance of responsibility in the engineering profession and the responsibilities of the engineer. On the 22nd of January 1986 NASA was supposed to launch the Challenger, due to delays on their previous mission the launch was postponed. On the 25th the launch was again postponed due to weather conditions. On the 27th the launch was a again postponed due to weather conditions and due to problems with the exterior access hatch. NASA started getting inpatient with these continuous postponements. The morning of the 28th was an unusually cold morning. On the evening of the 27th managers and engineers from the company that had produced the SRB’s and NASA discussed the weather conditions and how it may cause problems to the O-rings that are necessary for the SRB’s to work and thus for the Challenger to work. Managers and engineers from Morton Thiokol said that they didn’t have enough evidence that the O-Rings would hold up at the forecasted temperatures. NASA said that because there were back up O-Rings in place they would be ok if the first ones failed, this was never proven or even tested. Engineers from Rockwell International, the prime contractor for the shuttle also expressed concerns over the temperature. Because of possible financial burdens to both companies their engineers were over ruled by higher management and they both gave the go ahead for the launch on the 28th at unproven conditions. On the 28th of January 1986 at 11:38 eastern time the Challenger was launched after being cleared of ice that morning. 73 seconds after the launch the shuttle started to disintegrate. The two SRB’s didn’t disintegrate and were detonated as they may have been a treat to land. The crew cabin also withstood the disintegration but none of the crew survived dyeing from either loss of pressure in the cabin or from the impact of the cabin with the water which was close to 20G.


The Challenger disaster is a great example of the responsibilities of the engineer. Engineers are given privileges and they have responsibilities due to those privileges. In the Challenger launch engineers had crucial decisions to make. Those decisions should have been made according to the engineering ethics and taking their responsibilities to the community into account.


On the evening  of the 27th and the morning of the 28th of January 1986 Engineers and management of all 3 companies involved in this launch made decisions that cost us more than just money, the lives of 7 people. Engineers form Morton Thiokol made their feelings known about the performance of the O-Rings in the kind of weather that was expected for the launch. The Morton Thiokol engineers felt that there was not enough evidence that the O-Rings would work at the kind of temperatures expected thus the engineers recommended that the launch did not go ahead.Engineers form Rockwell International also expressed their concerns with the lack of data to assure them that the O-Rings would function properly. They also had concerns over the amount of ice that had built up around the shuttle. Engineers from Rockwell also recommended that the launch did not take place at the conditions but again were over ruled by higher management. The decisions By higher management in both companies were purely financial decisions. Both companies were afraid of financial burdens from NASA if they weren’t given the go ahead for the launch. NASA engineers and management were also aware of the condition of with the O-Rings. they also had a decision to make knowing that the O-Rings could have failed because of the temperature at launch. The NASA engineers decided that because there were backup O-rings. This should have never been the case since the O-Rings were criticality 1 components and according to NASA regulations “it is forbidden to rely on a backup for a Criticality 1 component ”. NASA’s rezoning for the decision unlike the other two companies was not completely financial,  it had more to do with the impatience as they had delayed the launch a few times already and this was damaging the image of the company.


No matter what the reason the companies used to decide to ignore their engineers and statistics they had on the O-Ring’s performance it was not an ethical decision and it  the people who made the decision ignored their responsibilities to the society. The Institution of Engineers of Ireland’s Code of Ethics states:

“At all times in their relations with the public, Members shall apply their
skill and experience to the common good and the advancement of human
welfare with proper regard for the safety, health and welfare of the public.
A Member shall not engage in any activity which he/she knows or has
reasonable grounds for believing is likely to result in a serious detriment
to any person or persons” 

In this situation engineers and managers of all three companies ignored the code of ethics as they didn’t place the safety and welfare of society and especially the 7 people that were in the shuttle ahead of their own needs and wants. The unethical decision made by those few people cost us the lives of 7 people.      

Categories: Uncategorized

Team Work Reflection

11 October 2009 3 comments

When we were first told that we were going on a field trip for this module I thought we would be going to a boring factory where we would listen to a load of people talking. So the field trip to the Killaloe Activities Centre was a pleasant  surprise. This fieldtrip was to teach us all about teams and working in teams. Team work was a topic I thought I knew a good bit about from sports I take part in and from working in teams on projects in school. When we got to the ULAC we were split into two groups in which we would do all the activities. In the group there were people I knew better than others. For the group to work well we would all have to work together.


individual (what do I know about myself as a team member)

Before this field trip I already knew a bit about my team working skills. I am usually good at working in groups and usually prefer working in groups them on my own. I believe that its easier to divide the workload. I knew that when working in teams it is good to divide the work load according to people’s preferences and to the special skills they may have. I also knew that for the group to work well there always needs to be a person in charge so that all others do their work like a manager or supervisor. Interpersonal skills are also essential to the success of a team.      

contextual (what is important about working in teams for an engineer)

Working in teams is a huge part of Engineering. Most projects undertaken in modern day Engineering jobs are done in groups. Working in group is more efficient as each person has their own area of expertise and mistakes can be identified easier. People working in groups  have extra motivation to work hard so that they don’t let down the other members of the group. To work in teams certain specific skills are necessary. Managerial Skills and Interpersonal skills are needed to make the work go smoothly and efficiently without major conflicts and dead lock. When conflicts and deadlocks occurs members of the group need to have the skills to deal with them and be able to move on quickly.     

relational (how good are others, what feedback have I had)

We got a lot of feedback throughout this project on the day at the activities centre and during the process of making the presentation. In almost every challenge we did at the activities centre we got feedback from the other group members on how we could improve our problem solving method and ways to tackle the problems we are going to come up against. Most people had good input into the group and thus contributed to the team. I learned a lot more about working in teams then from the fieldtrip and even more from making the presentation. I learned a lot about the skills needed to make a group to work smoothly. We as a group decided that it would be better if one person tried to take charge of each task so that we could split the workload and give people tasks that suited their skills.

developmental (what things do I need to focus on to improve myself as a team member)

Even though I learned a lot about team work from this exercise I also found that there are many places where I could improve as a member of a team. I too part in team activities a lot but this one made me realise that I could improve my communications so as to facilitate communication in the group. I also thought I could pay more attention to other people’s ideas so that when it came to my part of the task I would be able to use their ideas to help me.

Categories: Uncategorized

Reflection on presentation

22 September 2009 Leave a comment

As I look back on my presentation and the preparation that when into it I am amazed by the amount I’ve leaned from this one small exercise. This was my first proper presentation in a long time therefore I didn’t have much practice presenting in the last few years and had to do a lot of work preparing for it. Although there was a lot of work in preparing for this exercise, improvements can always be made.

Before I started this exercise I really didn’t know the amount of work that would go into a presentation. I thought I could put together a presentation in 20 minutes and look over it once and be ready to present it. I now know that this isn’t realistic if you want to make a good presentation. My slide show alone took nearly an hour to decide what was going to go into it and make it. I then had to look over it and look into things I was going to say during each slide as the slides contained only small bullet points that needed to be further explained. Usually a lot more time would have to go into researching the topic of the presentation as I was very familiar with the topic and only had to research some small parts concerning the history of the sport and a how big the NFL is in the world.

In the rest of this reflection I am going to write reflecting on different parts of my presentation and how I could have done it better and improve it for the next time.

I definitely found that to make a presentation on a topic the presenter must have an interest and a great knowledge of the topic. I didn’t think this was a problem with my presentation as we were allowed to make the presentation on any topic we wished so I could pick a topic I was very interested and had a good knowledge of. For future presentations I believe more research must go into the topic if I am not so familiar with it.

I also found that if visual aid is going to be used for the presentation, like a power point presentation a lot of work has to go into developing and making sure that the visual aid isn’t the whole presentation and that you have other notes to help with it. It is also important that if visual aid is going to be used you make sure that it will work at the time of the presentation. I didn’t think this was a big problem with my presentation as I tried to have more things to say than just what was on the slides and after witnessing a power point presentation that didn’t work on the computer I made sure to test mine before the presentation to make sure that everything was working fine.

I found that structure of the presentation is very important so that the audience can follow it and understand the presentation. I had a problem with this in my presentation. My presentation was poorly structured and therefore hard to follow.  For future presentations I will try to pick a structure that will suit my topic.

Finding what information is relevant to a presentation is key so that you make sure that you present all important parts of the topic and don’t make it tedious for the addressees. I had a small problem with this in my presentation. I expanded too much into the structures of the NFL and left out key information about the rules and pitch markings and sizes. For future presentations I will try to make the information in the presentation more relevant to the audience.

Nervousness is a major problem for many people during public speaking. I was a bit nervous during my presentation and I thought that it may have resulted in me leaving out parts of what I was going to say. I think that nervousness is a problem that can only be solved with experience and every presentation I believe that I will get better at dealing with it.

The delivery of the presentation is crucial for its success.  The delivery of my presentation could have been better.  My voice could have been louder and more variant. I think the solution to this problem is to practice more when getting ready for the presentation.

I would like to thank my fellow classmates and lecturer for the feedback I was given for this presentation which helped me write this reflection and improve my presenting skills.

Categories: Uncategorized

American Football Presentation

16 September 2009 4 comments

Please leave comments on my presentation.

Here is a link to the video on my presentation and also a link a Video of Super Bowl ads.

Categories: Uncategorized