CS计算机代考程序代写 database Java flex android algorithm COM31007 Software Development for Mobile Devices

COM31007 Software Development for Mobile Devices

Assignment 2021-2022

This assignment is primarily concerned with applying the ideas that are being presented in the

module on methods and technologies for Mobile Computing. Some of the basic algorithms

needed for it have already been introduced during the module, and can be obtained from the

BLACKBOARD.

https://docs.google.com/spreadsheets/d/1mxJaewY4ByBtwioVh_JKLO2hdxIrW_OV/edit#gid=1893727484

Deadlines

The deadline is absolutely fixed. You should therefore plan your work to aim at handing the

report in at least a few days before the deadline – do not leave it until the deadline, just in case

any minor thing goes wrong and you then find that you are late.

Note that the Computer Science department applies fairly severe penalties for handing

coursework in late. If you want to look at the details you can find them on the University’s

website.

Material Provided

Lecture notes, lab class examples and websites/books as detailed on the lecture notes.

NOTE: no third party code can be used in the assignment, except the code what has been

explicitly provided in the lectures. For example you are allowed to reuse the code given in the

lecture/lab slides and any library (e.g. EasyImage) used in the lab classes. However you are not

allowed to download any code from the Web or to use any other software that will perform a

considerable part of the assignment. Unauthorised re-use of third party software will be

considered plagiarism. In case of doubt ask the lecturer for permission before using any third

party code. In general, we will allow only the use of generic libraries designed to improve the

look and feel of any interface. However permission must be requested before use.

1. Scenario

The learning objectives of the assignment are to learn:

• to build an app with a flexible sophisticated layout

• to use separation of concerns (using MVVM)

• to cope with multimedia data

• to store data locally using abstractions of databases (Rooms)

• to use the phone’s sensors (GPS, barometric pressure, etc.)

• to use background services

• to work as a group

The field chosen is management of photos.

The solution will be composed of the following parts, each covering each of the above

learning objectives.

1.1. The problem

You will design, build and evaluate a city-based travel application consisting of an images or

photo display of attractions and places of interests around a city (Sheffield, London,

Manchester, etc.) you have visited or been to. You are able to receive and edit relevant

information about the images on mobile device and to organise them along geolocated visits.

The app will allow to:

1. Map integration and Taking photos: Taking pictures and allowing pictures to be uploaded

to the map (15% of marks)

2. Capturing a visit and Trip planning: using sensors and locating the user using the phone’s
location services; during a visit it must be possible to take pictures that are then associated to

the path and its sensor readings (20% of marks)

3. Visually browse previews of photos: stored in the phone’s photo library (gallery) using a

number of strategies (20% of marks)

4. Saving the pictures and metadata to local Room database (20% of marks)

5. Showing details of a photo including its location on a map and the details of the path the

picture is part of (20% of implementation marks)

6. Implementing any additional functionalities (inspect the details of a photo, i.e.

geolocation, description, title, weather forecast pinned upon the map, search location by photos,

rating and recommendations, etc.) (5% of marks)

These steps are detailed in the next sections. Examples are provided to help understand the

requirements. You are not required to implement that exact solution. You can use your

creativity, as long as the formal requirements are met.

Requirements for the solution are:

• It must be fully functional and robust

• It must work on multiple devices with different screen size, processing power and

screen resolution

• It must work at least for Android>11.0

• It must be efficient, able to cope with a library of thousands of photos

• The interface must be pleasant to the eye

• The interface must work both in portrait and landscape mode

• The interface must follow the typical design patterns of Android and in particular

MVVM

• The solution must be of high quality. A simplistic solution (although functional) will

not attract many marks.

All implementation must be done either in Kotlin (for Android phones) or in Java. No

other languages are allowed (e.g. Cordova, React Native, etc.).

1.1.1. Map integration and taking Pictures

Maps are a must-have-feature for this travel app. Users should have access to detailed maps

which are easy to use, understand and navigate with. The maps must provide as much relevant

and detailed information as necessary.

The app must allow taking pictures using the camera. This functionality must be working both

when used on a real device and on the emulator. If the phone model does not have a camera

the functionality must not be available to the user. The new photo must become available for

retrieval to the app. The user must also be able to upload a new picture from the gallery.

1.1.2. Capturing a visit and trip planning

One of the main reasons why people use travel apps is to plan their trips. Apps which offer

such functions allow picking different destinations, choosing transportation to get to those

destinations, booking hotels, etc. This function usually can be integrated with all the other

features such as maps.

The app should allow capturing a geolocated visiting path, i.e. an activity over a limited period

of time when the app tracks location, temperature and barometric pressure at regular intervals

(20 seconds). The activity must be started and stopped explicitly by the user. Date and time

must be captured at the start of the visit (click of the start button). A title must be associated to

the visit. Example of interface.

While on a track, the user can take pictures and these are associated to the path. While tracking

is active, the app should show a map showing (i) the geolocated path taken so far, (ii) the

location of the pictures taken so far and (iii) the current position. The map can either be updated

every time a new location is received (better solution) or just be refresh at the push of a button

(basic solution).

The tracking should be implemented as a service tracking geolocation (gps coordinates),

temperature and barometric pressure every 20 seconds. The service will have to work even if

the screen is off and or the app is swiped out from the list of recent apps.

1.1.3. Visually browse previews of photos

You must be able to browse all the pictures taken or uploaded to the app in the phone’s photo

library. In doing so you must design and implement an original program that:

• Allows visualising previews of the pictures

• Allows selecting a picture for further detailed inspection

It is important that the interface is efficient and able to cope with a library of thousands of

photos.

An example of the landscape version of such an interface could be:

Sheffield Cathedra The Diamond Crucible Theatre

Sheffield Botanical Gardens Sheffield railway station

We expect to be able to access in different ways, i.e.:

• A grid sorted by date in ascending order: example:

• Sorted by path, e.g.

Paths must also be browsable via a list, e.g.:

As mentioned you are not required to implement this exact solution. You can opt for a different

6 layout (e.g. all pictures may have the same size, etc.), as long as the same functionalities are

provided by the app.

1.1.4. Persisting data in a local database

All the data captured during the visit (title, date, description, GPS coordinates, sensor data, etc.)

must be saved in a local database implemented using Room (i.e. not directly using SQLite), so

that it can be retrieved at a later stage.

The database must allow searching of images based on keywords in title and description

AND/OR date of creation. Implement an interface for searching images, e.g. like the one shown

above. Note that you must implement an aSync process, as accessing a database on the UI

Thread is not allowed.

1.1.5. Showing pictures on a map

Most pictures will have metadata showing the location where it was taken. Another way to

browse the photo gallery will be through visualisation on a map. Clicking on a location with

photo, shows the details of the photo.

The only requirement is to show the location on the map and to show the details of the photo

when tapped on. The example above however shows some enhancement that you can

implement such as searching for locations or showing a preview of all the images shown. The

interface must provide a button to locate the user’s current location on the map.

1.1.6 Additional functionalities

Tapping on a photo in the browsing interface should allow inspecting the details of that specific

photo by tapping on it. In this case the photo must be shown together with the following data:

• A larger version of the photo (if clicked it should sow the full size photo)

• A path title

• A description

• Location on map (in red in the example) with full path displaying the location of other

pics taken on the same path (in blue in the example)

• Last available sensor readings at time of taking the picture (barometric pressure and

temperature recorded from the phone’s sensors)

• Any other interesting metadata.

Weather Forecasting: users will appreciate if this app provides them with accurate weather

forecasts. There exist numerous decent APIs for this purpose. The most notable ones include

Forecast.io, AccuWeather, OpenWeatherMap, YahooWeather.

Reviews & Recommendation: this travel app could provide users with honest reviews and

recommendations. Users should have the ability to leave reviews about restaurants, cafes,

hotels, and other places.

2. Marking schema
Each part described in the subsections above will carry marks divided as follows:

50% for the quality of the solution, inclusive of separation of concerns, use of async processes,

quality of the user interface, etc. as well as compiling and running without an issue 35% for

the quality of the documentation 15% for the correctness of results.

Please note

• the direct consequence of the marking schema is that providing a program returning

the correct solution is not enough to get a pass mark. You will need to implement the

correct strategies and document/discuss them properly!

• Quality of documentation and code are very important issues for computer scientists.

• Solutions not working on the departmental computers (e.g. working only on personal

7 computers) will not be considered.

4. Handing in

Your solution must be contained in a self-contained directory called COM4510 or COM6510

( in the following) compressed into a zip file submitted through THE

BLACKBOARD.

The directory must contain:

1. The source code of the solution (please note that we will both inspect and run the code)

contained in the directory /code/. All the code must be in the exact format to be

run via Android Studio (Arctic Fox).

(a) All code must be developed in Kotlin. We must be able to run your solution without

problems on a standard lab machine. Please note that the quality of the code carries a relevant

portion of marks, so be sure to write it properly.

(b) All the external libraries must be included in your solution. Maven or Gradle links are

acceptable. Libraries are allowed only if previously agreed with the lecturers. No library doing

a substantial part of the assignment are allowed. Always ask in writing before using any

library.

(c) The documentation in the Kotlin or Java files must be of very high quality. Please note that

this documentation carries a relevant portion of marks, so be sure to write it properly.

More information on guidelines for Java (JavaDoc) see

http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html

2. Screenshots of the different app screens showing the implemented functionalities

/screenshots

http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html

3. The filled self-assessment form documenting the solution. Please note in the form you are

required to assess the quality of your solution using a number between 0 (not implemented)

and 5 (full requirements met) AND to describe in details how you have met the requirements,

e.g. how you have implemented a flexible sophisticated layout, how you have used separation

of concerns (using MVVM), how you have stored data locally (using Rooms), why the Room

schema is appropriate to the problem, how you have implemented the tracking of the visit

(background service), why your solution is efficient, etc

4. A formal declaration of the contribution given by each group member. See below for

the division of work that has to be followed

4.1. How to submit

Everything must be submitted electronically. Nothing is to be handed in at the reception! Use

THE BLACKBOARD. Store your solution in a .ZIP file that when unzipped will generate the

directory organisation described above. As emergency measure (and only in that case!), if any

last minute issue should arise in handing in electronically, please send your solution by email

to the lecturer (cc to demonstrators) in a self contained .ZIP file.

4.2. Anti-cheat measures

Please note that measures are in place for detecting plagiarism and in general cheating.

5. Queries about this assignment?

Should you have any queries about the assignment, feel free to contact