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.
Related
I'm trying to create an app that manages a BLE connection in the background (receives notifications, reconnects and subscribes to a characteristic when connection is lost and the phone is moved near the BLE device again).
Right now I have the app somewhat built - everything that I need works relatively well but only when the app is open. Although the code isn't up to standard as this is my first app and I don't have any previous experience with Java/Kotlin/Dart (this is also why I'd rather not touch anything outside of flutter).
I need the app to send me local push notifications when tabbed out of the app or when screen lock is on and as far as I understand one could do this with isolates. I've searched a lot but found one guide which is kind of hard to understand as a beginner and also uses Kotlin.
Can I get away with only dart code for background code execution (described above) and is it suitable for a beginner?
Also, let me know if you have any alternative solutions since all I need is to get a notification on my phone whenever it receives a notification from a BLE device (and also auto connecting). I've already tried this with kivy since I'm more familiar with python but with no luck.
Talking about BLE there's this plugin by the way: https://pub.dev/packages/flutter_reactive_ble
As for the isolates, they are not ideal for this even though they do run separately, they'll get killed eventually. There's also a little helper package that makes working with isolates very straightforward if you want to try it: https://pub.dev/packages/computer
And so actually for the task at hand (background execution) I would suggest researching/using this one: https://pub.dev/packages/background_fetch
I would not encourage you to use any timer-based solution that tries to wake up your phone every 15 minutes or so, since that uses unnecessary CPU time.
Now I'm not that much into Flutter, but at least on Android, the "correct" way to have an ongoing connection (auto-connect) is to have a Foreground Service in the process running, so the process does not get killed. Then subscribe to characteristic notifications as usual, and handle the values as they arrive, either in Java or Flutter (by using some Java <-> Dart bridge).
I recently set up a web service using LABVIEW which exhibits a bunch of shared variables which can be changed via buttons in the LABVIEW program itself.
Apart from this I would also like to control the shared variables via my Android phone.
Actually, this works pretty well and I can also see the LABVIEW button's state change when I click the Android buttons within my app.
My question is now: Up to now the LABVIEW buttons' state is only updated but the other way round doesn't hold true. How can I make the Android buttons' state change when using the LABVIEW buttons?
Do I have to employ IntentServices or do I have to use GCM (Google Cloud Messaging) etc.?
I dont know exactly how LABVIEW works but basically you are providing some server-client communication functionality. So there is no magic way of updating your android's application state based on changes happening on the server side. basically you will have to follow polling or pushing approach.
Either your application can ask the server periodically (poll), or your server has to notify the client when the changes occur (push). The first approach is simple but will eventually drain your battery quicker, meanwhile pushing messages from server to client is more elegant but requires greater efforts.
How can I make the Android buttons' state change when using the LABVIEW buttons?
Using poll or push approach.
Do I have to employ IntentServices?
You dont have to. But eventually your notification mechanism will reside on a service. it might happen that IntenService is a good solution but depends on your requirements.
Do I have to use GCM (Google Cloud Messaging)?
You dont have to. There are other solutions as well such as establishing yourself a socket level communication.But GCM might be quicker for your case.
I have been developing for Android for little less then 2 years, and I am still puzzled by this seemingly simple question.
When should one implement a service?
From my experience there are some rare cases but I am questioning this because on every phone there are quite a lot of them running and I doubt it's just a poor application design.
This is essentially core of my question but following are some of my experiences and thoughts about the subject which can explain my question in more detail.
In all apps that I have developed only one really required a service. It was a background sound recorder and I was using it as Foreground service with notification since I wanted buttons to be able to control it (like music players do for example).
Except this I never really saw a requirement for the constantly running service because:
A) Intent listeners (Manifest registered BroadcastReceivers) are quite a useful feature and using them as you know is usually enough for many use-cases (for example showing notifications).
B) If scheduled execution is a must one can subscribe to alarm events.
C) I know that service in Android is quite different then for example in Windows since in Android services are just a "package" to organize your code in and have a the system manage the lifetime of the object. Services use the Main Thread but it's customary to spawn new threads in them.
D) In the development documentation services are suggested for network communication and background calculations but I don't get why you should not just use AsyncTasks for that. I am a big fan of these and use them extensively for lot of things from downloading data from the internet to doing FFT calculations under time critical conditions.
E) I get the usefulness of Foreground services but why are people using background services so much (excluding the system apps).
Those are my thoughts about the SERVICE and I hope someone with more experience will be able to explain these PROS and CONS (along with others that I probably missed).
When should one implement a service?
When you have work -- delivering value to the user -- that:
Needs some time to complete, perhaps longer than you have time for in the component wishing the work to be done, or
Is delivering that value under user control (e.g., music player, controlled by play/pause buttons in a UI), or
In rare cases, needs to be running continuously, as it delivers value continuously
there are quite a lot of them running and I doubt it's just a poor application design
Some are likely to be poor implementations, either due to technical misunderstandings, or other concerns (e.g., making marketing happy) trumping making users happy.
It was a background sound recorder and I was using it as Foreground service with notification since I wanted buttons to be able to control it (like music players do for example)
That is a reasonable use for a service, IMHO.
Intent listeners are quite a useful feature and using them as you know is usually enough for many use-cases (for example showing notifications)
I assume that by "Intent listeners" you mean manifest-registered BroadcastReceivers. In that case, if the work to be done by the BroadcastReceiver will take more than a millisecond, that work should be delegated to an IntentService for completion. onReceive() is called on the main application thread, and it is not safe for a manifest-registered BroadcastReceiver to fork a bare thread, as the process could go away shortly after onReceive() returns. However, in these cases, the service is usually short-lived (e.g., do some network I/O and disk I/O, then go away).
In the development documentation services are suggested for network communication and background calculations but I don't get why you should not just use AsyncTasks for that
An AsyncTask is a fine solution for background work that is:
Requested by the UI (activity or fragment), and
Will take less than a second or so, and
Is non-critical
For example, if you are downloading avatars to show in a ListView, AsyncTask is probably a fine choice, whether you use them directly or use some image-fetching library that uses them internally.
Conversely, if the user buys an MP3 through your app, and you need to download that MP3 file, an AsyncTask is not a good solution. That could easily take over a second. While the download is going on, the user could switch away from the app (e.g., press HOME). At that point, your process is eligible to be terminated... perhaps before your download is complete. Using an IntentService to manage the download is a signal to the OS that you are really doing work here, adding value to the user, and so the process will be left alone for a little while.
Note that if the background work might take 15+ seconds, WakefulBroadcastReceiver or my WakefulIntentService is probably a good idea, so the device does not fall asleep while you are trying to wrap up this bit of work.
I can name some of the Service uses from my experience:
to implement
location listener,
sound module, generating various voices
in app content updates,
API, provide services to other apps
in app billing
Communication with webservices (if requests frequency is high)
actually (excluding 5.) they all are working for the whole app duration, they are using some of the other android services, also they manage their state. I suppose one of the important thing here is state management during application life cycle changes.
I prefer to look at AsyncTasks in a same way as Executors (ExecutorService), they should be executed sequentially and for small tasks.
In the android website, you can find a table when to use Service, Thread, or WorkManager (the new API for scheduling jobs, currently in alpha as of this comment posted). https://developer.android.com/guide/background/#table-choose
The website also state that you need to use started service only as last resort. The Android platform may not support started services in the future. Refer to this link https://developer.android.com/topic/performance/scheduling#services
You should avoid using started services that run perpetually or perform periodic work, since they continue to use device resources even when they aren't performing useful tasks. Instead, you should use other solutions that this page describes, and that provide native lifecycle management. Use started services only as a last resort. The Android platform may not support started services in the future.
If you consider UI and bound services, u would think that both can exist and not be doing anything for certian periods. In such scenarios, your UI can be recreated a lot of times however service does not. And this is where service is important. Lets say you are processing images and then rotate device you want processing to continue while UI is being recreated. You recording a voice and then rotate device. These are one of the places where I find service very important. (Having lot of heavy data processing, interaction with web, that could be few seconds)
I hope this question meets the criteria for the site. I'll happily update otherwise.
I am, like many others, developing an application for multiple platforms using the PhoneGap (in this case Cordova 3) framework and want to keep my application alive while the use performs others tasks. I have read around this subject and seem many opinions and possible/partial solutions.
Notionally, what I want to do is allow the user to return to the application had they pressed back, home, they got a phone call, they played tetris or whatever and specifically if the app wants them back under certain conditions.
I am presently tackling this by concentrating on the Android platform and will expand out after this solved. I understand the mechanism by which Android OS will kill processes that are not visible and understand and have implemented an example background service.
I employ JQuery Mobile with collapsible content for my application.
Before I continue development, I would like to ensure I am on the right path.
I have successfully implemented pause/resume to handle phone locking and sleep. My application does not die and I can make it beep and vibrate through appropriate plugins.
My continued intention is this ...
Write a background service to perform periodic "checks" in this case position of phone relative to a known position. The intention is to inform the user when they have reached certain proximity. This would be started on the "pause" event and stopped on the "resume" or of the app is restarted.
Using Local Storage, maintain a record of state of the UI so it can be restarted in the correct state. Upon restart, the stored state will be restored and the app will look like it never went away. There is nothing in the app which continuously updates, like graphics or logs, so there is no reason to retrieve "past states" from the background service and perform a rendering of those as if they had been performed by the app, but that would not seem unreasonable should that be required on the future.
As it's possible that the app will not be running, it seems necessary for the service to create a ("something important has happened") notification that the user can click on in order to restart the application. I have found a couple of status bar notification plugins and intend to use one. I trust I will be able to beep/vibrate accordingly from the background service alo.
In addition, a "stuff is generally happening" continuous notification could be used to restart the app. I see no conflict with the above. It would be nice to find a "bring app to foreground is it's running" method, but I'm holding out no hope.
My essential question is this ...
Am I approaching this problem correctly and maintaining as much cross platform work as possible whilst not setting myself up for a fall when it comes to implementing the iOS facet of the solution?
I just don't want to miss a trick I've not located in the sea of answers to what seems like a common problem.
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.