petervanhoef / graphing-calculator Goto Github PK

Add a new button to your calculator’s user-interface which segues to your new MVC and graphs what is in the CalculatorBrain at the time the button was touched using the memory location M as the independent variable. For example, if the CalculatorBrain contains sin(M), you’d draw a sine wave. Subsequent input to the Calculator must have no effect on what the graphing MVC is showing (until the graphing button is touched again). Ignore user attempts to graph if the result in the CalculatorBrain is pending (e.g. there is a pending binary operation) at the time.

Rename the ViewController class you’ve been working on in Assignments 1 and 2 to be CalculatorViewController.

When your application first launches, have it show the last graph it was showing (rather than coming up blank). You could reset the Calculator MVC upon relaunch to the last state it was in as well (which may or may not be the same thing as what the graph was showing). Be careful not to violate MVC in your solution, though (each MVC its its own independent world). The simplest persistence mechanism in iOS is UserDefaults, but only Property Lists can be put there, so you will have to figure out how to get the function you are graphing into a Property List-compatible form. Because of that, you are allowed use the Swift types Any or AnyObject to implement this Extra Credit item.

You cannot add any new public API to your CalculatorBrain as part of this assignment and you still cannot use the Swift types Any or AnyObject anywhere in your solution (except as part of a solution to Extra Credit 6).

As part of your implementation of this new MVC, you are also required to write a generic, reusable x vs. y graphing subclass of UIView.

Create an entirely new MVC which graphs an arbitrary x vs. y function. It can have any public API you want (with the caveats below). Choose your Model carefully.

The graphing view must not own (i.e. store) the data it is graphing, even temporarily. It must ask for the data as it needs it, point by point. Your graphing view graphs an x vs. y function, it does not graph an array of points, so don’t pass it an array of points.

For example, when I draw tan(M), there is a straight vertical line at (x = π/2). Have you noticed that?

On iPad and in landscape on iPhone 6+ and 7+ devices, the graph must be (or be able to be) on screen at the same time as your existing Calculator’s user-interface (i.e. in a split view). On other iPhones the graph should “push” onto the screen via a navigation controller.

Anytime a graph is on screen, a description of what it is being drawn should also be shown on screen somewhere sensible, e.g., if sin(M) is what is being graphed, then the string “sin(M)” should be on screen somewhere.

Your graphing view must support the following three gestures:

1. Pinching (zooms the entire graph, including the axes, in or out on the graph)
2. Panning (moves the entire graph, including the axes, to follow the touch around)
3. Double-tapping (moves the origin of the graph to the point of the double tap)

You must begin this assignment with your Assignment 2 code, not with any in-class demo code that has been posted. Learning to create new MVCs and segues requires experiencing it, not copy/pasting it or editing an existing storyboard that already has segues in it.

Have your graphing button in your main Calculator scene reflect whether or not it is currently possible to graph what has been entered so far (i.e. whether there is a pending result or not). You could just disable it, but maybe a different graphic or something? This is a very easy task, so don’t expect a lot of extra credit for it!

Your new graphing MVC must be a completely generic, reusable component. It cannot have any mention whatsoever of anything Calculator-related in any part of its implementation (not in its Model, not in its Controller and not in its View).

Use the information you found above to improve panning performance. Do NOT turn your code into a mess to do this. Your solution should be simple and elegant. There is a strong temptation when optimizing to sacrifice readability or to violate MVC boundaries, but you are NOT allowed to do that for this Extra Credit!

Preserve origin and scale between launchings of the application. Where should this be done to best respect MVC, do you think? There’s no “right answer” to this one. It’s subtle.

Add screen shots to README.md

Your graphing view must be @IBDesignable and its scale must be @IBInspectable. The graphing view’s axes should appear in the storyboard at the inspected scale.

Figure out how to use Instruments to analyze the performance of panning and pinching in your graphing view. What makes dragging the graph around so sluggish? Explain in comments in your code what you found and what you might do about it.

Upon rotation (or any bounds change), maintain the origin of your graph with respect to the center of your graphing view rather than with respect to the upper left corner.