I am working on a bowling scoring app and am having a tough time figuring out what UI classes and controls to use for the paradigm I want. Here's the ideal:
I want to draw on an ipad (in landscape) a bowling scoresheet exactly like the oldstyle paper you see in a bowling alley with the 11 boxes for each scorer. I want to be able to input scores by touch the boxes etc, be able to print an old school bowling scoresheet (with the lines etc) at the end, and have the app essentially be what I call "hot paper". I want a full scoring sheet for 5 bowlers for example inside appropriate scroll controls so an olde phart using it can pinch or swipe to move around the paper to input scores.
This is targeted at olde pharts exclusively and they want it to act like paper. While I have written simple apps with TableViews and the like, I am not sure whether to use a Collection, Grid, or what, and what is the right way to draw so that I can send the completed "paper" scoresheet to a printer.
I am looking for some iOS genius who can recommend simply what classes I should be using for the elements - for example each row of the score sheet etc. Also shwhat elements should I use storyboards for and what should I do programmatically? I am quite storyboard challenged and usually do everything programmatically - I amgreat with making things work but awful on making them pretty.
I assume you want something like this:
Personally, I would draw/construct it entirely in code, as it so straightforwardly geometrical and repetitive. Just think of it as a hierarchy of views, each of which is itself a class that knows how to draw/construct itself. For example, MyFrameView is the box for one frame, which might or might not be the tenth frame. Then MyPlayerRowView simply gives itself ten MyFrameViews horizontally, and MySheetView gives itself five MyPlayerRowViews vertically. And presto, just three self-drawing classes so far and yet we've constructed almost the entire grid.
The only question is the underlying interactive interface. How should information be entered? What is the user to be allowed to do? That is a problem for you to solve. For example, should a MyFrameView just contain a UITextField? Or do you want the user to tap it and have some sort of "enter score" interface pop up? Those are the sorts of things you'll have to think about; in the latter case, you'll use a gesture recognizer to detect the tap and respond accordingly.
Related
In an iOS app written with Objective C, when Voice Over is on, The cancel button on the top-left and the save button on the top-right, those two buttons are in the same top bar on the view, now the order is cancel->save->other views on the page. But I need to actually traverse and edit all other elements before I can save, so I need to set the traverse order as cancel ->all other view->save button.
I saw some solutions that create new views to group elements or reorder accessibilityElementOrders. But I am just changing one button, is there an easy way like android:accessibilityTraversalAfter in Objective C?
It is rarely a good idea to modify the order of elements on the screen, especially in iOS. VoiceOver is used by people of many different abilities, including partially-sighted people, who would be confused about why the order doesn’t match the display. And even those who are completely blind will expect to interact with your app in the way other apps work. It’s a very common pattern to have buttons at the top when you can skip the action, but at the bottom if you have to do something with the content first. As much as possible, you should follow those conventions so users won’t be surprised at how your app behaves (a bigger issue for users of AX tools, since recovering can be much more challenging).
The way VO works is by creating a parallel object hierarchy and traversing that using a few simple rules like geometric order. So no, if you insist on modifying the order of the buttons, you will have to modify that hierarchy which means something like modifying accessibilityElements.
This values get from web servies. Totally i want to show 4 layer to display[i show here only 2 layer]. some times in web servies values are come more means the layer become big and show the values.same and anther 3 layers are displayed. help me..!
Use UIScrollView or Freeform make it independent means don't use static value make it dynamic whatever number of layers you are getting from server and according to that adjust content size of UIScrollView.
First of all. This view (and design) doesn't really follow any iOS consistency. The Apple human interface guidelines are there to help you with finding the correct way to do something.
Right...
Do you need to show all the options at the same time? i.e. do you need all four "layers" on the screen at the same time? If so, why? What is the user supposed to do with this screen?
Is the user selecting one option from each layer? Multiple options from each layer? etc...
With either of these I would go down the route of using a navigation controller with a single UITableViewController to display each layer.
So, the user gets a nice list of options...
dumbell
E-Zbar
cable
barbel
...
And selects one (or many) of them.
Then the second "layer" is pushed onto the navigation stack and the user gets another nice list...
incline
decline
close-grip
rotating
...
This way the user has to only concentrate on one task and each list is deployed nicely and readably for them.
If I was a user and was presented with a big list of buttons like your design I wouldn't know what I was supposed to do.
I am using core plot to draw line chart which is showing weekly details of user.
Now what I want is, to swipe next week of graph like scroll view paging functionality (we can also see it on iPhone home screen)
Please refer below image for more details.
Please share any solution or any logic to implement above task.
You can implement this by placing your graph view inside UIScrollView and allowing horizontal scroll. You also may want to enable UIScrollView's pagination feature to achieve "iPhone home screen"-like effect that you're describing.
This part is pretty straightforward, but you may find this StackOverflow answer useful.
However, your performance may suffer if your graph doesn't have reasonable horizontal bounds — i.e if width of your graph is too big to render at one time. You need to test this specifically with your set of data.
If this is indeed the case, one solution is to create separate "reusable" graph views for each week (like reusable UITableViewCells) and render them on-the-fly when user scrolls to the left or to the right. In other words, only render current, next & previous weeks' graphs and update this each time the user flips the page.
P.S. This doesn't relate to your question directly, but you may also want to take a look at JBChartView by Jawbone. I prefer JBChartView over Core Plot because it's really well-written library for creating graphs that you can dig into and customise however you want (unlike from Core Plot which is basically "a black box").
Using UICollectionView and excellent help given on here on StackOverflow, I've been able to build a "Gantt Chart" style control for my iPhone:
Cosmetics aside (I'm doing the functional right now, I've got a graphics designer on tap to look at colors and all that).
Background aside, the spans were relatively straightforward to do with a custom UICollectionViewLayout subclass. Each span is an item.
But I need to add some functionality, and am unsure how to proceed. Where I'm trying to go is illustrated roughly as:
Sketchy cosmetics aside, the point is that I want to "annotate" whatever the currently selected span is with additional information (I promise to find someone to help me look it pretty). And I want them to be active, I'm not sure if it brings up an editing control or does drag, but I want to be able recognize gestures on either the numbers or the bold lines and do things with them, distinct from touching on the span which drives selection.
I can think of (at least) 3 ways to try and implement this:
Use supplementary views. Cause selection to invalidateLayout, detect the selected state in my prepareLayout, and generate additional layout attributes for the two anchors. Implement a subclass of UICollectionReusableView which does the drawing, and adds touchable subviews (or its own gesture recognizers). This feels... wrong. I get the idea that supplementary views are more for headers and footers, not for controls that come and go as the selection state changes. But maybe it's an appropriate extension of the facility?
Use the backgroundView (or selectedBackgroundView, not sure it matters) of my current SpanCell class (which is a subclass of UICollectionViewCell). As long as I disable clipsToBounds, I can draw the annotation around the bounds of the span. I'll have to give it some knowledge of the big picture to find the endpoints, but that's not too offensive. I would just show/hide this view in response to selection changes. This seems like the best way to do it.
Do it in the main backgroundView of the entire UICollectionView. As shown, I've already got a specialized backgroundView which shows the the current time grid, strip style. I could further extend this view to draw annotations and manage touchable sub controls in response to selection changes. This would give me most direct implementation, but it feels like I'll end up with a big monster "doing too many jobs" object for the background.
Question then, for those who have more experience, is which route would you go? Would it be one of the above 3? Or something different? And why?
While your question is very technical with UICollectionView implementation, which I am not very familiar with, this seems like a job for the container (in this case, the collection view). Imagine you need your annotation to consider, in addition to the selected item, other items? Like for example, avoiding collision between annotation lines and another item?
For me, option number 3 seems like the most correct one. If you fear a large class, you can extern it to an annotation controller class, which should be notified whenever the annotations should be updated.
I have an app where I want to have one “background” view (view controller view), and on top of that, multiple UIViews that draw themselves as circles. I just don't understand how to implement all of this while still adhering to MVC...
The model and the view should be different. Does this mean that I generally need one set of header and implementation files for the view and another (separate) set for the model — even if my object is just a Circle class? Or, would I have one Circle.h and Circle.m set, and then inside the header file have two interface blocks, one for the model and one for the view, and two implementation blocks (again, one for the model and one for the view)?
I’ve seen a few people recommend using the view controller to handle all of the views in loadView, and to avoid creating separate custom view objects; does this mean that I shouldn’t create a separate set of .h and .m files for the view? The latter seems a lot more organized in terms of design to me.
Also, if I were to have multiple view objects and multiple model objects handled by the view controller, I would store these in two arrays in the controller — one for models, and another for views. Right? My question is: When I use key-value observing on each model, how would I, for each model object, alter the correct corresponding view object (assuming that indexes are not the same for both objects in both arrays)?
I was thinking about using a pointer to the model object inside of the view, and KVOing from the view to the model — but then it doesn’t go through the controller and thus breaks MVC altogether, right?
Thank you in advance.
MVC is a big, broad idea. It's more a guiding philosophy than a specific rule, and it's not always implemented the same way. Read Apple's discussion of MVC to appreciate the difference between traditional MVC and MVC in Cocoa.
It's hard to say how to apply MVC to your app because you haven't told us what the app should do, and also it doesn't sound like a realistic application. So I'll do my best here and make some assumptions along the way. An app that just draws a bunch of circles in fixed locations on a background isn't very interesting -- it could be almost all views, barely any need for a controller at all. So lets say that the circles are all moving in different directions, are drawn in different colors, and change in size over time. Now you start to have a need for a model, so that you can keep track of the data that these circles represent, and a controller to translate the model into terms that can be represented by the views.
Since you asked specifically about drawing circles, lets start with the view. It seems like a good idea to have a custom view that knows how to draw a circle given the necessary parameters: area, color, and position. You'd probably make these things properties, and override -drawRect: such that it draws a circle of the given area in the given color.
We don't know what these circles represent, but it's not much fun if they don't represent something, so let's postulate that the app's job is to help us compare corporations. We have data on revenue, market capitalization, number of employees, credit rating, name, ticker, etc. You could create a custom object to store all the data for each corporation, or you could put it all in a dictionary. Our model is a set of these custom objects or dictionaries.
Notice that the circle views don't know anything about corporations, and the model doesn't know anything about circles. This is A Good Thing. It's also where the controller comes in. The controller is where you put the code that expresses the model visually using the views. It also interprets events from the views, updating the model as necessary. So, our controller knows both about the particulars of the corporations, and the properties of the circle view. It creates a circle view for each corporation in the model. I want the area of a circle to correspond to the corporation's market cap, the vertical position to represent the revenue, and the horizontal position to indicate number of employees. We'll assign a color based on the corporation's credit rating. The controller should, of course, keep track of all the circle views and some way to map between circle views and corporations.
Now you've got something. It's still a pretty simple application, but you've got a useful chart comparing corporations in several dimensions. Let's improve it.
First, it's hard to know which circle represents which corporation. It would be nice if a circle view could optionally display some text. Let's add title and subtitle properties, and modify -drawRect: to draw these strings above and below the circle, respectively. We'll also change the controller so that a tap or click on a circle sets the title and subtitle of that circle to it's corporation's name and ticker symbol, or clears them if they were previously set.
Second, it's nice to compare corporations at a moment in time, but more interesting if we can show changes over time. Let's change the model to include historical data for revenue, market cap, employees, and rating. We can update the controller so that it can uses the historical data to animate the circles.
The first change related to how we draw information on the screen, and didn't require any modification to the model at all. The second change was about what data we have to work with, and didn't require any change to the view at all. You could easily re-use the circle view to represent some other kind of data, or maybe even to be the puck in an air hockey game. It's just a colored circle. And you could re-use the model in another app that deals with the same kind of data.
I'm sure the hypothetical application in this very long-winded explanation-by-example bears roughly zero resemblance to your own application, but perhaps it'll help to explain why MVC is useful and inform the structure of your own application. Good luck.
I got good explanation from CS193P IPHONE APPLICATION DEVELOPMENT (Winter 2013).
Model-View-controller:
Divide all objects into three camps:
Model : What your application is (A Card , A Deck , card game logic)
Controller : How your model is presented to user (UI Logic). Controller knows everything about the UI.
View : Your controller's minions.
How those camp communicate :
Don't cross yellow line.
You can cross over Dashed white line.
some special rules are there for crossing solid white line.
Controller --> View (via Outlet)
View --> Controller (via Data source (count, dataAt), delegate(will, should, did), Target-action)
Model --> Contoller (via Notification & Key Value Observing)