The last sentence of the Apple Documentation for ARSession.run(_:options) in the the discussion section states:
ARSession.run(_:options)https://developer.apple.com/documentation/arkit/arsession/2875735-run?changes=latest_minor
”After you call this method, the session runs asynchronously.”
What do this mean?
Does it mean it runs on a different thread from the main forever?
Or
Does it mean that while it is transitioning from the previous session to new session it will be rerunning on a different thread?
Or
Does it mean something else?
I really want like to know/understand and would really appreciate any kind soul out there who would like to give some insight:-)
Thank you to the kind ARKit community,
We all learn by sharing what we know
Smartdog
“(A)synchronous” doesn’t have to mean multithreaded.
I’m pretty sure all they mean by that is:
the run(_:options:) call returns immediately
the session is an ongoing process (at least partly in the main run loop, since it has per-frame callbacks, but possibly also involving other threads you don’t see)
This would be in contrast calls that are “synchronous” meaning that all effects of the call complete before it returns.
On iOS 10 I am trying to create a match using the GKTurnBasedMatchmakerViewController. I can bring up the view so the user can choose matchmaking or an invite. I can't figure out how to reliably determine which match got created in response to that. The problem is that, in iOS 10, the didFindMatch method of the GKTurnBasedMatchmakerViewControllerDelegate has been deprecated. That method used to be called with the match. The old days were easy!
The deprecation message says "use GKTurnBasedEventListener player:receivedTurnEventForMatch:didBecomeActive". The docs and stack overflow threads are filled with reasons why that method gets called. See this thread for a good list: Gamecenter ios 9 GameCenter GKLocalPlayerListener methods not called. If you imagine a user that already has several games going, you can see that this method will be called for a lot of different reasons and it could happen at any time, as far as I know. My question is: how to determine which of these calls is the "I just created a match for you, here it is!" call.
Some examples I think won't work:
Simply assuming the first call to receivedTurnEventForMatch that happens after you bring up the GKTurnBasedMatchmakerViewController seems wrong since receivedTurnEventForMatch could be notifying the user that it is their turn in another game. Unless the system guarantees that, while the view is up, they will only call this method with the match that corresponds to the view. That seems like a pretty big hack, so I'm assuming they don't do it.
A call to receivedTurnEventForMatch with the other player in "Matching" state and didBecomeActive=true seems to be a solution for the first player in a match, but not the second (since both players are done matching).
Looking at the MatchID and seeing if we've "seen it before", and if not, assuming it is the match that just got created seems unreliable since the user might have uninstalled the app and then reinstalled and we've forgotten all about which matches we've "seen before".
I'm stuck, any help is appreciated.
Double check your status when the event handler fires. I believe you should still be in invited state until you accept the match.
edit: Actually, I believe there will be two conditions that indicate a new match when the event handler fires:
You are in the invited state (you joined)
Everyone else is in the invited or automatch state (you started the match)
edit 2:
Checking my old code, it turns out that I looked at the matchData object. Since I knew that player 2 doesn't receive the invite until player1 ended the turn (and so forth), and since I knew that player1 had to save match data in order to end the turn, if matchData.length was greater than zero, I assumed I was joining a game in progress. I didn't rely on the participant status. But that doesn't solve your problem.
The other thing I did was create my own header struct which I inserted at the start of the NSData. In that header, player1 would set status flags for each other player, that would be obvious when those players joined. I totally ignored the participant status in the match object.
Regarding your third bullet, instead of saving the list locally, you could save it remotely using cloudKit. The cloudkit data will persist across installs/uninstalls unless you specifically delete it.
The gist with cloudkit is:
when you enable it in your app, your app gets a "container" with a public database that all users can share plus a private database unique to each app user.
You can create a record in the private database with a "Bytes" field
You can save a NSMutableArray directly into the aforementioned Bytes field
You can read back a NSMutableArray directly from the Bytes field
In the everyday front-end development I often use DOM as a global event bus that is accessible to every part of my client-side application.
But there is one "feature" in it, that can be considered harmful, in my opinion: any listener can prevent propagation of an event emitted via this "bus".
So, I'm wondering, when this feature can be helpful. Is it wise to allow one listener to "disable" all the other? What if that listener does not have all information needed to make right decision about such action?
Upd
This is not a question about "what is bubbling and capturing", or "how Event.stopPropagation actually works".
This is question about "Is this good solution, to allow any subscriber to affect an event flow"?
We need (I am talking about current usage in JS) stopPropagation() when we want to prevent listeners to interfere with each other. However, it is not mandatory to do so.
Actual reasons to avoid stopPropagation:
Using it usually means that you are aware of code waiting for the same event, and interfering with what the current listener does. If it is the case, then there may (see below) be a design problem here. We try to avoid managing a single thing at multiple different places.
There may be other listeners waiting for the same type of event, while not interfering with what the current listener does. In this case, stopPropagation() may become a problem.
But let's say that you put a magic listener on a container-element, fired on every click to perform some magic. The magic listener only knows about magic, not about the document (at least not before its magic). It does one thing. In this case, it is a good design choice to leave it knowing only magic.
If one day you need to prevent clicks in a particular zone from firing this magic, as it is bad to expose document-specific distinctions to the magic listener, then it is wise to prevent propagation elsewhere.
An even better solution though might be (I think) to have a single listener which decides if it needs to call the magic function or not, instead of the magic function being a stoppable listener. This way you keep a clean logic while exposing nothing.
To provide (I am talking about API design) a way for subscribers to affect the flow is not wrong; it depends on the needs behing this feature. It might be useful to the developers using it. For example, stopPropagation has been (and is) quite useful for lots of people.
Some systems implement a continueX method instead of stopX. In JavaScript, it is very useful when the callees may perform some asynchronous processing like an AJA* request. However, it is not appliable to the DOM, as the DOM needs results in time. I see stopPropagation as a clever design choice for the DOM API.
I always put calls to Response.Redirect in my WebForm's OnLoad method, mostly because every example I've seen do that. I was wondering if it was any more efficient (and correct) to do that in OnPreInit? Even if the endResponse param is true?
Obviously, the sooner the better. Don't make your server do any more work than it needs to before redirecting to the real page of interest.
However, you don't always know you want to redirect prior the page load event, or even later- perhaps after handling a button press event.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Re the recent question at when are modal dialogs truly necessary?. WHY are modal dialog boxes evil? Is it because people don't read them anyway? Because they are often implemented so poorly? Something else?
About half of the answers so far are addressing the flaws of confirmation dialogs, not of modal dialogs. While the vast majority of confirmation dialogs are modal, this does not mean that the two terms are synonymous.
A modal dialog is one which puts the program into a specific mode and does not allow you to do anything which doesn't correspond to that mode while it is open. In the most common implementation, this means you can't access any other windows.
This is evil.
Consider an address book application. Suppose you have an existing person in the address book and you wish to add their roommate.
If the "add person" dialog is non-modal, you can flip back and forth between the old record and the new one copying and pasting your data.
If the "add person" dialog is modal, you can't do anything with the old record while the add dialog is open. You can select something to copy before selecting "add", but just one thing. Everything else has to be manually retyped.
On rare occasions, you run into something which truly must be done in one piece without allowing the user to diverge from that task until it is complete. Modal dialogs are appropriate for such cases. But these cases are very rare! Which is basically the point of the other thread referenced by this question.
People don't read them, and that's a good thing. You want people to form habits around your UI, but having an important choice in popup is just going to make the user hit OK.
They interrupt the user, they prevent the user from doing other things.
What if you wanted to copy and paste something off the main window? What if you wanted to copy the message in the modal dialog? What if you don't care.
Just compare IE's Find dialog vs Firefox
Compare IE's "Do you want us to remember this password for you?" to Firefox
The best UIs are modal. As are the worst.
A modal UI - regardless of whether it is built from dialog boxes, toolbar buttons, or text prompts - is only desirable so long as each mode matches the expectations of the user transitioning to it. When the program transitions into a mode unexpectedly... or the mode requires the user to possess information he does not have readily available... then it will cause the user hardship, either forcing him to revert to a previous mode or guess at the proper action with potentially undesirable results.
A non-modal UI is a complete set of tools. Some are relevant to the job at hand, some are not. A user must have sufficient skill both to choose the correct tools, and to apply them in the correct manner. While a non-modal UI can therefore never be as optimal as a good modal UI (the right tool for the current task already in hand), it can also never be as sub-optimal as a bad modal UI (the wrong tool for the current task slamming into your careless fingers).
Designing a good modal UI can be a fiendishly difficult task for non-trivial applications, especially for general-purpose programs intended to be used by a wide variety of users for an even broader range of purposes. Menu systems and dialog boxes attempt to bridge the gap, allowing small, task-specific modal sections in a larger, non-modal application. Neither one scales particularly well however, and mis-use and overuse have left them with a bad reputation, often seen as the first refuge of the lazy programmer. Dialog boxes in particular are often used more as a means of forcing users into a programmer's (or designer's) idea of how an application should be used, or punting difficult design decisions and tricky error handling at the user, rather than for their namesake goal of communication.
Indeed, the rise of web applications has brought such tendencies to the surface in numerous forums, newsgroups, and Q&A sites such as this one, as programmers accustomed to writing ultra-linear logic which prompts users for input when needed by the program rather than when available to the user... are forced into a system where users can navigate non-linearly, and may well view any attempt to restrict this freedom as a quaint annoyance to be subverted rather than a necessary evil. The plaintive wails of these poor coders echo around the 'Net as their attempts to force this crude modal behavior onto a non-modal system come crashing down around them. For those of us who have long suffered under their cruel "dialogs", it is a lovely tune indeed.
Before you get to read my answer, you must carefully read the following message in it's entirety. All processes, subprocesses, tasks, and threads are suspended indefinitely pending your answer. And, once you completely understand the message, and possibly agree to some legal stuff, and all the implications of all of this, then and only then can you proceed.
In a consumer style application, they are more or less useless; users don't read them, learn to dismiss them, and when they DO read them, usually end up being confused. I think a Yes/No/Cancel dialog is downright lazy UI design. The "buttons say what they do" dialog is slightly better, because the user doesn't have to read much.
That being said: In data-critical intranet/"enterprise" applications, they are more or less necessary to confirm destructive actions or to sanity check non-standard workflows that may be allowed but not recommended.
So, I don't think they are conceptually "evil", but more often than not, the result of bad UI design.
They are evil because they violate the basic principle that the user is supposed to be able to direct the software's action. Modal dialogs (the evil form of dialog boxes in general) constrain the user to only one action.
Some answers seem to misapprehend that it's any popup that asks for e.g. user confirmation. This could be accomplished without tieing up the entire app or computer; it's this behavior that people object to.
In some environments, modal dialogs only constrain the user in the context of a single application (or maybe less). Really bad modal dialogs prevent the user from doing anything else in the entire operating system (say, Windows).
One of the reasons that I don't like them is because they are showing information in serial(one lot of information at a time) and not parallel(all the information you need to see at once), parallel will allow the user to choose what they want to look at where as in serial you are pretty much forcing them to pick an option.
Plus also the fact that they break a users flow of control(eg steals focus from the object you working on) which I really don't like doing. So in effect from this the user will just hit OK so that they can get back to what they where doing and ignore the information in the dialog box.
Mind you you still need them in some cases.
I don't remember where I saw this first, but a better approach to a modal dialog is often to allow an easy to find and use "undo" capability. Windows Explorer actually does both when you delete a file. It asks for confirmation (modal dialog), then, immediately after deleting the file, the Edit menu has an "Undo Delete" option. just a simple way to access the Recycle Bin, for sure, but in this case, Microsoft really could have just done away with the dialog.
The point being, you can often do without the dialog with a bit of thinking, and perhaps a bit of extra code, but it's just too easy an option for a lazy, or perhaps, more generously, a time-constrained developer.
That said, sometimes you really want a dialog. Think about all of the options on a typical Print dialog. Which printer? All pages, or just a few? How many copies? I don't know how you'd do that without a dialog box...
Noboy reads them, and they interrupt the program flow. Often when used as error notification they are the precurrsor to a program failure. By the time the user realizes what is going on, the message is gone and they are left to recall or invent the message as best they can.
Personally I think it depends entirely on how it is done.
Try copying 10 files where every file exists in the target directory, do it using Windows Explorer.
Is a single modal dialog for each file really the correct answer in such an operation. I know you have "Yes to all", but the entire loop system should've been built differently. It should've gathered all the files that exists into one big list and asked once "What do you want to do with these files", and then let me decide for each file down the list what to do before clicking OK and resuming the operation.
And lots of times dialog boxes just interrupt the normal workflow.
And yes, people don't read dialog boxes. So a golden tip if you must use a dialog box is to reword it.
Instead of "Do you want to delete this row in the database?", try wording it so that you're asking (but this isn't worded right) "Do you want to not delete this row in the database?" This way, if they just hit Yes, which is the typical response from a user who just wants to get on with it, they'll end up doing nothing.