I'm making a framework for iOS that collect data from the phone (GPS, WiFi, etc) and sends to a server and notifies the user on events.
My problem is that if two or more apps use the framework on the same device it will consume the battery and I only need to send the data from one app because the collection continues in the background.
Is there any way to know if these multiple apps are running and notify the app that other app is collection and sending the data?
No. The apps are sandboxed and cannot interact.
The framework will have no way of communicating with the other apps unless it sets-up some sort of networking on the client (not advised).
I wouldn't worry about it.
I'll probably look the problem inside out. When I start receiving info on the server from same ip/mac combination simultaneously I'll return a flag to all but one client on that particular device. When my framework receive that kind of flag, it will stop sending data, because someone else is already doing the same.
PS Your framework sounds like creepy spy thing though :)
Related
I'm trying to write a super-simple iOS app, just for personal use (i.e. it doesn't need to conform to any App Store stuff). I want it to do the following. Assume it's installed on two devices, both of which I own/control.
On device 1, it has a button that, when pressed, will immediately cause a notification to pop up on device 2.
I'm fine with hardcoding specific apple IDs, device IDs, whatever; it's also fine if this only works when the two devices are on the same LAN/Wifi. all I want is for the above to work, in the easiest way possible, and preferably without needing anything to run on a server anywhere.
How simply can this be implemented? I've set up a whole push-notification system once before, but that required some server-side stuff. Hoping to be able to do this without any of that.
====
Update: realized I wasn't clear in the original post that I need the notification on Device 2 to pop up whether or not the app is currently open/running on that device.
I think that what you are searching for is multipeer connectivity framework.
The Multipeer Connectivity framework supports the discovery of
services provided by nearby devices and supports communicating with
those services through message-based data, streaming data, and
resources (such as files). In iOS, the framework uses infrastructure
Wi-Fi networks, peer-to-peer Wi-Fi, and Bluetooth personal area
networks for the underlying transport. In macOS and tvOS, it uses
infrastructure Wi-Fi, peer-to-peer Wi-Fi, and Ethernet.
source: https://developer.apple.com/documentation/multipeerconnectivity.
You can also check those tutorials:
https://www.ralfebert.com/ios-app-development/multipeer-connectivity/
https://www.hackingwithswift.com/example-code/networking/how-to-create-a-peer-to-peer-network-using-the-multipeer-connectivity-framework
Send sms to port is a way (the protocol will become SMS): https://developer.apple.com/documentation/foundation/nsportmessage
and Maybe Firebase Remote Config can help you: you can get your data in FCM remote config (key-value) from the app :
https://www.raywenderlich.com/17323848-firebase-remote-config-tutorial-for-ios
https://firebase.google.com/docs/remote-config/get-started?platform=ios
, and you can modify your data whenever you want, and the app can fetch it.
I have similar requirements, and it seems like APNS (Apple Push Notification Service) is required for this because it's one of the only ways to 'activate' an application that is in the background.
As a result, then the question is how to make APNS as painless as possible? It seems like combining Firebase Cloud Messaging (or FCM) (to manage APNS / sending messages), and Firebase Functions (to help manage FCM server-side requirements) is one decent option.
This might be asking for the moon but here goes...
Is it possible to have an iOS app receive data and then forward it all while running in the background?
We're a restaurant currently using an ordering system that uses a main iPad as the till, with a second iPad in the kitchen to receive orders, and another third iPad used by the servers to take orders. Orders are sent to the main till which relays orders to the kitchen.
Works great... Unless someone switches app on the main till iPad to our other (necessary) hosting app, then all hell breaks loose and all orders stop getting sent.
Developer (small team) has told us it's impossible to solve but I have done some digging into recent Apple APIs that allow simple tasks to run in the background and have seen a few promising options, or perhaps it's possible via the External Accessory Framework, or even syncing via iCloud? A question for the more knowledgable than me, but is there currently a workaround to solve this that I could suggest or are they right in that it's currently impossible in iOS?
Yes there are ways to have an app in the background receive data, generally using either:
beginBackgroundTaskWithName:expirationHandler:
or
beginBackgroundTaskWithExpirationHandler:
Take a look at the Background Execution section in the documentation for more info...
There are two applications. How can they share information? Can we use a common database for them? Perhaps we can pass parameters from one application to another?
You cannot directly share any resources; every app is in its own "sandbox" and cannot access the resources of any any other app.
You can send data back and forth between apps a couple of ways, however.
If you want everything to stay on the device then you can implement application:openURL:sourceApplication:annotation: in both apps and provide a custom URL handler for both. The user will experience the device switching between the apps as they launch each other.
If you are willing to use a server and internet connection, then both apps can read and write the same server resource. When each app launches or becomes active, it can check for updated information on the server.
I have a situation where I would like to communicate between 2-4 devices over the 3G network (it should also work over WLAN, but 3G solution is critical).
Every device (except one) asks for a GPS-location every ~5 seconds, but when this process is cancelled by the user of that device, one device needs to be informed of this event.
I was thinking that one device could act as a server, and the rest as clients that should connect to the server. Is this possible over the 3G network?
I've also read about push-notifications, is this relevant here? Can you receive notifications without disturbing the user with a popups etc?
Are there other ways?
Basically I would like to use apple "standard" solutions (if there are any) before diving into eventual socket-programming or anything similar...
What I would like to avoid is to have a webserver or some similar "3rd-party" solution, because I don't want many users to simultaniously connect and "pull" from the same external server in a final solution...
UPDATE:
Basically my application will have thousands of users that will need to be informed if an even occurs. Also this happens simultanously ~5 second, what would be the best solution to reduce load and avoid spamming?
I was thinking that one device could act as a server, and the rest as
clients that should connect to the server. Is this possible over the
3G network?
It could work, but having a dedicated server would be a better choice
I've also read about push-notifications, is this relevant here? Can
you receive notifications without disturbing the user with a popups
etc?
In your case no, since you will need a server to communicate with apple
Basically I would like to use apple "standard" solutions (if there are
any) before diving into eventual socket-programming or anything
similar...
There are no standard solution, other than you should probably rethink about using a dedicated remote server for this
iPhones can't communicate directly with each other using 3G. You can access the internet through the 3G, but you can't do peer-to-peer as you are suggesting. If you were close enough, you could use bluetooth, but I expect you are too far away.
You would have no way of detecting the one device that acts as a server from the other devices. The IP address could (and probably would) change every time the device connects to a mobile data network. You would need a central server to co-ordinate all of the clients.
You have multiple questions, but I'll try to address as many of them as I can:
I was thinking that one device could act as a server, and the rest as
clients that should connect to the server. Is this possible over the
3G network?
No, you cannot run a server on a iPhone/iPad that is accessible over 3G without an external website acting as an intermediary. (You can run one that is accessible over Wi-Fi, but this does not solve your problem as stated.)
I've also read about push-notifications, is this relevant here? Can
you receive notifications without disturbing the user with a popups
etc?
Push requires you (or a third party contracted by you) to have a web server, so if you want a server-free solution it is not relevant here.
Are there other ways?
Over 3G you will, under the current Apple restrictions, always need an external server.
Basically I would like to use apple "standard" solutions (if there are any) before diving into eventual socket-programming or anything similar...
Diving won't help you here. Even using low-level socket programming you will not be able to run a server on an iPhone accessible over 3G without an external website to aid in establishing a connection.
You can try using GameCenter. The mechanism of network games in Game Center allows connect up to four players with no third-party solutions.
I am looking for ways where my RESTful web service can let my iPad app know to update its cached data when the server's data has been updated. The server is running on Tomcat & Apache Jersey.
Is this doable? And not using Apple Push Notification (APN)?
There are essentially two options: heartbeat check from the app to the server (on a timer) or something that keeps the line of communication open, such as web sockets. Here is an open source web socket for iOS, but I have not personally experimented with it:
http://code.google.com/p/unitt/wiki/UnittWebSocketClient
I'm not sure why you want to avoid APN, but this really sounds like what it's made for.
If you want to update only when your app is running, there are other options (straight forward polling comes to mind), but if you want the user to be notified even when the application isn't running, there isn't really any other Apple approved way to do it.
Can reverse the design around and make your device a client and pull data from a REST service at a regular interval?? With all the support one gets from REST, it might be helpful to know you will have complete control of when data is being pulled by the device from server and exactly the data that might goto device.
I'm curious to know your thoughts, Thanks.
I'll be building a web-syncing iOS application soon, and we're going to use RestKit. Take a look, it might be a big help.