I am trying to create an application that lets user(s) create or update an org chart. Specifically any node can be extended in any direction. I am new to UI development and so am stuck as to which view to use. Is a UIScrollView sufficient for this? The functionalities I want to code in are -
Able to scroll in any direction.
Able to zoom in and zoom out to see different levels of the chart.
Able to save the position and zoom level that user is in so that I can start there the next time the app is opened (of course this is not as important).
It did not look like core-plot would give me this option. May be I am wrong.
Yes UIScrollView has methods to handle these functionalities and you can save your zoom level and scroll position in NSUserDefaults so you can access data later.
https://developer.apple.com/reference/uikit/uiscrollview
I'd like to create a graph with a lot of custom content and add information to this as the time elapses while the app runs.
The graph I have in mind will look similar to this:
The pink horizontal bar gets drawn as the time elapses.. as with the black value curve. The yellow vertical bar is linked to a specific event and I'd like to be able to draw more than one. Once the pink bar reaches the letter t then the first part of the graph will be overridden (<---- this is the direction of the overriding animation).
Any suggestion on how I can get this started? Any decent tutorial?
I'd like to do this in a custom UIView.
Any idea on which framework I should use in iOS? Is there a good tutorial for this?
I can advice to use CorePlot library.
It's flexible well-documented library that supports different kind of graphs.
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.
Is the twitter profile view in iOS just ONE very dynamic table view? What's in the header and what's in the cells? I've just started developing for iOS and I'm trying to look at the big players and identify what they use and how they use it.
I've made a similar view, but it's a view comprised of carefully placed subviews, and I'm wondering if something like this would be a better route.
If it is a UITableView, how do they have such dynamic cells with different spacing between them etc? I know you can vary cell sizes, layouts, and insets, but to this degree, in one tableview?
Please don't jump me with downvotes for asking a non-technical question only twitter devs know for sure, I'm just really curious and don't know where else to ask. I'm only looking for a professional opinion.
It looks like it could be a very dynamic UITableView to me. Or at least, it could probably be recreated as a UITableView if it isn't already.
I'm looking at a twitter profile page now, and I would say there's probably 5 sections:
Header (everything from the profile picture to the "follow" button)
Recent Tweets (including the "view more" button)
Photos
"Special" items (Following, Followers, Favorites and Lists)
Who to Follow
The only component of this view that strikes me as particularly unique and special is the banner image that blurs and zooms when you pull down too far. I'm not quite sure how they pulled that off. It's possible that they track the offset of the scroll view, and if the offset is positive (i.e. it was pulled down), then zoom and blur the banner (and use the offset value as a scaling factor somehow).
All the other components could be probably be recreated by (carefully) designing custom UITableViewCells for each unique purpose (e.g. tweets, image carousel, other profiles), and then populating those cells with data from the tweet or profile.
I'm new to iOS development pondering how best to approach a fairly simple design problem. I want to display a set of items, each one of which has the structure as sketched. In a given set, not more than 10's of items.
Each item includes a thumbnail image, a heading, a blurb, and a set of buttons. There are two complications:
The amount of text and number of buttons is variable.
The text requires some internal formatting (italics and bold).
I've considered these approaches:
Use a table view, with custom, resizable UITableViewCell, probably using something like OHAttributedLabel for the text. For the variable number of buttons, either lay these out programmatically or possibly use the new collection view (for older iOS, have to use 3rd party grid view).
Use a table view with custom cell based on UIWebView.
Do the whole set as one UIWebView.
Use a table view with sections; each item having its own section and parsing out the buttons and text to rows.
Would love to get suggestions about how a more experienced iOS dev would approach this.
EDIT: I am now considering that the best way may be:
5) Use UICollectionView for the whole thing.
UPDATE: In the end, I laid the whole thing out in code as a custom table cell (ie., #1). This was a good choice, not only for the reasons given in the answer, but because as someone new to iOS development, it's something I needed to get under my belt. Didn't even use collection view for the buttons, because I was worried about performance and also the hassle of supporting iOS5.
I do think that using collection view for the whole design (#5) would have been an elegant solution, and I actually started down that path. However, some complications not shown in the simplified pic above made that unwieldy.
2nd UPDATE: #1 turned out to be a dead end. My final solution used a UIWebView (#3) - see answer.
I have found some resources that might be useful to some people who is doing complex tableviewcell and want fast scrolling. I am still developing it, but I want to share this first to you guys.
Facebook iOS release note: they mentioned techniques: core text, pre/asynchronous calculation of table height, do a lot of things on background thread, save layout attribute in core data. http://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920
Fast scrolling sample: https://github.com/adamalex/fast-scrolling
Apple's sample project TableViewSuite. The 4th example.
https://developer.apple.com/library/ios/#samplecode/TableViewSuite/Introduction/Intro.html
Very close to solution..YES
I know this is an old thread, but I found it very interesting, as I am just now getting around enough as an iPhone developer to reach these types of performance concerns. I found a very interesting article on Facebook's site by Facebook Engineering describing how they implemented UITableView and overcame the dynamic sizing issues, also with rapid content management. It seems they precalculated using deeper objects and kept everything asynchronous and pre-cached where possible. I'm going to provide a link to the article, but I'm going to copy the section that tackles exactly this problem. I hope you find it useful. Here's the link, https://www.facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920, and the most relevant excerpt:
(Re-)Building for Speed
One of the biggest advantages we've gained from building on native iOS has been the ability to make the app fast. Now, when you scroll through your news feed on the new Facebook for iOS, you'll notice that it feels much faster than before. One way we have achieved this is by re-balancing where we perform certain tasks. For example, in iOS, the main thread drives the UI and handles touch events, so the more work we do on the main thread, the slower the app feels. Instead, we take care to perform computationally expensive tasks in the background. This means all our networking activity, JSON parsing, NSManagedObject creation, and saving to disk never touches the main thread.
To give another example, we use Core Text to lay out many of our strings, but layout calculations can quickly become a bottleneck. With our new iOS app, when we download new content, we asynchronously calculate the sizes for all these strings, cache our CTFramesetters (which can be expensive to create), and then use all these calculations later when we present the story into our UITableView.
Finally, when you start Facebook for iOS, you want to see your news feed, not a loading spinner. To provide the best experience possible, we now show previously-cached content immediately. But this introduces a new problem: If you have a lot of stories in your news feed, UITableView throws a small spanner in the works by calling the delegate method -tableView:heightForRowAtIndexPath: for each story in your news feed in order to work out how tall to make its scrollbar. This would result in the app loading all the story data from disk and calculating the entire story layout solely to return the height of the story, meaning startup would get progressively slower as you accumulate more stories.
The solution to this particular problem has two main parts. Firstly, when we do our initial asynchronous layout calculations, we also store the height of the story in Core Data. In doing so, we completely avoid layout calculation in -tableView:heightForRowAtIndexPath:. Secondly, we've split up our "story" model object. We only fetch the story heights (and a few other things) from disk on startup. Later, we fetch the rest of the story data, and any more layout calculations we have to do are all performed asynchronously.
All this and more leads to high frame rates while scrolling and an app that remains responsive.
I originally accepted (and implemented) #Daij-Djan's answer, but now I believe the best approach is #3 (UIWebView). It comes down to performance.
UITableView strains to perform well with custom cells with subviews, especially in the context of cells with varying heights. The rows of buttons make the scrolling choppy. As suggested by Apple in Cells and Table View Performance , I made sure that subviews were all opaque, however there is no way to follow the suggestion of "Avoid relayout of content."
Add onto that dynamic cell heights and attributed strings and these tables scroll pretty poorly. I suppose the next optimization would be to override drawRect, but at that point I decided to try UIWebView.
UIWebView is not without its performance issues either! Its scrolling performance degrades pretty fast as the content grows, however, I can manage that by hiding content and letting user "open" it as desired.
no 1 is maybe the most work directly followed by #2 BUT
as ACB said, it's also the most flexible and IMO will surely provide the best look'n'feel
no 3 works but will not feel as smooth / alway be tad 'html-ish'
no 4 sounds like highway to hell (later on. it will be a PITA to modify/maintain)