This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is there a clock in iOS that can be used that cannot be changed by the user
I know in many iOS games that have tasks that take time (i.e. "10 hours until animal done breeding"), one can go into "Settings" and change the time to speed up the completion of the task. In the game I'm developing, I don't want users to do this, so I'm trying to implement a system to prevent this type of cheating. I've put a lot of thought into this, but can't come up with a solution. Basically, my question is how do I keep track of time without relying on the system clock (which can easily be manipulated) for the purpose of preventing users from cheating?
transforming my comment into an answer.
Instead of relying on a user or device, rely on an external source for providing unbiased time. A time server, your server, etc. If you don't trust....
Instead of "X hours of real-world time", would "Y minutes of in-app time" work for you? You can pause/continue a timer when your app suspends/resumes.
Related
Two Quick questions:
Are the seconds value of the clock/time on all iPhones around the world the same? If not, are they close at least & how close?
Do the seconds value of the clock/time on all iPhones around the world change/increment at the exact same time?
Upon request, I'm editing this post and adding the purpose for asking such questions:
I'm trying to make a corporate app that can play a video on multiple iPhones around the world at the exact same time (or as close as possible, ideally the exact same moment). Could you please guide me on how to do this?
Much thanks in advance!
To answer your actual question per se,
Are the seconds value of the clock/time on all iPhones around the world the same?
The fact is, yes, 99.9999% of iPhone users simply use the "get time from a server" system which is of course built in to any phone now.
(Indeed, this simply applies to any Windows, Mac, Android, iOS, etc etc device.)
Yes, they are all "about the same".
You could rely on it being within a second or two, probably even closer.
You cannot rely on it being closer than that.
It seems that you
I'm trying to make a corporate app that can play a video on multiple iPhones around the world at the exact same time
Synchronization in general and streaming video (is it streaming?) is a well-explored (and rather technical) branch of software engineering. (For example a massive amount of game engineering, which is a huge field, relates to inside-the-frame synchronization.)
This is not something you can learn how to do in five minutes, and it requires a stack of device-cloud stuff. Go ahead and ask new questions about this, or just google to get started! Good luck.
Regarding using push notifications.
With the push notification you would send a time. You would not send a "command to play it".
So say right now it is (example) 09:13:28. You would pick a time in the future by a couple minutes. So let's say 09:14:30.
Then using a push notification you would send that information "09:14:30" (and a video file name) to everyone connected. (You'd be sending a "command" as it were, to play video X at 09:14:30.)
Then every device would in fact play the video at 09:14:30 (simply using the local clock, as asked in your question).
Be aware that sending push notifications is extremely sloppy and slow. It can take any amount of time from 5 seconds to a minute, AND quite often there are delays beyond that (ie ten minutes or the like).
I personally would not even bother starting to experiment with push notifications, for the project you describe.
These days, making apps is entirely about using device-cloud services, such as Firebase. Everything is about "OCC" - occasionally connected computing.
(So, you can't get a job "making apps" anymore - i.e. if you know how to move buttons around on an iPhone screen. You get a job because you can make a total, live, device-cloud system - indeed such as you are making.)
Indeed your example project is the perfect such "demo" project for learning about how to do modern apps.
Simply use Firebase to sync everything up.
You'll essentially put a piece of information on Firebase ("play video X at 09:14:30") and that information will be communicated fairly quickly/reliably to everyone connected.
For the particular task you describe, I personally would use PubNub which is faster than Firebase and basically made for game-like problems precisely like you describe.
http://pubnub.com
If you truly needed performance/reliability better than pubnub, you are really talking major engineering. So, the (buildings of) engineers who make live games at Nintendo, Warcraft etc, would tackle such an issue as "being even faster than PubNub".
So, the answer in brief!
The very short answer then to your question posed is:
Learn to use the various device-cloud services, which are at the heart of all apps today. (Knowing how to make "an Android or iOS app", as such, is of no consequence today.) For your particular problem, you'll want to use PubNub specifically, as it is built for precisely realtime problems such as this. (Firebase more leans towards "OCC" type data problems.)
Really that's it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm learning how to parse JSON from web APIs. I have read that I need to asynchronously return my parsed data from the API for my application, as opposed to synchronously. I'm not sure why it has to be asynchronously. I know it has something to do with threading, but that doesn't clarify it for me.
Why do network requests have to be performed asynchronously?
The fact that you should to do this asynchonously has nothing to do with the nature of the response (JSON or otherwise). It’s just that you’re requesting data from an API on a remote server and you don’t know how long it will take (subject to the nature of the network the device is on, how busy the web server is, etc.).
Bottom line, any task that takes more than a few milliseconds should generally be performed asynchronously to ensure a responsive UI, and this API call will take much more time than that.
Analogy time
Imagine that you're employed in the information booth of a train station to manually update a board with trains' statuses. You read off an old-fashioned ticker tape and move models of the trains around so that passengers can see what's going on. You also answer questions about schedules and such directly, when passengers ask you.
You realize that for one particular portion of the board, some information is missing from your tape. Your colleague has the info, but she isn't in the station. So you leave the board, go over to the phone, and call her. You dial, and wait for her to pick up, and then explain what you need. She doesn't have what you need immediately to hand, so she asks you to wait a moment while she gets it.
Meanwhile, the tape doesn't stop. Information about trains continues to come in. but because you're sitting there on the phone waiting, you're not doing anything with it. The people who are watching the board get frustrated, and the people who have questions for you can't ask them either.
Finally, your colleage comes back and gives you what you asked for. You thank her and return to the board. You realize the board is in very bad shape, not reflecting the current state of the world at all. And the passengers with questions have stormed out and left you a one-star review on the App, I mean Train, Store.
Next day, the same situation comes up. You need information you don't have. Instead of stepping away from the board for several minutes, you quickly fire off a text message, and get right back to talking to passengers and moving things around on the board.
In about the same amount of time that you spent waiting on the phone yesterday, you get a text back from your colleague with the information. You incorporate it into your workflow, and nobody even notices that you spend a couple of seconds reading from your phone instead of the ticker tape. Victory!
The first day, you made a synchronous network request. You initiated a conversation with a remote service and waited until you got the response. When that happened, your UI was locked up, neither taking input from the user nor refreshing its own state.
The second day, you made an asynchronous request. You kept working normally until the response came back, allowing you to continue with all your other tasks.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Can an iOS app access the time of events using the iOS clock?
This would seem to be a simple question… but couldn’t find anything on Google search or here on Stackoverflow either.
Q1. I’m doing a feasibility study on building an app that needs to record the precise moment an event occurs. For example, if an event in astronomy, nature (e.g. lightning) occurs at 16h18m22s (4:18pm, 22 seconds), and the app supports the user to record when the event occurs, can the exact time the user taps the button be recorded using the iOS clock as a time reference?
Q2. How much precision is offered by the iOS clock? Is it possible to record the event-time as a decimal of one second? Milliseconds?
For example: 16h18m22s50c (where the last two digits represent 50 centiseconds or 0.5 of a second).
Q3. Would it be safe to assume that, apart from timezone differences, that everyone’s iOS device is reading exactly the same time, what one might call "universal device time"?
Q4. Or if this approach using the iOS clock seems a bit clunky, especially where ultra accuracy is required, would it be smarter to get a feed from an atomic clock server?
Thanks for any input on this one. Appreciated!
Cheers
Q1: yes! Using [[NSDate date] timeIntervalSince1970] you get sub-millisecond precision
Q2: you are going to get milliseconds as explained in Q1.
Q3: Since timeIntervalSince1970 gives you exactly what it says (the time interval since 1970), yes - that is a property unaffected of timezones. (watch out for the but below)
Q4: using a server will destroy any way of retrieving an accurate result since you have to contact the server and wait for a response, that will take around 100ms which is far worse than every inaccuracy the device clock would have.
BUT
the user can change its device time which makes the measurement still exact but useless since it no longer reflect the actual time! What you can do in this case is
retrieve the current timestamp of the action on the device
contact a server with a properly set up clock
compare the measurement and ignore the measurement if it is too far off / alert the user to correct his system time. A comparison threshold of half a second should be okay unless your server is very far away or very slow.
This question already has an answer here:
iOS Detecting connection speed or type [duplicate]
(1 answer)
Closed 9 years ago.
Using Objective C, I need find the specific bandwidth of the network an iOS is connected to. Does anyone have any hints for finding this information with code?
You just need to place a file big enough in one of your servers (or somewhere else)
This could be done using a normal NSURLConnection.
Before start downloading, set up a timer. When your file's been downloaded, you stop the timer. Then you have the amount of time it took for the device to download X MB. You can do the calculations based on this. Once this has been done, the file can be discarded.
Of course, this will vary depending on how far the device is from the server, ping, routing, etc... but I think it's good enough for an implementation this simple. If you want more accuracy repeat the operation several times and calculate average speed.
Alright, this is a design question more than anything. I am making a text based game using Ruby on Rails 3, and I'm not sure the best way to implement what I want to do. In the game, the user gets a bunch of goblins, and can tell those goblins what to do. One of the available actions is attack, which as you can assume, means your tribe attacks something else, whether it be an opposing tribe, or a NPC settlement.
If you choose to attack an opposing tribe, then your goblins go off to attack. There is a set point when the battle will commence, (let's say, 10 minutes in the future). Here's the question, what's the best way to implement running the simulation for the battle in exactly 10 (or X) minutes in the future? Because if the simulation is run too soon or too late, then the entire outcome of the battle could be changed by what the opponent does.
(I know it's a little vague, but for those of you who have played Ogame, entire battle outcomes can change if the simulation is run a second too soon or late.)
I was looking at ways to implement having something run at X time in the future (this episode, and the two previous), but it doesn't seem to be tuned toward something that needs to be run precisely at time X. I also looked in to Ruby timers, but there doesn't seem to be a consistent one, like there is in java, nor do they automatically make the data persistent. I was hoping for low coupling too, perhaps using the observer pattern.
So there you have it. If I send my attack, or want to do anything at exactly time X in the future, what's the best way to do this in Ruby on Rails?
Simple answer: Don't
You should save the time (now+10 minutes) in a database and then run a cronjob every minute (or whatever you prefer). This should then evaluate all fights that should be fought at that time.
For best practices on this behaviour see A cron job for rails: best practices?
You could also add a check if a fight can be fought on every request you get. This way you'll get a little bit more randomness when the fight will start exactly and depending on the traffic of your site, this could be like every second. Remember to start a thread to evaluate the fight, depending on the amount of your calculations. Otherwise some users can experience massive lags.
The typical thing to do if you want some event to happen in the future with ruby on rails is to use cron to fire externally (as simon suggested) or use the delayed_job gem and set a job for the future. You can also use rufus-scheduler gem like this:
scheduler.in '10m' do
puts "something happening 10 minutes from now"
end