OBJECTIVES
CSE4MPC 2016
(MOBILE & PERVASIVE COMPUTING) ASSIGNMENT (40%)
DUE DATE: WEEK 13 MONDAY 24/10/2016 AT 10.00AM, (BONUS 5 MARKS, IF PART 1 (TASKS 1 TO 4) IS DONE FULLY AND CORRECTLY EARLIER, AND DEMONSTRATED
(TO A TUTOR/LECTURER),
BEFORE WEEK 10 MONDAY 3/10/26, 5.00PM)
The purpose of this assignment is to demonstrate an understanding of the following tasks:
· designing a mobile computing application, from its architecture, user
interfaces to the use of a range of Android APIs and publicly available
APIs, addressing specific concerns and requirements, and
· implementation of a mobile computing application and its
documentation.
Because this is a group assignment, it is also expected that students will learn some amount of team work and team problem solving skills from this assignment. Given the different components of the system, it is recommended that each member participate in both the overall design and programming. Also, some of your own research and experimentation may be required to discover how certain functionalities can be implemented effectively, beyond what is in the lecture slides.
GROUP ASSIGNMENT ASSESSMENT POLICY
This assignment comprises two parts and, in total, contributes to 40% of the assessment for this subject. Groups of two or three are required to successfully complete this assignment. The assignment is not intended to be done by one person individually, and there will be no bonus marks for this. The outcome of the assignment should adequately reflect the work of such a team, in terms of size, depth, analysis and design. We expect each member of the group to contribute equally, and all members of the group must sign a declaration agreeing to this when the assignment is submitted.
ACADEMIC MISCONDUCT
The Department of Computer Science and Computer Engineering treats any sort of academic misconduct including plagiarism very seriously and when detected, penalties will be strictly imposed.
Students are referred to the document on ‘Academic Misconduct’
distributed in the first lecture and attached to the syllabus.
!1
!1
!2 SUBMISSION GUIDELINES
The hard copy part of the assignment must be submitted by placing it in the relevant boxes on the first floor of Beth Gleeson Building.
The soft copy part of the assignment must be submitted via LMS. You can submit your file as many times as you like before the assignment deadline; the previously submitted copy will be replaced by the latest one.
SUBMISSION CHECK LIST Hard Copy:
· Report: Documentation for the system.
· Statement of Effort: a form must be properly filled out and
signed by all members;
Plagiarism Form: The Plagiarism form must be signed by all the group members.
Statement of Effort forms and Plagiarism Forms are placed near by submission boxes on the first floor of Beth Gleeson Building
Soft Copy:
· All of the source code of the Info-Go System, including a
readme.txt explaining how to run the system.
All of the above files must be zipped in one file with the following naming convention (NO Exceptions): Group_XX.zip, where the XX is the assigned letter of your group (e.g., A, B, etc).
ASSIGNMENT DEMONSTRATION
In addition to the hard and soft copy submissions above, a demonstration of the assignment is required for each group. A means to sign up for a demonstration slot in the lab will be made available in the general office after the assignment submission date. The demonstration should demonstrate that the system works correctly, according to what is asked for in the specifications.
!2
RETURN OF ASSIGNMENTS
Assignments are planned to be marked and returned within two or three weeks of the demonstration (usually held within the week after the submission date).
If any clarification is required for the assignment, details will be posted on the unit website. Please check the website regularly.
!3
!3
!4
The Info-Go Application 1. INTRODUCTION
A lot of data can be collected via mobile devices today. In particular, while at one spot (or Point-of-Interest, or POI, in short), one can collect data about surrounding devices (via Bluetooh scans), data about surrounding WiFi Hotspots (via WiFi scans), take photos and perhaps even record audio or video. One can also manually enter data about a place one is at (e.g., saying this is a beautiful spot). Such data can be geotagged and then stored as a log or record (or diary) about locations one has visited. Such data can also be aggregated and analysed, e.g., to find spots with the most number of WiFi Hotspots. The data can also be visualized, for example, on a map showing where certain WiFi Hotspots are found, a map showing where the noisy points are at a given time and so on. While an individual can collect such data for personal use. The data can also be used by other mobile apps on the same device. One can also share such data on a Web site which can be aggregated and visualised as information maps that can be used by friends or other people.
2. AIM
The aim of this assignment is to design, document and develop an Android mobile app, which we call Info-Go, which enables its user to collect information as s/he goes around and to create logs about spots/ places s/he has been to. A range of information should be collected.
3. YOUR TASKS AND MARKING SCHEME
Your overall task is to design and implement the Info-Go mobile app which can be used to collect information about Points of Interest.
When a user is standing at a certain spot or at a certain point (as identified by a pair of GPS coordinates), the user can use the app to initiate collection of a range of information at that place.
!4
For example, the following types of information about a place can be collected via the app:
• a record of the current location/point (i.e., its GPS coordinates),
• some information about a place can be collected using the Google Places API (https://developers.google.com/places/); given a pair of GPS coordinates, possible places a person can be add can be given via this
API,
• a set of WiFi access points that can be seen from that point (via a WiFi
scan); this can vary since it depends on what access points are available
at that point at the time of scanning,
• a set of Bluetooth devices that can be seen from that point (via a
Bluetooth scan); this can vary over time since it depends on what
devices are actually nearby at the time of scanning,
• pictures taken from that point, and
• textual comments on the place, entered manually by the user.
The app should also be able to make use of screen estate if viewed on a tablet, compared to viewing on a phone, i.e., it should automatically adapt its layout according to the orientation of the screen and screen size.
Some data may already have been collected a short time ago and the user should be given the choice to reuse cached data or to collect data.
The user might want to view the data collected in the past, within certain periods or at certain points, or a particular type of data, visualised on a map.
!5
!5
!6
An overview of the tasks are as follows:
PART 1 – ALL THESE Coding TASKS MUST BE ATTEMPTED FIRST
BEFORE PART 2 (for a maximum of 40 marks):
TASK 1 (SKELETON APP WITH LAYOUT ADAPTABLE TO MULTIPLE SCREEN SIZES AND ORIENTATION) [10 marks]: [Coding]
TASK 2 (RECORD AND VIEW LOCATIONS) [10 marks]: [Coding]
TASK 3 (RECORD AND VIEW PLACE INFORMATION) [10 marks]: [Coding]
TASK 4 (GEOFENCING AROUND HOT SPOTS) [10 marks]: [Coding]
[If you can implement TASKS 1 to 4 fully and correctly and demonstrate that about three weeks before the due date, there is a bonus 5 marks.]
PART 2 – CHOOSE 5 OUT OF THE 6 Coding TASKS BELOW, BUT NOTE THAT TASK 8 DEPENDS ON TASK 3 (for a maximum of 50 marks): TASK 5 (RECORD AND VIEW WIFI SCANS) [10 marks]: [Coding]
TASK 6 (RECORD AND VIEW BLUETOOTH SCANS) [10 marks]: [Coding] TASK 7 (ENABLE PICTURE TAKING AND VIEWING OF GEO-TAGGED PICTURES) [10 marks]: [Coding]
TASK 8 (CACHING) [10 marks]: [Coding]
TASK 9 (RECORD INDOOR POSITIONS) [10 marks]: [Coding] TASK 10 (ACTIVITY RECOGNITION) [10 marks]: [Coding]
PART 3 – REQUIRED
DOCUMENTATION TASK [10 marks]: [Documentation: 4 to 6 pages]
BONUS PART – TO BE DONE ONLY AFTER PART 1 AND PART 2 OF THE ABOVE HAVE BEEN COMPLETED
BONUS TASK [5 marks]
Note that the above adds up to 105 marks so that successfully doing all tasks, including BONUS part, and if adding 5 marks for doing tasks 1 to 4 earlier, can lead to 110/100 marks! Marks can also be given if a task is only partially completed, depending on the functionality achieved.
NOTE: You are required to use multithreading appropriately (in one or more of the forms such as the Java Thread class, AsyncTask and/or IntentService) and the Android component types of Activity, Service, BroadcastReceiver and ContentProvider as much as possible in implementing the functionalities as appropriate.
!6
STATE ANY ASSUMPTIONS YOU MAKE – WHERE DETAILS ARE NOT SPECIFIED, OR THE ASSIGNMENT IS UNDERSPECIFIED, YOU ARE FREE TO DESIGN THAT ASPECT OF THE APP AS YOU SEE FIT.
You must attempt TASK 1, TASK 2, TASK 3, and TASK 4, and the DOCUMENTATION TASK. You are free to attempt the other tasks in any order or implement any subset of the tasks, BUT note that TASK 8 is dependent on TASK 3.
Note that all the tasks must be integrated into the same app – there should only be one Android app.
The details of the tasks are as follows.
!7
!7
PART 1 [40 marks] (attempt all 4 tasks)
TASK 1 (SKELETON APP WITH LAYOUT ADAPTABLE TO MULTIPLE SCREEN SIZES AND ORIENTATION) [10 marks]: [Coding]
Info-Go should have a user interface that supports multiple device sizes including a smartphone (e.g., Nexus 6 size) and a tablet (e.g., Nexus 9 size) (landscape and portrait orientations). Your app should have (at least) two layouts, one layout for the smartphone and portrait orientation of a tablet, and another layout for the landscape orientation on a tablet. You can use the the Master/Detail Flow template (available in Android Studio when you create a New Project).
The list view contains a list of types of information the app can collect and the detail view could contain the interface related to specifying parameters for collecting information and/or contain the interface for displaying or visualising the information on a map.
An example of what the detail might contain when it is used to visualise geo-tagged photos taken is shown here. Note that in this task, it is enough to set up the list of types of information to be collected, and the adaptive layout, leaving the DETAIL blank.
!8
DETAIL
LIST
List of types of information
DETAIL
!8
TASK 2 (RECORD AND VIEW LOCATIONS) [10 marks]: [Coding]
This task implements functionality to collect one type of information regarding the point where the user is, i.e., to collect the GPS location of the user and store it in a database. The user should be able to select this type of information from the list of types of information, and then
a. click a button to record the current location, or
b. view previously recorded locations on a map.
The current or last recorded location should have a marker with the label (“last recorded location”). The colour of the last recorded location should be different from the other locations on the map. A sketch is given below but you are free to design the layout differently and have other features as you see fit.
record current location
TASK 3 (VIEW PLACE INFORMATION) [10 marks]: [Coding]
You should have a functionality to get place information using the Google API. When at a point/location (with given GPS coordinates) and reverse geocoding, it is possible to have several places that match a given set of GPS coordinates. The task is to retrieve one or more places (or place names/descriptions) corresponding to the current point/location of the user and show that to the user.
[Hint:
You can use APIS such as https://developer.android.com/training/location/display-address.html and/or use https://developers.google.com/places/android/current-place
]
!9
———— ————
location ———— ———— ————
!9
TASK 4 (GEOFENCING AROUND HOT SPOTS) [10 marks]: [Coding]
Add a feature where the user can mark a given place/point as “hot”. Then use the geofencing API [http://developer.android.com/training/location/ geofencing.html] to add geofencing around the hot points so that the user is notified when s/he is within 100m of any one of the hot spots.
!10
!10
PART 2 [50 marks] (attempt any 5 tasks)
TASK 5 (RECORD AND VIEW WIFI SCANS) [10 marks]: [Coding]
This task is to allow the user to do a scan of the WiFi hotspots at the current location where the user is and to store results of the scans (i.e., the findings), and to retrieve and view that information later. Note that you also need to store the location where you do the scan, i.e. each scan being done at a location will be geotagged and timestamped.
TASK 6 (RECORD AND VIEW BLUETOOTH SCANS) [10 marks]: [Coding]
This task is to allow the user to do a scan of the Bluetooth devices in the surroundings at the current location where the user is and to store results of the scans (i.e., the findings), and to retrieve and view that information later. Note that you also need to store the location where you do the scan, i.e. each scan being done at a location will be geotagged and timestamped.
TASK 7 (ENABLE PICTURE TAKING AND VIEWING OF PICTURES) [10 marks]: [Coding]
This task will enable the user to take a photo and to store it, together with a textual description entered by the user and the location where the photo was taken, and later to retrieve that location or view them on a map (and by clicking on the photo on the map, the information about the photo including its description can then be seen). Note that the user might choose to take several photos at the same location. Since the photo and its location are stored, the photo is geotagged and timestamped.
TASK 8 (CACHING) [10 marks]: [Coding]
Note that TASK 3 involves retrieving place information over the Internet. Whenever there is no network connection or to save bandwidth/time, the app should be able to retrieve place information from a cache. Design and implement a cache that will store place information for a given location (i.e., for a given set of GPS coordinates), so that the user can choose to use the place information from the cache first (if it exists) rather than send a query over the Internet.
[Hint: since GPS coordinates are precise up to a range of decimal points, you can define a boundary (with a fix radius) around a given point beyond which you will query the Internet, that is, suppose the history contains the following two points:
Location: (x1,y1); Place: Preston Market Location: (x2,y2); Place: La Trobe University
!11
!11
Then, for some fixed r you set, if the user is currently at (a,b), then distance((a,b),(x1,y1)) < r means the user is at Preston Market, or if distance((a,b),(x2,y2)) < r means the user is at La Trobe University. You can use Euclidean distance as your distance measure. ] TASK 9 (RECORD INDOOR POSITIONS) [10 marks]: [Coding] GPS currently may not work well indoors. Add a feature on Info-Go to record indoor locations, instead of using GPS. Have a button “start tracking” for the user to start tracking and another button ”stop tracking” for the user to stop tracking, to create a history of indoor paths or locations visited by the user. Also, the historical paths of the user should then be visualisable on an indoor map. [Note: this feature relies on having indoor maps and an indoor positioning technology; for this assignment, you can draw up your own maps and need only show three locations that your application can distinguish (e.g., BG115, BG139, BG117, or any choice of three indoor locations on the LTU Bundoora campus you choose) - use either triangulation, signal strength measurements, and/or fingerprinting using WiFi signals to determine indoor locations.] TASK 10 (ACTIVITY RECOGNITION) [10 marks]: [Coding] Add a feature to continually track the path of the user as the user walks (you need to determine a suitable frequency for recording location updates as the user walks around). Have a button “start tracking” for the user to start tracking and another button ”stop tracking” for the user to stop tracking. Note that as GPS accuracy/readings can vary over time, even if the user is standing at the same spot, there may be a need to “average” or “smooth out” readings. Also, extending on TASK 2, the path of the user should then be visualisable on a map. Use the Activity Recognition API [http://developer.android.com/training/ location/activity-recognition.html] to determine if the user is really on foot, and disallow tracking at the points where the app detects that the user is no longer on foot, and allow when the user is back on foot (e.g., the user walks, takes a bus and then gets off the bus and continues walking) - the app only allows recording when the user is walking or on foot. !12 !12 PART 3 [10 marks] DOCUMENTATION TASK [10 = 3(i)+3(ii)+4(iii) marks]: [Documentation: 4 to 6 pages] The documentation describing the system should include: (i) a detailed wireframe diagram with explanation describing the structure of the mobile client GUI (showing the main screenshots and how they are related), for the Info-Go mobile application, and (ii) describe how multithreading is used in your application, including for which functionalities and explain why it was used, (iii) a description of how this app might be extended to a treasure hunt game where players go around to collect series of items to complete collections (e.g., collect pictures of museums or visit all the places visited by at least 5 people, etc). Also comment on what other types of context information can be used. As far as possible, provide rationale for your design – that is, provide reasons for why it was designed that way. !13 !13 BONUS PART BONUS TASK, to be attempted only after all the above parts have been completed [5 marks] (for a possible total of 105/100!) Add a feature to allow the user to geo-share selected information about its history of recorded places and associated information to a server or to friends via Bluetooth or WiFiDirect. With geo-sharing done, a user can access the information collected from another user (a friend) provided s/ he is at the same location. For example, when A shares to B (and mutually), user B can see a photo of user A when the user comes to that spot where the photo was taken. [Note: You need only to implement one way of sharing, ONE of (i) uploading via the Internet to a remote server, (ii) via Bluetooth to another mobile device OR (iii) via WiFi-Direct to another mobile device, not all three. If you choose the server option, this involves uploading data to a Web server - you are free to choose any Web hosting for the Webserver or to use the university’s server but you need to write PHP scripts to receive and store the uploaded data; only choose this option if you are familiar with PHP.] S.W. Loke, 2016, La Trobe University. END OF DOCUMENT !14 !14