代写COSC2309/2347、帮做Java语言编程、Java、Java设计代做

日期：2018-10-01 09:38

Mobile Application Development

COSC2309/2347 Semester 2, 2018

GeoTracking Application

Assignment part 1 (20 marks)

NOTE: In addition to carefully reading this document you should also

regularly follow the Canvas assignment discussion board for

assignment related clarifications and discussion.

Overview

You are to implement a GeoTracking application to track one or more moving

objects based on a set of search (filtering) criteria so that you can travel to

their location at specific times. Data for the moving objects comes from a

simulated TrackingService (more details later) and each object (Trackable)

varies between being on the move and stationary (for a fixed period) wherein

you can interact with the object at a specific location.

To give you more flexibility and make the assignment more fun we will allow

you to choose your own problem domain in terms of the tracked objects

(Trackables) and their purpose. However the actual requirements are fixed as

per this specification and thus it is simply the name of the tracked objects, and

graphics/branding of your application that changes.

For clarity in this specification (and the provided test data) I am going to use

the example of a Food Truck Tracker application where food trucks are the

Trackables and the goal is to make your way to a specific (and delicious!)

meal of your choosing at a suitable chosen time. But otherwise feel free to

use your imagination … track your favorite celebrities/rock stars, zombie

movements, parcel deliveries, garbage trucks (who wants to get stuck with a

full bin?!) .. whatever you like ?

NOTE: During testing/marking we will use Food Truck data so no matter what

domain you choose make sure your application can be effectively used with

Food Truck Data for testing/marking according to this specification.

Requirements

In this first assignment (assignment part 1), you will implement the basic user

interface to list all available trackable objects and display them in a filtered list.

You will also create and maintain a Tracking list of the specific Trackables that

you want to track. NOTE: Trackable and Tracking are specified in more detail

below.

NOTE: This functionality will be extended in Assignment part 2 to provide a

full application complete with local storage and networking/cloud service

behavior (including a location-based notification system that will allow you to

schedule tracking events based on location and trigger notifications based on

the distance between you and the objects you are tracking).

Implementation

Trackables have the following properties:

Trackable (e.g. Food Truck):

- Id: An integer starting at 1 (to simplify testing), which uniquely identifies

the object (not visible to the user)

- Name: A short String naming the object (e.g. Fat Ribs BBQ)

- Description: A longer description of the object (a sentence or two)

- WebSite URL: an arbitrary http:// address that can be opened in a

browser window

- Category: A text description of the object category (e.g. American

Cuisine)

- (Optional) Photo/Video Clip: Any non-copyrighted media asset (e.g.

Photo of customers and Van at Food Truck Site)

For assignment part 1 you can hard code (5 or more) Trackables so that you

can work on your UI. We have also provided a set of Food Truck data

(food_truck_data.txt) which you can use. In assignment part 2 you will

read data from this file and may choose to do this now.

Tracking: A Tracking event is when you select and follow a single Trackable

with a single stationary time so that you can use distance information (which

we will obtain from Google Distance Matrix in assignment part 2) to follow the

movement of, and schedule to meet with, the Trackable at a single specific

suitable time during which it is stationary.

Your application will support multiple Trackings (e.g. Lunch at Fat Ribs,

Docklands today and Dinner at Freda’s Fish ‘n’ Chips tomorrow). A tracking

has the following information

- TrackingId: A randomly generated String, which uniquely identifies the

tracking (not visible to the user).

- TrackableId: ID of the trackable so you can match Trackables to

Trackings (since the TrackingService only provides Trackable id’s not

the full Trackable object details)

- Title: The title of the tracking event (e.g. “Lunch at Fat Ribs, Docklands”)

- Target Start Time: The single start time of interest when the Trackable

is stationary (e.g. August 1st, 2018, 12.30PM)

- Target End Time: The single end time of interest when the Trackable is

stationary.

- Meet Time: the time you plan to meet the Trackable (i.e. when you plan

to visit the food truck to eat). Must be between Target Start and End

times.

- Current Location: A String representation of geographical latitude and

longitude of the current location (e.g. -37.805631, 144.963053). The

current location of the Trackable is retrieved from the supplied

TrackingService. NOTE: tracking_data.txt provides some data to

get started and you can get real co-ordinates from the Google Maps web

page directly (outside of your app).

- Meet Location: A String representation of geographical latitude and

longitude of the meeting location (e.g. -37.805631, 144.963053). Again

this data comes from the TrackingService and you can only meet with a

Trackable when it is stationary (i.e. its stop time is > 0 minutes).

Functional Requirements

Your application must provide the following functionalities and meet the nonfunctional

requirements stated under the “Other Requirements” section below.

- Display Trackable List – A complete list of Trackables either as a

ListView or RecyclerView (data can be hard coded for assignment

part 1 or you can read the data from food_truck_data.txt)

- Display Filtered List of Trackables: For assignment part 1 you only

need to filter by Category (e.g. Healthy Choice). The expected UI option is

that you select a filter and it changes the content of the Trackables List in

point 1 above.

NOTE: We will add some additional location based filters in assignment

part 2 (e.g. Duration, Distance, Walking time, Arrival Time etc.) so you

may wish to consider these in your UI design.

- Display Route Information (for a Trackable): This is the data that

comes from tracking_data.txt via the TrackingService, which is

basically just a number of waypoints in time as the trackable is moving as

well as times when the trackable is stopped and for how long (i.e. stop

time > 0 minutes).

NOTE: For assignment part 1 this is optional in the GUI and can just be

logged to the console however if you address the other requirements it

should not be too difficult and doing so will help you understand the

problem better to give you a head start for assignment part 2!

- Add a Tracking: The application should allow the creation of an

unbounded set of trackings. For simplicity, you can allow trackings with

overlapping times. i.e. we will assume correct data and will not validate or

range check your trackings.

- Edit Tracking Details: Users should be able to edit the tracking details

(e.g. Title, Meet Time) as well as remove trackings from the tracking list.

- Display Tracking List: This will be a synoptic view (summary) of the

trackings e.g. meet location, time and trackable name. The list should be

sorted according to date/time. As with the list of trackables you should

again use ListView or RecyclerView.

- Selection/Editing: In the Tracking List view mode described above,

users should be able to add or edit items via direct manipulation (e.g. long

press or gesture on a list row). All editing should take place in a separate

Activity (View) to the Tracking list.

NOTE: Even though it might initially appear that the requirements are

complex/large, there is significant overlap between much of the functionality.

e.g. the implementation of both the Trackable List and Tracking List is largely

the same and you should be able to reuse most of the code here (by OO

reuse not copy and paste!). Also note that the route information need only be

logged not displayed in the GUI for part 1.

TrackingService

The supplied code should be fairly self-explanatory and provides comments

and a simple usage example. Look at this early, since if you have trouble

working through some simple non-graphical Java code then you are likely to

find this course VERY difficult! If in doubt, please seek advice from your tutor

in the tutelab early in the semester.

NOTE: The purpose of this service is to simulate what would in real life be a

remote cloud service to provide a more realistic application use case. You will

get to use a real cloud service in the form of the Distance Matrix Google API

in assignment part 2.

Other Requirements:

- In assignment part 1 you are not expected to persist data however your

data must not be limited to the lifetime of any specific activity (i.e. must

have application scope to facilitate testing). For simplicity, you can also

hard code Trackable data and can edit tracking_data.txt for

Tracking. (NOTE: put any hard coded data in a separate class for

cohesion and code readability).

- Your Graphical User Interface (GUI) must support all of the functionalities

presented under “functional requirements” above (except for route

information which can be logged as previously described).

- The preferred Target Android Version is API Level 25, however, for

students with old devices who want to target lower levels you are allowed

to do so.

- You can write your application in the single Activity per screen phone style

however you may choose to write a tablet version using Fragments.

- You should use the Model View Controller (MVC) approach to assist in

writing modular and cohesive code. In particular we will be looking for a

domain neutral model implementation which is not dependent upon

Android specific features (i.e. java.* class/package dependencies only

not android.*). Some obvious model classes/interfaces we would

expect are: Trackable(interface)<-AbstractTrackable<-

FoodTruck (you may choose a different implementation class such as

Celebrity). Tracking(interface)<-AbstractTracking<-

MealEvent (MeetAndGreet for Celebrity)

- For your UI you should aim for simplicity. You will not be marked on the

aesthetics of your design (beyond common sense!) but we are looking for

clear workflows. The only constraints on the design and classes used are

those explicitly stated above, otherwise you are free to be creative

(menus, buttons, toolbars, navigation drawers etc.)

- Your implementation must make efficient use of common values (such as

Strings, Dimensions or Colors) by (re)using values from the appropriate

XML resource file. i.e. do not hardcode such values into your layout files

or your application.

- You may want to consider branding, business models, distribution

frameworks, 3rd party integration (maps, navigation, social media sites)

etc. and how these would impact on your app design although you will not

be assessed on these features (some of these will be covered in

assignment part 2).

Code Quality

Since this is an advanced programming elective you will be marked on code

quality as well as functional correctness (approximately 60/40 split of

functionality versus quality respectively. A more detailed marking rubric will be

provided closer to submission).

In particular:

1. You should aim to provide high cohesion and low coupling.

2. You should aim for maximum encapsulation and information hiding.

3. You should rigorously avoid code duplication.

4. You should comment important sections of your code remembering

that clear and readily comprehensible code is preferable to a comment.

5. If you use lambdas you should carefully consider the impact on

coupling, cohesion and comprehensibility. In many/most cases

inheritance, polymorphism and delegation are better approaches when

used well.

6. Where appropriate, MVC controller functionality should be placed in

separate classes in a separate controller package. A good rule of

thumb is if it is more than a single method call, or there are non-local

variable dependencies, then put it in a separate class!

Submission Instructions

Your project should be implemented using Android Studio and your project

exported as a single compressed .zip archive before submission. Do not use

any other compression formats - use of other formats (e.g. tar.gz, RAR, etc.)

may lead to delays in marking and/or a deduction of assignment marks.

Important Regulations

- You are free to refer to textbooks and notes, and discuss design issues

(and associated general solutions) with your fellow students and on

Canvas; however, the assignment should be your own individual work

(or optionally a pair of students, see details below).

- Note that you will only be assessed on your own work so the use of third

party designs and APIs (beyond the standard Android libraries) is not

allowed (since it will not be marked).

Optionally forming pairs:

This assignment is of a size and scope that can be done as an individual

assignment. However, since we understand that some students benefit from

working in pairs we will allow optional pairs to be formed. We will however

strictly adhere to the following procedure, keeping in mind that group work is

NOT a core learning outcome of this course and is only offered as an

extra/bonus option.

This assignment can be done in pairs or individually. If done

individually there is no marking advantage. If done as a pair, students

are NOT marked individually, only as a pair (No ifs, no buts .. so when

choosing a partner it is Caveat Emptor i.e. Buyer Beware!).

If students choose to be a pair they must register together in their

tutelab class in week 2 with their student ids (NOTE: Student pairs are

encouraged to be in the same scheduled tutelab but this is not strictly

required other than initial signup).

If students are unable to attend together due to timetabling issues

students must promptly confirm their pairing via email to the head tutor.

If you fail to inform your tutor that you are working as a pair you must

submit individually and not share any source code.

Students cannot change pairs but pairs can separate and both

students become individuals if problems arise with the pairing (both

students being able to use any shared code that has been created to

this point). In this case your tutor must be notified at the latest by

Friday 17th August (end of week 5).

No changes will be allowed after this time unless special consideration

applies.

NOTE: The required implementation language for this assignment is Java

since it is stable, widely used and most importantly students can leverage

their experience from the pre-requisite courses. Moreover, Android is

challenging enough (by design) without having to learn a new language at the

same time. However if students have a compelling reason to use Kotlin and

can demonstrate a track record of high competency and independent learning

they can make their case to their tutor in the tutelab (email applications are

not acceptable since this is a special arrangement) and your tutor may use

their discretion and make a decision to allow this.

This assignment is due at 9:00AM Mon. 3rd September 2018 and is

worth 20% of your final assessment