3 ms·

> just beware of problems with asynchrony Please elaborate. (I have also been experimenting with Flex.)

a-priori 17y ago
Many operations in Flex occur asynchronously, such as when accessing remote services. That is, they spark a remote query, and you must explicitly wait for the response (such as by binding a function to the appropriate change event) before you can continue a computation. Sometimes this occurs when you may not expect it, in which case you'll see problems such as UI controls not being updated, or exceptions from using nil values (because they are used before the response comes back). When you do expect it, you have three options: 1) you always wait for a response before returning, making your function sychronous (thus maybe killing performance), 2) you pass the responsibility to handle this behaviour to the caller (thus creating an abstraction leak), 3) or you define a custom event that you trigger when the response occurs (best behaviour, but needs extra code). Certainly not a huge issue once you get the hang of it, but something that can definitely trip you up when you're just learning it.
- cellis 17y ago
  It is very similar to ajax. The problem I have is when a game gets into the 2KLOC territory and above; when you have multiple files loading at different times in the game engine in order to offer the player a better experience. This leads to many, many handlers and a lot of chaining, and your pretty UML will quickly become incredibly hard to see in the program flow. For instance to save the user you can't just call User.Save and then go about dependent routines, because there is a possibility that call fails or takes a long time and then the player is out of sync. This is especially important if you want to try to minimize cheating, as the longer the client goes without syncing, the higher the probability for tampering, replays, etc.
  - asciilifeform 17y ago
    It seems that Flash doesn't even have a "yield" operator. And if you try to busy-wait, the machine grinds to a halt, because Flash events do not preempt code execution.

Many operations in Flex occur asynchronously, such as when accessing remote services. That is, they spark a remote query, and you must explicitly wait for the response (such as by binding a function to the appropriate change event) before you can continue a computation. Sometimes this occurs when you may not expect it, in which case you'll see problems such as UI controls not being updated, or exceptions from using nil values (because they are used before the response comes back). When you do expect it, you have three options: 1) you always wait for a response before returning, making your function sychronous (thus maybe killing performance), 2) you pass the responsibility to handle this behaviour to the caller (thus creating an abstraction leak), 3) or you define a custom event that you trigger when the response occurs (best behaviour, but needs extra code). Certainly not a huge issue once you get the hang of it, but something that can definitely trip you up when you're just learning it.

cellis 17y ago
It is very similar to ajax. The problem I have is when a game gets into the 2KLOC territory and above; when you have multiple files loading at different times in the game engine in order to offer the player a better experience. This leads to many, many handlers and a lot of chaining, and your pretty UML will quickly become incredibly hard to see in the program flow. For instance to save the user you can't just call User.Save and then go about dependent routines, because there is a possibility that call fails or takes a long time and then the player is out of sync. This is especially important if you want to try to minimize cheating, as the longer the client goes without syncing, the higher the probability for tampering, replays, etc.
- asciilifeform 17y ago
  It seems that Flash doesn't even have a "yield" operator. And if you try to busy-wait, the machine grinds to a halt, because Flash events do not preempt code execution.