earthiverse / food Goto Github PK

• Update recipe, buggy delete photo code results in inconsistent photo
• Inconsistent style, "Add recipe" is a clickable text view whereas "add ingredient" is a button.
• If publish fails with a recipe with pictures, the recipe will cause the entire app to fail if you save it.

The default picture in picture taking activity shows notepad instead of photo.

Search for recipes:

• When searching for no user (left blank), app crashes
• When searching for a user that doesn't exist, app should say "No results found," but instead shows nothing.
• After selecting a recipe to view from search results, have an animation indicating the device is working.
• Search by username crashes with no internet connection.

Fixed:

• Fix title on Search Recipe page (multiple pages have this issue actually).

Chris' reorganization moved all the files around, be careful when merging in to main branch.

If you have unsynced commits not yet on main, you might consider checking out another branch based off of main, and copy and paste your changes to the new branch.

The current storyboard doesn't show how to edit a recipe, please update. 🐹

Remove the old photo in the following cases:

• When the photo is changed (remove the old one)
• When you remove an ingredient
• When you remove a photo

There might be other cases...

Finish preliminary UI design (with comments). Assemble a storyboard.

Create a couple of new pages in the wiki for the following items:

Glossary

Initial entries for our definitions of public and local.

Information Sources

Mobile mockups from https://www.fluidui.com/
Use Case Specifications from http://www.agilemodeling.com/artifacts/systemUseCase.htm

Wouldn't it make more sense to compile the ingredients needed for the entire recipe from the ingredients needed in each step, instead of having a list of them at the beginning of the recipe creation?

Alright, so we have this problem currently of storing and retrieving pictures.

@solinas10:

1. Can we save the picture to a file in our working directory, instead of the gallery? I don't want issues arising from users deleting photos in the gallery. Alternatively, we can save them in two places.

A couple things we need to look in to / consider / implement.

1. Imgur has an API for saving pictures! We should take advantage of this. http://api.imgur.com/#anonapi
2. Cached recipes will contain local URIs for pictures. Getters and setters need to be updated. Recipes on the server will have URLs instead, with getters for downloading the pictures.
3. Database will need a function that takes a recipe ID, downloads the recipe and pictures, and saves the pictures locally, changes the URLs to URIs in the recipe and saves it to the cache.

Here's how I've setup the cache to be updated.

Cache cache = new Cache();
cache.load();
// now apply any update operations using getters and setters
cache.save(); // save if you want any changes to persist

This allows us to avoid using a singleton, and also avoid using unnecessary bundles / intent extras.

Note: we will still have to use intents in any activity that requires data from the parent acivity.

Please don't ask to comment inside a git commit description ( @gongal ), haha.
Ask the question on here, or comment on your commit on github afterwards.

@Shahrzad-Rafatnia
Can you please update the wiki with the document you showed us during our meeting?

From what I recall...

@solinas10 and/or @earthiverse
The login is no longer included in the storyboard, as we can extract the user email for use as a username. Also, the storyboard needs to be expanded upon.

@Gnarlywhale
Please update the UML diagram to address our lack of "MVC".
Ignore the arrows in this diagram (figure out what they're supposed to be), but here's what I did for the assignment: https://dl.dropbox.com/u/431832/temp/UML.zip

The View Ingredients List branch has been pushed but there is a bug I have yet to identify, resulting in no ingredients being listed 🐙. I believe the error is probably coming from the custom adapter (FoodListAdapter.java). For reference, I followed this guide rather closely:
http://www.framentos.com/en/android-tutorial/2012/07/16/listview-in-android-using-custom-listadapter-and-viewcache/

We need a new way to save our cache. Not sure if reading the cache is affected.

The UML has been pushed in the "UML" branch and the wiki has been updated, please review for accuracy/validity.
I am also unsure as what is meant in the submission requirements by "Include notes on the use of design patterns among the classes," since our code really only reflects basic OOP concepts (no singletons or any other majour design pattern that I'm aware of). If anyone has a suggestion, please feel free to give it to me, otherwise I'm going to try to ask the prof about it tomorrow.

In order to pass around Recipe and Ingredient things, I think we need to have them implementing Parcelable.

@solinas10 , how did you do this in your assignment? I passed indexes of the database, and had the new activities load it... Not the best approach...

I have a potential solution:
Implement Parcelable on the cache, and have recipes and ingredients and other things have IDs that identify them.
So when you click on a list of items, you add the cache parcel to the bundle along with an ID. Then the activity you open will assume the ID will correspond to a recipe if it's a recipe viewer, an ingredient if it's an ingredient viewer, and so forth....

Which means cache will also need getRecipeByID and a getIngredientByID functions.

see: http://developer.android.com/reference/android/os/Parcelable.html

Step 1

Finish Use Cases
UC1,2,3,4,6 - @gongal
UC5,7,8,11 - @earthiverse
UC9,10,12 - @Gnarlywhale and @solinas10

Step 2

Re-organize use case for hierarchy (What use cases are per-requisites for others? What use cases should be grouped together?)
Consider renaming them in to groups, too. (i.e. 1.1 - sign up, 1.2 - login, 2.1 - create recipe, 2.2 - edit recipe, 2.3 - share recipe, etc...)

Step 3

Re-visit UML diagram, see if anything is missed. See also if anything is included that doesn't have a place in the overall plan.

Somehow, have a link in the email, such that if you have an android phone, and you click on the application, it will open up in our application and view the recipe.

Regardless, the share via email should output the recipe without pictures so anyone using plain-text email, on any platform, can get a satisfactory experience.