420 likes | 503 Views
Android Final Project. Kirk Scott. Normalized response spectra of human cones, S, M, and L types, to monochromatic spectral stimuli, with wavelength given in nanometers. Purpose. This set of overheads is just a summary of the information in the Word document posted online
E N D
Android Final Project Kirk Scott
Normalized response spectra of human cones, S, M, and L types, to monochromatic spectral stimuli, with wavelength given in nanometers.
Purpose • This set of overheads is just a summary of the information in the Word document posted online • The purpose is to make sure everyone is informed and give them a chance to ask questions if they want to • It’s not too soon to start thinking about what you want to do for the final project
Deadlines • Depending on the year, the exact dates will vary, so check the syllabus • In general, though, this is the plan • You will be getting this introduction to the project about 1/3 of the way into the semester • At the 2/3 mark you have to let me know what you plan on doing • At the 3/3 mark—time’s up…
Contract • The final project is based on a contract between you and the teacher • At the 2/3 mark, you have to present a written document containing your project proposal • This has to be approved by the teacher • Its contents are open to discussion or negotiation • The general plan is outlined below
The contract has to contain a brief, clear textual description of what you have in mind • Think in terms of 1 page • The main part of the contract will be a list of numbered items • These are clearly identified parts of the project • You will have to associate points with each part
Parts and Points • At one extreme you could say the project consists of one part, worth 200 points • At the other extreme you could say the project consists of 200 parts, worth 1 point apiece • A happier medium would be 5 to 10 to 20 parts, worth 40, 20, or 10 points apiece, respectively • Not all parts have to be equal in value, but the total has to be 200
What are the Items? • For a code intensive app, you could identify different parts of the logic or functionality which you assign points to • You could also assign points to different GUI features, namely elements of the Android API which you use • Anything which can be clearly defined and identified in the finished app is open as an item to have points assigned to it
Philosophy and Outcomes • The final project is based on the idea that students can get out of the course what they want to • This leads to certain consequences • It will affect how you go about writing your contract • It will affect how grades will be given
There will be a tension between proposing a lot, with the prospect of not being fully successful, and proposing very little in the hope of being completely successful • There may be a temptation to propose little • There is an additional aspect of the project contract which should encourage people to propose more than the minimum
In addition to the list of items with points attached, the contract has to contain a proposed grade for successful completion • If the proposed grade is an A, then successful completion is worth 200 points • If the proposed grade is a B, then successful completion is worth 200 * 90% points • This continues down through the grade cutoffs, 90, 80, 70, 60
There are several different scenarios that might occur at grading time • The simple case is that everything goes as planned and grading is a purely mathematical exercise • This would be nice, but it might not happen in most cases
Here are some other cases: • Someone proposed an ambitious project and fell short—but even so, the project was a major undertaking, involved a lot of work, and was successful overall • Someone proposed a minimal project, but got inspired while working on it and added a bunch of features and ended up with something much better than originally proposed
In general, whether better or worse, for a lot of projects it is likely that some things will work as planned, some won’t, some will dropped, some will be replaced, and some will be added • In other words, the contract was a starting point for doing development, but what you have at the end doesn’t really agree with the contract
Deliverables • At the end of the semester, you will have to do several things: • Give an in class presentation • Prepare a written report • Demonstrate the project to the teacher • Copy the project to the teacher’s machine • Have a discussion with the teacher outside of class
Grading • The final report and the discussion will be integral parts of the grading process • It is sad but true that there will be a lot of professorial discretion in the grading • The best possible case is an ambitious project that’s fully successful • All other cases may involve “upgrading” or “downgrading” depending on what happened
On the other hand, keep in mind that when professors devise assignments and tests for a “normal” course, even if grading is rigidly deterministic, their discretion in creating the course definitely affects the grades that result • In other words, nominally objective courses have a subjective component • The discretionary component of this course is just out in the open
The overall philosophy, as mentioned earlier, is to allow students to do what they want to do, and reward them for taking the initiative • The awarding of letter grades is of secondary importance • As part of the final report and discussion, in case things have gone awry, the student has the chance to justify, explain, and make the case for the letter grade they think they should get, regardless of how the project turned out
This point can’t be emphasized enough: • The reality is that you will be reverse-engineering your contract • Even experienced programmers can have difficulty estimating the level of time or effort needed to implement various features or functions • None of us, including the teacher, has any realistic experience implementing Android apps in practice
I would not seriously require keeping a timecard of activities • However, you could try to keep track of the amount of time spent working on implementing various items in your project • It would provide useful objective information for your final report, especially if you had to make major changes from what you proposed in your contract due to time constraints
Another objective measure of effort is lines of code generated, for example • If you chose to document this, it would be another objective item that could be included in your final report
It’s well understood in the software development world that time spent or lines of code alone are not particularly meaningful measures • Time can be wasted • Useless code can be written • If used honestly, they can still add a dimension to an estimation of effort expended in a project
Content • In general, there are no restrictions on the content of your project • Your imagination and your ability to implement are the only limitations • You are welcome to assign points to features, like graphical user interface things, which have been covered in class
You are also encouraged to use features of Android that weren’t covered in class • If you go out to the developers’ Web site for Android there are all sorts of possibilities • Lots of the topics sound interesting • You may just pick one and decide to build an app around a particular feature that you’d like to master
Examples • Some students may have enrolled with a clear idea of the kind of app they would like to learn how to develop • The final project is an opportunity to do that • Other students may not have a good idea of what to do • They may be kind of at a loss because in other courses they’ve always been told what to do
On the following overheads example project ideas are listed • They may not be very inspiring, but they follow from the programming assignments, so they should at least be understandable • The individual ideas listed may or may not make complete projects • If you want to use them, you can • You can mix and match the features you’d like to include
Examples Inspired by Wari • 1. Redo Wari with linked cups and a listener structure more reminiscent of the final project code for CSCE 202. This alone is not very ambitious. • 2. Redo Wari so that it has clickable cups and dots representing the seed. This is reminiscent of the version of Wari at the 2/3rd mark in CSCE 202. This is actually a reasonably interesting problem. Done right, the various components would resize themselves to fit nicely on any sized screen. • 3. Implement some other board game altogether.
Examples Inspired by Flashcards • 1. Write an improved version of flashcards where the user can step through the various parts of a multi-part answer, one click at a time. Think in terms of the steps in a math problem solution, or the multiple lines of an SQL query. • 2. Write an improved version of flashcards which includes a scratchpad area where the user can scribble their answers (either with the keyboard, or better yet, using a stylus or fingertip) before checking them with the app.
3. Building on (2), write a version of flashcards where the user’s answers are saved and can be replayed in some fashion. • 4. Building on (3), write a study guide creation app. The idea here is that the original app contains no answers—just questions. As the user enters answers, they are recorded in tandem with the questions. At the end, the app works like flashcards. In other words, this app causes users to create their own study guides.
5. Building on (4), write a completely generic study guide creation app. In other words, the user is prompted to enter both questions and answers, in succession. At the end, the collected set works like flashcards. • 6. The foregoing train of thought could lead to an app that had nothing to do with flashcards and was simply a data-entry tool for some problem domain. Up to this point, you might have been managing questions and answers as resources. Or you might already have reached the conclusion that having a db backend would be helpful. For a full-scale data entry tool, a db backend would start becoming a necessity.
7. Write a two-player version of flashcards. The idea here is that one student could quiz another. The app plays in teacher mode on one device. This shows both the question and answer, plus it has a button to advance to the next question. The app plays in student mode on another device. Here it shows only the question. The idea is that the student would have to orally answer the teacher before being advanced to the next question. • 8. Think in terms of vocabulary flashcards for foreign language learning. In addition to the text of the words in the two languages, consider adding the following: pictures, pronunciation sound, pronunciation recording and playback, videos.
9. Building on (7), make the language bi-directional. In other words, make it just as useful for the speaker of either language as a native speaker to practice vocabulary in the other. • 10. Instead of a question and answer format, develop a flashcard app based on multiple choice questions. Notice that foreign language vocabulary would be relatively easy to implement. Along with the one right choice, 3 others could be randomly selected from the master list of all vocabulary included. This could be randomized so that the choices and the position of the correct answer would be different every time.
11. Building on (9), create an app that will actually test the student, recording counts of the number correct. In theory you could grow this into an app that changed the path through the questions and answers based on the knowledge that the student has already proven based on previous answers.
Meta-Projects • I do not expect most students to be interested in doing this. • However, someone might be interested, and it would lead to a more complex project, even though, as you will see, the second level will be Java programming, not Android programming. • Suppose you did one of the suggested flashcard versions of the project, or some variation on it.
Now write a Java program that has a user friendly graphical interface where someone who doesn’t know anything about Android apps could enter the questions and answers. • At the click of a button, the Java application would produce all of the files needed for the corresponding app. • The Java application would have to have a predefined “idea” (template) for the app in question.
This may seem to duplicate some of the ideas given above. • In other words, if you can have the app itself prompt for questions and answers, why build a Java application? • One reason is that you have access to a full sized keyboard and monitor when doing the work. • Another reason is that if you are developing multiple flashcards apps, say for multiple chapters in a book, you have a convenient grand central station for organizing your work.
It would be the starting point for creating an environment where you could develop multiple versions of the same app that would work on different devices. • In short, it’s a step towards production work rather than piecework. • This idea could apply to multiple choice as well as simple question and answer apps. • In the long run, the Java application could have multiple templates, and the user could select which one to use when creating an app.
Undergraduate Research • Both the full development of flashcard apps and a flashcard based meta-project could be the basis for an undergraduate research project. • Other completely original apps could also be the basis for and undergraduate research project. • If anyone is interested in undergraduate research funding, you can do a search on the UAA Web site for information on funding.
You can either talk to me before or after doing such a search. • I anticipate having a flashcards based project going during the spring of 2014 and student participation would be welcome.