acani uses zimt websocket for chat. Can we make it so that when a user closes his phone and puts it in his pocket, he can still receive chat messages from and send location updates to the node.js server? I think this would be nicer than push notifications. Don't you? If not, why should we use push notifications instead or also?
Thanks!
You can't keep a network socket open, unless you are registered for voip/GPS/music playing in the background.
if you register for these, and then don't do them, apple usually reject the app.
the reason you cant keep a network socket open, is that without your app jumping to the foreground when it receives a connection, it cannot respond to network traffic(because if it is not in the foreground its memory content is frozen).
background network traffic kills the battery, as the radios in phones are one of the most energy intensive parts.
with push notifications, apple manage how often they are sent out, so you don't have all of the applications on the phone polling the network every 2 minutes killing the battery, you only have one active network connection, which is intermittent.
Related
Is there any way to create push notifications with Flutter without using Firebase (FCM)? Would it be possible to have a background job that has a socket connection to the message backend to receive the notification?
There is no way to do deliver messages to apps that are not actively being used without FCM/APNS, as that would require the process to keep a socket connection open even during this inactivity. The underlying operating systems (iOS and Android) either don't allow this to begin with, or actively kill such open connections after a short period of the app being inactive.
I'm trying to create an iOS application that sends data over UDP continuously over wifi/3G network.
I have an issue when I launch my app over 3G network after like 10 seconds I get this message :
sendto() : No buffer space available
It's not that a big deal because my app still works well BUT when I quit the app, I guess my buffer stays full because I can't use 3G anymore (I have to wait some time or reboot my phone)
Is there a way to flush this buffer before I quit my app ?
It sounds as if you're hitting the outbound bandwidth limit. If your app does this continuously while in use, isn't that going to make it very expensive for users to run? Most mobile users, I would guess, are on some kind of metered plan where they pay for transferred data.
I would guess that closing the socket normally before exiting should flush it first, since you've requested the data to be sent after all, but sometimes UDP sockets don't try very hard to deliver the data (since they are "lossy"), perhaps that's what's happening in your case too.
I want to develop an application which sends a Message from iPhone to other iPhone over the internet, I want to receive the Message from other iPhone even if my iPhone is running in the background.
I have seen the WiTap application, but socket will get disconnect when application is closed or if there is screen lock.
So is that possible to develop the application so that I can receive the message even if my app running in the background forever?
From my little Knowledge, You can't do it through WiFi.
When a screen lock happened, device will automatically OFF the wifi connection for increasing battery life.Thats why socket connection getting disconnected.
In iOS, apps can’t do a lot in the background. Apps are only allowed to do limited set of activities so battery life is conserved.
But what if something interesting happens and you wish to let the user know about this, even if they’re not currently using your app.
For example, maybe the user received a new chat. Since the app isn’t currently running, it cannot check for these events.
Luckily, Apple has provided a solution to this. Instead of your app continuously checking for events or doing work in the background, you can write a server-side component to do this instead.
You can do it using Apple Push Notification Service.
It uses push technology through a constantly open IP connection to forward notifications from the servers of third party applications to the Apple devices; such notifications may include badges, sounds or custom text alerts. In iOS 5, Notification Center enhanced the user experience of push and local notifications.
More details are here
Note: details and screen shots are taken from raywenderlich website/blog.
I would like to be able to discover other iOS devices over Bluetooth while my application is in the background. Is it possible to use Bonjour or Game Kit to do this discovery while my application is not in the foreground?
Would it be possible to do this and fire off a notification if a compatible device is discovered?
Also, would I be able to run in the background while playing audio and do this detection?
This is not possible while your application is suspended. From the iOS Application Programming Guide:
Cancel any Bonjour-related services before being suspended. When your
application moves to the background,
and before it is suspended, it should
unregister from Bonjour and close
listening sockets associated with any
network services. A suspended
application cannot respond to incoming
service requests anyway. Closing out
those services prevents them from
appearing to be available when they
actually are not. If you do not close
out Bonjour services yourself, the
system closes out those services
automatically when your application is
suspended.
Be prepared to handle connection failures in your network-based
sockets. The system may tear down
socket connections while your
application is suspended for any
number of reasons. As long as your
socket-based code is prepared for
other types of network failures, such
as a lost signal or network
transition, this should not lead to
any unusual problems. When your
application resumes, if it encounters
a failure upon using a socket, simply
reestablish the connection.
However, if your application is streaming audio, it would be necessary for it to maintain network connections, so you should be able to do Bonjour discovery while in the background for an application continuously playing audio. Make sure you don't abuse this by playing a silent audio clip in a loop just so that you can stay in the background, or your application will be rejected.
I am developing a network application on iPhone that requires internet connection all the time. However, once I login to the server and keep the iPhone idle for a while, the iPhone goes to sleep mode and disconnects my network connection (it logs me out).
If I run the same application on iPhone, while the iPhone is connected to the PC through USB cable, it never loses its network connection.
In the info.plist file I have added these two flags, but does not seem to have any effect.
UIRequiresPersistentWifi -> true
SBUsesNetwork - integer ->3
Am I missing anything? Could you please let me know how can I make sure that the network connection is persistent throughout the life of the application?
In your application delegate ("appDelegate"), disable the idle timer in the +initialize method:
myApp.idleTimerDisabled = YES;
Note that this will keep your iPhone from sleeping while your app is open. This can present issues with battery life.
Another option might be to set up a background thread that opens a small CFStream on a timed basis.
What do you mean by "logs me out" here? At the network level, there is no "logged in" (*). There are only packets. You send them or you don't. So does your server process have some expectation of packets or messages arriving periodically? If it does, then you must send them, and that means that you can't go idle (idleTimerDisabled = YES). If you control the server, it is better to make it less demanding about how often you talk to it. This all happens well above the network layer, however.
UIRequiresPersistentWifi means that the Wifi radio is kept on while you're app is running, even if you don't talk on it. This is important for receiving data. Otherwise you drop off the network and others can't talk to you after about 30 minutes. It should be set in Info.plist, but this is certainly in your app bundle. If it weren't, your app wouldn't launch, so that isn't the problem.
(*) The cell network does have the concept of logged in, but that's not what's causing your problem.