CSCI 4176
web代做 | Network | GUI作业 | 代做Android | network | 代写Algorithm | app | project代写 | assignment代写 | assignment代写 – 这是一个关于安卓代写的题目, 主要考察了关于android的内容,是一个比较经典的移动开发题目, 涵盖了web/Network/GUI/Android/network/Algorithm/app等程序代做方面, 这个项目是assighment代写的代写题目
assignment 2
The purpose of this assignment is to give you some experience working with Android Views and Layouts, and with simple network requests using Volley. This is anindividualassignment and should reflect your ownindependentwork.
1 Your Task
Implement an Android application that allows the user to enter the name of a city and see the current weather conditions for that location. The application should consist of a single Activity, with a layout similar to that of Figure 1. The application code must be written using the Kotlin programming language.
Figure 1: Weather app wireframe.
1.1 Requirements
- The interface must include a text input field into which the user can enter the name of a city (or a comma-separated city and country code).
- The interface must include a clearly-labelled button that, when pressed, initiates a request to get the current weather data for the specified location.
- The application must retrieve the weather data from the OpenWeather API.
- The application must parse the retrieved JSON data and use it to populate all of the UI fields, as shown in Figures 1 and 3.
- The application must allow the user to change the city and make a new request (or refresh the current one) without having to leave or restart the app.
- Use ConstraintLayout and/or LinearLayout to construct the main display.
- The minimum Android SDK level must be set to API 23 (Android 6.0, a.k.a, Marshmallow) the same version used in the lab exercisesor lower.
NOTE:Remember to always sanitize and properly encode any user input before including it in a service request.
The wireframe (Figure 1) is a visual outline of the applications layout. Replace the wireframe components with standard Android Material Design components (buttons, text fields, etc.).Taste- fuluse of colour, sound effects and animations can add polish to the application, but dont go overboard.Marks will be awarded partly on how polished the application is.
Consider Jakob Nielsens Usability Heuristics^1 when developing your application. For example, think of what errors the user could make. How can you prevent these errors from happening? How can the user recover from an error?
To achieve an Exceptional mark in Functionality,you should consider adding some extra (useful) functionality to the app, such as using the Android LocationManager to obtain the users current location (latitude, longitude) and submitting that information to the OpenWeather API instead. (This must bein additionto allowing a city to be entered, as one often wants the weather for a location other than where one is currently.) You could also make the input handling more robust, by adding auto-completing, allowing full country names, and more. (See the OpenWeather API for the query parameter formats it accepts.)
2 Implementation Notes
2.1 OpenWeather API
As with most open web services, OpenWeather requires you to register to obtain an API key, which you must include in your requests. The Free tier should be more than adequate for the assignment. You can find instructions for signing up, obtaining your key and using it in your requests in the OpenWeatherMap API guide.^2 Note that it may take a couple of hours for your API key to be activated, so set this up before you are ready to use it.
OpenWeather has several data endpoints, such as 5 days/3 hour forecast, and 16 days/ daily forecast. For this assignment, you will only need to use the Current weather endpoint (https:// openweathermap.org/current). An example response is shown in Figure 2. Figure 3 is annotated with the specific JSON attributes to be displayed in each location.
(^1) 10 Usability Heuristics for User Interface Design, https://www.nngroup.com/articles/ ten-usability-heuristics/ (^2) https://openweathermap.org/guide#how
Figure 2: Example JSON response. Figure 3: JSON data elements to be displayed.
Postman^3 is a useful (and free!) tool for experimenting with web APIs. You can build a request, just as your app would, and view the JSON text returned. This allows you to check that the format of the response is as you expect and also allows you to quickly see the effects of various parameter values.
Finally, take the time to read the API documentation and to review Lab 3 (Volley).
2.2 Allowed Libraries
The following libraries may be used (and are suggested) in your submission:
Volley^4 to fetch and parse JSON data from OpenWeather
Glide^5 for loading remote images (if needed for additional functionality)
No other libraries, beyond the standard Jetpack Android X support libraries, may be used without prior permission.
3 Version Control
You are strongly encouraged to use Git for this assignment. Refer to Lab 3 for a primer on setting up a Git repository for an Android project. (Specifically about setting up an appropriate.gitignore
(^3) https://www.getpostman.com
file.)
- Use the CS GitLab host (git.cs.dal.ca) for your remote repository.
- Ensure that the remote repository is private, allowing access only to the course instructor and TAs.
- Add commits at logical points in your assignment. Think of a Git commit as a checkpoint when you completed a working subset of your applications logic/design.
- You may use whichever CLI or GUI clients for Git you prefer, such as the built-in VCS tools in Android Studio, or a dedicated GUI client such as SourceTree, GitUp, or GitKraken. (A free Pro account for the latter is available with the GitHub student pack.^6 )
4 What to Hand In
Submit a ZIP file via Brightspace^7 containing the Android Studio project directory (including all source code files) for your assignment.
Include a copy of the final APK (Android PacKage) file in the root of the project archive, so that the marker has something with which to test your submission if even he or she in unable to build the project for some reason. You will find this file (after building your app) under app/build/outputs/apk/debug.
Also include aREADMEfile in the root of the archive, to describe any additional functionality that you have included, and note any known bugs or issues. These notes will help ensure that the marker is aware of and knows how to test your extra features, and may be able to work-around bugs, where the remaining functionality is still operational.
IMPORTANT:Please clean your project directory before creating the ZIP file, to reduce the size of your upload. You can usegradlew clean(or./gradlew clean, on Unix/Mac) from a command shell, or use the following steps in Android Studio:
- Click on Gradle pane, by default found in the top-right corner of Android Studio.
- Expand the root element, and the top entry inside (this one labelled(root)), Tasks, other, then double-click on clean to execute the operation.
- When the task completes (check status in the Run tab), immediately close Android Studio.
5 Academic Integrity
Dalhousie academic integrity policy applies to all submissions in this course. You are expected to submit your own work. Please refer to and understand the academic integrity policy, available at: https://www.dal.ca/academicintegrity
In particular, if you use an Algorithm or base your code on an example found online (for example, on Stack Overflow), always include a link to your source in a comment and/or in your README file, andrewritethe code in your own fashion. A good practice is to read and understand the
(^6) https://education.github.com/pack (^7) https://dal.brightspace.com
example, make a few (general) notes if necessary, thenclosethe window with the source code and write your own solution, based on your understanding. Doing these two things should protect you from questions about the integrity of your work.
6 Grading
The assignment will be graded using the rubric given in Table 1.
Exceptional: A Acceptable: B Substandard: C-D Unacceptable: F
Functionality
(40%)
Application meets
all functional
requirements. Ap-
plication does not
crash. Application
has significant and
useful additional
functionality.
Application meets
all functional
requirements. Ap-
plication crashes
rarely or not at all.
Application meets
some but not all
functional require-
ments. Application
crash often.
Application does not
work.
Usability
(20%)
screen layout, in-
tuitive, consistent
interface, etc.
The application is in-
tuitive and easy to
use. The screen
structure and lay-
out are well orga-
nized and most use
cases have been an-
ticipated. The inter-
face is consistent.
The interface is con-
sistent. Most com-
mon use cases have
been anticipated.
Some common use
cases have been an-
ticipated and the
screen layout in-
cludes all controls
necessary for the
application. The
application is usable.
The interface is dis-
organized and does
not correspond to
the applications
function. The ap-
plication is not
usable.
Polish
(20%)
background,
icons, button im-
ages, transitions,
themes, special
effects, etc.
The application is
very polished and
engaging, with icons,
images and special
effects to engage the
user. The appli-
cation looks profes-
sional.
The application is
somewhat polished.
Examples where pol-
ish has been applied
are evident, e.g., im-
ages and icons. Ad-
ditional polish is nec-
essary before the ap-
plication can be re-
leased.
A minimal amount
of polish has been
applied. The ap-
plication uses stan-
dard buttons and
text fields. Ba-
sic polish such as
application icon are
present.
No application pol-
ish is evident.
Code
(20%)
organization, com-
menting, readabil-
ity, etc.
Code is very well or-
ganized, commented,
readable, and main-
tainable. Code looks
professional.
Code is compe-
tently organized,
commented and
understandable. Re-
quires minor tuning
to bring it up to
professional looking
code.
Code is poorly
organized, un-
commented, or
confusing. Requires
significant effort to
bring it up to pro-
fessional looking
code.
Code is unintelligi-
ble.
Table 1: Rubric for Assignment 2.