I'd like to implement a search into my app. I'm planning to use a left swipe, like the Spotlight search. Would that violate anything with Apple?
My app is tableview based. The user can drill down a few levels before reaching a detail view. I'm considering two options for implementing the search:
1.) From the search results, I display lower level topics. Meaning, once a user clicks a search result, they will open a detail view. Should I back the user out of the search, navigate the UI down to the detail view...or just show the detail view (option #2)?
2.) If I just popup the detail view, it will be out of context. Once finished with the detail view, the user will not be able to navigate backwards to the top level. They will basically already be there (search results). Or is that how it should be - just put the user back on the search results view?
I don't know if it'd get rejected, but it sounds weird as I've never seen it in an app before. Why not just put the search bar in the first row of the table as in the iPod app?
You probably could also mimic the iPod behavior when "backing out" of Search results.
But yeah, this isn't really programming related.
Related
Good Afternoon/Evening/Morning Folks,
I recently encountered a discussion with another developer on dismissing a UIPickerView. We work on a legacy enterprise application that had a lot of issues and was written very poorly (among other things). Since then, we revamped and fixed a lot of bugs with this program, strictly adhering to Apple's Human Interface Guidelines as much as possible while keeping to original requirements.
We seem to have a difference in opinion as Human Interface Guidelines do not really go into any detail about picker views. We implemented our new UIPickerView with a "Done," Button to confirm a selected value to be placed in a UITextField. Screen's input would be locked until they selected a value or clicked done.
Legacy application prior to our changes allowed users to utilize a done button but also by way of tapping a value selected in a picker. In addition, legacy application would also show selected UIPickerView value in UITextField prior to selection, wiping out original contents , if any was selected prior to opening a UIPickerView.
So, What is correct way to implement a UIPickerView per common practice or Strict Apple Documentation (if any exists). What is common practice?
Sorry, I cannot post any screen shots or code snippets due to business process reasons. I will do my best to explain if any questions arise.
Thanks,
We can figure this out through apps designed by Apple. Here are two examples
1. Contacts
Find a contact person in the Contacts app and set birthday. The picker shows up. While you are dragging the pickers, it does not set value to the text field. It happens only when you release the wheel. There is no Done button to hide the picker it self. To dismiss it, you can either click on the done button on navigation bar to end editing for the whole page, or click on another text field which pops a different keyboard.
2.Setting - Date&Time
Basically the same as Contacts app. Here you cannot even dismiss the picker.
I am creating a bible application. There are lots of chapters in the bible (e.g. genesis, exodus etc).
I created a button for each chapter loading. I load the verses and chapter in table-view cell. When the button is tapped it loads the next chapter and vise versa. I put the button in the footer of the table-view, but I want to change this functionality with pull down to refresh. I know pull down to refresh is used in many applications like Facebook and Twitter. I've also implemented this in my previous applications, but my need is to change the chapter when the user pulls down the table. When pulled down it changes to the next chapter.
I saw this functionality in the pocket-sword bible application; pull up for next chapter and pull down for previous chapter. How can I implement this in my application?
While that would work fine. I don't think it's the ideal implementation for navigation.
How would you go back to the previous chapter?
How would users know to pull down to go to the next chapter?
It just sounds and feels wrong.
I feel it would be better to implement swiping left and right to jump to the next page/chapter or even next/back buttons in either a navigation bar or toolbar. This is fairly standard.
Another option is to replicate the iBooks interface for jumping to chapters using the "paging bar" at the bottom (not sure what the correct name for it it)
we have to put same code thAT IS what code we used for directing next chapter in button-click,that code have to be put inside the _(void)refresh method.It automatically redirected to the next page when we pull down the table-view.What ever functionality we can add to this function.Thanks.
(Duplicate of this question, but I figured I could try again, since that one wasn't answered...)
The UISearchBar on the iPhone has an option showsSearchResultsButton. When you turn it on, it shows a button with horizontal lines inside the search bar, and you can implement a callback that will be called when the user presses it.
The thing is, I can't find a single place on the Internet where it says what the intended purpose of this button is. I know I could make it do anything, but I'd like to know what it's actually for. Should it show a history of searches, or all items without filtering, or what?
It's simply to show search results when tapped.
Where Apple uses this is in their iPad App Store application. If you go to the Categories tab you'll see various app categories. Search for an item, you'll get a list of results, and when you press "Done" you are shown the categories screen again. Your previous search term is still listed in the search field, but now the Search Results Button appears in the field. After tapping this, a UIPopOver is displayed, showing a text list of the results from your last search.
I have a very specific application design that I'm trying to figure out how to create with iOS 4.
Here's how it works:
The user selects an installed data set, or triggers a data set download.
The user provides a key for decrypting the data set.
A tab bar is shown with different search options for looking at the data. There are more searches than fit on the tab bar, so there's a More item and an Edit button. (Thanks, Apple!)
The searches provide different options, some requiring an additional screen for setup.
Once a search result is tapped, the user sees details. They can usually tap deeper into the result.
The tab bar stays visible as users look at details, letting them start a different kind of search. Tapping a search takes them back to step 3.
If at any time the device goes to sleep, the data must be locked. This is a hard requirement, despite may efforts to remove it. So at the moment, I'm returning to step 2.
I've implemented this in iPhone OS 3.1 with a UINavigationController for steps 1 and 2. The app pushes a UITabBarController with each tab represented by a UINavigationController for step 3, hiding the navigation on the outer controller. The user then operates within this UITabBarController. For a lock, I just pop the tab controller off the navigation controller.
It mostly works in iPhone OS 3.1, but it's fragile and hackish. There was no good way to change the data set, but the user could just close the app. With iOS 4 this workaround is gone! The only option I see is returning to step 2 on a supsend/resume, which is going to be a terrible multitasking experience.
How should I be doing this?
The tabs don't make sense until the data set is opened and unlocked.
I (and my users) really like the single tap (no matter the depth) to start a new search.
I am building an iPhone app, which will function similarly to many restaurant finder applications. When launched, the application will start with a view that allows a user to specify a zip code for performing a search. Alternatively, if the user has an iPhone with a GPS, the application will automatically perform a search based on their current location, although it will be possible for the user to specify their own location.
After the search has been performed, the user will be presented with a tab bar view, which displays a list of all results, or a map view, containing all of the results within a specified range. Finally, there will be a details view, which gives the user detailed information about any one particular result from the list or map.
The application should flow as follows:
Search -> (list | map) -> details
I'm very new to iPhone development, so I'd appreciate some feedback on how to put together the interface.
What I'm thinking is I could use a navigation view controller for the opening search view. When the user clicks the "Search" button, the app will switch views to a view containing a tab bar controller (one tab for the list and another for the map). Both the list and map views will be placed inside yet another navigation view, which will allow the user to switch to the details view when the user attempts to drill down into the details view.
Does my solution to the problem sound feasible? Is there an alternative way I should consider?
I wouldn't use a tab bar for switching between the map and the list. They basically display the same data, just in a different way. This is usually done with a segmented control in the title bar.
Use one UINavigationController to switch between the 3 main views (Search > (list | map) > details).
Within the (list | map) view, use a UISegmentedControl to switch between viewing modes.
When in the details view, users can go back to the search results by using the back button.
Two mockups I came up with quickly:
alt text http://img340.imageshack.us/img340/8913/uimockup.png alt text http://img219.imageshack.us/img219/9553/uimockup2.png