I have a section in my app where I would like to display static content that is divided in short chapters (mostly text and some figures), for example a manual. The questions is: what's the best way to do this?
I was thinking of a static TableViewController containing my chapters, which on click lead to a ViewController containing the actual content. However, having a segue for each of the TableView cells to my ViewController seems wrong. Also, what is the best way to embed the static content in my ViewController? The content consists (depending on the selected chapter) of text and figures, taken from a PDF.
You are describing a totally standard vanilla boring everyday 5-cent master-detail interface.
The thing that's wrong with your drawing is the use of multiple segues. You only need one segue — one that looks at which row was tapped and loads the data corresponding to that row into the view controller that is then instantiated and pushed onto the navigation controller.
If you create a new iPhone app from the Master-Detail template in Xcode, you'll see a standard setup for doing this sort of thing.
As to the question of static vs. dynamic, personally I'd recommend a normal code-based table data source for this. Your data may be static, but most table data is, ultimately; that doesn't mean you'd want to use a static table. The key is simply to store your data in a format that can be loaded at launch time and parsed quickly into a data structure that is precisely adapted to the way the data is to be displayed and related.
Related
I am building an app which mainly shows a tableview. In this tableview I have some custom table rows. The table rows are filled with data received from the server. I receive multiple kinds of data from the server. I will store it in arrays.
For example, I've got three kinds of arrays. Each is filled with different kinds of data received from the server. See below:
(NSArray*)carList_
(NSArray*)motorcycleList_
(NSArray*)bicycleList_
The actual program that I've got now, only shows the carList in the tableview. Foreach car in carList, there is a table row.
The thing that I've in mind to do is a little bit tricky. I want to add a tabbar at the bottom of the screen with three buttons. When I press the first button, I want the table to be filled with the carList. When I press the second button, I want to fill the table with the motorcycleList. And when I press the third button, I want to fill the table with the bicycleList.
As you can see, I will use the same tableview. I will only refill it with the data I want to see. Is this allowed in iOS? Cause I read something about that the tabbar is for multiple views, and I only want to use it for changing the data in my table. Only the fourth button I've planned for future development will open a new view. If it is not allowed, what is a good alternative do do it? Buttons maybe? I searched the web for what I want to do, but it seems that my idea has never been used before, I think my idea is not allowed in iOS.
At this moment I've a initialViewController (with almost no code cause it is used only to initialize some things of the server. It acts like a splash screen) and I've got a rootViewController which does the works. In the rootViewController I've got my Table with Table rows and it has the different arrays of data which are retrieved by a method that is called when the rootViewController is loaded.
I am programming without Storyboards, because I'd like coding and I want to understand how it works 'underground'. What is a good way to implement the tabbar if it is allowed what I want to do with it? I don't think a standard tab controller will work, because I am working with only one view.
Of course you can use the UITabBar solution. However this might be not very useful and this is not the idea behind the UITabBar. You can instantiate the same TableViewController vor each tab. In this case you can use the same class but you have up to the instances of this class when the user cycles through the tabs. This will be obvisously a waste of memory.
Your descriptions sounds like a UIToolBar with a UISegmetenControl in it might fit your needs better. You can also place it at the bottom of the screen and you will need just one TableViewController for your data.
UISegmentedControl is designed for switching between different data representations. It is also commonly used for switching between table datasources. But it often appears at the top of a view. Take a look at Top Charts tab of App Store app.
Tab bar is designed to present different views for each tab. Here are progress steps to achieve your result:
Use different instances of table view controller for each tab
Configure each instance for displaying one particular array, depending on tab position
Keep arrays in external (outside table view controller) storage, instances should have an access to it
It's better to preload data, while user is examining an active tab. Hence, load data outside of table view controllers, possibly in AppDelegate. Use notifications to update table view when data are available.
I'm making a sample app to learn iOS dev, and I have the app create default items to populate the tableview originally, and you can add further ones as well.
If I tap on the default ones (well, there's only one) and segue to the detail view it shows all the details (Name, Location and Date) as intended. But if I add a new one, it comes up with those fields being Empty.
I can't figure out why. I have seemingly all the view refreshing methods set, and it should be setting the detail view's data object which then feeds the labels.
Could anyone help? I'd supply further code if requested, I just don't know what to supply now as I'm not sure exactly where the problem is. It's a rather simple app, though.
Project available here: http://cl.ly/3N0o272M3y1K
Ok this took a bit longer than planned - but it is a good way to learn.
I have attached the project in a zip file.
The code is a bit different then what you posted, but if you compare them side by side, you will see how they are planned and build differently.
It shows the Segue working within the Storyboard.
There where 2 big problems with your project outside of your misuses of the methods.
You need something like Core Data if you want your data to be persistant. In the example I have given you I have used Plist, this will do the trick, but is not persistant in this case.
Also your detailViewController had no labels for the text to appear, so you will need to look into Custom Cells for that - to match your design.
Good Luck and I hope this is useful:-)
Updated Project
I want to have two tables and a webview in one iPad screen from the following:
The first table will parse items from an RSS feed, and will have an option for a
checkmark
The second table will be comprised of all checked items
The webview will be the content from didSelectRowAtIndexPath from the first table (so basically the first table gives the opportunity to display content from didSelectRow, AND check a box (or whatever) to create the secondary table.
I am told for the second table, I should have the checks write to a plist with NSMutableDictionary, and then the second table will just be a table of the plist...but really, what's the code for this?...where do I put it?...etc etc etc. And if the user unchecks the items, the line in the plist will be cleared, right???
I PRESUME I can show all three classes in one screen with something like
[viewController.view addSubview:someOtherViewControler.view];
Is there any reason why I should not do this??
Thanks so much!
XOXO
There is no reason you shouldn't do this, and you will be happier with your proposed approach than you would be if you tried to do it all with one view controller.
Organizing with design patterns is done to simplify design and maintenance of your software. What you have described is clearly three independent data sources each with their own independent views. You can use the MVC design pattern independently on each one of them. This independence lends itself to having separate view controllers that are easy to design and maintain.
The fact that they are collected into one main view for your application is outweighed by the simplification in maintainability that you will obtain with separate view controllers.
I am currently working on an iPad application that uses a table view to present data, I was inspired by the iTunes application in iPad that present it's data in multiple columns in a very nice and neat manner, and the most interesting thing is that during the portrait mode the itunes application displays data in 2 columns but when the user switches to landscape mode, it switches the display to 3 columns (since there are plenty of space to display data horizontally).
This is what i'm talking about:
but i found out that iOS SDK only supports single column for tableview (it would be nice to utilize the entire space provided on iPad screen to present data), i did some research and i found out that the best way to present data in multiple columns yet like spreadsheet style is to use datagridview instead, but iOS SDK did not provide any data grid view controls for iOS developers.
I found out over the internet some customized tables like:
AQGridView.
DTGridView.
and also the one from this:
http://usxue.is-programmer.com/posts/14176.html
and the one from this:
http://xebee.xebia.in/2011/04/14/building-editable-gridview-for-iphone-apps/
But sadly none of these ever met the requirements of the application i was working on.
Could you guys provide me some ideas or share some sample codes or links on how to display data in somehow-data grid view, to achieve similar effect used in iTunes application (as shown above).. Any form of help would be pretty much appreciated. Thank you guys!
The summary answer is, place multiple data "views" across in a single cell.
The more detailed answer:
Create custom views that represent the single cells you want. You can for this purpose make them resizable enough to work two across or three across (they will get loaded into 1/2 or 1/3 of the cells bounds).
Then make a custom UITableView cell, that can take two or three data items - load up an instance of the custom view previously created in the cell for each data item you have, placing them next to each other. You can have the cell do the view layout when groups of data items are added.
In the cellForRow code in the table delegate/datasource, you use your data source in groups of two or three (and report the row count accordingly) to pass along to the custom cell.
Sorry I can't share code, but I have used this technique before in other applications.
What's wrong with creating a UIView class to represent a single cell, and another that lays out an array of those cells in a grid? Put your grid view in a UIScrollView and you're about done.
UITableView is obviously a pretty complex class. Much of that is to make it very general, very reusable, and able to support a huge number of rows. Your class doesn't necessarily need to be that complicated -- if you have a fairly small number of cells, your "grid" could really just be a UIView in which you lay out cells in rows and columns. UITableView removes cells that aren't seen in order to save memory; you might need to do something similar if you have hundreds of cells, especially if they're large, but a few dozen probably won't require that.
In short, since you need a grid view for a particular use, you don't need to do all the extra work that would be required for a general, reusable solution.
I'm building an app that has views that are build programmatically. That is, I am fetching data from a database that contains information on things like the number, size and placement of buttons in a view. At some point, there will be code that uses this data to instantiate new subviews and set them up. My question is, where should this code go? The view, the viewController, or somewhere else. It seems to me that this is a grey area regarding typical MVC principles. Should a view accept data, and then know how to draw itself using this data? Or perhaps, a viewController is responsible for building all the various subviews, and then simply adding them to the view.
Thoughts? Thanks.
I agree that it's a gray area. Personally, I make a decision like that based on whether it's the data that needs manipulated or the display of that data. For example, a view controller displaying a date may need to process various dates (ie, a data represented as a DMY struct vs. a date represented as a seconds count from some reference time) into a format suitable for the view, while the view itself may be only capable of receiving one particular format (ie, DMY) and is responsible for displaying that. That's the sort of line I tend to draw between the two -- displaying data (the view) vs. interpreting data (the controller).
In your example of reconfiguring a view I would probably put most of the logic into the controller since it involves interpreting the data. I would design the view to accept configuration details such as how many items to display and what sort of layout format to use (think of a UITableViewCell), but I would design the controller to interpret the data to decide how many items and what to put in the various fields within the view (like a UITableViewController).