I'm looking for a (likely) NSNotification which signals when a computer hasn't been used in x amount of time. Or it would be acceptable to have a notification that tells you every 1 or two minutes if it has been inactive since the last time.
It doesn't have to be a NSNotification, I just guessed based on other notifications that this would be how they were distributed.
Bonus points, anything special needed to pause NSTimers using this information?
The question is rather broad, by computer I assume you mean the same computer the application is running on. If you are talking about another computer then the issue is more complex as one case of not beeing used for another computer is that it is turned off and then no notification can be sent. Thus if you are looking for a solution for any computer you need to implement some form of ping/heartbeat functionality.
If you mean on the same computer you still need to define what not beeing used means. No mouse or keyboard activity perhaps. But what about a user listening to music or watching youtube - is that in use or not?
In any case I think you cannot hope for a system message when it is not in use. I think you need to track the absence of messages that prove it is in use. One very heavy-handed appoach would be to trap all mouse and keyboard action and check how long ago you got the last such activity. This could be used as an indication of no activity.
For example the class method on NSEvent + (id)addGlobalMonitorForEventsMatchingMask: NSEventMask)mask handler:(void (^)(NSEvent*))block could be something to look into - but be prepared to handle a lot of events I suspect.
I've recently started to work on Time attendance software. People are using cards to check in and check out, but sometimes they check out before they check in and then some of them realize they made mistake and check in again. sometimes they check in instead of check out. I wrote an application that creates report and everything works fine when mistakes are simple, but sometimes people are just people and they check in for example 15 times.
I know my question is kinda complex and I doubt there is and answer but I was wondering if there is any algorithm which can determine such mistakes and can create decent report.
thanks in advance.
I think really if you are trying to have your software guess what the users intent was then you would need to base it on what the users schedule should be and what their expected check in/out cycle looks like
If its a workplace and the users are punching in their time and they work 8 hour shifts, you could try to be smart and flag checkins 7.5-8.5 hours apart as probably a check in that should have been a check out. Then you could flag back to back checkins 23+ hours apart as probably a missed check out on the previous shift. 16 hour differences would still probably be impossible to guess because they could be clocking out for a double, or changing their schedule and working an earlier shift the next day.
If this was for a college building you could probably at least say that back to back checkins that occur on separate calendar days were a missed checkout.
I am programming a 30-Day-trial application, I need to make sure if the user changes the system time it will not harm my application and the 30-day-trial will still be calculated, or at least I will be able to figure he did something wrong.
The best way I found is to check for a system file which its contents updated and every update contains the time with its data, so I can find out if the user changes the date or not, by comparing the dates with each other ...
I know it is not certain way, but it is kind of make it harder and shrink the area of who can crack it.
I found about Event log
windows7 log files
it can help..
Any solution proposed can be hacked. But it sounds like you only want to ward off the casual pirate, not the determined hacker.
Instead of trusting the system clock, how about just making a network request back to your own website or time server to get the current date and time?
Another idea is to just limit the number of times the application can be launched instead of limiting it to a specific amount of time.
I'm working on an app that will be used by the public services (ambulance). Since those people work around the clock, they will realistically need to enter date/time values at ANY time of the day. Which also includes DST changeover times.
Now, when entering the time at the "short" day, things are easy. Simply any value between 3:00:00 and 3:59:59 is invalid. Problem is with the "long" day, where values in that same interval are ambiguous.
Is there any standard way/notation for entering time at that dreadful hour? Have you ever used any other workarounds, and which ones did your users find good?
Added: Also cloned on ux.stackexchange.
Allow the user to enter the localised time (i.e. whatever their PC clock is displaying) but save it in UTC. When you display them remember to use a localised time method and it will fix itself, see this SO Question for more details: How to display localized date and time information to web users with ASP.NET
I'm trying to find a benchmark for how long users are willing to wait for a response from a remote service. In my case the response is for very useful but not business critical validation of data entry. I guess that there must have been some work done in the HCI space on this.
If you know of a generally accepted definition for soft realtime responses then great but I'd also appreciate your well reasoned thoughts.
Chris
US DOD MIL-STD 1472-F Human Engineering Standard has the most widely accepted requirements for maximum allowed response time (from Table XXII, page 196, times in seconds):
Key Response (Key depression until positive response, e.g., "click"): 0.1
Key Print (Key depression until appearance of character): 0.2
Page Turn (End of request until first few lines are visible): 1.0
Page Scan (End of request until text begins to scroll): 0.5
XY Entry (From selection of field until visual verification): 0.2
Function (From selection of command until response): 2.0
Pointing (From input of point to display point): 0.2
Sketching (From input of point to display of line): 0.2
Local Update (Change to image using local data base, e.g., new menu list): 0.5
Host Update (from display buffer): 2.0
File Update (Change where data is at host in readily accessible form): 10.0
Inquiry - Simple (e.g., a scale change of existing image): 2.0
Inquiry - Complex (Image update requires an access to a host file): 10.0
Error Feedback (From command until display of a commonly used message): 2.0
As you can see, acceptable response time depends on what response the user is waiting for. For something like a pulldown menu appearing, it's 0.5 seconds max. For a full page load in a browser, you want something to appear in 1.0 s to 2.0 s and the full page loaded in 10.0 s. In all the above, shorter response times are better. Only in bizarre circumstances will users object to a 0.001s response time.
In any case, if the response time will be greater than 0.5 s, then you need to provide feedback such as a throbber or hourglass sprite. If response time is a minimum of 5-15 s (depending on what standard you use), provide a progress bar. With a progress bar, very long response times (on the order or minutes over even hours) may be acceptable as long as you set it up for the user as a “batch” process rather than being an interactive program. It's much better for the user to make all input and wait an hour than to make input on four occasions, waiting 15 minutes after each.
The above list has the accepted standards. How long your users are willing to wait (e.g., before giving up) essentially boils down to the user making a cost-benefit analysis. Is what I’m going to get worth the wait? What are my sunk costs? Is there an alternative (e.g., another web site) that can do it better? Can I do other things while I wait to make the most of my time? However, whatever users willing to do, you can bet they’ll resent delays greater than the standards above.
Human reaction time seems to be around 200 ms - anything around there will be perceived as instantaneous. That sort of number is hard to achieve, especially in an application that gets information from remote services.
If you take a look at Google's search suggestion box, the lag there is minimal - less than a second. It's astoundingly fast, and really remarkable for a web application. This is really nice for Google's users, but it's bad news for you. These days, users expect most applications to react with the same sort of speed an efficiency; anything slower is considered rather laggy. However, it's worth noting that people's patience usually varies with the complexity of the task at hand. A simple form submit should never take much time, but something like uploading photos is expected to take a while.
My feeling is this: go with your gut. If your application is fairly simple then you should try to get the wait/load time down to less than a second. If you can't, then your best bet is to add an indicator so the user knows that some computations are being done in the background. This can be in the form of a small animation or a progress bar.
Unfortunately, the answer to this question is not typically a well-defined number. Users expectations vary widely and can change depending on what it is you're talking about.
As computers continue to become more ubiquitous and we (the consumers) continue to have growing expectations of speed, remote services, websites, and even applications will need to continue to respond more quickly. Generally speaking, you want everything to be as fast as possible.
With this said, I would look at what your remote service is for. Since you said, "the response is for very useful..." to me, that means it probably will get used frequently. People tend to use what is useful. If that's the case, I would look for ways to make that remote service respond quickly.
Of course, there is also the caveat that you don't want to start optimizing before the service is written. What is the current response time? What is the context in which this will be used? Those factors will do a lot to determine the longest users are willing to wait for the service.
You might want to search for "SLA" or "Service Level Agreement". Those are the documents in a web business that make guarantees as to how long data will take to get back to the user, whether it's an HTML document or a web service call.