I'm pretty new with app development and am experimenting with a master-detail app using Swift.
I have a master UITableview that I have successfully populated with an array of data (i.e. not static cells) and now I am ready to design the detail pages for each of the 100 or so items in the master tableview.
Each detail page will have its own unique combination of text and images, and in my mind there are two approaches I can take.
The first is to add a static view controller and segue for each item in the master tableview.
The second is to use a single detail page and change the content of that page depending on which item in the master tableview was selected.
Can anyone comment on these approaches and make any recommendations regarding which approach to take?
Are there any performance benefits/detriments of using one approach over the other? Would having multiple static detail pages make a significant difference to the overall size of the app?
There seems to be less thinking involved if I used multiple detail pages, but the single view controller approach would be much easier to manage and add to in the future.
Related
I am attempting to build an application in swift that is essentially a book and some pages of this book allow for user input that is stored in the application.
I am new to swift and am unsure of the best way to approach this problem. So far I have tried using a Page View Controller and separate View Controllers corresponding to each page. The Page View Controller class navigates through the pages using Storyboard IDs to instantiate the View Controllers in an array. This works in creating a navigable book but I run into issues when trying to create outlets from the text fields on some pages since essentially the View Controller is instantiated each time its accessed and so it does not permanently exist.
I am totally and utterly lost as to where I should go from here. Any advice/wisdom will be deeply appreciated.
Thank you
simplest Approach is Collection-view with pagingnation(self.collectionView.pagingEnabled = YES).
https://medium.com/#shaibalassiano/tutorial-horizontal-uicollectionview-with-paging-9421b479ee94
create multiple cell one for your Page(reading) and second for input field.
it also helps for memory management. because cell are reusable. and cell that are visible to Screen are only loaded in memory.
you can also Create Custom layout for animation as per your requirement.
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.
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 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.