I've seen much of the apple documentation, many examples, and some github projects.
http://www.raywenderlich.com/16873/how-to-add-search-into-a-table-view
and
http://www.appcoda.com/search-bar-tutorial-ios7/
are ios 7 only.
https://developer.apple.com/library/ios/samplecode/TableSearch_UISearchController/Introduction/Intro.html
is confusing with a lot of unnecessary clutter complicating it.
http://www.raywenderlich.com/76519/add-table-view-search-swift is for swift only, but seems to be exactly what I need if it someone could translate it to objective c.
I don't get it at all.
If someone could just tell me step by step the differences, or maybe a simple breakdown, that would help.
It seemed to be a lot easier in ios 7, why did they change it?
Even when I drag a search bar controller in the storyboard editor, and link it to my header, the default property and name is uisearchdisplaycontroller which is deprecated.
I also have another question that can't easily be googled:
If I have a table view, it's easy to know what was selected.
But when I select or edit the search results,
how do I know what to do to the table view array, if the index paths will be different?
Related
I am currently developing a new iOS app which is basically a decision tree app. All the data comes from an XML file (list of questions and logic path depending on answers). The XML reading is not a problem.
I know I could develop this by hardcoding everything in the storyboard, but I don't find this efficient. Design-wise, I don't know where to start to sort of build the storyboard dynamically. What stops me is that, based on what the user answers, some paths have different number of levels (or questions); so different storyboard screens.
Any help would be much appreciated!
You may want to build your views "manually" from code.
I am new here and new to iOS, so my apologies in advance if my question is silly.
I have just finished a course on iOS and Xcode and learnt how to build the different types of apps, like master-detail, tabbed or single view applications.
My question is : Is it possible to build an app that would be for example a master-detail app but would look like a tabbed one on one of the views and would look like a page-based on another view? In other words is it possible to create an app that would be a mix of several types ? I have Googled everywhere but I can't find anything. I may be using the wrong key words as on the top of that, I am French. I am not looking for precise explanations, just if somebody could point me in the right direction where to look and continue studying.
Thanks in advance and have a nice day.
Well am not sure if this is exactly what you are looking for but you can take a look at this example. Its a combination of UISplitViewController & UITabBarController
Custom UISplitViewController for iPad
I'm trying to create a custom NSTextFieldCell for a NSTableView. I want to do something like the email listing provided by Mail (example below).
I found some references here and here, but I'm not able to evolve.
I think that it's not as simple as a multiline text. I think the cell should have predefined places, like the timestamp on the upper right corner, the attchment icon, etc... This "placeholders" should be always at the same place, regardless the text size. I'm thinking about embeeded objects.
Please, could you help me? An example or sample code is very welcome.
EDIT: I'm looking for a MAC OS X Lion (10.7.x) solution.
Based on Monolo comment, I googled view-based table view. I found this excellent tutorial and followed it and I succeeded.
I also found this OS X Developer Library document regarding view-based programming guide. Very good too.
Being a somewhat proficient iOS developer, I have just started working on a desktop OSX project in Cocoa and I'm running into issues that I just can't grasp. So this question is for the OSX developers out there.
I don't like the Interface Builder much, so I tend to write my views in code. The most prominent method I write my view layout code in is a view controller's loadView method, and at least on iOS I use autoresizingMasks for everything. Try out the view small, large, rotated landscape and portrait and if all is dandy, I continue with the next item on my list. Now on the desktop, the autoresizingMask works (or just looks) a little bit different. First of all the properties have different names, but their behavior also seems weird or unexpected.
When I ran into the issue below, I thought it must be my code was wrong, so after trying out long enough I re-created it with Interface Builder just for confirmation's sake, and guess what: I got the exact same result. Take a view with four vertically stacked subviews. Set the middle two to have flexible heights, the outer ones to be fixed. When you run it, size it down and back up again, I get two completely different layouts before and after the resize. See image:
Now I can follow why this happens from a mathematical standpoint between run loops, but from the point of an 'autosizing' or 'autoresizing' feature, this makes absolutely no sense.
Before I try to write the mother-of-all-resizing-topics here, might I ask you these questions? Feel free to elaborate some more on the resizing topic if you feel it adds to the post.
Am I a fool for not wanting to use the Interface Builder on desktop projects?
Should I depend on the autoresizingMask less than I would on iOS projects?
What are decent alternatives to making sure your layout lives up to standards without Interface Builder?
Cheers!
Yes, in my opinion. :)
You should depend on it when it does what you need. When it's insufficient, override resizeSubviewsWithOldSize: and/or resizeWithOldSuperviewSize: (or see below).
???
If you can target 10.7, look at the new constraint-based layout system. Check out the Cocoa Autolayout video from WWDC 2011.
You could also set minSize on your NSWindow to something large enough to prevent the singularity.
I'm not sure I'd say "fool," but refusing to use Interface Builder on the Mac is a very…avante-garde choice.
You should definitely use autosizing on your views.
Be maniacally attentive and spend lots of time making sure everything is right. (This is why I don't recommend going without Interface Builder. In general, what you get is a lot of wasted time that you could have spent doing something else.)
In this case, I think the best approach would be to set a sensible minimum height for the window. Don't let it get too small to display what it needs to display.
I am using a NSSearchField to run a query over the internet and display the results in a table view. Whilst the query is running I would like to display a progress indicator inside an NSSearchField? I think I have seen this done in another application before.
Is there an open source component that I could use to accomplish this?
How would I go about doing this? What is the best way? What are the pitfalls?
The easiest way is to put the progress indicator above (atop) the search field and leave them as separate views. It used to be that view z-ordering would give unpredictable results and weren't encouraged. That's not been true for several OS X versions, now, so if it looks good and behaves as expected, I say go for it.
The harder way would be to subclass NSSearchField and muck around according to the goodies found in the Control and Cell Programming Topics for Cocoa guide.
I'd go for a custom subclass of UISearchFieldCell. Find the method that draws the background and try to add your custom drawing code there. I'd rather not fiddle with nested components. I think the one used in safari is also a custom control.
This is not my solution but I came across this question and I eventually found someone that worked out a solution and it worked for me:
https://github.com/owainhunt/UAShared/blob/master/UAShared/NSSearchField%2BSpinner.m