It is more or less asking how Whattsapp, Instagram, Facebook etc works.
How does my Phone know i got a new message even if the app is closed
(Please dont focus that much on the examples above, it is more a general question.)
I can think of a couple of solutions:
1.My Phone asks (in the background) an api every couple of seconds and fetches the data.
2.My Phone has an on going connection over the Web(i heard of technologies like: WebSocket, WebRTC, WebTransport, (standard) sockets, TCP)
My Phone is running a Webserver 24/7 and gets the signal like that
So in general the question is how can my PC/Phone etc. wait for a signal/data (Im talking 1, 2 or 3 bytes) in the background efficiently
it Highly Depends on the Operating System that the Program is Running on and also each OS has its own specific Security & Privacy Policy. However, all of them have a Common Agreement that this Types of Operation should be Handled in Background Processes as Secure Lightweight as Possible. so for your listed solution the closest one is 1th case.
2th Case almost Impossible because it is in Contradiction to being Lightweight
3th Case totally wrong way
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.
This is for a visualisation project on what data gets recorded about us from our phones.
The idea would be to log as much detail as is reasonable to an internal location (probably) on the phone for later analysis, e.g. HTTP requests. It doesn’t need to be secret at all – the subject will be aware they are participating – and it doesn’t have to be 100% automatic; if the phone owner needs to perform some action regularly that’s okay too, although they need to be able to use their phone approximately normally throughout the day.
I can’t find any Apple APIs that look suitable, but that’s hardly surprising. I can find some approaches that would potentially work on OSX (tcpdump, netstat), so perhaps a jailbroken iOS device would support one of those?
Alternatively, running a custom proxy server would open up a bunch more options, but is there any way to get a mobile device to reliably route through a proxy server?
It appears this question provides a viable proxy-server-based approach:
https://apple.stackexchange.com/questions/81102/proxy-settings-for-iphone-3g-connection
Basically, it seems it is possible to route all requests through a proxy server, even over cellular.
I am attempting to stream audio files from a server to iOS devices and play them completely synchronized. For example on my phone I might be 20 secs into a song and then my friend next to me should also be 20 secs into the song as well. I know this is not an easy problem to solve, but I am attempting to do so.
I can currently get them within one second of each other by calculating the difference in time between the devices and then have them sync up, however that is not good enough because the human ear can detect a major difference in a second and this is over WIFI.
My next approach is going to be to unicast the one file from the server and then have the all devices pick it up directly from the server and then implement some type of buffer system similar to netflix so that network connectivity would be a limiting factor. http://www.wowza.com/ is what I would use to help with that.
I know this can be done, because http://lysn.in/ is does it with their app and I want to be able to do something similar.
Any other recommendations after I try my unicast option?
Would implementing firebase help solve a lot of the heavy lifting problems?
(1) In answer to ONE of your questions (the final one):
Firebase is not "realtime" in "that sense" -- PubNub is probably (almost certainly) the fastest "realtime" messaging for and between apps/browser/etc.
But they don't mean real-time in the sense of real-time, say, as race game engineers mean it or indeed in your use-case.
So firebase is not relevant to you here and won't help.
(2) Regarding your second general question: "how to synchronise time on two or more devices, given that we have communications delays."
Now, this is a really well-travelled problem in computer science.
It would be pointless outlining it here, because it is fully explained here http://www.ntp.org/ntpfaq/NTP-s-algo.htm if you click on "How is time synchronised"?
So in fact, to get a good time base on both machines, you should use that! Have both machines really accurately set a time to NTP using the existing (perfected for decades) NTP synchronisation.
(So for example https://stackoverflow.com/a/6744978/294884 )
In fact are you doing this?
It's possible that doing that will solve all your problems; then just agree to start at a certain exact time.
Hope it helps!
I would recommend against using the data movement to synchronize the playback. This should be straightforward to do with a buffer and a periodic "sync" signal that is sent at a period of < 1/2 the buffer size. Worst case this should generate a small blip on devices that get ahead or behind relative to the sync signal.
I'm familiar with using Reachability to determine the type of internet connection (if any) being used on an iOS device. Unfortunately that's not a decent indicator of connection quality. Wifi with low signal strength is pretty sketchy and 3G with anything less than 3 bars is a disaster (not to mention networks that only allow EDGE connections).
How can I determine the quality of my connection so I can help my users decide if they should be downloading larger files on their current connection?
A pragmatic approach would be to download one moderately large-sized file hosted on a reliable, worldwide CDN, at the start of your application. You know the filesize beforehand, you just have to measure the time it takes, make a simple computation and then you've got your estimate of the quality of the connection.
For example, jQuery UI source code, unminified, gzipped weighs roughly 90kB. Downloading it from http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.14/jquery-ui.js takes 327ms here on my Mac. So one can assume I have at least a decent connection that can handle approximately 300kB/s (and in fact, it can handle much more).
The trick is to find the good balance between the original file size and the latency of the network, as the full download speed is never reached on a small file like this. On the other hand, downloading 1MB right after launching your application will surely penalize most of your users, even if it will allow you to measure more precisely the speed of the connection.
Cyrille's answer is a good pragmatic answer, but is not really in the end a great solution in the mobile context for these reasons:
It involves doing a test "at the start of your application" by which I assume he means when your app launches. But your app may execute for a long while, may go background and then back into the foreground, and all the while the user is changing network contexts with changes in underlying network performance - so that initial test result may bear no relationship to the "current" performance of the network connection.
For the reason he rightly points out, that it is "penalizing" your user by making them download a test file over what may already be constrained network conditions.
You also suggest in your original post that you want your user to decide if they should download based on information you present to them. But I would suggest that this is not a good way to approach interacting with mobile users - that you should not be asking them to make complicated decisions. If absolutely necessary, only ask if they want to download the file if you think it may present a problem, but keep it that simple - "Do you want to download XYZ file (100 MB)?" I personally would even avoid even that.
Instead of downloading a test file, the better solution is to monitor and adapt. Measure the performance of the connection as you go along, keep track of the "freshness" of that information you have about how well the connection is performing, and only present your user with a decision to make if based on the on-going performance of the connection it seems necessary.
EDIT: For example, if you determine a patience threshold that in your opinion represents tolerable download performance, keep track of each download that the user does in order to determine if that threshold is being reached. That way, instead of clogging up the users connection with test downloads, you're using the real world activity as the determining factor for "quality of the connection", which is ultimately about the end-user experience of the quality of the connection. If you decide to provide the user with the ability to cancel downloads, then you have an excellent "input" about the user's actual patience threshold, and can adapt your functionality to that situation, by subsequently giving them the choice before they start the download. If you've flipped into this type of "confirmation" mode, but then find that files are starting to download faster, you could dynamically exit the confirmation mode.
Rob's answer is very good, but for a more specific implementation start with (https://developer.apple.com/library/archive/samplecode/SimplePing/Introduction/Intro.html#//apple_ref/doc/uid/DTS10000716)Apple's Simple Ping example source code
Target the domain for the server that you want to monitor connection quality to. Use the ping library to "ping" it on a regular basis (say 1 or 10 seconds depending upon your UI needs). Measure how long it takes to get a response to your ping (or if it never returns) to develop an estimate of the connection quality to communicate to your user.
We have a requirement from a customer to provide a "lite" version for dial-up and all the bells-and-whistles for a broadband user.
The solution will use Flex / Flash / Java EJB and some jsp.
Is there a way for the web server to distinguish between the two?
You don't care about the user's connection type, you care about the download speed.
Have a tiny flash app that downloads the rest the of the flash, and times how long it takes. Or an HTML page that times how long an Ajax download takes.
If the download of the rich-featured app takes too long, have the initially downloaded stub page/flash redirect to the slow download page (or download the bare-bones flash app, or whatever).
The simplest and most reliable mechanism is probably to get the user to select their connection type from a drop down. Simple, I know, but it may save you a world of grief!
There's no way to distinguish between a broadband or dial-up as a connection type, but you can make an educated guess by connection speed.
Gmail does this and provides a link to a basic HTML version of their service if they detect it.
(source: nirmaltv.com)
My guess is that there is some client side javascript polling done on AJAX requests. If the turnaround time surpasses a threshold, the option to switch to "lite" appears.
The best part about this option is that you allow the user to choose if they want to use the lite version instead of forcing them.
Here's a short code snippet from a code who attempted something similar. It's in C#, but it's pretty short and it's just the concept that's of interest.
Determine the Connection Speed of your client
Of course, they could be a temporary speed problem that has nothing to do with the user's connection at the time you test, etc, etc.
I had a similar problem a couple of years ago and just let the user choose between the hi and lo bandwidth sites. The very first thing I loaded on the page was this option, so they could move on quickly.
I think the typical approach to this is just to ask the user. If you don't feel confidant that your users will provide an accurate answer, I suspect you'll have to write an application that runs a speed test on the client. Typically these record how long it takes the client to receive x number of bytes, and use that to determine bandwidth.
Actionscript 3 has a library to help you with this task, but I believe it requires you to deploy your flex/flash app on Flash Media Server. See ActionScript 3.0 native bandwidth detection for details.
#Apphacker (I'd comment instead of answering if I had enough reputation...):
Can't guarantee the reverse, either--I have Earthlink dial-up, soon to upgrade to Earthlink DSL (it's what's available here...).
You could check their IP and see if it resolves to/is assigned to a dial up provider, such as AOL, Earthlink, NetZero. Wouldn't guarantee that those that don't resolve to such a provider are broadband users.
you could ...
ask the user
perform a speed test and ask the user if the result you found is correct
perform a speed test and hope that the result found is correct
I think a speed test should be enough.
If you only have a small well known user group it is sometimes possible to determine the connection speed by the ip. (Some providers assign different subnets to dial-up/broadband connections)