SmartER (Smart Energy Recommender): An Overview
In Phase 1, you created the backend of the system as RESTful web services (including a database) to
enable querying the electricity usage data and updating it. The RESTful web service provides services
such as registering new residents, and storing and querying electricity usage data.
In Phase 2 (this assignment), you will implement an Android application. The Android application
will be the mobile client and consume the RESTful Web Service that you developed in Phase 1 in
NetBeans. It will also invoke other public web APIs.
The mobile app assists Victorian residents (energy consumers) with better energy management by
providing related information, and enabling them to view their energy consumption reports. If the
usage is high during peak hours, it will provide the user with a warning message. Alternatively, when
the usage value is low, the user will receive an encouraging message to continue saving. The
historical data usage can be viewed on an hourly or daily basis using different types of graphs on the
mobile app.
Task 1: Invoking public web APIs (10 marks):
A weather API will be used to provide the weather information (i.e. temperature) for a location. You
need to call the right API methods and pass the right parameters, and then parse the JSON response to
retrieve the current temperature. (10 marks)
The current temperature value will be displayed in the home page of the Android app (Task 6), and
also stored hourly in the electricity usage table (Task 3).
These are some examples of weather APIs below, but you can find and use any other weather API.
Make sure you use the free access.
Open Weather Map http://www.openweathermap.org/api
World Weather Online’s weather http://developer.worldweatheronline.com/api/
Dark Sky API https://darksky.net/dev/
Task 2 Electricity usage simulator (10 marks):
a) You need to create a class that continuously generates random electricity usage value for THREE
appliances per hour. The random values should be close to real values (refer to Phase 1
specifications). (3 marks)
These usage values along with the temperature value (obtained from the weather API) will be
added to a database every hour (in Task 3).
b) You need to add a set of business rules to ensure your random values represent real world
scenarios:
o the fridge works all the time,
o The washing machine works up to 3 continuous hours per day between 6am and 9pm (i.e.
it should stop working by 9 pm). The usage for the hours that the washing machine is not
working will be considered as zero. The washing machine can be used every day but only
once.
o The air conditioner works up to 10 hours (does not have to be continuous) per day
between 9am and 11pm (i.e. it should stop working by 11pm). The usage for the hours
that the air conditioner is not working will be considered as zero. The air conditioner
should only work when the temperature value is greater than 20.
To implement these rules, you will need to use flags and counters (e.g. a flag to make sure washing
machine only works once in 24 hours, and a counter to make sure the air con and the washing
machine do not work more than the hours specified).
(8 marks) (7 marks)
Task 3 Local Storage (10 marks):
You need to store part of the data locally on the mobile phone’s SQLite database. You will create and
maintain one table (HourlyUsage) that its structure will be similar to the usage table you created in
Phase 1. You will write the hourly usage of each appliance (that will be provided by the simulator
every hour) to the SQLite table first. The entries will be for the time 0 to 23 (24 hours) per day.
Your code logic should make sure after writing 24 records (for 24 hours of a day), at the end of the
day, all these 24 records are written (added) to the backend database of RESTful web services (by
calling the POST method). Then you need to delete all the existing data entries in the SQLite table.
This means the table always stores the hourly usage data for the current day.
Here, we assume the app works 24/7 without any disconnection.
During your interview, since we will not have 24 hour data to test this part. You will have only one
record for the hourly usage data that will be created by the simulator as soon as you start the app
during the interview. You need to add a small button to one screen of the app so when the button is
clicked, the hourly usage data for the current date and hour (only one record) will be written to the
REST database, and then clear the SQLite table. Using this button also allows you to test your code.
(10 marks)
Task 4 – Android Client of RESTful WS (5 marks):
a) You need to create an android application client that will connect to the server and consume the
RESTful web service created in Phase1. You need to make http connections using
HttpURLConnection to invoke all the methods required for completing tasks in this assignment.
(2.5 mark)
b) Accessing data and executing all the queries from the server side (and the web service) should be
achieved using the AsyncTask approach. (2.5 marks)
Task 5 Login and Registration Screens (15 marks):
a) The login screen enables existing residents to login, and allows new residents to register. The
login form. will require a username and a password. This data will be verified with the data stored
in the server-side database during the login. You also need to follow the password design
guidelines (refer to Lecture 7). This means if you violate any design guideline there will be mark
deduction. (5 marks)
b) The passwords should not be sent in the clear text to the server-side database. First, you need to
hash the password on the client side using the right libraries in Java. (2 marks)
c) The registration form. will enable the new residents to enter their information (i.e. first name,
surname, DoB, address, postcode, mobile, email, number of residents, energy provider, user name
and password). In this screen, use spinners for the number of residents, and the names of energy
providers. For DoB, use a date picker (a calendar widget to pick a date). Data entry validation
and error messages should be implemented where necessary. You need to make sure that the
user name and email do not exist already, and ask the user to re-enter it if there is a duplicate.
Your form. should follow the mobile form. guidelines (refer to Lecture 7). This means if you
violate any design guideline there will be mark deduction. (8 marks)
Task 6 Home Screen (10 marks):
a) The home screen – this page should display “smartER” as the app name, the current date
and time, the current temperature based on the resident’s address. This requires invoking the
weather API as described in Task 1. The main page should also welcome the user by their first
name. The main page will use navigation drawer and fragments to navigate to other screens. (5
marks)
b) The home screen shows a negative message and image when the hourly usage (for the current
hour) is higher than the threshold during peak hours and a positive message and image when the
resident saves electricity (the usage is less than the threshold during peak hours). You need to
write a set of rules to implement these requirements. (5 marks)
Peak hours are considered between 9am and 10pm weekdays, excluding the weekends.
The hourly threshold is considered 1.5 kWh.
Task 7 Maps (15 marks):
a) The map screen will show the current location of the residence (the resident’s house) and all
the other houses. You need to programmatically convert the location of the resident’s house
(based on the address and postcode) into latitude and longitude values (using either Google
Geocoding API or Android built-in libraries like Geocoder). Then use the latitude and longitude
values for displaying the location on the map. (5 marks)
b) The screen will provide two options of Hourly or Daily (using a spinner) to show the total
usage. When you tap on a marker, based on which option is selected, it should show the hourly
or daily total usage of that house by calling the right REST methods. (8 marks)
o The marker colour will be based on the usage value, and whether the usage is below or
above the threshold during peak hours. The houses with high usage will have a red
marker. Houses with low usage will have a green marker. (2 marks)
The hourly threshold is considered 1.5 kWh. The daily threshold is considered 21 kWh.
You can use MapQuest or Google maps to complete Task 7.
Task 8 Reports (25 marks):
The Report screen: this screen will enable the user to select and generate three types of reports.
a) Pie chart: a pie chart will include a date picker to allow the user to select a date. Then it will
show the DAILY electricity usage for each of the three appliances for that date (and for the
resident who logged in). This will require calling the right REST method. The labels and
percentages should be shown on the pie chart. (8 marks)
(During the interview, we can select the date that you have records of 24 hours)
b) Bar graph: A bar graph will show the total electricity usage for the resident’s house. You need to
provide two options to generate an hourly or daily usage graph. The user can choose from a
spinner: Hourly or Daily. The Hourly option will show the resident’s usage per hour (from 0 to
23) for the most recent day in the database. The daily option will show the resident’s total usage
per day for the most recent month. This requires you to add 2 or 3 extra records for few other days
of the recent month so the graph shows more than one bar when the Daily option is selected. The
labels and values should be shown on the chart. (8 marks)
(During the interview, for the daily option, we can consider the day for which you have records of
24 hours)
c) The line graph with two Y axes: you will create a line graph with two Y axes where one Y axis
represents electricity usage data and the second Y axis shows the temperature. The X axis will
represent hours or days. You need to provide two options for generating an hourly or daily
graph. The user can choose from a spinner: Hourly or Daily. The Hourly option will show the
resident’s usage and the temperature per hour for the most recent day in the database. The daily
option will show the resident’s usage and the temperature per day for the most recent month in the
database. (9 marks)
(Note: a line graph with one single Y axe will be 4.5 marks out of 9 marks)
(During the interview, for the daily option, we can consider the day for which you have records of 24
hours)
Additional Marking Criteria
Only completing a task does not yield a HD mark. There are 5 other criteria that will be considered
for marking your assignment as described below. Not meeting any of these criteria can result in
mark deduction:
1. Full functionality of all the operations (during the interview),
2. Student’s deep understanding of their code and the program logic (during the interview)
3. Handling all the exceptions and user data entry validation (and preventing program
crashes)
4. Following coding standards, providing meaningful code comments where appropriate,
proper and meaningful naming of variables and methods.
5. Following good design guidelines for the graphical interface such as consistency (e.g. colour,
font), alignment, balance, using the right contrast, avoiding clutter, visibility of objects
Submission Guideline:
A ZIP file will be uploaded to Moodle by deadline including the following files (any missing file in
the zip file will result in mark deduction up to 2 marks from your total marks):
1. Include the signed cover sheet.
2. The Netbeans and Andriod projects including all the packages and classes and files.
3. You need to provide screenshots of all your screens in ONE word document in a proper
order with a title (NOT each as a separate file).
4. The zip file should have this name: FIT5046Assign2-[studentsurnname]-[studentid]-[tutor
name].zip
Late Submission:
Late Assignments or extensions will not be accepted unless you submit a special consideration form.
and provide valid documentation such as a medical certificate prior to the submission deadline (NOT
after). Otherwise, there will be 5% penalty per day including the weekends.
PLEASE NOTE.
Before submitting your assignment, please make sure that you haven't breached the University
plagiarism and cheating policy. It is the student's responsibility to make themselves familiar with
the contents of these documents.
Please also note the following from the Plagiarism Procedures of Monash, available at
http://www.policy.monash.edu/policy-bank/academic/education/conduct/plagiarism-procedures.html
Plagiarism occurs when students fail to acknowledge that the ideas of
others are being used. Specifically it occurs when:
• other people’s work and/or ideas are paraphrased and presented without a reference;
• other students’ work is copied or partly copied;
• other people’s designs, codes or images are presented as the student’s own work;
• Lecture notes are reproduced without due acknowledgement.