The componentWillLeave feature and the corresponding callback is a powerful feature I haven't seen in RN. Without it, you're always forced into producing very crappy code using additional states to make sure an element stays on the page/phone until its animation is complete, when ideally some boolean state from redux simply triggers the removal of the element while respecting its willleave animation.
So does anyone have any ideas how to accomplish this consistently in RN without having to write custom code every time to make sure the element stays rendered until you animate it away??
I know this is an old question, but I just landed here from a google search on the topic so I'll give my 2 cents on it.
This library should represent a 1:1 replacement for react-addons-transition-group for RN and comes with support for componentWillLeave method you can implement. It supports both componentWillEnter and componentWillLeave.
Link to the library: react-native-transitiongroup
Related
The AVAudioEngine and related AVAudioNode objects seem to be quite powerful for audio processing but it's difficult to see how to automate parameter changes with them. I'm sure there must be something more effective than manually using a Timer to change values, as a crude example.
AVMutableAudioMixInputParameters includes a method setVolumeRampFromStartVolume:toEndVolume:timeRange: but I cannot see how I could integrate that with AVAudioPlayerNode (connected with AVAudioEffectNodes) and use that method to fade the volume over time. Instead, I have only seen examples of AVMutableAudioMixInputParameters working with AVMutableCompositioninstances and none of them include AVAudioNode objects.
Can anyone post or link to some code samples that combine the use of AVAudioNodes with setVolumeRampFromStartVolume:toEndVolume:timeRange: or explain best practices for automating parameter changes on a node over time?
Many thanks
The AVAudioEngine is a real-time engine, but AVMutableComposition seems to be a non-real-time object. Thus incompatible. An alternative is to build and insert your own fader real-time AUAudioUnit node..
Several months ago I met a flux and I found it's awesome, I love it, I use it.. almost in every new project and when I met a redux I love it even more, but couple of days ago Pete Hunt publish a tweet where he judge the people to use flux for everything. And I think it have a perfect sense, but on the other hand I don't get it.. He publish another tweet where explain cases for flux, also I read an article about use cases for flux. Long story short - "If your app doesn’t have complex data changes and caching, don’t use it. But if it does, I strongly recommend you try Flux." and it's totally make sense for me why I should use flux, but it not clear to me why I shouldn't if I don't have a complex data changes.
In the article Dan point, that when you faced those issues(that flux solve) in real project you can easier to understands the benefits of the flux, but exactly of this(cause I faced with these problems at work project) now I try to use flux in every project, because I don't wanna to deal with it anymore.
And crazy part, that now I often use it also for ui states, not just data changes. Let's pretend I can have a widget component, for example a clock. It can make some ui changes, like show/hide seconds, switch between digital/analog and it has a daytime type state(day/night) and can dispatch an event when it changed, but other component listen it and can react, for example change a background color. I can easily solve it just with local component state and container(smart component) state, but same as I can put all these logic into store(reducers) and components will be really dump and just react on the current state(props) and containers(smart) just listen the store and partitioned state between the components. And if even it looks ok, point that I can use it for every ui state - open/close sidebar, some specific component changes, etc.
Reasons why I can do it:
It looks predictable for me. I completely know that any changes happened in my app serve in one place.
It easy to debug. I can just log all the actions and if I will get some bug, I can easily found what happened and reproduce it.
I can easily expand my app without worrying, mb I should move something to the flux state, cause I already did it.
But also I agree that it's looks overwhelmed and I can solve it without flux, but I can't answer to me, why I shouldn't use flux in these cases. What is wrong with it? Please help me.
So I realize that this question can be seen as somewhat vague, but it's actually quite specific.
I started to write this out, then realized that lack of specific verbiage makes it sound vague. So let me put it this way.
I've got an Order object, that has customer data on it. It also has, for the sake of this example, a single order for a car.
The Car has a Category, Product, Year, Color. For the sake of this example, my Order page has 4 drop downs, which cascade one to another. Category populates Product populates Year populates Color.
(I was going to go with Make and Model, then realized using "Model" was getting confusing, haha.)
I've got several problems:
I've got multiple layers of dropdowns. Four, not just one.
My drop down objects are not related to each other specifically - that is to say, I use an id from Cateogry to populate Products, but Category does not come with Products when it's retrieved. This is different than the Cart example that KO has on their website.
I am stuck with the above architecture. I need to change a drop down, then send a service call to get the next drop down based on the selected drop downs id. I can't alter the service layer to nest the objects together.
My Order comes with child objects to indicate Make, Model, Year, Color. However, since these are different, I've been using the knockout.mapping keyed array and a custom binding handler to look up data object. Thankfully I only have to do this once, as after the object in the top level is replaced, it's fine.
I've been trying to use knockout.mapping to map the relevant objects, especially considering the key thing.
However, I'm totally open to just making the objects in knockout.
The problem I'm having, and this thing has really turned into a disaster, is that since everything is asynchronous, it's very difficult to resolve things in the proper order, aside from nesting within nesting within nesting.
Hence my question - I'm getting to the point where it seems like ditching knockout completely is the answer here, which doesn't seem right. It feels like I'm very close but it still doesn't work properly. (Often things load in the wrong order.) Unfortunately I can't really post the code because it's huge.
The thing is, it seems like it shouldn't be this hard. It feels like I'm missing a fundamental design pattern for knockout and drop down combos. Looking at the cart example, I'm starting to suspect that multi-layer cascading drop downs are just not feasible in knockout at the moment unless the data is all loaded ahead of time.
Am I actually missing the design pattern? If so, please elucidate. If not, go ahead and say so. I guess whichever more people agree with will be accepted.
Update
I realized after the first comment I got that I did not discuss much about some of the solutions I've tried.
So, basically yes, I've tried subscribing to the change event. I should emphasize that at the beating heart of this problem lies the fact that all of our calls to load these dropdowns are network calls.
The problem that happens is that the change event fires multiple times - once when you load the drop down, and again when the value is bound to the drop down. At least, that's been my experience.
What ends up happening is that any subscription will then fire multiple times. When it does, it causes the load to happen multiple times. Aside from the fact that I don't want to fire multiple times, there are often issues where the drop downs will get loaded incorrectly. My guess is that one of the times arrived "out of order" than the others.
I've gotten similar results with my various efforts. It really does seem to be pushing me toward some hackish stuff, like nesting 5 or 6 or 7 network calls inside of each other's callbacks. And it seems like there must be a better way.
I've tried computed observables to similar effect. I've tried loading things once via the MVC viewbag, etc. Every time I try something, I'm stymied by either something loading weird, the knockout.mapping plugin behaving strangely (it apparently will not add its key/mapping functions to existing knockout observables) or just ... some other weird issue.
Again, I ask, is this something knockout is simply incapable of? Is our situation just too peculiar? Or am I missing some method or function or object that would make all of this work?
Knockout subcribe event will solve your problem.. Its not too complicate I think..
If you think its complicate add a fiddle or code block.
Could you give me an example of the way I should code into the pfc_Validation event? This is an event that I have never used. For example here is something I have coded in the ue_itemchanged event.
if dwo.name = 'theme' then
This.Setitem(row,"theme",wf_clean_up_text(data))
end if
if dwo.name = 'Comments' then
This.Setitem(row,"Comments",wf_clean_up_text(data))
end if
Which is the proper way of coding those validations in the pfc_Validation event , so that they are performed only on save-time?
You're asking something outside of native PowerBuilder, so there's no guarantee my assumptions are correct. (e.g. anyone could create a pfc_Validation event and have it fire when the user draws circles with his mouse) There is a pfc_Validation event coded as part of the Logical Unit of Work (LUW) service in PowerBuilder Foundation Classes (PFC). If you want to find out more about it, I've written an article on the LUW.
Firstly, your question: Everything in the LUW service is only fired at save time, so you're in good shape there.
Having said that, from the looks of the code, this isn't validation, but data preparation for the update. On that basis, I'd suggest the appropriate place for this logic is pfc_UpdatePrep.
As for converting the code, it's pretty simple. (Now, watch me mess it up.)
FOR ll = 1 to RowCount()
Setitem(ll,"theme",wf_clean_up_text(GetItemString (ll, "theme")))
Setitem(ll,"comments",wf_clean_up_text(GetItemString (ll, "comments")))
NEXT
Good luck,
Terry.
I'm not generally a GUI programmer but as luck has it, I'm stuck building a GUI for a project. The language is java although my question is general.
My question is this:
I have a GUI with many enabled/disabled options, check boxes.
The relationship between what options are currently selected and what option are allowed to be selected is rather complex. It can't be modeled as a simple decision tree. That is options selected farther down the decision tree can impose restrictions on options further up the tree and the user should not be required to "work his way down" from top level options.
I've implemented this in a very poor way, it works but there are tons of places that roughly look like:
if (checkboxA.isEnabled() && checkboxB.isSelected())
{
//enable/disable a bunch of checkboxs
//select/unselect a bunch of checkboxs
}
This is far from ideal, the initial set of options specified was very simple, but as most projects seem to work out, additional options where added and the definition of what configuration of options allowed continually grew to the point that the code, while functional, is a mess and time didn't allow for fixing it properly till now.
I fully expect more options/changes in the next phase of the project and fully expect the change requests to be a fluid process. I want to rebuild this code to be more maintainable and most importantly, easy to change.
I could model the options in a many dimensional array, but i cringe at the ease of making changes and the nondescript nature of the array indexes.
Is there a data structure that the GUI programmers out there would recommend for dealing with a situation like this? I assume this is a problem thats been solved elegantly before.
Thank you for your responses.
The important savings of code and sanity you're looking for here are declarative approach and DRY (Don't Repeat Yourself).
[Example for the following: let's say it's illegal to enable all 3 of checkboxes A, B and C together.]
Bryan Batchelder gave the first step of tidying it up: write a single rule for validity of each checkbox:
if(B.isSelected() && C.isSelected()) {
A.forceOff(); // making methods up - disable & unselected
} else {
A.enable();
}
// similar rules for B and C...
// similar code for other relationships...
and re-evaluate it anytime anything changes. This is better than scattering changes to A's state among many places (when B changes, when C changes).
But we still have duplication: the single conceptual rule for which combinations of A,B,C are legal was broken down into 3 rules for when you can allow free changes of A, B, and C. Ideally you'd write only this:
bool validate() {
if(A.isSelected() && B.isSelected() && C.isSelected()) {
return false;
}
// other relationships...
}
and have all checkbox enabling / forcing deduced from that automatically!
Can you do that from a single validate() rule? I think you can! You simulate possible changes - would validate() return true if A is on? off? If both are possible, leave A enabled; if only one state of A is possible, disable it and force its value; if none are possible - the current situation itself is illegal. Repeat the above simulation for A = other checkboxes...
Something inside me is itching to require here a simulation over all possible combinations of changes. Think of situations like "A should not disable B yet, because while illegal currently with C on, enabling B would force C off, and with that B is legal"... The problem is that down that road lies complete madness and unpredictable UI behaviour. I believe simulating only changes of one widget at a time relative to current state is the Right Thing to do, but I'm too lazy to prove it now. So take this approach with a grain of scepticism.
I should also say that all this sounds at best confusing for the user! Sevaral random ideas that might(?) lead you to more usable GUI designs (or at least mitigate the pain):
Use GUI structure where possible!
Group widgets that depend on a common condition.
Use radio buttons over checkboxes and dropdown selections where possible.
Radio buttons can be disabled individually, which makes for better feedback.
Use radio buttons to flatten combinations: instead of checkboxes "A" and "B" that can't be on at once, offer "A"/"B"/"none" radio buttons.
List compatibility constraints in GUI / tooltips!
Auto-generate tooltips for disabled widgets, explaining which rule forced them?
This one is actually easy to do.
Consider allowing contradictions but listing the violated rules in a status area, requiring the user to resolve before he can press OK.
Implement undo (& redo?), so that causing widgets to be disabled is non-destructive?
Remember the user-assigned state of checkboxes when you disable them, restore when they become enabled? [But beware of changing things without the user noticing!]
I've had to work on similar GUIs and ran into the same problem. I never did find a good data structure so I'll be watching other answers to this question with interest. It gets especially tricky when you are dealing with several different types of controls (combo boxes, list views, checkboxes, panels, etc.). What I did find helpful is to use descriptive names for your controls so that it's very clear when your looking at the code what each control does or is for. Also, organization of the code so that controls that affect each other are grouped together. When making udpates, don't just tack on some code at the bottom of the function that affects something else that's dealt with earlier in the function. Take the time to put the new code in the right spot.
Typically for really complex logic issues like this I would go with an inference based rules engine and simply state my rules and let it sort it out.
This is typically much better than trying to 1. code the maze of if then logic you have; and 2. modifying that maze later when business rules change.
One to check out for java is: JBoss Drools
I would think of it similarly to how validation rules typically work.
Create a rule (method/function/code block/lambda/whatever) that describes what criteria must be satisfied for a particular control to be enabled/disabled. Then when any change is made, you execute each method so that each control can respond to the changed state.
I agree, in part, with Bryan Batchelder's suggestion. My initial response was going to be something a long the lines of a rule system which is triggered every time a checkbox is altered.
Firstly, when a check box is checked, it validates (and allows or disallows the check) based on its own set of conditions. If allowed, it to propagate a change event.
Secondly, as a result of the event, every other checkbox now has to re-validate itself based on its own rules, considering that the global state has now changed.
On the assumption that each checkbox is going to execute an action based on the change in state (stay the same, toggle my checked status, toggle my enabled status), I think it'd be plausible to write an operation for each checkbox (how you associate them is up to you) which either has these values hardcoded or, and what I'd probably do, have them read in from an XML file.
To clear this up, what I ended up doing was a combination of provided options.
For my application the available open source rule engines were simply massive over kill and not worth the bloat given this application is doing real time signal processing. I did like the general idea.
I also didn't like the idea of having validation code in various places, I wanted a single location to make changes.
So what I did was build a simple rule/validation system.
The input is an array of strings, for me this is hard coded but you could read this from file if you wish.
Each string defines a valid configuration for all the check boxes.
On program launch I build a list of check box configurations, 1 per allowed configuration, that stores the selected state and enabled state for each checkbox. This way each change made to the UI just requires a look up of the proper configuration.
The configuration is calculated by comparing the current UI configuration to other allowed UI configurations to figure out which options should be allowed. The code is very much akin to calculating if a move is allowed in a board game.