I'm wondering when the app model might change.
Specifically, is code like this guaranteed to be correct, or not?
onClick <| UpdateModelVersionMessage (model.version + 1)
That is, between rendering the UI component, and registering and dispatching the event, could something else update the model such that the UpdateModelVersionMessage value is out of date? Javascript's concurrency model makes me believe I'm safe. But is Elm doing or could Elm possibly do something like batching/reordering messages?
I have been informed that, as of 0.18:
The view is rendered asynchronously through requestanimationframe so, no, it's not safe.
But also:
in 0.19, html events will trigger synchronous rerenders, so that will not be a problem
And finally:
Requestanimationframe runs at 60fps, tho, so the window for events to be sent with an outdated model is really small
i.e. 16ms at most, assuming your view can render within a single frame (if it can't, that's a different issue)
So in this case, I'd recommend doing the simplest thing that could possibly work, knowing the odds of it going wrong are very very slim, and knowing that in 0.19, the view can re-render synchronously, preventing this from being an possible issue altogether
Thanks to Ilias (https://github.com/zwilias) for the answers.
Related
I started learning Kotlin few weeks ago and I need help understanding the basics.
What is a listener? For example, what is RatingBar's listener? How do I find a listener of other widgets?
What are the parameters? Again, what is RatingBar's parameters? How do I find the parameters of other widgets?
What is View.____?
If you're writing a component that handles events of some kind, you'll probably want a way to inform other components about those events. There are lots of ways to do this (in a software design sense), and one of those is the idea of a listener.
The basic idea is that components can register themselves as listeners, and when a relevant thing happens, they get a callback. The component generating the events doesn't need to know what those listeners are, it just needs to hold a reference to one (or more) and call some callback function when the event happens. The key thing here is that the component doesn't have a listener, you have to provide them. You're hooking components up.
So a typical way to do this is for a component to implement a callback interface, which basically says "I have a function called this with these parameters" and the event component can just call that function with the details when an event happens. You could also create an object that implements that interface, or in Kotlin's case you can just pass a function in that matches the signature of the callback function - basically providing a block of code that says "when the event happens, do this stuff in response". That's typically how you define behaviour, like setting an on-click listener - you write a block of code to execute when the user clicks a thing, and when the event happens, that code gets run.
I hope that makes sense generally - if any of it's confusing (since you're new) I'd recommend reading the basic trails in the Java Tutorials (which Kotlin is based on) to get a handle on interfaces and the like.
As for the other questions... if you're asking what the parameters are when you construct a RatingBar or whatever, the best place to look is the documentation (although you generally won't be constructing Views in code anyway, just adding them to a layout XML file) - Android Studio should pop up some hints too (you can hit ctrl+q for documentation on the thing your cursor is currently over, or ctrl+p for parameter hints).
If you're asking what a View is, it's the base class for Android's UI components, it's really anything that's able to draw itself and be included in a layout. It has a lot of methods because it has a lot of functionality built in to handle all these UI responsibilities.
If you're asking what View.something is, that's a static method or field defined on the View class - if you don't know what that means, read the Java tutorial link I included! You'll typically be referencing things like View.VISIBLE which is a set value you provide to a View's setVisibility method - it knows what those values mean and what to do with them
In my project, I need to know the changes in the child components in real time from the parent component.
So I'm going to use watch in a child component to emit event to the parent component whenever the data in the child component changes.
Is this a bad way? I'm afraid there's an unnecessary overload in this flow.
If you have a better way, please recommend it.
There's nothing wrong with this approach. Vue is very efficient in the way it detects changes, and there shouldn't be an unnecessary overload, unless you watch more than you need to. You shouldn't notice any performance issues unless you have a huge object graph (eg thousands of objects being watched).
Make sure you only watch the properties that require change detection, and only use deep:true if you really need to.
First of all: This is not an question of opinion (I'm afraid someone will flag this question), I'm interested in the technological background or the decisions for this.
That being said: Redux's store needs to be serializable. It is not allowed or frowned upon to use model classes and write their instances in the store. This is highly annoying to me. The applications logic ends up in actions or reducers where models would be a nice thing to have.
I am wondering why. What is the technological decision behind this? Why not write class instances to the store?
1) Class in instances are mutable, which leads to the same problems redux has tried to address around predictability of state by championing immutability. It also means you have to do more manual shouldComponentUpdate checks for changes if pairing with React (as references to mutated instances will be the same even if their internal state has changed)
2) Immutability makes it possible to move back and forth between states (eg during time travel debugging), something that cannot be done when mutations have occurred within instances
3) Serialisation means its very easy to persist and rehydrate the store (to/from JSON) for more advanced uses such as server side rendering and offline use
If you are interested I just wrote a more in depth answer to a similar question with an example of how it is possible to use the best of both worlds https://stackoverflow.com/a/47472724/7385246
What's the purpose of if statement in a custom setter? I see this routine a lot in sample code. Provided using ARC, why bother checking the equality?
- (void)setPhotoDatabase:(UIManagedDocument *)photoDatabase
{
if (_photoDatabase != photoDatabase) {
_photoDatabase = photoDatabase;
...
}
}
The important part is typically what follows the change (what's in ...): side-effects after assigning new value, which can be very costly.
It's a good idea to restrict those changes to avoid triggering unnecessary and potentially very costly side effects. say you change a document, well you will likely need to change a good percentage of the the ui related to that document, as well as model changes.
When the conditions are checked, a significant amount of unnecessary/changes work may be short circuited, which could wind up avoiding making unnecessary changes.
such unnecessary side effects could easily eclipse your app's real work regarding CPU, drawing, object creation, writes to disk -- pretty much anything.
believe it or not, a lot of apps do perform significant amounts of unnecessary work, even if they are very well designed. drawing and ui updates in view-based rendering systems are probably the best example i can think of. in that domain, there are a ton of details one could implement to minimize redundant drawing.
One of the main reasons to override and implement custom setters is to execute additional code in response to changes of the property. If the property doesn't actually change, why execute that code?
The answer is usually in the ... section that you have commented out: when there is nothing there, the code makes no sense. However, a typical thing to have in that spot is some sort of notification of your own delegate, like this:
[myDelegate photoDatabaseDidChanged:photoDatabase];
This should not be called unless the photoDatabase has indeed changed. The call may be costly, anywhere from "expensive" to "very expensive", depending on what the delegate really does. It could be updating a screen with the images from the new library, or it could be saving new images into the cloud. If there is no need to report the change, you could be wasting the CPU cycles, along with the battery and the network bandwidth. Your code has no way of knowing what the delegate is going to do, so you need to avoid calling back unless the change did happen.
If you check for equality you can prevent the redundant assignment of the parameter that is passed into the method.
This way you can avoid the cost (even if it's small) of doing all the code within the brackets if there is no change to the photoDatabase in your sample method.
Ex (Extending your example):
- (void)setPhotoDatabase:(UIManagedDocument *)photoDatabase
{
if (_photoDatabase != photoDatabase)
{
_photoDatabase = photoDatabase;
// do stuff
// do more stuff
// do even more stuff
// do something really expensive
}
}
As you can see from the example, if you check first to see if the photoDatabase doesn't equal what is passed in, you can just exit the method and not run additional code that isn't necessary.
I'm working on an iPhone/iOS game, and I was wondering if I could/should use a global object for statistic tracking between scenes. Now wait, before you jump down my throat - yes, it goes against everything I know about good code, but I don't think that concurrency is going to be an issue in this case. The structure of my game is similar to an Oregon Trail kind of affair with a sprinkling of Civilization thrown in for good measure - since it's not real-time I can ensure that only one process will be accessing the object in question at one time, and thus I'm pretty sure concurrency will not be an issue at all. Basically every scene will need access to most of the data (population, current technology level, current date, current map state) and so I'm wondering if I can get away with using a global object to store this data.
Everything I ever learned in college screams that this is a Bad Idea, but the sneaky programmer part of me keeps whispering "it won't be that bad, just this once couldn't hurt." And without worrying about concurrency, I'm kind of leaning towards the sneaky programmer. Is there any other reason I should avoid using a global object for this kind of statistic tracking?
Can you explain what you mean by global object?
If you're talking about the singleton design pattern, there's nothing wrong using it.
If you're talking about an object instance that different threads can modify, there's nothing wrong doing this, if you're careful and use #synchronize on objects correctly
But I think it iS wrong to assume your application is going to be mono thread during its whole lifecycle for the reason that iOS can do stuff behind the scene and that it would prevent you to do any asynchronous processing (and I also assume any game requires some non-trivial processing and this processing should be done on a background thread to let the main thread be as responsive as possible on user interactions)