On Fri, Jan 8, 2016 at 4:52 AM, Mark Waddingham <m...@livecode.com> wrote:
>
> That actually is referring to *blocking wait* which is evil. Non-blocking
> wait is entirely natural though. It is the difference between being able to
> write code like:
>
> on processThing
> put url "..." into tInput
> put revdb_query(..., "SELECT * FROM x WHERE y = %1", "tInput") into
> tQuery
> doThingWithQueryResult line 1 of tQuery
> end processThing
> And (imagining the existence of certain things):
>
> on processThing
> load url "..." with "processThing2"
> end processThing
>
> on processThing2 pUrlData
> revb_query_async("processThing3", ..., "SELECT * FROM x WHERE y = %1",
> "tInput")
> end processThing2
>
> on processThing3 pQueryData
> doThingWithQueryResult line 1 of pQueryData
> end processThing3
>
This whole problem is one I stop to think about every time I start writing
desktop code that loads data through a web API. One one hand we want to be
able to write code that is compact and easy to understand. On the other
hand we want to have a great user experience for people using our apps.
Currently you can't have both.
The synchronous approach is good because it is easy to read and write. All
of the logic is in one place. The synchronous approach is bad given the
current engine design for a couple of reasons:
1) The interface will not be as responsive (if at all) while the
synchronous requests are going on. Think showing animated busy indicators
or resizing windows.
2) If the user closes the window that the synchronous request is being
performed in you can't cancel the operation. That code is going to keep
running until it is finished.
The asynchronous approach is good for a couple of reasons:
1) The user interface is responsive while the operation is being performed.
2) You can cancel requests if the user decides to close a window that
relied on the request(s).
The asynchronous approach takes a lot more code though. You have to write
the callbacks and if you want to cancel the request then you have to keep
track of the fact that the request is running so you know to cancel it if
the user cancels through the UI.
Personally I don't use asynchronous URL calls any longer in my apps. I
think the user experience suffers too much. I don't know that there is an
ideal solution. I wonder if being able to treat a block of code as a single
entity that could be canceled and would report errors? Take this ugly
pseudo code for example. It allows me to see all of the operations related
to the high level action (processThing) without having to split it up
between multiple commands. It also allows the current async action to be
canceled.
on processThing
start asynchronous block "processThing" with error callback
"AnErrorOccurred" # or maybe you have something similar to try/catch for
reporting errors?
request url "..."
put the response into tInput
query database "myDatabase" with "SELECT * FROM x WHERE y = %1" using
variables tInput
doThingWithQueryResult the query response
end asynchronous block "processThing"
end processThing
# An error occurred in the asynchronous block. No more code in the block
executes and the
# error is reported here.
command AnErrorOccurred pError, pAsynchronousBlockName
answer "Bad things going on in asynchronous block" &&
pAsynchronousBlockName & ":" && pError.
end AnErrorOccurred
# If user clicks Cancel then cancel current async operations.
command uiCancelAsyncOperations
cancel asynchronous block "processThing" -- this would cancel the current
async operation and not execute any more code in the block
end uiCancelAsyncOperations
--
Trevor DeVore
ScreenSteps
www.screensteps.com - www.clarify-it.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
