We don't need this variable, but currently it's really integrated in the code.

So you don't need data at the grocery store to use this app.

Make it not do that.

Figure out how to do this incorporating screen size.

In detail:

For EditSinglePropertyViewController, make it a UIViewController that implements UITableViewDelegate and UITableViewDataSource with a nested TableView for the results instead of what it is currently (UITableViewController).

For EditArrayOfPropertiesViewControllers, make it just a UIViewController.

Documentation here.

Requires figuring out OAuth and GET/POST requests and creating the IOUs tab (a must-do anyway).

Self explanatory. Lots of (careful!) copy paste.

Commit 7ca61ec introduced a problem where on first loading the first list item and half of the second are below the top navbar. After swiping to pantry and back, the issue goes away.

Includes adding price as a property for Item class.

The error is on Line 82 of InventoryTableViewController.swift, the line in question is a part of the method below

80    override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
81        // The number of rows is equal to the number of items.
82        return itemListPantryInstance.dict[type]![groupIDs[section]]!.count
83    }

Extension of Issue #20. Probably goes in the settings menu. Maybe get from Google profile picture.

List views do not support scrolling.

Suspected cause: clearing empty rows? or maybe deleting multiple things at once.

Make sure you record who it was that paid.

So that balances get reverted and items get pushed back. Consider using "last X" items to remember which were used as opposed to using an actual array. Make this undoable using a toast or similar, that disappears after you take another action or after a certain amount of time.

Make user settings editing generalizable over multiple settings.

Maybe don't worry about this yet.

It might be swiping too often, but I don't really believe this to be the case. It is probably caused by going between the two view controllers too fast.

Probably a best practice.

Where did this debt come from? Why do they owe me money? Because you went shopping in Group X.

Use Firebase to integrate creating user accounts and syncing databases with the cloud.

Right now we're doing the hacky method of calling self.present on another navigation controller containing the view controller we want to present. There must be a way to present normally and remove the tab bar on the bottom (probably present modally).

Currently we are leaving reference in each user to the groups they are in.

Float is apparently not the most graceful way to handle money. Investigate NSDecimalNumber, but be wary of read/write issues when using NSCoding which according to some people plays nice but other people doesn't.

Current solution is to clear the entire members tree before saving which seems excessive and unnecessary.

It's not large enough, and sometimes it runs over the dollar sign and so forth. Figure this out.

You can see the sign in window if you swipe all the way to the left or right in the list tab, which is evidence of the fact that it isn't completely removed from the view.

Quick fixes would be to configure the look of the controller depending on whether the user is signed in or not (if the user is signed in, hide the button and labels and change the background to whatever color we want the background to be -- probably white). See Google's example

$ pod try Google
$ 2              # to try the sign-in example

for how to do this hiding; it relies on methods of GIDSignInUIDelegate if memory serves.

7ca61ec introduced an issue of the tab bar looking strange and not how it used to look (what is this black bar on the top?).

Implement "checkout" button which will take all checked items (if they are not blank) and add them to the other thing of items.

Leaving things checked in the other tab creates strange selection behavior when moving items into that inventory.