I have a scenario, wherein if the user stays idle on the screen for 45 minutes, I will have to transfer the user to home screen.
In my Espresso test, I want to recreate the scenario, and i would not want to wait for 30 minutes for that to happen.
Is there a way we can advance time in Espresso?
I have checked idlingresource and waitingforview etc, but none of them seemed right to me. Can anyone guide me on how to advance time in espresso?
I don't know about manipulating the system clock for a test, but instead of hardcoding a 45-minute wait, you might want to handle the time limit with dependency injection - either by setting a timeout property, or passing in a Clock object that the code refers to, instead of accessing the system clock directly.
That way your test can either configure it with a more useful timeout setting, or the Activity (or whatever) can poll a Clock that you're able to manipulate from the test. (Having a configurable timeout would allow you to do things like set it as a user option too, maybe change the value in power-saving mode, etc)
Related
I have a timer that talks to java objects through LS2J. It has only to call some getters of the java objects and to update the GUI with new values. This causes the GUI in iNotes Client to show the "Busy" cursor very shortly when the timer ticks. I is really annoying because it occurs even when another window is open and even in the designer.
I actually have to expect that the functionality in the timer event will get more complicated in the future, so I don't want to solve the problem by making my handler lighter.
Is there a way to tell iNotes client not to show this cursor or even an alternative way to make this regular check without timers?
The NotesTimer class in Notes client (not iNotes) does take over the foreground when it triggers, so there will be a bit of a delay if you do something that takes time to execute. It's possible to set up the Notes client to execute background scheduled agents in local database replicas, so that might be an option. You can to the heavy lifting in background and deposit the results somewhere -- say, in a profile document -- that can be accessed quickly by the UI code.
Alternately, you could try a XPages in the client application. I believe it can do partial refreshes while other stuff is going on.
For the record, I simplified the functionality of the Java call by preparing the data so that the timer only has to read the results. I also made the timer run every 3 seconds instead of 1.
Now I don't see any flicker!
I'm using Selenium WebDriver to get some content from a site that dynamically loads it using Ajax. I created a custom Wait class to check for a condition on the page to make sure that the page has loaded before continuing. I used FluentWait to set the polling interval to 2 and timeout to 10. However, I noticed that it checks for the first time at time increment 0, then waits 2 seconds if the condition was false, then checks again, etc.
Since the page takes some time to load, it always is false at the first check, but usually is true at the second. Is there any way to make Wait wait the 2 seconds before checking for the first time? I.e. check at times 2,4,and 6, if necessary, rather than at 0,2,4,and 6?
Thanks,
bsg
EDIT
I've been asked to mention why I want this behavior - after all, I'm using the Wait the way it's meant to be used. The benefit I get from it returning true the first time is the following: WebDriver apparently opens a new socket every time it issues a command to the browser. For whatever reason, these sockets don't always get closed after the call executes. When executing a large number of calls in a short time (for instance, when repeatedly checking for a condition, which is what Wait does), it is possible to run out of virtual sockets, and the driver crashes. (The lack of enough virtual sockets seems to be a known issue on Windows 7, but I can't modify my system.)
The fewer calls to the driver I issue in a short period of time, the less likely it is to overrun the number of available sockets. I have observed that the first check never returns true, and therefore it's just opening a socket for no reason, making the program more likely to crash. That's why I want to wait. I hope this explanation is helpful for someone searching for information as to why they keep getting SocketExceptions in WebDriver.
The obvious answer would be to just insert a time.sleep(2) (or similar method) before your first check. Would that work for what you're trying to do?
What's the best way of detecting when a user has been idle for X amount of time, and then detect when the user becomes immediately active?
I know there's NSWorkspace which provides will/did sleep/wake notifications, but I can't rely on that because the sleep setting is usually about ~15 minutes to never. I need to be able to detect if the user's been idle for ~1-2 minutes.
This answer provides a way to get the idle time. I'd like to avoid polling if possible.
Polling is your only option, to my knowledge. As user1118321 points out, polling every O(minutes) is unlikely to cause any problems, performance or otherwise.
If your app has a GUI and receives UI events anyway, you could install a handler via +[NSEvent addLocalMonitorForEventsMatchingMask:handler:] that resets your timer on each event. That'll help reduce if not eliminate polls when the user is consistently active, in your own app at least.
Once you've determined that the user has been idle long enough, you could then install a global event tap to watch for the next event. See for example -[NSEvent addGlobalMonitorForEventsMatchingMask:handler:].
Note: you should use CGEventSourceSecondsSinceLastEventType if at all possible rather than poking into the IO registry. It's a formal, supported API and may be more efficient. Not to mention it's way simpler. There's also UKIdleTimer though it relies on Carbon, so may not be applicable.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How can I locally detect iPhone clock advancement by a user between app runs?
Is there a way to determine the actual time and date in iOS (not the time of the device)
Is there a clock in iOS that can be used that cannot be changed by the user
Brief
I am working with an auto-renewable subscription-based app. When the app receives the latest receipt from Apple, it stores the expires_date_ms key in NSUserDefaults. Thirty days after that date, the app checks with Apple to see if the subscription is still active. The app can be considered an offline app, but it must connect to the internet once every 30 days in order to check the subscription status. This time comparison will be used to tell the user he/she must connect.
Problem
I am using the code below to compare the current time with the expires_date_ms:
NSTimeInterval expDateMS = [[productInfo objectForKey:#"expires_date_ms"] doubleValue];
NSTimeInterval currentDateMS = ([[NSDate date] timeIntervalSince1970] * 1000);
if (currentDateMS > expDateMS)
subExpired = YES;
This is fine and works well, but from what I can tell there's a loophole that can be exploited - if the user sets the device's clock back a hour/month/decade, the time comparison will become unreliable because [NSDate date] uses the device's current time (please correct me if I'm wrong).
Question
Is there any way of retrieving a device-independent time in milliseconds? One that can be accurately and reliably measured with no regards to the device clock?
While Kevin and H2CO3 are completely correct, there are other solutions for the purposes of checking a subscription (which I would hope does not need millisecond accuracy....)
First watch UIApplicationSignificantTimeChangeNotification so that you get notifications of when the time changes suddenly. This will even be delivered to you if you were suspended (though I don't believe you will receive it if you were terminated). This gets called when there is a carrier time update, and I believe it is called when there is manual time update (check). It also is called at local midnight and at DST changes. The point is that it's called pretty often when the time suddenly changes.
Keep track of what time it was when you go into the background. Keep track of what time it is when you come back into the foreground. If time moves radically backwards (more than a day or two), kindly suggest that you would like access to the network to check things. Whenever you check-in with your server, it should tell you what time it thinks it is. You can use that to synchronize the system.
You can similarly keep track of your actual runtime. If it gets wildly out of sync with apparent runtime, then again, request access to the network to sync things up.
I'm certain that attackers would be able to sneak 35 days or whatever out of this system rather than 30, but anyone willing to work that hard will just crack your software and take the check out entirely. The focus here is the uncommitted attacker who is just messing with their clock. And that you can catch pretty well.
You should test this carefully, and be very hesitant to accuse the user of anything. Just connecting to your server should always be enough to get a legitimate user working again.
You need to connect to/retrieve information from a reliable, official time server and use that time data in your app. For example, here's a world time server with an easy-to use API
Here are three options I can think of:
clock_gettime(CLOCK_MONOTONIC) gets the current system uptime. This is relatively unreliable because if the user reboots, this is reset. You could save the last value used and at launch use the last saved value as an offset, but the problem with this is that the time that the device was shut off for won't be calculated.
mach_absolute_time() counts the number of CPU ticks since the last reboot. It can be fetched easily through CACurrentMediaTime. Note that this can be reset simply by rebooting the device, so if changing the time is very important, I'm not so sure if you would go this way.
Network Time Protocol (NTP) is a networking protocol for synchronizing the clocks of computer systems. In practice, all NTP is is querying a time server. An iOS library for NTP can be found here.
So the first two methods do not require connectivity, while the third does. However, the third method is the only foolproof one.
There is no such thing as a non-mutable device clock that persists across reboots. The only way to get a trustworthy time is to contact a remote server that you trust and ask what its time is.
I am creating a BREW app that requests the user's position.
If the phone cannot acquire the position, I would like to display an error.
How long should I wait for my callback to be called before I determine that the phone is not likely to get a GPS fix?
When a cold start is required, the receiver has to download a full set of Ephemeris data, which is broadcast from the GPS satellite over a 30 second cycle and re-transmitted every 30 seconds.
So I would say that 60-90 seconds (two or three Ephemeris cycles) would be a suitable time to wait before declaring failure.
http://www.navigadget.com/index.php/gps-knowledge/ttff-time-to-first-fix
Note that if a device requires an almanac download, the startup time can be much longer (on the order of 12.5 to 15 minutes). This is referred to as a Factory TTFF (Time to First Fix).
I might go with an increment (say 20 or 30 seconds) between notifying the user that you have failed to establish a link, and give them the option to stop trying. Keep at it until they stop you, or a set number of iterations have passes (say 5 - 10 iterations).
45-90 seconds.
For more information, see the GPS Time To First Fix article at Wikipedia.
But you can never know when the user actually has view to the satellites or not, maybe they are still inside when they start your program, so the approach suggested by Matthew Vines is much better than a constant delay.
Cellphone-specifically, I've had a Motorola phone that had a GPS receiver, but was horrendously bad at it - it could take it around 5 minutes to get a fix where my standalone Bluetooth receiver would manage in less than a minute.
Why are you declaring failure after a fixed timeout anyway? Why not, after a reasonable time has passed (say, a minute), display a message to the tune of "GPS fix still not available; but I'm still trying" with a possibility to cancel at any time if the user is fed up? What do you expect the user to do with the failure message you're proposing to give him?