This is a pretty common UX design pattern for apps, and I'm trying to figure out how best to implement this in React Native:
Users can switch between navigator scenes without losing their scroll position...
By default, the React Navigator component wants to re-render each scene when the user switches tabs. This has two drawbacks:
For complex scenes, there is a needless delay while the scene re-renders itself.
When the user returns to a scene (e.g. home page), she loses her scroll position and any interim UX state on that scene (e.g. expanded cells, etc)
Question: is there a way to persist scenes between navigator changes that avoids re-rendering them?
I'm using the following component layout for my navigator pattern:
p.s. I know React's flux/routing pattern prefers to re-render the scene because it prefers UX state to be captured entirely in one route state object, but in this case I really want to avoid the disadvantages of re-rendering a panel since it creates a crappier user interface....Instagram is an example of an app which does this seamlessly.
If you are pushing and popping scenes it will re-render them.
To avoid this you can start with all your scenes specified in the Navigator's initialRouteStack property then use the jumpTo(route) method of the navigator to transition between them without unmounting and re-rendering. This should preserve the current state of all the scenes.
By default, the React Navigator component wants to re-render each scene when the user switches tabs.
Where is this from? I'm using Navigator in similar patten, and the secenes is "Persist". I don't know what's wrong because there's no code here (maybe you re-render the Navigator?), but seams react-native-scrollable-tab-view would be helpful in your example case.
Related
I am building an HTML5 single-page web app that employs the concept of "views" or "screens"; essentially just different DOM elements rendered to be visible at any given time. As the user navigates between "views", I'm really just hiding/enabling DOM elements.
I'd like to be able to make use of the browser's history functionality, including the back/forward buttons, but I'm not sure how that plays into the concepts of history.pushState and window.onpopstate.
Ideally, I'd like to register "click handlers" with the browser's back/forward history buttons (obviously in a cross-browser-compatible way) so that when the user clicks either button, it engages my own custom Historian object (in JavaScript) that figures out which "view" to render for the user.
How can I do this?
Firstly, you need some sort of routing solution. You can use Crossroads to register and manage your routes. Each route should have a handler, which enables the appropriate div in your single page.
var route1 = crossroads.addRoute('/page1/', function(id){
//enable div for page1 route
});
Then, you can use Hasher to manage browser history.
Another way is to rebuild your application with Durandal, which has a router and manages browser history out of the box.
On our page we have some iframes in a long horizontally-scrolling <div>. If the user is using a mouse they can scroll with the scrollbars and we would like them to be able to select text within the iframes. If they are using touch only however, the scrollbars are a hassle and I would like to overlay a transparent element over the whole thing to give them the ability to scroll easily by dragging, this of course sacrifices the select-text feature but makes sense in that scenario.
Which gets me to my question, is there a way to reliably detect if a user is interacting with a webpage via a mouse?
Everything I've seen on detecting touch or mouse is that touch will broadcast mouse events so it is very difficult to detect touch OR mouse (not to mention that you can have both). My problem is simpler - it is whether the user has interacted with the page via a mouse.
Can anyone think of a way to check this reliably?
A mouse can do one single thing a touch device can never do - move without having any buttons pressed. So I'd just install an onMouseMove event on page load, and if it triggers without buttons pressed mark the user as a mouse user. You could then persist this through a cookie or LocalStorage since the flag will not change within the same environment, and remove the event right away. The precise way of implementing the single-fire event depends on which library you use (if any at all), but it should be easy with Mootools/JQuery docs in hand.
In general I'd recommend the easier route of just checking for a touch interface in most cases :
if('ontouchstart'in window)
{
/* it's a touch device */
}
I have a control in which I repeatedly run some animations (e.g. DoubleAnimation). Can I detect if my control is no longer visible to the user? E.g it gets scrolled away from, the user navigates forward to another page, or it gets obscured behind other controls.
I don't want to run those animations unless at least some part of my control is visible for the user.
You could analyze the visual tree or get a transform from control coordinates to screen coordinates to see if its positioning is within the view port and also check things like opacities, visibilities etc. of controls down the visual tree path, but that is so processing intensive that it is not worth doing all the time for a general solution.
The only thing that would make sense is to handle the ScrollViewer.ViewChanged event and check if the offsets make it visible or not while limiting the TransformToVisual or VisualTreeHelper calls only to times when the actual layout within your ScrollViewer changes.
This is more of a best practices question rater than something technical.
I'm working on a mobile app using the Flex 4.5 SDK and I'm trying to figure out the best way to handle notification windows. In most cases these windows will be alerting the user to when something goes wrong. Ex: bad login, no data, cannot resolve server.
I'm using a singleton design pattern, I have a Requests class that handles server calls. Most popups will be originating from this class (IOErrorEvents from my loader being used to access the API). Since this class is a singleton and is used from all Views inside the app it is not aware of applications current view. I'm also not sure having this class keep track of the current view and having it push popups on top of it would be best practice.
I'm hoping that I can use PopUpManager to keep track of where to add popups and what popups are currently on the stage. Though all examples I've seen online about this show static Components being used in a views Declarations tag.
I'm really just looking for any examples or input on how you would solve this problem. Any help would be greatly appreciated!
I had the same problem, and sorted it by making an Alert popup component that you can call from anywhere in the code base, and it will pop up in the currently active window. It also has an always visible scrollbar text area which is handy
http://bbishop.org/blog/?p=502
It works for a view navigator application, but if your using a tabbed navigator application, you can add a call for that, or simply change the code to
mainTabbedNavigator = FlexGlobals.topLevelApplication.tabbedNavigator;
currentTab = mainTabbedNavigator.selectedNavigator as ViewNavigator;
I am trying to accomplish an "imagemap" in flash where you click on different areas in the image and when you click on it, a popup (within flash) comes up showing more information about the object that was clicked on. The popup has a close button that can will then close the popup.
My biggest trouble is the way I have my code right now is when you click on a region of the map, it creates a popup on the fly, and then I use addChild(_myPopup) to add it to the display list. The problem with this approach for me, is that the Popup is now a Child of the button I just pressed, but this object organization doesn't really make sense to me. I'd like to have the popup not be a child of the button and it be on it's own layer or a child of the stage directly.
What is a good approach and code architecture for building such an organization of objects? I'm fairly new to AS3 and I've built some small applications but my knowledge is limited.
Thanks
UPDATE
ok looks like calling stage.addChild(myPopup) from inside the button works pretty well. Is this good practice?
Assuming you have a hierarchy that looks something like this:
stage
Main class
Image class
Button
It's good practice to never call upwards in the displaylist, every object only deals with it's children. Events however, are a nice way of communicating upwards. Have the Button dispatch an event, preferrably a custom one, then handle that using a listener in the main class that then deals with creating a popup on top of everything.
An often encountered practise to organize the layers of the visible application is:
stage
main class with all children
popup container
tooltip container
mouse cursor container (apparently not longer necessary since player 10 supports custom cursors)
So you create your popups always in the popup container above the main class. If you would have tooltips, they should go into the tooltip container. This approach guarantees that popups are always visible above the main app and tooltips are always visible on top of everything.