I have an application that needs to "poll" a webservice to see if the user has any new messages waiting. I have no control over the webservice so I cannot switch to a "push" mechanism, I'm stuck making a request every X number of seconds to see what's available.
I am using a System.Threading.Timer to make the request every so often, but am encountering a few problems. The biggest is that it stops running when the phone is sent into "standby" mode (screen off, but still able to get calls and email/txt notifications).
I'd really like it to behave like other background applications. What can I do to make it work without being too big of a drain on the battery?
Hate to answer my own question, but I was pointed to this, which was able to perform even when the device is asleep. Looks like it's working perfectly.
There's nothing you can do, AFAIK. Standby mode is meant to suspend the processor to save power, and there's no way your code can execute if the processor isn't running. There are things your application can do to prevent the device from going into standby mode, but this really isn't advisable at all.
Yep. Similar to how MusiGenesis has answered, you won't be able to do much without keeping the device up and running. Similar to how some phones will notify that "Game/App Running" and thus your battery is being slapped around.
What about writing an interface from your phone to leverage text messaging (which still works) and get it to send a text message to the web service? Would that be possible? I'm guessing that sort of method might also stop running, but I figure it's a thought?
I'm not sure about compact framework, but in Win32 there is WaitableTimer that can wake up computer from standby. It takes some native calls though as there's no wrapper in .Net.
Although you can't modify the webservice, you might be able to add a second "shadow" webservice in between your clients and the original webservice. The shadow webservice could poll the original webservice and then "push" anything it finds out to the PDAs.
I think you might still have the same problem, though. I've never done "push" from a webservice, but I think it's basically implemented by having the client make an initial call to a webservice method that takes a delegate to a method in the client, which the webservice then hangs onto. When the webservice needs to push something, it calls that delegate. If the client has gone into standby mode in the meantime, the attempt to call the delegate from the server will fail.
Related
I am using the UI Automation COM-to-.NET Adapter to read the contents of the target Google Chrome browser that plays a FLASH content on Windows 7. It works.
I succeeded to get the content and elements. Everything works fine for some time but after few hours the elements become inaccessible.
The (AutomationElement).FindAll() returns 0 children.
Is there any internal undocumented Timeout used by UIAutomation ?
According to this IUIAutomation2 interface
There are 2 timeouts but they are not accessible from IUIAutomation interface.
IUIAutomation2 is supported only on Windows 8 (desktop apps only).
So I believe there is some timeout.
I made a workaround that restarts the searching and monitoring of elements from the beginning of the desktop tree but the elements are still not available.
After some time (not sure how much) the elements are available again.
My requirements are to read the values all the time as fast as possible but this behavior makes a damage to the whole architecture.
I read somewhere that there is some timeout of 3 minutes but not sure.
if there is a timeout, is it possible to change it ?
Is it possible to restart something or release/dispose something ?
I can't find anything on MSDN.
Does anybody have any idea what is happening and how to resolve ?
Thanks for this nicely put question. I have a similar issue with a much different setup. I'm on Win7, using UIAutomationCore.dll directly from C# to test our application-under-development. After running my sequence of actions & event subscriptions and all the other things, I intermittently observe that the UIA interface stops working (about 8-10min in my case, but I'm heavily using the UIA interface).
Many different things including dispatching the COM interface, sleeping at different places failed. The funny revelation was I managed to use the AccEvent.exe (part of SDK like inspect.exe) during the test and saw that events also stopped flowing to AccEvent, too. So it wasn't my client's interface that stopped, but it was rather the COM-server (or whatever the UIAutomationCore does) that stopped responding.
As a solution (that seems to work most of the time - or improve the situation a lot), I decided I should give the application-under-test some breathing point, since using the UIA puts additional load on it. This could be a smartly-put sleep points in your client, but instead of sleeping a set time, I'm monitoring the processor load of the application and waiting until it settles down.
One of the intermittent errors I receive when the problem manifests itself is "... was unable to call any of the subscribers..", and my search resulted in an msdn page saying they have improved things on CUIAutomation8 interface, but as this is Windows8 specific, I didn't have the chance to try that yet.
I should also add that I also reduced the number of calls to UIA by incorporating more ui caching (FindAllBuildCache), as the less the frequency of back-and-forth the better it is for the uia. Thanks to the answer of Guy in another question: UI Automation events stop being received after a while monitoring an application and then restart after some time
I have an application where I need to create local notifications via polling without doing push - primarily due to client infrastructure limitations and their security model.
I've read: http://www.objc.io/issue-5/multitasking.html, I've seen David Chan's WWDC presentation - where single push messages kick off download tasks - but what I truly need is background fetch - on a regular basis - like every ten minutes - in iOS 7.
I've seen the VOIP hacks. No. What non-hack way is there to do this without user interaction or push messages? Any examples you can point me to?
Here's what I know:
Background data tasks will work in the debugger but if you can get a console on an IPA, you'll quickly find out they really are prohibited (thereby invalidated many examples).
Background URL tasks require custom delegates - but fetch completion handlers are iffy. This too I found with an IPA and console.
I would love to avoid using the AFNetworking lib - for something quite simple.
Background fetch is not a reliable solution - you are at the mercy of the OS, and it is not very merciful. Abusing iOS background modes is not a reliable solution - Apple is known to reject applications that enable background modes, such as location, VOIP and music playback, without a legitimate reason. Background URL tasks are not something you can rely upon to wake your app; they will wake it, but the app will not be awake enough in the background to enqueue a background URL task.
Your best and most intended method is still background fetch, but be prepared to be disappointed. Your app will not be woken app in the interval you need. Also, the user can kill the app in the app switcher screen, causing your app to never wake up until opened.
No real reliable method other than push. You need to insist with your client for the sake of user experience.
Unfortunately there is no "reliable" way to do that on iOS. With the background fetch API you are not guaranteed to have process run when you would like it run. As you've said, you've already looked at the API so i'm probably telling you something that you already know. A local notification wouldn't solve your issue either as this isn't a way that you can wake your application up and kick off network events. This is behavior that Apple doesn't want as this would negate the whole purpose of their background task coalescing.
You really need to have a push mechanism in place for something like this, so if this is something that is needed, then you may have to stress that to the client.
I have created a web-service app and i want to populate my view controllers according to the response i fetch(via GET) in main thread. But i want to create a scheduled timer which will go and control my server, if there becomes any difference(let's say if the count of an array has changed) i will create a local notification. As far as i read from here and some google results, i cant run my app in background more then ten minutes expect from some special situations(Audio, Vo-IP, GPS).. But i need to control the server at least one per minute.. Can anyone offer some idea-or link please?
EDIT
I will not sell the app in store, just for a local area network. Let's say, from the server i will send some text messages to the users and if a new message comes, the count of messages array will increment, in this situation i will create a notification. I need to keep this 'controlling' routing alive forever, whether in foreground or background. Does GCD give such a solution do anyone have any idea?
Just simply play a mute audio file in loop in the background, OR, ping the user's location in the background. Yes, that will drain the battery a bit, but it's a simple hack for in-home applications. Just remember to enable the background types in your Info.plist!
Note: "[...] I fetch (via GET) in main thread." This is not a good approach. You should never fetch any network resources on the main thread. Why? Because your GUI, which is maintained by the main thread, will become unresponsive whenever a fetch isn't instantaneous. Any lag spike on the network results in a less than desirable user experience.
Answer: Aside from the listed special situations, you can't run background apps. The way I see it:
Don't put the app in the background. (crappy solution)
Try putting another "entity" between the app and the "server". I don't know why you "need to control the server at least one per minute" but perhaps you can delegate this "control" to another process outside the device?
.
iOS app -> some form of proxy server -> server which requires
"babysitting" every minute.
I have to design and implement a way to deal with long running processes in a client/server application. A typical long running process would/could take 2-3 minutes. I also need to report progress to the UI in the meantime and keep the UI responsive.
Having these in my mind I though of a few solutions:
One async request to start the process which starts the server-side process and returns an assigned LRPID (Long Running Process ID) then poll periodically from the client using that LRPID. (Pro: simple to deploy, no firewall messing around Con: Unelegant, resource consuming etc.)
Use a duplex binding (such as NetTcpBinding) and initiate callbacks from the server as progress is being made (Pro: Elegant, efficient, Con: Deployment nightmare)
[Your suggestion???]
What would be your take on this?
Here is a post by Dan Wahlin about how to create a WCF Progress Indicator for a Silverlight Application. This should be of some help.
If you do not want to have to worry about the client's firewall, etc... I would probably go with your first solution and use a BackGroundWorker to make the call in order to keep from blocking the UI thread. I did this recently for an app where a request to generate a report is put on a queue and is retrieved once it is done. It seems to work well.
Another way (without having to change the WCF binding) is to use a WebBrowser control in the WPF client, and SignalR to post progress messages from the server to that control.
Note that to avoid javascript errors that happen with the WebBrowser control (because by default it seems to use Internet Explorer version 7 which doesn't seem to be compatible with jQuery.js), you will need to add keys to the registry on the client machine to change the default for the client app to use IE10 or later - see http://weblog.west-wind.com/posts/2011/May/21/Web-Browser-Control-Specifying-the-IE-Version).
This could be a deployment nuisance (because admin rights seem to be needed - eg on a 64 bit Windows 8.1 pc - to add the registry keys).
Also, it still seems necessary to call the long running WCF method in a separate thread, otherwise the WebBrowser control doesn't seem to update its display to show the SignalR messages it is receiving. (This makes sense because the UI thread would otherwise have to wait until the WCF call had finished).
But I mention it as an alternative approach using a newer tool (SignalR) :)
Scenario:
I have a Distributed-objects-based IPC between a mac application and a launchd daemon (written with Foundation classes). Since I had issues before regarding asynchronous messaging (e.g. I have a registerClient: on the server's root object and whenever there's an event the server's root object notifies / calls a method in the client's proxy object), I did long-polling which meant that the client "harvests" lists of events / notifications from the daemon. This "harvest" is done through a server object method call, which then returns an NSArray instance.
It works pretty well, until for a few seconds, the server object's process (launched thru launchd) starts being labeled red with the "(Not responding)" tag beside it (inside Activity Monitor). Like I said, functionally, it works well, but we just want to get rid of this "Not responding" label.
How can I prevent this "Not responding" tag?
FYI, I already did launchd-based processes before and this is the first time I did long-polling. Also, I tried NSSocketPortNameServer-based connections and also NSSocketPort-based ones. They didn't have this problem. Locking wasn't also an issue 'coz the locks used were only NSCondition's and we logged and debugged the program and it seems like the only locking "issue" is on the harvesting part, which actually, functionally works. Also, client-process is written in PyObjC while server process was written using ObjC.
Thanks in advance.
Sample the process to find out what it's doing or waiting on.
Peter's correct in the approach, though you may be able to figure it out through simple inspection. "Not responding" means that you're not processing events on your event queue for at least 5 seconds (used to be 2 seconds, but they upped it in 10.4). For a UI process, this would create a spinning wait cursor, but for a non-UI process, you're not seeing the effects as easily.
If this is a runloop-based program, it means you're probably doing something with a blocking (synchronous) operation that should be done with the run loop and a callback (async). Alternately, you need a second thread to process your blocking operations so your mainthread can continue to respond to events.
My problem was actually the call for getting a process's PID using the signature FNDR... that part caused the "Not responding" error and it never was the locks or the long-polling part. Sorry about this guys. But thank God I already found the answer.