I want to write a tracking application, which reacts/record when users get in a car and phone automatically pair with Bluetooth hands free. I need also Id of the hands free device.
On Android it is easy, using Broadcast Receiver your app listen to broadcasts that device had been paired with phone. It is working even after phone had been restarted and App did not run after restart.
Is it possible on iOS(7+) ?
You can do it by reading the "Performing Long-Term Actions in the Background" part of this docs
Essentially, using state restoration, the system takes note of what your app was doing when it was killed.
If the app is searching for a bluetooth device and is killed by the system, the system will take care of continuing this research and wake up the app again when the bt device has ben found.
Note that this will work only if the app is killed by the system, not by the user (using the multitask bar). This behavior has changed since iOS 7.
Alternatively, If your BT hardware can be programmed to send advertisements using the ibeacon protocol, your app can be "awakened" by the corelocation/ibeacon api. After that prompt then maybe the corebluetooth pairing code could be initiated.
Related
I want to build an application for the Android TV platform. Part of this app is a service/daemon, which must start when the device boots, and must always run when the Android TV is powered on, even in stand-by.
Why do I want this service/daemon to run at all times? Part of my project is an application for portable devices (such as a smartphones and/or tablets), which will send commands via TCP to the Android TV app. Based on the kind of TCP message, the app will perform an action (power device on/off, push my app to the foreground etc.).
I have tried different code examples, but Android TV Oreo just kills this service after a while. I think these code examples were made before the Android Oreo restrictions.
An application like Kodi for the Android TV, has a web service that is always running in the background. Even on Oreo. but I can't figure it out how they have done that. Does anyone have some tips for me?
Edit: Yatse Remote Starter does what I want for Kodi, what I want to do with my app. It starts on boot, runs even in stand-by. https://play.google.com/store/apps/details?id=tv.yatse.android.remotestarter&hl=en. Still I would like to know how, so I can do it myself as well. Thanks in advance!
Many android apps and services are running simultaneously. To lower the chance of problems which cause poor user experience, Android 8.0 apps has two ways to limit what an app can do:
Background Service Limitations: While an app is idle, there are limits
to its use of background services. This does not apply to foreground
services, which are more noticeable to the user.
Broadcast Limitations: With limited exceptions, apps cannot use their
manifest to register for implicit broadcasts. They can still register
for these broadcasts at runtime, and they can use the manifest to
register for explicit broadcasts targeted specifically at their app.
Therefore, you need to create a ForegroundService in order to continue processing of your app. You can check this SO post regarding this issue.
I am trying to access the network with my Android Wear 2.0 App.
The Problem:
If the smartwatch is connected with the phone then I get an connection timeout. But if the smartwatch isn´t connected with the phone then the connection works fine.
I am using HttpUrlConnection.
Thanks and sorry for my bad english!
This has been answered in a different post:
Android Wear 100% packet loss
The basic idea is that you should not count on having Wi-Fi on the watch. The user may disable Wi-Fi on the watch and then your application will not work on the watch. Instead you should use your companion phone app to connect to the internet. If the phone isn't connected to your watch then use Wi-Fi.
Even if you want your app to run on an LET enabled watch the user may have turned this off or may not have a SIM card installed. At this point the user will most likely still expect your app to work.
So depending on what it is you're working on, if you want your app to work even while connected to the phone, then make a companion app for the phone. If you want your watch app to be a stand-alone app but you still want to be able to access the internet even when the watch is connected to the phone then you're basically saying that you want to drain the user's battery by using Wi-Fi/LTE instead of going via Bluetooth through the phone to access the web.
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 am working on an iPhone and Mac OS X application, which allows you to lock and unlock your Mac via proximity. Means if you the signal strength is under a determined threshold or the connection gets lost it shall lock the mac.
I am working with Apples CoreBluetooth framework for BTLE, using the iPhone as a peripheral and the Mac as a central. So far so good. It also works very well but when I send the app to the background on the iPhone the advertising seems to change. The iPhone still advertises but without the service profile and characteristics, I use in the app.
Although this is not a problem when the iPhone is still in the range of the Mac, because it's still connected and the characteristics are not used in the central, it becomes a problem after moving the iPhone out of the range. As expected the Mac locks and starts discovering to reconnect the iPhone and unlock if succeeded.
But in this discovery, I use the specified service profile and the characteristics to only get devices running my app and to identify the one for unlocking.
I tried a workaround by discovering without a service profile and identifying the correct device via its UUID, which I saved when I started to use this iPhone for locking and unlocking. This workaround also works in a small scope, because when I turn off the Bluetooth on the iPhone and turn it on again, it gets another UUID. That's a constraint I could live with, but it also changes the UUID after a few hours and then the unlocking does not work.
Maybe someone already worked on an app like that and know how to fix such a problem? Or you know a static value which I can use to identify the device?
So it seems, like usual, Apple has some weird and unique things going on in their framework. When you advertise from an iOS device (such as your iPhone), there are two "storage areas" for the advertisements -- a normal one that any device that is scanning can see, and an "overflow" one that can only be seen by iOS devices that are specifically scanning for it. When your app advertises in the background, all services UUIDs that you advertise go into this overflow area unfortunately, so it looks like only other iOS devices can see it -- and not your Mac. From the CBPeripheralManager docs:
Any service universally unique identifiers (UUIDs) contained in the
value of the CBAdvertisementDataServiceUUIDsKey key that do not fit in
the allotted space are added to a special “overflow” area; they can be
discovered only by an iOS device that is explicitly scanning for them.
While your app is in the background, the local name is not advertised
and all service UUIDs are placed in the overflow area.
Situation: My iPhone communicates to an external device through Wi-Fi. The app has also the ability to set up a schedule. This means that on a specific time the device should turn on and do some stuff. Now for this to happen there should be a timer on the external device or the iPhone should send a command to the device on a specific time.
Question: Is it possible to send a command to the external device while the app is in the background? Or does the app have to be in the foreground? Is it possible when the external device is an accesory? Cause I have read that apps are allowed to run in the background when they need to communicate to accessories??
Thanks in advance!
No you can't do this, you are only able to run an app in the background if its stream audio, a VOIP client or track user location. If you are in the accessories program (which means you can make hardware that works with the dock connector, then your app can also run in the background. but only if the accessories that is respons to is connected.
There is no way the schedule any operation to be triggered at a set time.
You can schedule a local notification, but the user wil have to view (open you app by click in the notification) before you app get informed about it.
Do you actually have the devices communicating? If not, you should take a look at Apple's MFI (Made for iPhone) program. Sending data or communicating from your iPhone to an external accessory through bluetooth falls under it. They provide you with certain protocol specifications that allow you to communicate with external accessories. It's difficult to do something like this if you are an individual developer though. Here's the link: https://developer.apple.com/programs/mfi/.