GitXplorerGitXplorer
C

ios-cleanse-1

public
0 stars
0 forks
0 issues

Commits

List of commits on branch develop.
Unverified
483ecde8bf4c83fbdd61373d787cd4bd2d1c9d43

Got rid of the duplicates that were showing. Now to add viewing the details.

EEDKarlsson committed 8 years ago
Unverified
cd1e46188ced8795ed899bd4af5314111f27ef69

Ugh was an issue with how I was counting the sections... wasn't including a section for the original recipe set.

EEDKarlsson committed 8 years ago
Unverified
b4daeb83b18724f77262f3f8e6ac9579fe463ecc

Downloads the recipes but isn't adding them to the recipe list to be viewed..FML

EEDKarlsson committed 8 years ago
Unverified
c162d48248d43a8776dc577bffe4032b7f2d7449

Downloads the images now, there was something wrong with the way I was constructing the URL while downloading the recipe JSON. The purchases page shows the recipes and rounded image. Next is to implement when they purchase the recipe they can view it under the recipes tab and add it to their meal plan.

EEDKarlsson committed 8 years ago
Unverified
94a85705023ec9479f34622b6af7e358ed7adcd1

I have it downloading the recipes, the images aren't being downloaded however. Need to figure out why the URLs are weird.

EEDKarlsson committed 8 years ago
Unverified
fa8991ba619357bc787573f465db049ebff65558

Still working on the purchases, should have them done today.

EEDKarlsson committed 8 years ago

README

The README file for this repository.

Just changing something stupid....

Stories in Ready Build Status ##Nano Nimbus (Cleanse App) ##An iOS Mobile Application for helping people out complete body cleanses.

###Git flow and branching scheme

  1. Always branch from develop.
  2. Branch naming scheme is defined as such:
  3. Include a '#' followed by the issue number in every commit.
    • For example, commits to this branch will look like this: [#1] Added stuff to readme.
  4. Never work on a branch without an associated issue. If you don't see the issue on waffle, create one.
  5. Always push a branch immediately after creating it. This is to correctly update issues on waffle, and also to let other teammates know what you're working on.
  6. Pull-requests must be reviewed by all members of the team before they are approved for merge.
  7. Delete the feature branch once a pull-request is merged.

###A mini command-line git tutorial (for our purposes for this project) 0. Clone the repo. - git clone https://github.com/home-run/subtle-cosmic-moose.git - cd subtle-cosmic-moose

  1. Switch to branch develop.
    • git checkout develop
  2. Make sure to do a git pull before branching, so you always have up-to-date code.
  3. Create/switch to your branch. (This one command does both.)
    • git checkout -b 66-a-brief-description
  4. Push the newly created branch.
    • git push -u origin 66-a-brief-description
  5. Start coding!
  6. Add your changes to the staging area to prepare for a commit.
    • git add my_new_file.cpp for files that don't exist on the repo yet.
    • git add -u for files that already exist on the repo that have been updated.
    • You can use the command git status to view the staging area at any time.
  7. Make a commit. Make sure to include '#' followed by your issue number somewhere in the commit message.
    • git commit -m "[#66] Mashed keys until it compiled. Don't bother testing it. It's fine, I swear."
  8. Push your changes.
    • If you used the command in step 4, this is simply git push (The -u flag sets the upstream so you don't have to explicitly set it for every push).
    • Otherwise, the command is git push origin 66-a-brief-description
  9. Drink more coffee. ☕

###A Brief Doxygen Style Guide note: ALL code must be doxygen commented. If your code isn't commented, it will not be approved for merge.

In QT, typing /** + return above a declaration will produce a doxygen comment block.

Full commenting manual can be found here.

Things to note about Doxygen comments

  • Comments can come before the code item.
  • For class members and parameters they may also come after them.
  • They may be either brief (one line) or detailed or both.
  • Put the reference documentation type comments (class and method descriptions) in the .h file and not in (or, at least, in addition to) the .cpp files.

Brief comment before

Add an extra "/"

/// This method does something
void DoSomething();

Detailed comment before

Add an extra "*"

/** This is a method that does so
  * much that I must write an epic 
  * novel just to describe how much
  * it truly does. */
void DoNothing();
  • the intermediate leading "*"s are optional.

Brief comment after

Add an extra "/<"

void DoSomething(); ///< This method does something

Detailed comment after

Add an extra "*<"

void DoNothing(); /**< This is a method that does so
  * much that I must write an epic 
  * novel just to describe how much
  * it truly does. */
  • the intermediate leading "*"s are optional.

Example .h file

Below is a full example.

/**
 * \class ExampleClass
 *
 * \brief Provide an example
 *
 * This class is meant as an example.  It is not useful by itself
 * rather its usefulness is only a function of how much it helps
 * the reader.  It is in a sense defined by the person who reads it
 * and otherwise does not exist in any real form. 
 *
 * \note Attempts at zen rarely work.
 *
 * \author (last to touch it) $Author: bv $
 *
 * \version $Revision: 1.5 $
 *
 * \date $Date: 2005/04/14 14:16:20 $
 *
 * Contact: bv@bnl.gov
 *
 * Created on: Wed Apr 13 18:39:37 2005
 *
 * $Id: doxygen-howto.html,v 1.5 2005/04/14 14:16:20 bv Exp $
 *
 */

#ifndef EXAMPLECLASS_H
#define EXAMPLECLASS_H

class ExampleClass
{

public:

    /// Create an ExampleClass
    ExampleClass();

    /// Create an ExampleClass with lot's of intial values
    ExampleClass(int a, float b);

    ~ExampleClass();

    /// This method does something
    void DoSomething();

    /** This is a method that does so
      * much that I must write an epic 
      * novel just to describe how much
      * it truly does. */
    void DoNothing();

    /** \brief A useful method.
      * \param level an integer setting how useful to be
      * \return Output that is extra useful
      * 
      * This method does unbelievably useful things.  
      * And returns exceptionally useful results.
      * Use it everyday with good health.
      */
    void* VeryUsefulMethod(bool level);

private:

    const char* fQuestion; ///< the question
    int fAnswer;           ///< the answer 

};                              // end of class ExampleClass

#endif  // EXAMPLECLASS_H

###Unit Tests

  • All team members are responsible for writing unit tests for their own code.
  • Simply add the unit test to its appropriate section in test_main.cpp. Note: This currently isn't working properly. Still you should try to add unit tests as you code.

###General Style Guide

  • For this project we will be following, loosely, Google's C++ Style Guide. Have a quick read through of some of the sections. This is where we will refer to if there are disagreements about style.