Guidelines for Android Oral Pres

Guidelines for Android Oral Presentation and Written Reports

Overview

These guidelines assume you will present some Android feature, library class, or other aspect of the Android Application development. Your presentation should explain a topic (usually with short code example(s)). Do not use terms that have not been used in class without explaining them first. Be sure that you explain the benefit of the feature you are talking about - that is, what features, functions, capabilities, etc. that it will provide to a Android programs.

The basic rationale is this: pretend you are working for a company with a new project and it has been suggested that the feature/technology that you will explain should be used in this project. The other members of your team don't know anything about this new thing, and you have been assigned to find out about it and give them a summary so they can better decide if it should be used or not. You assume they know the basics of Android programming - for example, as much as we have covered in the course through week 11, and you want to tell them the basics of this new feature/technology - including what it is good for, how complex it is, what is needed to get it to work (extra software or databases, or hardware...) and a good introduction to what it looks like at the code level.

If you include code, present a minimal code example - a sort of "hello, world" example for this feature. You may omit lengthy obvious details like layouts and event handling, etc. Do not spend time in your presentation explaining things that your audience already knows. Bold-facing and numbering important lines of code will help your audience find the specific statements you will discuss.

Your presentation should take about 20 minutes. Arrange with your instructor ahead of time if you are going to do any live code demonstrations for the class.

For presenters, prepare a 1 to 6 page handout summarizing your talk for the class, including your code examples. Make sure there are enough to go around. You could include longer code examples for study.

Note clearly: your job is NOT to impress me with how much you know and how many buzzwords you can use. Your job IS to impress me with how well you can explain (ie. teach) new material to me and your classmates. This is for them as much as it is for you.

Guidelines for a Typical Written Report

If you are asked to submit a report, the report should be at least 6 pages long in font size 12. The report should be in your own words. If English is not your native language, do your best. You will not lose credit for grammatical errors.

You need to organize the report into sections typically as follows:

Introduction -- Explain definitions and basic concepts involved.
Background -- Give brief history of the technology.
Methodology -- This is the section where you give the details.
Code Examples -- Give concise and easy to understand code examples when applicable.
References -- Note that you should not just give a list references or websites at the end of the paper, instead, you must include citations in the body of the text (i.e. the previous sections) whenever any direct quotation more than half a sentence long is used in your report. In the section of "Citations" below, some examples are given when you include citations directly in the text. Alternatively, you can also number your References, and cite them besides the location in the text using symbols such as [1] or [2].

Citations (applicable to both the handout and the written report)

Important:

At the end of the handout, cite the references you have consulted to prepare the talk (books, magazine articles, Web URLs, etc.). You should consult and cite at least three different sources.

In addition, let me repeat that this presentation and the handout should be in your own words. If English is not your native language, do your best. You will not lose credit for grammatical errors.

You may quote from other sources, but any direct quotation more than half a sentence long must be cited at the point in your document where the quotation occurs. If the quotation is more than a sentence, it should be indented. (we should be able to see clearly who wrote it, in what article or book or Web site, page number, if any, etc.). Examples:

1. A single sentence in your own narrative:

Java is fast becoming a mainstream language. For example, E.R. Harold notes in his Web site "The College Board, the monopoly that brings you the SAT and the Advanced Placement Tests, has announced that starting in 2003 the AP Computer Science test will include object orientation (about 10 years late); furthermore, the language will change from the current C++ to Java." (http://www.ibiblio.org/javafaq/)

2. A paragraph:

These naming issues may appear superficial at first -- "cosmetic", as programmers sometimes say. But do not forget that one of our eventual aims is to provide the basis for powerful, professional libraries of reusable software components. Such libraries will contain tens of thousands of available operations. Without a systematic and clear nomenclature, both the developers and the users of these libraries would quickly be swamped in a flood of specific and incompatible names, providing a strong (and unjustifiable) obstacle to large-scale reuse.

Naming then, is not cosmetic. Good reusable software is software that provides the right functionality and provides it under the right names.

--Bertrand Meyer
Object Oriented Software Construction, 2nd Edition, p. 128

Alternately, you could use endnotes and place the actual citation at the end of your document.

Please Note: Failure to do this is called plagiarism and is considered to be academic misconduct.

General Suggestions

Don't choose too big a topic. You only have 20 minutes. If the topic is large, you will not be able to go into too many details.
Don't talk too fast. Speak clearly.
Prepare screen displays with the main points only - not every single word in your handout (or your talk). Make the font big enough for people in the back of the room to read.
You have the advantage of knowing what your audience knows about Android apps. Don't waste time telling them things they already know.
Practice your talk out loud at least once - with a friend listening, if possible.
Make sure you don't go over the time limit.
If you use the Smartboard, be sure you know exactly what you will write. Don't make it up as you go along. Understand that writing on the board takes a lot of time, and that it is difficult to write large enough and neatly enough for everyone to read.
Don't use words that your audience does not know unless you define or explain them. For example: "RMI marshalls the arguments to a method call before..." What does "marshalls" mean?
Don't simply copy sentences from some source into your handout (even if you cite them) if you can't explain in different words what they mean.

Your Audience

Be aware of your audience's needs. In particular:

1. Set up the projector or computer in advance.

2. Prepare and pass out enough handouts before you begin your talk.

3. Check the lighting and be sure that it is not too bright for people to read the screen, but not too dim for them to take notes.

4. Be sure your slides can be read at the back of the room. This involves focus and size. (See point 3 above)

5. Speak loudly enough to be heard in the back. Don't talk too fast.

An Outline of a Typical Presentation (this example is for a Java I/O topic)

1. Give a brief (one minute) summary of what your presentation will cover.

I will describe the RandomAccessFile Class and some of its most important Methods, and then show how it can be used in an Application to implement a simple Relative Record File Access Method.

2. Describe what the language feature will allow a program to do.

The RandomAccess File class allows a program

To move a file-pointer to a specified byte position in a file

To move the file-pointer to the beginning or end of the file

To read or write a specified number of bytes at the current location in a file

Using these facilities, we can implement direct access file operations similar to a VSAM RRDS or KSDS. (The latter would require a lot of work.)

3. Explain what you need to do in a program to implement a simple version of this feature.

Declare and Create a RandomAcessFile object
Declare and Create a longint data item to hold a byte offset
Use seek() to set the file pointer. Explain seek()
Use read() or write() to read/write data. Explain read() and write() and the kind of data they can handle (bytes, byte arrays, primitives, etc.)

4. Present some simple code that illustrates the feature.

As an example, present two demonstration programs that:

write out a series of fixed length records filled with blanks to serve as an "RRDS" file all of whose "slots" are "empty".

Accept data from a user and

write data records to appropriate slots according to some well-defined scheme.

Read data records from the file

In each of these demo programs, use pseudocode or indicate via comments the details not relevant to the File operations.