switchswap/usc-menu-kt

A USC Dining Hall Menu API for Kotlin!

USC-Menu-kt

A USC Dining Hall Menu API for Kotlin!

Wow, that's a lot to say!

Installation

Gradle

1. Add this to your root build.gradle at the end of repositories

allprojects {
    repositories {
        ...
        maven { url 'https://jitpack.io' }
    }
}

2. Add the dependency

dependencies {
    implementation 'com.github.switchswap:usc-menu-kt:v1.0.0'
}

Maven

1. Add the JitPack repository to your build file

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>

2. Add the dependency

<dependency>
    <groupId>com.github.switchswap</groupId>
    <artifactId>usc-menu-kt</artifactId>
    <version>v1.0.0</version>
</dependency>

Usage

// Create API object
val dining = Dining()

// Generate a date object
val simpleDateFormat = SimpleDateFormat("MM/dd/yyyy", Locale.getDefault())
val dateString = "02/21/2020"
var date: Date = simpleDateFormat.parse(dateString)

// Pass into function
var diningMenu = dining.getDiningMenu(date) // Return full dining hall menu object

// Print all breakfast items at Parkside dining hall for the given date
for (menuItem in diningMenu.parkside.breakfast) {
    // MenuItems are stored as a HashMap with name as the key and the object as the value
    // This is for fast lookups of items
    println(menuItem.value.itemName) // Here we reference the name from object instead of just using the key
}

usc-menu-kt's Issues

Date model concerns

The HallMenu class contains a Date parameter but the overarching DiningMenu class already has one and the MenuItem class doesn't.

If the idea here is that a HallMenu can be used independently from a DiningMenu, then it should probably have some way of identifying which hall it is.

Also, instead of a different variable for breakfast, brunch, etc., why not just have a List or HashMap of these parameters in case iteration is needed.
The .breakfast/brunch/etc. attribute can still be achieved with functions that wrap around the underlying data type.

Each item knows it's type anyways, so even if all the types were mixed in a worst-case, underlying functions for this class could still achieve clean functionality.

I would extend this idea to the DiningMenu model as well with a HashMap of each HallMenu mapped by it's DiningHallType enum.