I'm not very experienced when it comes to implementing Android apps which make a lot of use of Services and I couldn't find any good advice or examples to help me on SO or github (or by just googling) so I decided to ask my own question.
When my app is started, it needs to start discovering nearby Bluetooth LE beacon devices and it has to continue doing so at least until it's gone to the background. The only thing I need from these beacons is to get the basic data (like the UUID) of the one whose signal is the strongest.
What is the best approach to achieve this?
Currently I've got only got a regular Service which runs the startLeScan() method on BluetoothAdapter as soon as anything is bound to it. However, I've got more than 1 Activity in the app and I don't think binding to the Service and unbinding from it in each of them is the best thing to do. I thought about starting the Service instead of binding to it but then again stopping it could involve a lot of coding - it isn't exactly easy to determine when an Android app is put into background afaik.
Any hints and advice could be useful.
Sounds like you are using iBeacons. Check out radius networks beacon library. It has a bunch of examples and instructions for how to download. Here is the link:
http://developer.radiusnetworks.com/ibeacon/android/pro/download.html
Included in the library are methods for discovering new beacons and easily getting there info (UUID, Major, minor, etc..). They even have examples showing how to do it.
In addition to other answers, I recommend this iBeacon scanning app.
BeaconBox for Android
It is useful for you to testing your beacons on smartphone.
I hope that you reach your goal.
Right, I don't consider myself an expert so feel free to correct me whenever I'm wrong.
I'm dumb - I didn't realise that the startLeScan() and stopLeScan() methods both take a BluetoothAdapter.LeScanCallback parameter and that this callback actually contains a method named onLeScan() called asynchronously upon a BluetoothLE device being scanned.
That means that no Service is necessary at all - it's enough to actually implement the onLeScan() method and it should do. I also put all of that in a singleton class instead so it's accessible from everywhere in the app.
I'll mark my answer as the correct one for now but do answer if you've got a better solution.
Related
for my current project I try to figure out the differences between Android and iOS. I only have knowledge in Android and absolutely no idea about iOS.
What I want to know is:
Is there something similar like Intents for iOS? Especially those which indicate changes in Wifi / BT connection like android.bluetooth.device.action.ACL_CONNECTED or android.net.wifi.STATE_CHANGE? Or is there another method to find out about connection changes even if the app is not running / in background mode?
As I understand from
IOS background service (like in Android) enable all time & https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html, having a background service in iOS is only allowed for specific types of apps. So an app which asks for sensor values (like accelerator) on regular basis is not allowed - is this correct?
I am very thankful for answers and also further literature regarding these quesiton!
You can use an implementation of Reachability to get the notifications about Wifi connectivity, but keep in mind these won't wake up your app.
From Apple
From Cocoapods
You can use Core Bluetooth to look for connectivity events. Again these won't wake up your app. I believe you can setup a delegate to a CBCentralManager to find out about that. Check out the docs here.
However, you are correct in saying that you still need to solve the issue of background execution to keep your app awake. For that you need features that actually make background execution useful to a user or Apple won't approve your app. Here are some of your options.
If your app has actual bluetooth features you can use one of those modes (bluetooth-central and bluetooth-peripheral).
If you have a feature that warrants background audio you can use this
If you have a feature that warrants background location you can use CLLocationManager startUpdatingLocation (but this would eat up some serious battery)
You might also be able to set up a system that spams silent remote notifications and then use the remote-notification background mode. This is meant for downloading content
Also keep in mind that a user can basically disable all of these things on you at any time.
Good luck!
Im not sure if this will answer your question directly but it may be helpful. I know in Android that you can you an Intent to switch Activities. Well in iOS in order to switch to another UIViewController (iOS equivalent of activity) you would perform a segue. In prepareForSegue method you can handle what you want to do in the next UIViewController, such as passing variables etc.
You can use Background Fetch in iOS7 you can perform services while the app is asleep/in the background. This wakes the app at regular intervals in the background to perform a task, like refreshing data etc. You may be able to record the accelerometer values here. http://www.appcoda.com/ios7-background-fetch-programming/ has a good tutorial on this.
I hope this is somewhat helpful.
I am trying to build an NFC enabled application that transmits data to another device via Android Beam (pushing a NDEFMessage).
While I know there is a success callback void onNdefPushComplete(NfcEvent event), I can't find a failure callback, which would be really useful.
I tried to think of other way to sort of guess whether the transfer happened, if it succeeded or failed but cannot really find anything satisfying. Even a dirty timer would not work since I cannot know for sure when and even if the user actually starts the beam.
I feel pretty much bound by the API since the OS is handling most of the functionality and the application is only providing the message to send.
Any suggestions, something I might have missed? I'd rather avoid rooting the device if possible, but if it cannot be accomplished without tinkering with the core NFC code, then so be it.
Cheers
No, there is no such callback. Or a notification or anything that would give you a clue that things didn't worked.
Unfortunately.
In general the Android Beam API has not been designed with error handling in mind.
I'm writing an application with 3 mapactivities, and i've implemended a local service(like google tutorial) that recives update from location manager, to share location data from gps between these activities.
Now i want to put every activity in separated process to follow google's suggestion.
So my question is how I have to proced??
Implement and AIDL interface for remote services or register every mapactivity to location listener??
Thanks for answers and sorry for my bad english :P
If it's just a single application that needs location information, then using a remote service and AIDL is an unnecessary complication. The easiest way would be to have a local service with which the activities can bind, then have the service use sendBroadcast() to send location information. The activities can then register a BroadcastReceiver to pick up this data.
First the rationale:
That quote in the Javadoc is a bit... weird. If you understand "running" as being between onResume() and onPause(), then normally two Activities belonging to the same Application cannot "run simultaneously". You would probably have to mess with the Application class or the OS itself to have it behave otherwise.
To wit, I'm actually developing an app at the moment that uses several MapActivity subclasses and haven't encountered any problems so far (i.e. 40+h of development and testing, both on emulators and a device).
Therefore I would suggest:
Try to implement your app as a single-process activity with a local service and just run with it.
If you don't want to do that (can't blame you ;) ), or you encounter any problems, I would suggest starting out with a MapView, perhaps encapsulated within a Fragment. Here's a discussion to get you started.
In short, due to Android's practical fragmentation, keeping your Activities in one process and commiting more time by starting with a more bare-bones implementation will be a safer, ultimately less time-consuming and probably more efficient approach than artificially splitting your app and potentially gritting your teeth on the IPC. At least in my opinion.
After some research i think the best way is to implement IPC with a messenger like described in Android doc http://developer.android.com/guide/topics/fundamentals/bound-services.html#Messenger.. I'll test this solution an report here the result..
Best tutorial is http://developer.android.com/reference/android/app/Service.html#RemoteMessengerServiceSample where is implemented a 2 way communication from client and service..
First I'm sorry for my english that is not so good :).
I am facing a problem to develop my app.
That is a general architecture scheme of my solution.
http://i.stack.imgur.com/ooTmE.png
To be quick, the app has to decode code bare but with two possible ways:
using exernal device (The constructor provides a sdk containing an android Service to communicate with the device),
use the camera of the mobile using the library Zxing which is possible to manage it with intent.
The goal of my own service is to manage some business code and make transparent the choice of the tool for the user.
I believed that was a good solution but I wanted to implement it and I had different problems.
My main trouble is that I cannot execute StartActivityForResult inside the service.
Do somebody have any suggestions for my problem whether a change in the architecture or a solution for the main problem?
#Laurent' : You have totaly right my service acts as an API adapter.
I will try to make the expected behaviour more clear.
I have an app that needs to recognize (real) objects which have QR codes on their top. This recognition action will be done several times by the user during the life of the app.
The user chooses to launch the recognition by clicking on a button (or otherwise but he knows that the recogntion will start). So no notification is needed.
The thing is he doesn't choose the way to do the recogniton. It is why, as you said, I implement an adapter.
The adapter chooses between :
Camera mobile or external device. The first is an activity coming from the Zxing library. The second one is a service that manages the external device. This service provides an interface to get back result.
One more thing, I need that my whole implementation (adapter and co) can be re-used by other apps that will also need to do recognition.
So my thought was to implement a service as an adapter to answer my two conditions (make transparent the choice for the user - and make the recognition available for other apps).
I hope you understand my problematic.
Given your architecture, your MyOwnService must act as an API adapter : it should provide a unified scanning API and address each external service specificities transparently.
Your expected behaviour is not clear enough to provide a solution that suits your needs but here are a few remarks that can be of some help.
Passive scanning:
Even if there are some workarounds : no activity should be launched from a service (not directly). Never. Bad. Services are background stuff, the most they will be permitted is to hint users with Notifications (this is point 2 of Justin excellent answer).
As a consequence there's nothing as a 'popup Activities' (and that's good!). If you need to continuously scan for barcodes, even when your activity is not run, then the only way to warn users is by using status bar notification.
Active scanning:
Inside your own activity you can bind to your wrapper service and make it start scanning for codebars. When it finds one it has to message your activity. Your Activity message handler has complete access to the UI to inform the user of your findings.
You selected Active Scanning in your edit, your problem is therefore to find a way for your service to actively notify your main application (the one that started the active scanning) that a new item has been scanned successfully.
You do NOT do this by starting a new activity (remember: this is bad) but you can bind to a service and/or use Messages between the wrapper service and the application.
I advice you take the time to read (and more time to comprehend) this android developer article on BoundServices and especially the part about Messengers.
A full example of Two Way Messaging between a Service and an Activity can be found in the following android examples : Service & Activity
Warning: designing robust, full blown AIDL-based services is a tough job.
Two ways you could solve this problem.
1) Have MyOwnService do a callback into MainActivity telling it to launch your ScanActivity.
- This is a better approach if MyOwnService's task is only going to be running while MainActivity is running and if the user would expect the ScanActivity to come up automatically.
2) Have MyOwnService create a notification that will let the user access the ScanActivity.
- This is a better approach if MyOwnService's task might be running longer than the life span of MainActivity. That way, you can let the user know, unobstrusively, that they might want to access the ScanActivity.
So finally I changed my architecture.
I make the choice to delete myOwnService and to create an intermediate activity that will be my API Adaptater.
This activity will have a dialog.theme to look like a dialog box indicating that a recognition is under execution.
If the recognition uses the external device this activity will stay at the foreground otherwise the camera activity will start (Being managed by the intermediate activity).
Thank to that I can manage my result from the intermediate activity and do not have an android strange architecture, keeping my business code for the recognition outside my main app.
Service was not the good choice.
Thanks a lot for you help and your time.
I can find several examples of how to build a service, but I'm having a difficult time finding a working example of how to send messages between an Activity and a Service. From what I can find, I think my options are to use Intents, AIDL, or to use the service object itself as per this question.
In my case, my activity is the only activity that will ever access the service, so a local service will do. When the activity is open, I want to see some status messages from the service, which will be coming in at up to 20 Hz. Are there any limitations on how many messages per second those communications methods will support? Basically, which method is going to be best for my situation?
Thanks.
Since your Actvity and Service are a part of the same app, then no need to use AIDL. You may simply use your Service as a local one.
The limitation is only affected by the performance of your device. There is no cap on requests per second.
Usually there is a context switch involved, that uses quite a lot of cpu (compared to other parts of the transmission), but since you use a local service you don't suffer from that. In any case, 20Hz is not a problem.
The best solution for you would be to use AIDL, and set up a callback that the service can call to report its status.
There is good example of how this is done in the APIDemos.