I am getting very inconsistent plot results with different devices. Here are some of the issues I have noticed:
The same fences and triggers are deployed to both devices, but:
1) One device is only triggering the exit event on a particular fence, the other doesn't fire the exit event at all.
2) Both devices are not firing the geofence enter or exit events for a series of geofences I have created. I have tried going into the fence and waiting to see if the enter ever fires and does not.
I am retrieving the list of active triggers using the plugin to ensure the triggers are registered with the device.
What can affect geofence triggering behaviour and how do you troubleshoot?
Which devices are you testing with? And are you testing with the Plot Projects demo app or your own app with Plot integrated?
Whether a geofences triggers or not is dependent on a number of things, such as accuracy of the location update. You can troubleshoot the behaviour of our plugin by checking the debug log. How you can use this is explained in this blog post: https://www.plotprojects.com/how-to-test-plot-integration-with-debug-log/
In case you are using Titanium, we expose a mailDebugLog() method for that framework, this is explained in the documentation here: https://github.com/Plotprojects/plot-titanium-module#function-reference
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
In Android, an app which is not currently running can be notified when certain event happens (like wifi scan results available, boot process completed) through Broadcast Receivers mechanism. Is this possible in anyway so that the wifi/geo triggers can be invoked even if the Worklight app is not running, including not running in the background?
Regarding wifi/connectivity changes notifying your app, that looks possible since it is a standard system event. It would likely take custom native code since you'd need to implement a broadcast receiver. And you'd need to register your receiver in your app's AndroidManifest.xml file. Take a look at http://developer.android.com/reference/android/net/ConnectivityManager.html and http://www.grokkingandroid.com/android-getting-notified-of-connectivity-changes/
Regarding geolocation triggers, it is unclear what sort of triggers you are looking for. This is all I see in the Android docs: http://developer.android.com/reference/android/location/GpsStatus.html and the standard broadcast actions at http://developer.android.com/reference/android/content/Intent.html#constants
If you are looking for something like geofencing, it would take application logic to determine when to fire events, so that means an app or service needs to be running. So although your broadcast receiver's onReceive() method can get called upon a geo event, who is going to fire that event?
Having the triggers activate when the application is not running at all (not even in background) isn't supported through the Worklight APIs.
You could try and use Worklight Android Native SDK together with cmarcelk's suggestions. Or you could use the Worklight Android triggers within a native service, together with the Broadcast Receivers mechanism so that it will run automatically on boot. You could then use an Intent to open the application from the trigger callback.
I am testing our iBeacons on iOS 7.1 and I can detect beacons correctly when I am in foreground and invoke the app from the background. However the issue comes when user has killed the app. The "didDetermineState" callback get invoked twice when I am in the beacon region while the app is killed. Am I missing the obvious or has anyone experience this same behavior ?
I have seen this happen not just when the app is completely killed, but in other cases, too. You will need to add filtering logic to your region callback methods, so if you get multiple calls it doesn't cause trouble in your app.
Another common issue is that you will get an exit region notification, followed within a couple of seconds by an entry region notification. Again a software filter is the way to deal with this. An example of a software filter for iBeacon callbacks is described here.
When we deactivate a WP app, it can be tombstoned and terminated later by the OS. I need to save some unsaved app data to a persistent storage when the process is terminated, but not before this. Obviously, the Deactivated event cannot be used for this purpose as it is raised immediately when an app is moved to the background; the Close event is also not the event we need as it si not raised when the app process is terminated by the OS. Is there a special Windows Phone app event for that, something like Application_Terminated?
The problem is that the operating system only tombstones your app when it is under severe resource pressure. At the time it is not practical to wake up the app and run app code because it might risk whatever is currently in the foreground. This limitation exists on all modern mobile operating systems (Android, IOS included). This is just the cost of operating in a battery/resource friendly environment.
Having said that, it sounds like your backing store does not disambiguate between data the user "saved" and data that is just being cached until the user can finish the transaction. It would be useful to build the idea in. Think of it the way some of the smarter web sites on the internet now work. You can navigate away while you were in the middle of entering data and when you come back the site presents you with the partially filled form. The site understands that you weren't "done" but it respects the fact that you had provided some of the information you'd need to get "done".
What I'm saying here is that the problem is easily fixed by understanding and accommodating the way your users are likely to use the app. Thinking of your app like a web site (at least in this context) helps out things into perspective. Sorry about the longish answer. I hope it helps :)
There is no such event. You should save your state on Deactivated so that if the application is removed from memory (tombstoned) you can set yourself up again upon reactivation. If your problem is figuring out whether or not you need to restore state on Activated, check out the ActivatedEventArgs.IsApplicationInstancePreserved flag (http://msdn.microsoft.com/en-us/library/windowsphone/develop/microsoft.phone.shell.activatedeventargs.isapplicationinstancepreserved(v=vs.105).aspx). This flag tells you whether your app was tombstoned. If it wasn't, you can throw away the old state or overwrite it the next time you are deactivated.
I am working on a Win8-UI-App (previously called Metro...) and trying to implement Periodic (Documentation for different methods) Tile Updates (Live Tiles) for the first time.
I found a couple of very good resources on the internet and was able to do it. Unfortunately the question of where I should register for the notifications remained unsolved:
Do I have to register for Notifications every time the app starts (e.g. in the App.xaml.cs OnLaunched() Method)? - Or is there an other, more professional way to do so? (I could imagine to save if I already registered for the service or is there a variable I can access to see whether notifications are registered?)
thank you!
PS: For everyone who is also new to this see this StackOverflow post, this example, the tile template types and the Dev Center for quick starting :)
Periodic updates will continue until they are explicitly stopped or your app is uninstalled. Technically, you only have to do that once. But, the Guidelines and checklist for periodic updates states
Call the StartPeriodicUpdate or StartPeriodicUpdateBatch method each
time your app is launched or brought into focus. This ensures that the
tile content will be updated each time the user launches or switches
to the app.
According to that, App launch and App resume are good candidates for a call to StartPeriodicUpdate.