I am using this sample for receiving location updates :
https://github.com/googlesamples/android-play-location/tree/master/LocationUpdatesPendingIntent
It receives location after I register a location request using a connected instance of Google API Client.
My question is how can I re-register Google Api Client after device reboots? Some say Android O will put restrictions on background services, so a service is not recommended?
I found this link useful, but still don't know about actual behavior of OS and whether treating my app as foreground or background?
https://developer.android.com/preview/features/background.html#services
My question is how can I re-register Google Api Client after device reboots?
Register a BroadcastReceiver in the manifest for the ACTION_BOOT_COMPLETED broadcast. Then, in its onReceive() method, re-register your request for location updates.
Some say Android O will put restrictions on background services, so a service is not recommended?
Whether you use a service for registering for location updates or for processing a location update depends on what work is needed at either of those points. If you are doing any sort of I/O (disk I/O, network I/O, etc.), you should use a service.
What Android O changes is that:
a pure background service can only run for about a minute; if you may need more time than that, you will need to consider using a foreground service
location updates will be delivered less frequently to background apps
Related
I have implemented a background service that sends some data to server.
But the service is only triggered after the trigger is fired.
I want the service to fire immediately as and when its registered.
I have tried
DeviceTrigger
LocationTrigger
SystemTrigger(Internet available/Timezone-changed)
MaintenanceTrigger
TimeTrigger
but they all are fired when their conditions are met as documented. Does any one have any idea how to get this work, btw I'm on windows phone 8.1 and C++.
PS. I just want my service to get triggered as it is registered.
AFAIK you can’t do that directly. Microsoft is very strict about what background tasks can and cannot do because battery life depends on it.
There’s a workaround.
Move your server-sending functionality from your background service into a separate DLL. Call that DLL from both background service process, and the GUI process. If you need to, in that DLL you can guard shared resources with a named mutex or use any other IPC mechanism that works across processes.
I have been using Windows APIs for NFC communication. I am successful in getting and sending NFC messages from Windows PC, using a local console app. However, I want the communication to be done using a Windows service. Here is what I have:
A C# plugin (DLL), which makes the API calls.
C++/CLI Wrapper that allows unmanaged C++ code, to use the above plugin.
A C++ plugin, that the service will load (this is a requirement, it has to be a plugin)
If I load the C++ plugin into a local console app, and run, it can catch all NFC events (NFC device arrives in proximity, departs from proximity, can read and write to it). But, when I use the same plugin with a service, it is not able to catch those events. I can clearly hear the ping sound that comes when an NFC device comes close to Windows PC, however, none of the event handlers are called (For device arrival, device departure, read or write).
I also tried impersonation thinking that perhaps the context of who calls the method might result in blocking of the events. I could impersonate local user on the service, but the results were the same, no events could be identified.
Is there a reason why I cannot see any NFC events from a service, where as a local console app can get all of them? Again, I am able to hear the ping sound signifying that NFC device is close to Windows PC, but there is no handler getting called for it, suggesting there is blockage of something. Any ideas of what is going on?
Appreciate your time guys!
I have some .NET code in a COM+/Enterprise Services serviced component. I communicate with this component from a WPF application and also from a legacy VBA application.
This arrangement works well when only one user is logged on to a machine. The component starts in its own process when either the .NET or the legacy application instantiates one of its COM objects.
The system also works for the first user to try to run it on a terminal server installation. However, when another user logs on, he/she is unable to use the application. I had hoped that each session would run in isolation, and that one host process would run per session. Am I wrong in this expectation?
In Component Services on the Activation tab my application is configured to run as a "Server application". On the Identity tab, "Interactive user" is selected. On the Security tab, "Enforce access checks for this application" is unchecked.
There isn't session isolation as you describe, instead process ownership limits what you have access to.
Your conclusion seems correct & you will need to determine a suitable mechanism to exchange data with the service.
I used WCF to create a service with a net named pipe listener https://learn.microsoft.com/en-us/dotnet/framework/wcf/index
The idea of using proxies to make rpc calls is attractive, but I found the proxy definitions and stubs to link it all together quite clumsy to use.
If you have events that may be triggered at either end then keeping client/service in sync becomes problematic.
AIUI you cannot invoke a rpc method that ends up invoking an rpc back at the originating end, although that could be a named pipe limitation.
If I was doing this again I would use a socket server in the service & the websocket protocol for biderectional data transfer, even though you might need to implement some thread handling to avoid the listener thread blocking whilst servicing requests.
Hard to find anything authoritative on this. For standard COM you can set the identity to 'Launching user'. The same is not available for COM+.
According to this archived post,
A COM+ application can be configured to run under the logged in account, or
a specified account. Under the application properties, see the Identity tab.
...
Once set however, it remains under that account until the application shuts
down, so you can't have multiple users using the same COM+ application under
different IDs.
That seems to match what is said in this knowledge base article too.
My conclusion is, I should probably accept that my component must run once per machine rather than once per session. It will need to be modified to accommodate this. Since it needs to start new processes in individual sessions, it will have to run as a Windows service under the Local System account (giving due attention to the security implications).
I have an app which needs almost no user interaction, but requires Geofences. Can I run this entirely within a background service?
There will be an Activity when the service is first run. This Activity will start a service and register a BroadcastReceiver for BOOT_COMPLETED, so the service will start at boot. It's unlikely that this Activity will ever be run again.
The service will set an Alarm to go off periodically, which will cause an IntentService to download a list of locations from the network. This IntentService will then set up Geofences around those locations, and create PendingIntents which will fire when the locations are approached. In turn, those PendingIntents will cause another IntentService to take some action.
All this needs to happen in the background, with no user interaction apart from starting the Activity for the first time after installation. Hence, the Activity will not interact with LocationClient or any location services.
I've actually got this set up with proximityAlerts, but wish to move to the new Geofencing API for battery life reasons. However, I have heard that there can be a few problems with using LocationClient from within a service. Specifically, what I've heard (sorry, no references, just hearsay claims):
location client relies on ui availability for error handling
when called from background thread, LocationClient.connect() assumes that it is called from main ui thread (or other thread with event looper), so connection callback is never called, if we call this method from service running in background thread
When I've investigated, I can't see any reason why this would be the case, or why it would stop my doing what I want. I was hoping it would be almost a drop-in replacement for proximityAlerts...
Can anyone shed some light on things here?
The best thing would be to just try it out, right? Your strategy seems sound.
when called from background thread, LocationClient.connect() assumes that it is called from main ui thread (or other thread with event looper), so connection callback is never called, if we call this method from service running in background thread.
I know this to be not true. I have a Service that is started from an Activity, and the connection callback is called.
I dont know about proximity alerts; but I cant seem to find an API to list my GeoFences. I am worried that my database (sqlite) and the actual fences might get out of sync. That is a design flaw in my opinion.
The reason LocationClient needs UI, is that the device may not have Google Play Services installed. Google has deviced a cunning and complex mechanism that allows your app to prompt the user to download it. The whole thing is horrible and awful in my opinion. Its all "what-if what-if" programming.
(They rushed a lot of stuff out the door for google IO 2013. Not all of it are well documented, and some of it seems a bit "rough around the edges").
I'm writing an application for Windows Mobile 7 which required information about "When a voice call was placed" and "when a voice call was hanged up or disconnected". Are there any API's or events/triggers that can give me this information.
The current SDK doesn't offer this capability - generally, you cannot keep track of user activity (like calls) outside the application due to a sandboxed environment that by default doesn't offer any system process hooks.
While you can't get any information about a specific phone call, if your application is running you can be informed when a call is received (and ended) by using the Obscured and Unobsured events on the page.
Please note that this will be triggered when ANY piece of UI chrome covers the page. In addition to incoming call notifications, this will also include incoming SMS notifications, alarms, etc.
These event are an important part of the application lifecycle for some types of apps (typically games) but are often overlooked.