Skip to content

Assessment Lab Plan

Plan by Dates

Laboratory Plan Assignment Due Date
1
  • Discuss requirements.
  • Set up development environment.
  • Join the MS Teams class (announcements and questions only).
  • Accept the organization invitation, then accept the Project Idea assignment to get your repository.
 Project Idea
  • From a potential client's point of view, present the requirements for a mobile app.
  • Submit all details as a README.md in your assignment repository on GitHub.

Grading rubric Accept assignment on GitHub


Sunday, end of week 3
2
  • Evaluate previous assignment.
  • Clarify next requirements.
 CRUD Project - UI only (Native)
  • Each CRUD operation has its own screen.
  • Demo all CRUD operations with fake/in-memory data.
  • Use Android (Java/Kotlin) or iOS (Swift/Objective-C) to build the application.

Grading rubric Accept assignment on GitHub


Sunday, end of week 6
3
  • Evaluate previous assignment.
  • Clarify next requirements.
 CRUD Project - UI only (Non-Native)
  • Each CRUD operation has its own screen.
  • Demo all CRUD operations with fake/in-memory data.
  • Use Flutter, React-Native, NativeScript, or another multi-platform framework.
  • Unity framework is not allowed.

Grading rubric Accept assignment on GitHub


Sunday, end of week 9
4
  • Evaluate previous assignment.
  • Clarify next requirements.
 CRUD Project - With local DB
  • Convert one UI-only project to use a local DB.
  • CRUD operations should interact with a local database.
  • Demo all CRUD operations using a local DB engine (no cloud services allowed).

Grading rubric Accept assignment on GitHub


Sunday, end of week 12
5
  • Evaluate previous assignment.
  • Clarify next requirements.
6
  • Evaluate previous assignment.
  • Clarify next requirements.
 CRUD Project - With Server Integration
  • Implement server support for the DB project.
  • CRUD operations should send/receive data from a remote server, falling back to local DB if offline.
  • Demo all CRUD operations using your own REST server (no cloud services allowed).

Grading rubric Accept assignment on GitHub


Sunday, end of week 13
7
  • Evaluate previous assignment.
  • Clarify/Discuss exam requirements/rules.
  • You need to attend your faculty assigned subgroup laboratory!
  • You are allowed to present only two requirements!

Assignments & Grading Rubrics

Every assignment is described and graded here. Read the rubric before you start, not after you submit. Click an assignment to expand it.

Project Idea 6 criteria, weighted

What to do

  • From a potential client's point of view, present the requirements for a mobile app.
  • Write the details for a client who does not have a technical background.

How to submit

Submit all details as a README.md in your assignment repository on GitHub, with the mockup images committed next to it.

How it is graded

  1. A short description. Note that the client does not have a technical background. 17%

    Excellent 3 points More than 3 sentences.
    Good 2 points Less than 3 sentences.
    Poor 0 points Missing details.

  2. Domain details. Present the details of the entities that will be persisted. Each field should have a description. 17%

    Excellent 3 points The entity has at least 5 fields.
    Good 2 points The entity has at least 3 fields.
    Poor 0 points Missing details.

  3. CRUD. Present the details of each CRUD operation: create, read, update, delete. 17%

    Excellent 3 points In the context of the specified entity, for each CRUD operation, the details are presented.
    Good 2 points Minimal details are presented or the details are too generic.
    Poor 0 points Missing details.

  4. Persistence details: which CRUD operations are persisted on the local DB and on the server. 17%

    Excellent 3 points At least 3 operations are persisted on the server and the local DB.
    Good 2 points At least one operation is persisted on the server and local DB.
    Poor 0 points Missing details.

  5. Details on what is happening when the device is offline. 16%

    Excellent 3 points One separate scenario for offline access for each CRUD operation.
    Good 2 points Generic details or missing scenarios.
    Poor 0 points Missing details.

  6. App mockup, e.g. using figma.com, sketch.com or something equivalent. 16%

    Excellent 3 points At least 2 screen captures are submitted: the list and the add/edit screen.
    Good 2 points At least one screenshot is submitted.
    Poor 0 points Missing details.
UI only - Native 5 criteria, weighted

What to do

  • Implement the user interface in either Android (Java/Kotlin) or iOS (Swift/Objective-C).
  • Each CRUD operation has its own screen. Demo all CRUD operations with fake/in-memory data.

How to submit

Push the complete source code to your assignment repository on GitHub before the deadline. Only sources, no build directories. The last push before the deadline is graded.

How it is graded

  1. Read operation is implemented in a list 20%

    Excellent 4 points A recycler view is used, linked to a view model using a live data object. Or the activity/fragment is marshaling only the affected object/operation. No rebuild of the list/adapter or activity/fragment.
    Good 3 points The activity/fragment is reused but the list/recycler view/adapter is recreated on each operation.
    Fair 2 points The activity/fragment is recreated on each operation.
    Poor 0 points Not implemented or not working, or the information is not presented in a list.

  2. Create operation 20%

    Excellent 4 points Only the created element is added in the list. The create operation is maintained in a separate activity/fragment. All the main fields are available to be set. The create view/form has labels for each input field. If we have validation errors the errors are handled in this view.
    Good 3 points The add operation is implemented in a dialog or as part of the list activity. Or some fields are missing from the create form. Or some field labels are not visible.
    Fair 2 points A subset of the element fields were used.
    Poor 0 points Not implemented or not working.

  3. Update operation 20%

    Excellent 4 points Only the updated element is passed back to the list. The element is properly identified. The update operation is maintained in a separate activity/fragment. All the main fields are available to be updated. The update view/form has labels for each input field and the existing values are pre-populated. If we have validation errors the errors are handled in this view.
    Good 3 points The update operation is implemented in a dialog or as part of the list activity. Or some fields are missing from the update form. Or some field labels are not visible. Not all the field values are pre-populated. The update button label still says 'add'.
    Fair 2 points A subset of the element fields were used. The field values are not pre-populated. The old entry is still in the list.
    Poor 0 points Not implemented or not working.

  4. Delete operation 20%

    Excellent 4 points Only the id of the removed element is passed back to the list. The element is properly identified. A confirmation dialog is used.
    Good 3 points No confirmation window. The object is properly identified and removed from the list/adapter.
    Fair 2 points The element is still part of the list.
    Poor 0 points Not implemented or not working.

  5. GitHub 20%

    Excellent 4 points The code is in the assignment repository. Only the sources were added, no build directory.
    Good 3 points The code is in the repository but build output or generated files were committed as well.
    Fair 2 points The code was presented but not yet pushed to the assignment repository.
    Poor 0 points The code was not pushed to GitHub.
UI only - Non-Native 5 criteria, weighted

What to do

  • Implement the user interface using a non-native framework: Flutter, React Native, NativeScript, or another multi-platform framework. Unity is not allowed.
  • Each CRUD operation has its own screen. Demo all CRUD operations with fake/in-memory data.

How to submit

Push the complete source code to your assignment repository on GitHub before the deadline. Only sources, no build directories. The last push before the deadline is graded.

How it is graded

  1. Read operation is implemented in a list 20%

    Excellent 4 points A list view is used, linked to a view model/repository class/component. The component is marshaling only the affected object/operation. No rebuild of the list/adapter or component.
    Good 3 points The component is reused but the list/adapter is recreated on each operation.
    Fair 2 points The component is recreated on each operation.
    Poor 0 points Not implemented or not working, or the information is not presented in a list.

  2. Create operation 20%

    Excellent 4 points Only the created element is added in the list. The create operation is maintained in a separate component. All the main fields are available to be set. The create view/form has labels for each input field. If we have validation errors the errors are handled in this view.
    Good 3 points The add operation is implemented in a dialog or as part of the list component. Or some fields are missing from the create form. Or some field labels are not visible.
    Fair 2 points A subset of the element fields were used.
    Poor 0 points Not implemented or not working.

  3. Update operation 20%

    Excellent 4 points Only the updated element is passed back to the list. The element is properly identified. The update operation is maintained in a separate component. All the main fields are available to be updated. The update view/form has labels for each input field and the existing values are pre-populated. If we have validation errors the errors are handled in this view.
    Good 3 points The update operation is implemented in a dialog or as part of the list component. Or some fields are missing from the update form. Or some field labels are not visible. Not all the field values are pre-populated. The update button label still says 'add'.
    Fair 2 points A subset of the element fields were used. The field values are not pre-populated. The old entry is still in the list.
    Poor 0 points Not implemented or not working.

  4. Delete operation 20%

    Excellent 4 points Only the id of the removed element is passed back to the list. The element is properly identified. A confirmation dialog is used.
    Good 3 points No confirmation window. The object is properly identified and removed from the list/adapter.
    Fair 2 points The element is still part of the list.
    Poor 0 points Not implemented or not working.

  5. GitHub 20%

    Excellent 4 points The code is in the assignment repository. Only the sources were added, no build directory.
    Good 3 points The code is in the repository but build output or generated files were committed as well.
    Fair 2 points The code was presented but not yet pushed to the assignment repository.
    Poor 0 points The code was not pushed to GitHub.
Local DB 5 criteria, weighted

What to do

  • Convert one of the previous UI-only projects, at your choice, to use a local database.
  • CRUD operations should interact with the local database. Demo all CRUD operations using a local DB engine. No cloud services allowed.

How to submit

Push the complete source code to your assignment repository on GitHub before the deadline. Only sources, no build directories. The last push before the deadline is graded.

How it is graded

  1. Read operation is implemented in a list 20%

    Excellent 4 points All the values are retrieved only once and reused while the application is alive. A separate repository is used. The values are retrieved in a separate thread/coroutine. An observer/live data mechanism is used to listen for changes. If we have retrieve errors the messages are handled in this view, presented to the user and logged.
    Good 3 points Stale data is presented. No error handling.
    Fair 2 points The values are retrieved multiple times, on each operation or component refresh.
    Poor 0 points Not implemented or not working, or the information is not presented in a list.

  2. Create operation 20%

    Excellent 4 points Only the created element is added in the DB. The id is managed by the DB/app. The user is not aware of the internal id. If we have persistence errors the messages are handled in this view, presented to the user and logged.
    Good 3 points The errors are not handled or not displayed in the create component. No error handling.
    Fair 2 points A subset of the element fields were used. The new element is present on the UI but not in the DB.
    Poor 0 points Not implemented or not working.

  3. Update operation 20%

    Excellent 4 points The DB element is reused, e.g. the element is not deleted and then a new one added. The id remains the same. If we have persistence errors the messages are handled in this view, presented to the user and logged.
    Good 3 points The errors are not handled or not displayed in the update component. Some of the previous field values are lost. No error handling.
    Fair 2 points A subset of the element fields were used. The updated element is present on the UI but the DB still has the old values.
    Poor 0 points Not implemented or not working.

  4. Delete operation 20%

    Excellent 4 points Only the id of the removed element is used to delete. The element is properly identified. If we have persistence errors the messages are logged and presented to the user.
    Good 3 points The object is properly identified and removed from the list/adapter. No error handling.
    Fair 2 points The element is still part of the DB.
    Poor 0 points Not implemented or not working.

  5. GitHub 20%

    Excellent 4 points The code is in the assignment repository. Only the sources were added, no build directory.
    Good 3 points The code is in the repository but build output or generated files were committed as well.
    Fair 2 points The code was presented but not yet pushed to the assignment repository.
    Poor 0 points The code was not pushed to GitHub.
Server Integration 9 criteria, weighted

What to do

  • Iterate on the database project to add server support. Implement your own REST server. No cloud services allowed.
  • CRUD operations send and receive data from the remote server, falling back to the local DB when offline.

How to submit

Push the complete source code to your assignment repository on GitHub before the deadline. Only sources, no build directories. The last push before the deadline is graded.

How it is graded

  1. Read operation 20%

    Excellent 4 points All the values are retrieved only once and reused while the application is alive. A separate repository is used. A websocket is used to listen for server changes.
    Good 3 points Stale data is presented. Missing offline support for at least two operations.
    Fair 2 points The values are retrieved multiple times, on each operation or component refresh. The list is not available offline.
    Poor 0 points Not implemented or not working, or the information is not presented in a list.

  2. Create operation 20%

    Excellent 4 points Only the created element is sent to the server. The id is managed by the server. The user is not aware of the internal id.
    Good 3 points The errors are not handled or not displayed in the create component. If created offline, the values are not properly marshaled back to the server.
    Fair 2 points A subset of the element fields were used. The new element is present on the UI or the local DB but not on the server.
    Poor 0 points Not implemented or not working.

  3. Update operation 20%

    Excellent 4 points The server element is reused, e.g. the element is not deleted and then a new one added. The id remains the same.
    Good 3 points The errors are not handled or not displayed in the update component. Some of the previous field values are lost.
    Fair 2 points A subset of the element fields were used. The updated element is present on the UI but the DB still has the old values.
    Poor 0 points Not implemented or not working.

  4. Delete operation 20%

    Excellent 4 points Only the id of the removed element is sent to the server. The element is properly identified. If we have persistence/network errors the messages are logged and presented to the user.
    Good 3 points The object is properly identified and removed from the list/adapter/server. The element is still part of the local DB or UI.
    Fair 2 points The element is still part of the server.
    Poor 0 points Not implemented or not working.

  5. Separate thread/coroutine 4%

    Excellent 4 points All server operations are handled in a separate thread/coroutine.
    Good 3 points Some operations are handled in the main thread.
    Fair 2 points All the operations are on the main thread.
    Poor 0 points Not implemented or not working.

  6. Error/validation messages 4%

    Excellent 4 points Errors are presented to the user in a friendly manner. No raw messages are shown.
    Good 3 points For some operations the validation/errors are not handled properly.
    Fair 2 points The server/framework errors are presented as is.
    Poor 0 points Not implemented or not working.

  7. Client debug logs 4%

    Excellent 4 points All client operations have debug logs.
    Good 3 points Some operations are missing the debug log.
    Fair 2 points No operations have debug logs.
    Poor 0 points Not implemented or not working.

  8. Server logs 4%

    Excellent 4 points All server operations have debug logs.
    Good 3 points Some operations are missing the debug log.
    Fair 2 points No operations have debug logs.
    Poor 0 points Not implemented or not working.

  9. GitHub 4%

    Excellent 4 points The code is in the assignment repository. Only the sources were added, no build directory.
    Good 3 points The code is in the repository but build output or generated files were committed as well.
    Fair 2 points The code was presented but not yet pushed to the assignment repository.
    Poor 0 points The code was not pushed to GitHub.

Notes

  • Deadlines are final! All groups share the same deadlines.
  • Every deadline is a Sunday at 23:59 Romanian time, at the end of the teaching week shown in the table. The assignment is evaluated in the lab of the following week.
  • A 25% penalty applies per calendar week for late submissions. For example, for the deadline:
    • - Last push by , 23:59 for full credit.
    • - After : 25% penalty.
    • - After : 50% penalty.
    • - After : 75% penalty.
    • - After : 100% penalty (0 points).
  • To receive a grade, present results to the lab instructor. Push the sources to the assignment repository created for you in the course organization (the one you get from the "Accept assignment" link), but simply pushing is not enough.
  • Work in your own personal repository, public or private, is not graded, even if you add the instructor as a collaborator. Only the assignment repository in the course organization counts.
  • The demo must run on a physical mobile device or a mobile emulator/simulator (Android Emulator, iOS Simulator). A web build, a browser preview, a design tool such as Figma, or screenshots are not accepted as a demo.
  • Your work must be pushed to your assignment repository on GitHub before the deadline. The time GitHub receives the push is what counts, not the commit timestamp. The last push before the deadline is the version that gets graded. Work in other repositories, zip files, or links sent by chat is not graded.
  • Learn to use Git and GitHub from your IDE (e.g., Android Studio, Xcode, Visual Studio Code).
  • The application must support CRUD operations on business objects. The main screen should list these objects and allow:
    • Create - Add new elements.
    • Read - Display elements in a list.
    • Update - Edit existing elements.
    • Delete - Remove elements.
  • The application should persist content locally for offline access, and synchronize with a remote server when online (server must be implemented by you; no server-less solutions allowed). Use REST for communication.
    • On update/delete while offline: persist the operation offline (should survive restarts). Once the server is back online apply the changes to the server and on device.
    • On read while offline: display local data with a note that the server is down.
    • On create while offline: save input locally and sync with the server when back online.

📢 Bonus Points

Earn up to 3 extra points for your final practical exam!

  • +2 Extra Points (Early Completion): Successfully present ALL lab assignments (Project Idea, UI-Native, UI-NonNative, DB, and Server) before , the Sunday two weeks before the winter break.
  • +1 Additional Extra Point (Advanced Feature): Implement one or more significant "extra features" in your final server-integrated project.
    Same deadline as above. This point depends on the +2: it is awarded only if you have already earned the Early Completion bonus.
    See the list of suggested features here.

Final Grade

  • Laboratory Grade (LG) = Project Idea (2p) + UI-Only-Native (2p) + UI-Only-NonNative (2p) + DB (2p) + Server (2p).
  • Exam Grade (EG) - the grade from the practical exam.
  • Final Grade (FG) = (LG >= 4.5 && EG >= 5) ? (LG * 0.6 + EG * 0.4) : 0.
  • To take the practical exam, you must have at least 90% attendance in labs.
  • If LG < 4.5 or attendance criteria are not met, you can only attend the practical exam in the re-examination session.