Download Workshop Materials
The workspace is already configured, but you will need Eclipse with the Android SDK installed. To do this, please follow the instructions listed here: developer.android.com/sdk
We are using a SQL Server database called "Incident" for this application. Here is a summary of all of the tables and how each is setup:
This table is used to store the users for the application. It is keyed on by "LoginEmail", but all fields are required.
This table is used to populate the introductory screen with a personalized image and message for the user. If no record exists, the application will use a default image and message. The image field is just using a filename to reference the particular image. It is owned by the User table.
This is a simple table used to populate the Incident Type combo box. It is being reference by another table. It is keyed on by IncidentType.
This is the primary table of the application. It stores all the relevant information for the Incident. It is owned by the User table, and uses Incident Number as a surrogate key.
IncidentType (referred to)
This table will store the file name of Image attached to the incident, as well as the file name of the Thumbnail version of the image. It is owned by the Incident table.
Customized Server Functionality
All views in the application were made to be "Type Table_access". Because of this, no views need to be generated and all SQL queries will be done using the tables.
A custom view was created for the User entity. This view inherits directly from the Fetch view, but keys on the CellNumber
The Incident Number was added to the Output for this function. This field is being set just before the row is inserted. This is so we can reference the Incident Number after the record was created.
Several changes were made to this function.
- 3 fields are added to the Output/FetchedData: ThumbnailURL, IncidentStatusDescription, and DateString.
- In the Initialize, we are fetching the user record. This is so we can reference the CellNumber later in the function.
- After the row is fetched, there is meta code to read the value of the IncidentStatus, get the name of the value, and cast it into IncidentStatusDescription. This is done because we will not be using standard Plex grids in the application to display the data. Since IncidentStatus is a Status field, normally, it would only show the literal value of the Status. This is not very descriptive to the user, so we are displaying the full name of the value instead.
- Also after the row is fetched, there is code to fetch the Thumbnail image for the incident. If none is found, then we will use a default image. If one is found, then we will set the full image location: "photos/*CellNumber*/*ThumbnailImgLoc*". This is the reason we fetched the CellNumber in the initialize. A user's photos are being saved to a folder named after their CellNumber. This is done to avoid naming conflicts on the files.
- Again after the row is fetched, there is code to change how we are displaying the IncidentDate. Since we are not using standard Plex grids to display the data, we want to reorganize the date string from what it is on the database.