Course+Materials

=Slides=
 * [|Introduction to the course]
 * [|Language basics]
 * [|OO basics]
 * [|Introduction to the platforms]
 * [|Application basics]
 * [|Application basics for Android]
 * [|Application basics for iOS]
 * [|Application basics for Maemo]
 * [|Design patterns]
 * [|Approaches to UI specification]
 * [|App tip: switching UIs]
 * [|App tip: saving UI State]
 * [|App tip: managing screen orientation]
 * [|Data storage: SQLite]
 * [|Accessing hardware]: [|Android], [|iOS], [|Maemo]
 * [|Guidelines for user interface design]
 * [|User interface: gestures]
 * [|Multitasking] in Android and iOS
 * Data storage: Android's [|content providers], Apple's [|Core Data]
 * [|More about languages] (notes: slides on this topic will be added during the course)

=Default Course Project= = Design and implement **an application that records and charts data coming from the accelerometer** built into your device. = The application should manage and store multiple recording sessions. The application should provide at least the following 5 user interfaces (UIs). All UIs must be correctly displayed in both portrait and landscape mode with the exception of UI #2, where support for portrait mode is optional. Error messages should be presented to the user when appropriate (e.g., when no more space is available for recording data). Be aware that **quality will be rewarded more than quantity**. For instance, an application that provides only basic functionalities but is "rock solid" will get higher grades than an application that offers a lot of optional functions but does not respect the UI guidelines for the chosen platform, does not properly handle error conditions, stops recording data when it is moved to the background, and so forth. **The quality of the source code will be also considered in the grading process**. For instance, source code that is properly commented and highly modular will be favored over code that lacks comments, uses cut-and-paste instead of inheritance, and so forth.
 * 1) A UI that lists all the recording sessions stored on the device and makes it possible to visualize (see UI #2) and delete any of the sessions. To better understand how a list may look like, consult this page.
 * 2) A UI that shows a single recording session in detail. Data from the session must be displayed in graphical form as a run chart. Some form of support for panning and zooming is mandatory; however, support for data exploration through gestures (e.g., pinch to zoom) is optional. Further optional features for the UI are: support for multiple visualization scales (e.g., linear and logarithmic); display of the current recording session with real-time update; display of data in the frequency domain.
 * 3) A UI that shows the details (exact values of the readings, date and time, ...) of a single record. It is suggested that this UI is entered from UI #2 by touching a data sample.
 * 4) A UI that allows the user to start a new recording session after having set the appropriate parameters (sampling time, duration, axes to record, ...) for the session.
 * 5) A UI that is displayed while recording is in progress. The UI should display some summary information about the session (e.g., number of samples recorded so far) and offer the possibility of stopping the recording process.

=Suggested Exercises=
 * __Language basics__: build a program that generates two matrices, prints them, sums them and then prints the result. Fill the input matrices with random doubles. **Do the exercise in all three languages** (Java, C++ and Objective-C). If you do not know how to generate random numbers, look at the sample code in [|CompilerTests.zip].
 * __OO basics__: design a class called Polygon that handles polygons with an arbitrary number of sides. The class should store the coordinates of all the vertices of the polygon: the vertices are assumed to be on a plane, therefore two coordinates are sufficient. The vertices are numbered so as to establish the correct order of connection. The class should provide methods to 1) get and set the number of vertices in the polygon; 2) get and set the coordinates of the vertices; 3) get the perimeter of the polygon. The class should also provide a non-default constructor that receives the number of vertices when an object is instantiated from the class. In the default constructor you can assume that the polygon has an unmodifiable number of sides of your choice or, if you want to tackle a challenging exercise, you can use a data structure that allows you to adjust the number of sides dynamically (an ArrayList in Java, a vector in C++, an NSMutableArray in Objective-C). When Polygon is complete, design a new class Triangle derived from Polygon . The new class should provide an additional method to get the area of the triangle. **Do the exercise in all three languages** (Java, C++ and Objective-C).
 * __Application basics__ (coming soon)