Here is a codepen http://codepen.io/shirha/pen/BNBxWJ/ to better show my question.
First notice on the recipes tab that Briar Heart shows on multiple rows.
Now navigate to the ingredients tab and uncheck Briar Heart.
And then tab back to the recipes tab and notice that all the Briar Heart recipes have been removed (thanks to the filter:available).
Now go to the options tab and click refresh ingredients.
The recipes tabs includes Briar Heart again. Notice that clicking the Briar Heart ingredient button on the recipe tab also unchecks the ingredient and removes the recipes.
If you now change the link to the ionic-bundle.js to 1.0.0-rc.3 and perform the same steps, you will notice that the recipes tab will not refresh without scrolling forward past the buffer specified on the collection-repeat.
I've tried to code an scope.$apply() to work around this but I don't know how to do this and have been unsuccessful so far. I'm not sure if this is the right idea.
I think in your case the best option is to disable the view caching. The view will get cached (even if the state changes in the background) and not immediately updated. You will notice if you follow your steps above, but then click on another item on the recipes view (when Brian Heart still shows, but shouldn't be) it will also update the scope and the view will reflect the correct changes. Here is and updated working codepen http://codepen.io/gnomeontherun/pen/KpPLop?editors=001.
.config(function($ionicConfigProvider) {
$ionicConfigProvider.views.maxCache(0);
})
Related
I'm developing a flutter application and I'm now struggling to understand what is the best way to implement a complex bottom bar navigation.
Here are my requirements:
each button on the nav bar should lead to a different section
each section should be able to have multiple screens inside of it
user can navigate from any page of a section to any page in another section and back
each section should show the last visited page if we come back to it
for example, let's say we have two sections, each made of two pages: SectionOneA, SectionOneB, SectionTwoA, SectionTwoB.
A few use cases:
user navigates from SectionOneB to SectionTwoB by pressing a button inside SectionOneB, when user presses back (on android) from SectionTwoB, we should navigate back to SectionOneB
user navigates to SectionTwoA by the nav bar, then navigates to SectionTwoB via a button in SectionTwoA, then navigates to SectionOneA via the nav bar and then press the SectionTwo icon in the nav bar again. we should show SectionTwoB. if back is pressed we should navigate to SectionTwoA.
in both these examples, when moving from one section to another, the correct nav bar item should be highlighted.
I'm new to flutter so I'm learning as I go. For now, what I've done is using nav bar with PageViewer to switch from section to section, then each section uses a PageViewer to handle switching from page to page. This worked well until I had to implement the first usecase above, at this point it seems to me that it would be quite challenging to implment a proper navigation stack as demanded by the usecase and I feel it would be better to rethink the whole thing, only I've no idea what is the best way to approach this.
A temporary solution would be to also include SectionTwoB in the PageViewer of section one, but that would not allow me to highlight the proper nav bar item.
Any lead on how to approach this? All the examples I find seems too simple and/or I'm failing at understanding how to connect the pieces together. I'm using flutter_bloc as a state management library.
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.
I am trying to find the most usable/accessible way to implement a simple form dropdown list which will sort a list of products by pice and alphabetical order.
In your opinion is the dropdown more usable when there is a button that governs its submission or when it automatically submits onchange of the dropdown?
The research I have read is both for and against such methods and there is a variery of implementations on the web so interest to hear the thoughts of the community.
Thanks in advance
As a blind computer user either method works fine. I find that having a button to click is slightly easier for me then the onchange event firing. I wouldn't say it's a big enough difference to take into account though assuming the majority of your users will not be disabled. If your targeting specifically blind users I would not use the onchange event.
So long as you do not change focus or navigate to another page when the selection changes, either approach should work. The classic example of a problem dropdown is where it contains a list of other pages on the site, and navigates as soon as the selection changes. This prevents a keyboard user from using the list; they can't browse it, and can't navigate to any pages beyond the first selection, since it's impossible to navigate past those. So in cases where focus changes or the page navigates as a consequence, having a separate action (eg. Go button, or handling enter) to cause the navigation to take place is essential. This is likely where the advice you've read is coming from.
In this case, however, it sounds as though you are just updating content elsewhere on the page, and not changing focus or doing navigation. Simply resorting existing content should be fine.
Depends on your users and their respective expectations and the context in which it's presented.
As a blanket, general statement, you should have the drop down accompanied by very obvious submission button. That is the safer approach.
If you are refreshing page data or if the focus moves away after the dropdown option is selected, you should use a button to be accessible. If you fire the event on change, blind or keyboard-only users will not be able to use the dropdown menu at all if they are on windows with ie and chrome (so added together, a majority of the people on windows). As soon as they use the arrows to scroll down and make a selection, the first option they hit will be selected and the page data will refresh or the focus will move, making it impossible for them to navigate or select the second option, third option, etc. Below is a thorough explanation with examples so you can see what I mean.
Designers definitely don't like the buttons, but if you are blind and on chrome/ie, it is impossible to use a lot of dropdowns without it. I'm guessing Jared uses firefox or a mac.
http://pauljadam.com/blog/javascript/onchange-event-on-a-select-inputjump-menu-accessibility-problems/
After the right '+' button is pressed the item in that view is added to favorites and an UIAlertView is shown on screen saying "Added to Favorites". After it is added to favorites I make the '+' button disappear so the same item doesn't get added again to favorites. I am not sure if this ok with Apple's Human Interface Guidelines instead should the '+' remain there and if pressed again say "This item is already in favorites"?
Any help will be appreciated! Thanks
I wouldn't use the AlertView for this. By showing the alert, you force the user to confirm reading some confirmation message and taking action (by pressing the OK button). It is a good idea to provide feedback that the favorite was successfully added, but this should not be an intrusive alert. Perhaps you can use other design patterns for favorites, such as a star that lights up when pressed to indicate that the item is listed as a favorite, or perhaps an animation effect that 'moves' the selected item to a visible 'favorites' category.
The Human Interface Guidelines have this to say about the Alert view (in relation to your question):
Avoid creating unnecessary alerts.
These alerts are usually unnecessary
if they:
Merely increase the visibility of some
information, especially information
that is related to the standard
functioning of your application.
Instead, you should design an
eye-catching way to display the
information that harmonizes with your
app’s style.
Why not have two states for the button ? A "selected" state (for example negative contrast) showing the item is in favorites, and a "normal" state indicating it can be taped.
This way you can add/remove from favorite using the same button, and in a less obstructive way than with a UIAlertView.
I also suggest you use a ★ instead of a +
How would one implement a wizard style interface for the iPhone?
For instance I have a form that I would like to break down into 5
different pages or views instead of putting all the information to fill out
into one page or view.
This interface must have the ability to go prev or next in case they want
to change something on page 2 when they are on page 4.
This interface must have the ability to go to page 3 directly and still be
able to go prev and next. Seems like using UINavigationController wouldn't
work here since views 1 and 2 are not on the stack so prev would not work.
Update: Check out the "gas cubby" application. It has what I'm looking for. UITableView presents the items you can fill out. Selecting a row takes you to the detail view to enter data and prev and next to fill in other information.
UINavigationController seems like the obvious solution. It gives you nice, familiar page transitions for free, and if you need to jump to a specific page you can just set up your navigation stack without using the transition animations.
I would say use a Navigation Controller. On the 1st view, show the 5 options in a Table View. The user selects a row, and then the corresponding section is pushed onto the stack as a new UIViewController. So, if they are in view #3 and want to go back to view #1 (to be honest, I would recommend rethinking whether or not somebody in the real world will actually want to do this), they hit "back" and then select view #1 from the table.
I can't think of a better way to do this because you won't have room to do something like breadcrumbing, which Apple would recommend against anyway. You could use a tab bar but that is more like options then some sort of wizard workflow.
If you really want them to be able to skip around the process, the combination of a UINavigation controller with a UISegmentedControl to jump to sections would do what you want. You can either embed the segmented control in the nav bar or place it just below the nav bar (which seems more like what you want since you have five sections).
If the Segmented control is not quite to your taste just put up any set of five buttons to change sections and make them visually appealing.
A "wizard" UI is typically used when you have a relatively small number of steps where one step depends on the previous, at least at some steps, the results or presentation depends on previous steps. This is like a navigation tree that usually results in the use of the navigation controller, but with only one potential branch at each each step. My feeling is that the navigation UI would be perfect, but with one exception; A button on the right hand side of the navigation bar that is the left to right mirror image of the "back" button that is usually found in the left part of the navigation button. That button would navigate to the the next step, and at each step the page presented would allow the user to fill in the information for that step. The only problem then is navigating to a step not the next or previous, and this could be corrected with a custom button that includes a drop-down list of the steps in the process. And this would fit nicely with the rest of the iPhone UI, which Gas Cubby's wizard UI (as good as it is) does not.