I am new to Iphone programming. So please don't mind if I ask some basic questions. :mad:
I want to develop an application where the landing screen will be a login screen and after login application should display a new screen with the list of available categories. And on selecting any category a new screen should appear with the information related to the selected category.
Basically I want to display different screens in the applications and my confusion is how can I make different screens with one .xib file? or should I use different .xib files for each screen. If I use different .xib files for each screen then how should I navigate to different screens.
Please help in solving this confusion.
Thanks in advance
Gaurav
You should definitely use different .xib's for each view. You will end up having a standard view, a table view (probably programatically wrapped in a navigation controller) and a standard view, respectively. Each will also have their own class.
You navigate to different screens by programmatically initializing them. The condition on which they are created varies from screen to screen. For example, your login screen will only create and load a table view for the categories after a successful login. The category screen will only create a detail screen when the user touches a category in the table.
I think your best bet is to pick up an iPhone programming book and do the first few chapters until you feel comfortable with the basics of XCode. The Apple documentation usually contains more than you really need to know and by the sounds of it, you just want to jump in and make a few simple apps.
After that, you can look at the Apple sample code here: http://developer.apple.com/iphone/library/navigation/index.html#section=Resource%20Types&topic=Sample%20Code
Related
How would I go about making a simple iOS app that simply has to display "data sheets" (just text documents basically) in a way reminiscent of OS X's Finder's Column View?
I want the interface to present a list of Manufacturers. I select one and then a bunch of Models made by that Manufacturer come up. I select one and finally I'm presented with Years. I select a Year and then I am shown a list of all variants of that Model made in that Year. When I press one of these Models I'm shown a textual data sheet for that model.
I mean, I don't even know whether to start this as a Master-Detail Application (although that sort of looks like it might work), a Page-Based Application, a Single View Application or a Tabbed Application...
Thanks
Essentially, you will nee dto get in to UITableView.
It's fairly simple:
https://developer.apple.com/library/prerelease/ios/referencelibrary/GettingStarted/DevelopiOSAppsSwift/Lesson7.html
https://www.weheartswift.com/how-to-make-a-simple-table-view-with-ios-8-and-swift/
Be sure to work 100% using storyboard, and Swift. In answer to your final question simpy start it as a single view app.
Interestingly, once you get good one of the toughest and most expert-level skills in iOS is dynamic height cells in table views. Example of that.
I'm gonna create an app that supports both iPhone & iPad. Before proceeding, I just want to know the best practices about both app development.
Here is some points that I know:
Consider that I have a tableview that shows N number of records and say it as PAGE-1. When the user tapping on the cell, it will load the PAGE-2 to show details about the tapped record. This is more common scenario that used in every app.
For iPad, this is not the case. I can show PAGE-1 along with PAGE-2 in the same page.(Consider landscape mode)
So, iPhone's PAGE-1 will be displayed in the left panel of the iPad & iPhone's PAGE-2 will be displayed in the right side panel of the iPad.
Conclusion:
So, I can make a common class for both iPhone & iPad. That will handle the PAGE-1's common functionality to both iPhone & iPad.
The device specific functionality may separated into separate classes for both iPhone and iPad.
Other than that, network related methods, parsers, utility methods, categories, custom controllers can be written commonly for both iPhone & iPad.
The only addon to the iPad is, it should have a controller that will hold and handle PAGE-1 and PAGE-2. This make sures that the PAGE-1 does not hold PAGE-2 and they both are independent like iPhone's PAGE-1 & PAGE-2.
Refer the below attached image that will demonstrate clearly.
Questions:
Is this approach correct?
I really don't know about iPad's "Container" controller. Should I need it? Or is there any other better proposal to group the things effectively?
This may be a basic question, but I need a clarification for better code pratice.
Thanks
It doesn't sound like you need specific page 1 & 2 subclasses, though that depends on exactly what the differences are between the pages on each device. It may be that a collection view suits your needs better so you can simply set the item width and the layout will organise your content into columns where appropriate.
It sounds more like all you need is 2 different container classes for the top level which decides how to display page(s), or more specifically, how many pages to display and where they are on screen. For iPhone that's really simple, for iPad slightly more complex (mainly due to rotation handling).
Note also that if you create a new master-detail project in Xcode and ask it to support iPhone and iPad you will see that a split view controller is used, optionally, for exactly this situation. This bypasses the need for 2 container classes by having the app delegate decide whether to use a 'special' container or not (for iPad).
I am building an app where I need to add a TabBarController on a particular screen, Lets assume maybe on second or third screen.
I have gone through several blogs but everyone says UITabBarController can be added as an initial view controller only.
But I want it for some few screens only. How can I accomplish it?
Need guidance!
The answer is "you shouldn't."
From the Human Interface Guidelines:
"In general, use a tab bar to organize information at the app level. A tab bar is well suited for use in the main app view because it’s a good way to flatten your information hierarchy and provide access to several peer information categories or modes at one time.
Don’t use a tab bar to give users controls that act on elements in the current screen or app mode. If you need to provide controls, including a control that displays a modal view, use a toolbar instead (for usage guidelines, see Toolbar). "
New to iOS, I have to make an app that will show photos and videos.
Could be simple, but there's a little bonus.
The app will have to download configuration based on user. ( xml or json )
After downloading this configuration, it will have to download the elements to be shown.
The app will have to show , based on configuration file, views with buttons.
Each button can be used to show another view with buttons or a photo album, or a video, or a pdf.
I don't know where to start.
I tried to search on google but english not being my mother tongue, I think I don't have the right words to search on.
So any advice on how to structure that and how to make it possible ( nothing is impossible ).
I'm not asking for code, but for guidelines.
Regards
English isn't my mother tongue, but most valuable information in English. I would suggest to find informations in books, they are usually with downloadable examples. This can be useful for you.
Also you can try "ios recipes" in google.
Finally, my version of guideline:
Download configuration in applicationDidFinishLoad:withOptions:
Develop classes with view controllers + xib files, for each term(video, photoAlbum, etc.)
NavigationController or TabBarController to navigate between viewControllers. (There are too much examples with it. I like TabBarController, and "Each button can be used to show another view with buttons or a photo album, or a video, or a pdf." - this is too easy with tabBarController, tabs instead of buttons).
Something like that.
I was wondering what would be the best configuration of view controllers and views for an app that I’ve been planning out. Conceptually, the way I would like to lay out the app is with an initial loader/browser view, likely with document thumbnails. When a user chooses to open one, a new view comes up that forms the main document-editing mode. The user can also choose to bring up a third view that contains an alternative document-editing mode.
I suppose this is very much like the way the Pages for iPad works, with first a row of document thumbnails to choose from, then the main word processing view, and accessible from a popover a third page setup view. Document browser view, and two document editing views.
Now, I can think of, and have been playing around with a few different set-ups, but in each case I can see problems that I’ll be running into later. So really, I’m looking for advice on a configuration that you think would keep things as neat and manageable as possible.
I hope this is not too open a question, and I would very much appreciate any answer.
Thank you,
I will probibly get shot in the head for making a suggeston like this, but I'll make it anyway:
In learning iOS programming, I spent a lot of time studying (as most people do - and as is taught by every tutorial on the planet) on how to use Navigation Views, and toolbars, and all the standard type views that assist in different types of navigation.
On the latest app I have been working on - I spent a lot of time and frustration trying to figure out how to best characterize what I was doing - and moreso trying to fit it into what the iOS frameworks would use to implement this stuff. Then (of course) I got stuck trying get things to do what they weren't supposed to - like when a navigation view wouldn't let me use the "back" button to jump out of the navigation herirarchy I'd set-up, etc.
In short - when I stopped worrying about the specifics of what all these different types of views and controllers were - and how they interacted and how I was supposed to do it - and started worrying about how I wanted my application to work - and working from a basis of generic views, custom toolbars, etc - the whole think made a whole lot more sense.
In my case, I liked the look-and-feel of the Mapquest app - and they way it dealt with toolbars that your could open and close from the top and bottom of the screen - which had buttons - which could switch to other views etc. So I started using "generic" views to implement this functionality - and the whole entire thing clicked together.
So in-short:
1 . I'd decide how you want it to look and what you want it to do
Use a third-party app as your inspiration, if needed
Decide when/where/if some of the "standard" practices apply - and use them where/when they do.
Have fun!
-BKG