Our app is made for teachers and professors to randomly select students for participation in class and keep track of their performance. Users will be able to create and maintain multiple classes so that they can use this app to evaluate student participation in all of their classes.
For this project, we use Google's Kotlin style guide found here.
In order to build this project, you first have to install:
To setup our app for testing or further development:
- First, clone this repository into the directory where Android Studio stores its projects (e.g. ~/StudioProjects).
- Next, add a file called local.properties into the root directory of this project.
- Finally, in local.properties, add the line
sdk.dir=/path/to/Android/sdk(replace this path with the actual path to your Android SDK). - NOTE: Android Studio may automatically generate the local.properties file. If this is the case, nothing else needs to be done after cloning the project.
To emulate this app on an existing Android Virtual Device (AVD), simply open the project in Android Studio and select the "Run 'app'" button in the top tool bar (the play button). If you do not have an AVD created, follow the instructions here.
To deploy this app, a signed APK must be generated so that the app can be distributed through a store like Google Play Store. Follow the instructions here to sign the release APK.
For debugging purposes, a debug APK can be generated easily. With Android Studio open, go to
Build > Build App Bundle(s) / APK(s) > Build APK(s).
Either a release APK or debug APK can be tested on emulators and Android phones. To test an APK on an emulator, simply open an AVD on Android Studio and drag-and-drop the APK into the AVD screen. To test it on an Android phone, access the APK file from an Android phone (by transferring it through any means of file-sharing) and download the APK file onto the phone. To install the APK file as an app, follow the instructions here.
There are two types of tests within the codebase: behavior (UI) tests and unit tests. To run all tests, use the command
gradlew test connectedAndroidTest.
Behavior tests test the UI of the app by loading an Activity, performing actions, and checking for specific
on-screen reactions. Because they require the Android framework APIs to run, behavior tests are typically slower than unit tests.
Our classes of behavior tests are kept in USCoders/app/src/androidTest/java/cscecapstone/uscoders/spotlight with names that match *Tests.kt.
To run these behavior tests, use the command gradlew connectedAndroidTest (./gradlew connectedAndroidTest if on MacOS or Linux). If the build succeeds, all tests have passed. If
the build fails, there will be a print out of which tests failed and an html link to view further details. The tests can also be run by
navigating to a test class in Android Studio and selecting the play button beside the class (to run all tests in the class) or beside a specific test.
Unit tests test the correctness of small sections of code which typically do not rely on the Android framework APIs to run. Thus they run much
faster. Our classes of unit tests are kept in USCoders/app/src/test/java/cscecapstone/uscoders/spotlight with names that match *Tests.kt.
To run these unit tests, use the command gradlew test (./gradlew test if on MacOS or Linux). If the build succeeds, all tests have passed. If
the build fails, there will be a print out of which tests failed and an html link to view further details The tests can also be run by
navigating to a test class in Android Studio and selecting the play button beside the class (to run all tests in the class) or beside a specific test.
William Edwards (wwe1@email.sc.edu)
Dylan Johnson (dbj3@email.sc.edu)
Harvey Villanueva (harveycv@email.sc.edu)
Jack Hyatt (jahyatt@email.sc.edu)
Chance Storey (bcstorey@email.sc.edu)