Here is the use case:
the user launches the app and grants permission, the app connects to the server
at some point in the future, the server sends a request to the app
the app
regardless of whether it is running or not in the foreground or background, wakes up to run this code
Here are some options I have explored which I am unsure about:
server sent events
websockets
push notifications
Is there a reliable and safe way to do this on android, whether it's Kotlin or Flutter? Can you provide examples or documentation?
Thanks!
Turns out that the best way to do it is with push notifications!
Websockets and server sent events are better suited for other use cases. Persistent connections to a server are resource consuming, and both Android and iOS have mechanisms in place to terminate apps running in the background to save memory etc. So we would probably lose the connection and not be able to receive anything from the server if we minimized the app or locked our phone screen.
Push notifications are basically built for this exact use case because, even though they work differently on Android and iOS, they are built to receive messages from a server regardless of whether the app is in the foreground, background, or not even currently running.
I used Firebase Cloud Messaging to build my app since it's primarily an Android app. It worked like a charm.
Related
I'd like to create a flutter IOS app which stores data and allows to edit it within the iOS app.
Then the iOS app be able to provide a webserver [start an internal webserver e.g. using jaguar] and serve a WebApp, which operates on the same data on the iDevice.
Idea: Make the iDevice the only data store. And allow a e.g. windows client to access the data on the iOS device using a web interface [and not require it to push it into a cloud].
I have used Flutter jaguar to make it work, have you tried to run the example ?
I think what would be very challenging is that IOS kill background processes, so to use your IOS app as a (reliable) server in the background would be impossible (if reliability, and it should, is a concern), only audio streaming apps would not be killed. So it means you will have to run your server at all time in the foreground
And not to mention that if your phone is out of battery it would also stop working (but of course, you are aware of that, and that's true that if connect to charger, it could perfectly act as a server, as I have tested myself!).
NB: If it's for some serious project, not a fun personal project/challenge, I advise you to reconsider and what you could still do is to manage your server data from the IOS app (meaning that you would send data on on-premise or cloud server like Firebase). But as you stated in your question you are looking to make it work on the Iphone device.
Is there any good advice on uploading files to the device? I've seen many apps create a http server on 80 or 8080 to upload files. Does that mean I have to implement a server too?
Are there any 3rd-party libraries? (Preferably open-source and non-GPL)
EDIT: I am going to upgrade files in the app for specific devices in a corporate environment, so the ipad pulling files from a central server is also an alternative. But I would have to send messages to these ipads to tell them to fetch those files.
But I would have to send messages to
these ipads to tell them to fetch
those files.
Push Notification Programming Guide
Or mail with custom URL scheme for launching your application.
iOS Application Programming Guide - Implementing Custom URL Schemes
I assume what you want is a kind of automatic update. An app do something by order from server without user's manual operation.
I don't know enterprise-license specific feature of iOS. But I believe there's no such enterprise-specific APIs. And as I know, automatic update is almost impossible. Because,
There is no system-level support for automatic update. (yet?)
So messaging and fetching feature should be implemented in app.
But no app is guaranteed to run in background for long time.
And also user can turn off any app at any time.
There is no way to send message to an app which is not running.
Even you can send, there is no way to address each client form the server.
If your app is running, sending message or commanding them to fetch or do anything is just a simple work. The problem is there is no regular way to force them always keep alive. Even under situations like OS reboot or abnormal termination.
However there is an alternative. Just registering app as VOIP app like Skype. OS does not keep the app running too, but will monitor specific socket port, and will wake your app when the socket receives some message. For more details, see here: http://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH5-SW15
In AppStore, an app using VOIP for other purpose like automatic update will not be passed, but you have no need to concern about it.
And other way to send message to device without running app is push notification. This is a feature supported in system-level. But this is not designed to commanding app. This is designed to send textual message. So If your app is not running, the message will be displayed to user. However, you can guide the user to start the app by sending push notification.
As a final option, you can request some feature to Apple for enterprise environment. If your company is big enough to get an enterprise license, Apple will consider your feature request seriously.
If you decided to use VOIP method, I'm sorry I can't help you any more. I have no experience of implementing this kind of app. But it should not so hard.
However hard part is server. It definitely require custom server program which keeps TCP/IP connection. Regular HTTP server cannot be used. Because HTTP itself is designed as not to keep TCP/IP connection. You have to build this kind of server yourself from scratch. You'll have to handle lower level TCP/IP transmissions.
There are a few solutions(both of free/commercial) for this kind of server, but none of are popular because this kind of server regularly needs full customization. So there's nothing to re-use or share.
However I believe this is most suitable implementation for your app.
If you can satisfy automatic update only when the app is running, you can archive it by polling server status from the client periodically.
This is easy to implement because you can use regular HTTP servers for this. Client connect and download recent updates from central server periodically. If there is a new update, just fetch and do what you want. And the app is launched, just check the update at first. Prevent all operation until update applied.
This is regular way. Most of applications are built with this method. In this case, you have no need to implement server or hard thing.
However applying speed of update is depend on polling period.
(Edit)
I couldn't care about private APIs. Because your app is not for AppStore, so you can use private API's freely. (This is different thing with jail-breaking. There are so many hidden features by excluded from documentation) I don't know about private APIs, but it's possible there is some API which enable the support for keep-alive of the app.
However, this reverse engineering work is so painful unless you're born to hack.
You may try to use the following open-source in your project:
http://code.google.com/p/cocoahttpserver/
https://github.com/robin/cocoa-web-resource/wiki
Apple has some sample code on their website that details exactly what you're looking for:
http://developer.apple.com/library/mac/samplecode/CocoaHTTPServer/CocoaHTTPServer.zip
So you have a couple options:
You could distribute your app wirelessly within your organization and push new content out as app updates. Apple provides this option to their Enterprise Developers.
Wireless App Distribution
iPhone enables enterprises to securely host and wirelessly distribute in-house apps to employees over Wi-Fi and 3G. Apps can be updated without requiring users to connect to their computers. In-house apps can be hosted on any web server accessible to users. Users simply tap on a URL to install apps wirelessly without needing to connect to their computers.
The alternative is you configure the app to fetch the updated data. You describe adding an HTTP server to the iOS device, but there's no way the server can receive data when the app isn't running. Given your needs, it would probably work better to embed a web client in your app instead.
If I was in your shoes (and option #1 didn't work), I'd use ASIHTTPRequest to check with a server at launch/daily. If there are new updates, the app could then either prompt the user that there are new data files to download, or it could just silently download them in a background thread.
UPDATED: Perhaps I should have been more explicit about how to do #2. You can configure the download so it isn't interrupted when the user quits the app (you don't need to do a Voip hack). Check out the Completing a Finite Length Task in the Background section in the iOS Programming Guide.
There are http server sample codes from Apple and open source community such as cocoahttpserver TouchHTTPD.
You can upload file to the http server on iphone.
Here's a blog and screen-shots about running cocoahttpserver and upload file to iphone.
The Python CGIHTTPServer allows you to create a server in 0 lines of code:
jcomeau#intrepid:~/rentacoder/bin2txt$ python -m CGIHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...
Actually implementing a script to parse the input and save the file would take a little more effort.
[later]
OK, so forget about that, Apple doesn't allow it. See Local server on iPad for the iPad at least.
I currently sell a Mac-only productivity tool that uses visual and audio notifications to remind the user of certain events taking place.
I've started planning the iPhone and iPad versions of that Mac program and would like to be able to provide notification services from the Mac to the iPhone, e.g. instead of the Mac playing an audio cue, the iPhone could vibrate, etc.
I have so far done very little iPhone development and I'm not really sure how the various push notification services work. Is this easy enough to do? or is a "challenge".
A few more potentially relevant pieces of information:
there will be a Dropbox-based sync between the iPhone and the Mac versions, so there is also the possibility of "sharing" a file that would prompt some action
it might be acceptable as a first step to not have "background" notifications and require that the iPhone client is running
What authentication issues should I expect to deal with?
You'll need to implement APNs (Apple Push Notification Service) in both your app and your server.
To clarify a few things:
You'll need a server doing those transferring messages job between the user's Mac/PC and their iDevices.
Your server will decide when to push what kind of notification to which user's device.
After that, your server sends a message to Apple's APNs server, which will push that message on your behalf.
It's absolutely OK that your app can be in the background or even closed when the APNs message arrives at the user's device. The user will be guided by the OS to open your app.
If the user has explicitly disabled your app's APNs function in her/his device, or, if the user cancels the APNs alert when it arrives, your app won't be launched if it originally stays in the background or if it hasn't been open yet.
The user will be asked to enable (as you put it, authenticate) your app's APNs function by the OS in her or his device when your app is launched for the first time.
It's not a challenging task for an experienced iOS developer or an experienced PHP developer, since Apple's documents and APIs are pretty straightforward. However, configuration on the server side can be a little tricky.
I believe Stack Overflow already has tons of information on how to enable APNs in iOS apps. All you need to do is be specific in your question and do the search work beforehand.
Hope that helps.
How does Apple do polling of a phone's location remotely? Is there any API that allows an app developer to do the same with the SDK?
My guess is that they are private, undocumented and probably un-callable api's.
I couldn't imagine the huge security implications of having an external party/app be about to poll a phone location without the users consent.
An iOS device already maintains a connection to one of Apple's push servers if push is enabled, and the server has to know the device on the end of the connection (to determine the push notifications to deliver to it). The easiest way to build on this is to have the server say "tell me where you are!" as a push notification.
The device also hits Apple's servers for other reasons (App Store updates, captive login page detection), but it's less likely that the server can identify the device in these cases.
That said, you can do this with the user's consent:
Make your app a background "voip" app (<key>UIBackgroundModes</key><array><string>voip</string></array> I think)
At app launch, check that you can retrieve the current location (I'm not sure what happens if you do this while your app is backgrounded).
Maintain a "voip" connection to your server.
When the server asks the device for its location, ask Core Location for the location again and send it to the server. (I think you also need either "location" in UIBackgroundModes or you need to keep the connection active, possibly in both directions; the former may be easier.)
You won't be able to stop the "location services" icon from appearing in the status bar. The usual multitasking caveats also apply (your app can be killed if the phone runs out of memory; "voip" causes your app to be relaunched sometime later though).
I'm pretty sure if you do the "voip trick" your app will be refused from the store. It is only allowed if your app is actually a VOIP app, not just using it as a technique to circumvent background processing restrictions.
How are push notification better than pull notification on iPhones?
Are there any links with more information about this?
Any help would be appreciated.
Pull notification requires the user to be running your app, and your app to be wasting battery power constantly polling some server (or waiting on some network socket in another thread , or using the new background services).
Push notifications, when enabled by the user, and if the phone has a network connection, allows a message to be sent to a phone even when it's not running your app, prompting the user that your app wants some attention. It uses a much lower power network connection than any frequent polling method.
If you want to know about push notifications, I'm guessing you are interested in the Apple Push Notification Service.
You can read about its architecture here:
http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
There is no such thing as a "pull" notification, but using APNs gives you the advantage that you don't have to manually poll a server every so often within an app, which usually saves you a lot of battery life in the long run if you are interested in telling the user about sporadic, infrequent events. Using push notifications also allows you to interrupt the user if they are not currently running your app, which of course can be very useful in certain use cases.
You should think about what kind of message flow you expect to see between your app and any server components in your system. Push notifications make the most sense where some event external to your app is going on which requires the app to be updated in some way, and where the frequency of those updates is low or highly variable.