Developed an app using Xamarin.Android that periodically sends the location of the device through an API rest.
I randomly receive the following message in the UI: "My app is not responding, would you like to close it?"
I would like to know how to intercept the cause since I can not intercept it at development time.
Thank you.
Adding a crash reporter will definitely help you get to the bottom of your issue. Is there a chance that you are calling the REST service from the UI thread? If so, then if there is a network delay, it could "hang" the UI thread, this will result in Android killing the process because it thinks it is no longer working. To get around this issue use:
Task.Run(() => CallYourRESTService());
That way your UI thread won't be locked up. Just a suggestion. Of course it's hard to say without seeing a code sample.
Related
My use case is the following - being able to periodically send updates to a web service with the current location of the device on which the {NS} app is running. This should happen even if the app is "minimized".
I saw that workers have been added to the framework, but as I understand it, the app is supposed to be active(not minimized) for the worker to execute.
Is there a way to accomplish this?
Cheers
You need to use background-services for this purpose.
NativeScriptBackgroundServices
We are developing an app(iOS) in appcelerator which has a sync contact feature in it. This calls an API which syncs contacts with server. I want this to run in background of the app. It should not make the user stop on a screen. Can anyone help me on this?
If you use the iOS background it's only when the app goes to the background and has limitation set by the OS - so if, for example it takes too long to process, or if the OS needs memory - it will shut it down.
I'm guessing (correct me if I'm wrong) that you want to do the sync while the app is running, yet not compromise the user experience by freezing the app?
First of, know the the request to the server is made async - only processing the response is made on the js thread - so to make better use of your single thread I suggest you view the following presentation: http://www.slideshare.net/ronaldtreur/titanium-making-the-most-of-your-single-thread
If you truly want a background thread to do the job, currently you would have to write your own native module to do that.
Also, this is something to look forward to in future versions: https://github.com/appcelerator/cspec-titanium-multithreading
You can use the background service for that.
But be aware, that this services will stop after a few minutes
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 am working on an application that is receiving XMPP notifications using the Matrix SDK. As well I am using async web service calls to receive an initial set of data from the server.
Now, I am aware that with Mango I can close the app or move it to the background and have a background task that is able to be run every 30 mins (or so) for 15sec max which obviosuly means the XMPP push isn't going to work in this scenario. Is there any way to get background apps to execute more frequently than this?
Failing that for the syncing process all I can do is every 30 mins use a web service call to get any updates and store into Isolated storage for my app to pick up when it's next run. But I believe I cannot use any UI from a background task so cannot tell the user of updates?
So, if I get an important message can I somehow override the slowness here and force my app to run and inform the user visibly that something has happened and he needs to look at it? Is this where push notifications come in?
You can use the ShellTile API to update the application's tile on the Start screen, or use the ShellToast API to show a toast to the user. Both of these can be configured to launch into a specific part of your application (deep-linking) when tapped.
If you need a constant monitoring/update/notification system for your application when it's not running, then using push notifications is probably the more appropriate approach.
I would like to create an application that will monitor apps running on my machine, and respond to situations where an application has beachballed. Is it possible (using any of the various OSX programming tools -- I'll teach myself Objective-C for this) to detect whether this has happened? If so, can someone give me a short code sample that does so?
I'm afraid I don't the actual classes or functions involved, but I can give you an outline of the process.
First, understand that every Application (perhaps every Window) has an event queue backing it. Each is serviced by a thread that just pops an event* off the queue, does some processing, and then returns to waiting for the next event. A "beachball" comes up (when forced by the system) when the event queue isn't getting serviced quickly enough. A "frozen" event queue implies that an application locked up when responding to some event in the past.
Now - outside of debugging contexts - you shouldn't be able to reach into another application and fiddle with a thread's event queue to see if its getting serviced. But what you could do instead is periodically post an event that would illicit a response, and if ever that response doesn't come you know the application is "locked up".
This constitutes polling, so be wary of the performance implications.
*Events are things like key down, key up, mouse moved, repaint, and so on.
Besides the WindowServer itself, the other system components that I know of that can detect unresponsiveness are the force quit dialog, spindump (which collects sampling profiles of applications while they are unresponsive), and Activity Monitor (presumably via its pmTool privileged subprocess). Perhaps running strings on pmTool might provide hints about what system calls to use?
Note that none of these evidently does its job by polling, because no application is ever detected as unresponsive until it fails to respond to an event — if an application hangs/does a lot of computation without checking its event queue, but it receives no events during that time, then it is not reported as unresponsive.