I have written an Apple Watch app with a complication that works well. But I often accidentally click on that complication, and it opens my watch app.
Is there some attribute to tell the complication that there is no action when I click on it?
As an example, the sunrise/sunset complication has no click action.
No. There is no ClockKit feature which would stop it from launching your app when you (inadvertently) tap your complication.
You can, however, slide your finger away from your complication, which will deselect it, and avoid opening your app.
You can get a feel for this by long pressing your complication, which will indicate that it's selected. If you slightly swipe away from it, it will deselect itself. If you swipe too far, you may bring up a glance or notification.
Apart from deselecting the complication, I'm not sure that there would be a way to handle any inadvertent-versus-intentional interaction, where you might not want the app to be launched. If you can come up with a case, you should submit a feature request to Apple.
Related
First I want to make clear that my problem is not a technical question. I want to talk about usability.
In my company we have a function to check if a scale works properly. We have the button you see bellow (1) to start a function named scaleCheck(). During the scale check the weight of the scale is set to 0 and then a specified weight is put on the scale automatically and when the weight matches the number set in a config file the scale is OK. So when you click on the button, it gets the white border (2) and when the check is finished the button turns normal again (3).
This is the automatic process, but not every customer has a scale which can put automatically a weight on it. So in this case the customer has to go to the scale an put a weight on it by his own. In our application the customer can configure, if he wants the process to be manual or automatic and the button will adjust to this. So when the configuration is set on manual we have to interrupt our function an wait for the customer until he is ready. Because we don't know how many time he will need, he has to click on the button again to tell the application that the process can continue. Therefore we changed the button a bit when we are in manual mode. As you can see below the button (1) changes the image, when the customer clicks the first time on it (2), to show that the weight has to be put on the scale. When he clicks the second time the process proceeds (3).
So this is the current state. The automatic mode works how the customers imagine it to be, but in the manual mode many people have problems with it and need a lot of time the recognize that they have to click on the same button again they clicked before.
And here is my question, is there a better way to show the customers that this button should be clicked again. Are there some people who have experiences with a similar kind of functionality? Or is there a better way to do it? I'm open for every idea which comes in.
We ended up with the opinion that it is not a intuitive solution to click twice on the button. We solved it by showing the user a message after the first click on the button, and accepting that message is count as the second click. With usability in mind this i by far a better solution and the customers can handle this situation much better.
In the apple watch's passcode setting screen the passcode on top updates as soon as a user clicks on the buttons and not after lifting the finger. How can one achieve that in Xcode 6.3? Because the only event that triggers the ibaction is the touch up event
I don't think that behavior is possible with the current version of WatchKit. Apple is likely using their own internal method to accomplish that (as they do with many/most of the default Watch apps). Hopefully we'll get more functionality in the next major update.
From what I see, QApplication::mouseButtons() may return no buttons even when a button is held down. This happens when you have clicked a side of a window for re-sizing. It's coherent with the docs because mouseButtons() reflects the state from the flow of QEvent::mouseButtonPress, etc. However, I need just to know if the button is held down. Does any one know if it's possible through the Qt API?
I think it's not possible. Mouse events outside an application's window are not passed to its event handlers. Dragging mouse borders is one of such events, it's processed by the window system. Another example is clicking on other windows. Usually an application doesn't know what the user does with other windows. You need to install system-wide event listener or use native API features(e.g. GetAsyncKeyState on Windows) to determine that. This behavior is unusual and possibly dangerous. In most cases it's not useful, and it seems that Qt doesn't have this ability.
Looking through the documentation, it seems that the new advanced gestures API doesn't determine the direction of a swipe beyond the basic { left, right, up, down }.
I need the start point of the swipe and the direction.
Is there anyway to retrieve this other than coding my own advanced gesture library from scratch out the basic gestures?
And if this is my only option, could anyone point me to some open source code that does this?
Got it! Documentation is here, under 'Creating Custom Gesture Recognizers' at the bottom.
Basically the six gestures Apple provides all derive from UIGestureRecognizer, and you can make your own gesture recogniser in the same way.
then, inside your view's init, you hook up your recogniser. and just the act of hooking it up automatically reroutes incoming touch events.
Actually, the default behaviour is to make your recogniser an Observer of these events. Which means your view gets them as it used to, and in addition if your recogniser spots a gesture it will trigger your myCustomEventHandler method inside your view (you passed its selector when you hooked up your recogniser).
But sometimes you want to prevent the original touch events from reaching the view, and you can fiddle around in your recogniser to do that. so it's a bit misleading to think of it as an ' observer '.
There is one other scenario, where one gesture needs to eat another. Like you can't just send back a single click if your view is also primed to receive double clicks. You have to wait for the double-click recogniser to report failure. and if it is successful, you need to fail the single click -- obviously you don't want to send both back!
I have a Flex app I built. It uses the BrowserManager class to listen for changes in the # part of the URL. When a change is made to the hash my application updates accordingly so you can link directly to a state of the application. Also inside my programming when a user clicks something, all I do is use the BrowserManager to update the # and then my listener will apply the correct changes once its finished. I believe this is the best practice way to doing this in Flex.
I have some issues though. When using the Back button in FF or IE, it gets "stuck". for example if the hash is like #state4 clicking the back button will take you to #state3 then #state2 but sometimes get stuck where you can be on #state3 click the back button, see it flicker to #state2 real quick then change back to #state3 preventing you from going back any further in your history.
Now in Chrome its even worse. As you make your way through the application the hash # is updated and so the application updates (proving that the app can see changes in the hash since thats the only way it updates). but when you click the back button, the hash # goes back to its previous state, but my application does not as if it is unaware the hash is changing.
I find this very bizarre and don't know what to make of it. I was wondering if anyone else had experienced this or knows what might be the issue.
To see it in action go here and navigate the builder (it will ask you to click jewelry type, metal, etc.) a few times until you see the big red add to cart button, then try to use your back button to get back to this page.
Have you tried the History Manager. Have a look on the http://www.nbilyk.com/blog/1/68/flex-history-manager