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
Related
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.
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
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.
Why not use the Windows scheduler?
I have several applications that have to run at certain times according to business rules not the typical every weekday at 1pm.
I also need a way for the applications to provide feedback of their progress so that I can have rules that notify me when the applications are running slow or aren't even running anymore.
What Windows API should I be looking into? (like, a time version of the FileWatcher apis)
What's the best way to have the application notify the scheduler of its progress (files, sockets, windows messages, ???)?
For Vista/Win2k8, there's the nice Task Scheduler 2.0 API: http://msdn.microsoft.com/en-us/library/aa384138(VS.85).aspx. Previous version have the Task Scheduler 1.0 API, but I've never used it.
AppControls has a CronJob component that you can use to create scheduled events. This saves your program from having to wake up every minute and check the schedule itself. Instead, just schedule the job and indicate a callback method.
I have used this component for scheduling jobs myself and have been very happy with the way that it works.
I think what you really want is a common framework for your applications that report to something (you or the system messages or tracing or perfmon, event log, whatever) and also to receive via some inter process protocol a way to receive messages and respond.
based on the reporting you can change the scheduling or make changes, etc.
So, there is some monitor app, and then each of your other apps does common reporting.
events I can think of:
- started
- stopped
- error
- normal log messages
- and of course specific things your apps do.
I think there are probably existing classes/framework that do this - you'll have to check around.
If it were me, I would make a service that could talk to all the other apps and perhaps was even an http server. It would be able to route messages to particular apps and start stop those processes and query them.
There are lots of ways to do what you want though. those were just off the top of my head.
Alternatively you might just be able to get these to be services and they handle messages sent to them. Their normal processing does nothing until they are "woken up" with some task command.
You have more questions in one. Normally you should split them. But let's overlook this and try to answer.
To schedule certain events (including running an application): Use TJvScheduledEvents from JVCL. IMHO JVCL is the best Delphi open source library around with extensive number of components, developers & support. TJvScheduledEvents is quite neat, uses threads for event scheduling and also you have in JVCL a detailed editor for your events (it needs a small hack to use it though).
To provide 'feedback' from your applications to a (remote) central point: A very very very good solution (if your requirements permit) is to log the progress of your applications in a table (let's call it LOG) on a Firebird server. In LOG you can have the following fields: COMPUTER, USERNAME, APPNAME, MSG, LOGDATE (etc. etc.). In the After Insert trigger of the LOG table you can fire an event (let's call it NEW_LOG). In your console app you can register the interest for this event and so, your application will be automatically updated with everything which happens in any of your applications, so you can do log analysis, graphs etc. Of course you can do it with IB, but IB costs.
...going on Windows API route you need headers (which probably aren't translated), you'll encounter our dearest Pointers/PChars etc. etc. Of course, building from scratch everything isn't worthwhile but when this is already done in a Delphi way, why don't use it?
Use service with a timer that is fired regulary (for example each minute). It reads the schedule and looks if some are due before the next iteration. If so, you can execute them.
You can add an interface that shows all running apps. For the feedback and query that using a desktop application.