I'm using Adobe's Google Analytics SWC library for flex. What I'm trying to achieve is to simply be able to utilize the realtime features of Google Analytics to know when users have my AIR desktop application open.
Making it detect an open application was easy enough. I can visually see the count on Google Analytics getting updated in a matter of seconds whenever I open up my application. However, the problem occurs when I close my app. Google Analytics doesn't seem to detect a closed app and still detects it as open on the realtime view. How would I go with making Google Analytics know that the application has stopped?
So far, it seems the realtime counter only reverts back to 0 after some 30 or so minutes that I have already closed the app. This leads me to believe that it was considered to be idle by Google and so decided to update the statistics. That might be good and all but I really want to utilize the realtime capability so I need it to reflect when an app closes with only a few seconds of offset.
Any thoughts?
Not sure if this one will work (don't know that Android will kill the process and restart it each time) but if it does it's an answer:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/NativeApplication.html#event:exiting
Also check out the Deactivate event as it seems to be relevant, more on mobile app life cycle here:
http://help.adobe.com/en_US/air/build/WSfffb011ac560372f82c4ee412b1275403b-8000.html
From the Google Analytics documentation.
setSessionTimeout () method public function
setSessionTimeout(newTimeout:int):void
Sets the new session timeout in seconds. By default, session timeout
is set to 30 minutes (1800 seconds).
Session timeout is used to compute visits, since a visit ends after 30
minutes of browser inactivity or upon browser exit.
If you want to change the definition of a "session" for your
particular needs, you can pass in the number of seconds to define a
new value.
This will impact the Visits reports in every section where the number
of visits are calculated, and where visits are used in computing other
values.
For example, the number of visits will increase if you shorten the
session timeout, and will decrease if you increase the session
timeout.
Related
I'm building an app which is made of a webserver (currently using NodeJS but doesn't really matter here) and a Chrome extension.
The point of the Chrome extension is to display some data from the server. For this, I need the extension to be aware of changes on the server-side. To do that, I see 3 possible strategies :
1. Websocket
Having a websocket in the background that triggers updates in real time.
2. Regular fetch
But I also can have a timer that will fetch new data on a defined frequency (something like every minute)
3. Event triggered fetch
Another solution would be to detect browser activity, and to trigger a server call during that activity (eg. on active tab changed)
The tradeof I see is browser memory/network usage vs. realtimeness.
To define realtimeness necessity, I'd compare it to an unread email indicator: it doesn't matter if the user is made aware a minute after, but conceptually, it means always displaying out-dated data, which doesn't sound great to me.
On the other hand, if using websockets, or event listeners come at a too high cost and will eventually slow down the browser too much, I'd rather have a minute delay. :)
But maybe fetching the server every minute with most of the time no update to send may be even more expensive than keeping a websocket alive...
Well, any insights on this tradeof and how to choose would be highly appreciated!
Special thanks to #Rob-w for helping me to reformulate the question.
I'm using the AS3 Timer class to sync data between a Flex Mobile app and a server ideally every 30 mins then send a local (distriqt) Notification to the user when action is required.
However, when the device goes into sleep / hibernate mode it seems to slow down, even stop the Timer. I've tried using a lower interval (5mins) but it still only works intermittently.
This is very hard to test as the behavior is different in debug / run modes.
Any suggestions?
Thanks.
Sounds like you might need to change your approach here. Background operation of applications is very different from the foreground.
Your application will run for a little while (depending on the current device memory load among other things) and will then enter a suspended mode, mainly to preserve the application's memory state.
There are some background mode exceptions to this, such as audio playback and location updates, however if you aren't performing these then Apple will most likely reject your application as part of the review process.
You can also investigate the executeInBackground flag on the NativeApplication. This allows a long running task to execute in the background, however this does not guarantee that the application would run in the background continuously.
You can read more here: http://blogs.adobe.com/airodynamics/2012/05/04/air-ios-background-behavior/
UIBackgroundModes: https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html#//apple_ref/doc/uid/TP40009252-SW22
I'm trying to develop a Google Chrome Extension app VoIP softphone. I will be using the Inline Installation feature (https://developer.chrome.com/webstore/inline_installation) and will be publishing on the Chrome Developer Dashboard (https://chrome.google.com/webstore/developer/dashboard)
My problem is due to the nature of the softphone that has to be always connected, every time I need to publish an updated version of the softphone users will be disconnected, and this will be a big hit on user experience.
Anyone ran into the same issues in publishing a softphone extension app in Google Chrome?
An update may be downloaded at any time, but an extension is only reloaded when the background page goes inactive.
I guess that you're using Web sockets for signaling. Since the connection need to be available at all times, you are probably using a persistent background page. This is enough to prevent a sudden unload. If you use event pages, then you need to jump through some hoops to get the page to stay alive even if the Web Socket is not busy all the time (crbug.com/204573), but also in this case, the extension will not suddenly be reloaded.
If you do want to reload an extension after an update, add a chrome.runtime.onUpdateAvailable listener and call chrome.runtime.reload when it is convenient (e.g. when the user has unregistered their soft phone, and/or when the user is idle, etc.).
The dashboard provides the ability to ramp up your updates. So only a small percentage of users will be affected at any time under your control.
In addition to the a slow ramp you can do it during off hours to minimize user experience.
This won't solve for disconnections during the update but could minimize the impact.
I'm in the process of developing a WP8 app that makes use of the background location tracking abilities provided by the OS. The idea is to monitor the users position and to notify them when they are near certain types of places.
So far it all seems to work fine and when running the location tracking works as I would expect.
The problem is, it seems that the phone times out background apps after around four hours, stopping the location tracking.
I can understand why Microsoft did it, to preserve battery life etc. But there's not much point having a background location tracking app that has to be manually restarted every four hours! If a user chooses to run this app and is made aware of the potential battery hit, surely it should be able to run indefinitely - to a point of course, if the system runs out of resources or similar then that's fair enough.
Does anyone have any experience with this? There must be hundreds of others apps in the store that have run into this issue I would have thought? And presumably there must be some way of keeping the location tracking running?
I've tried periodically updating the live tile (using a DispatcherTimer) while the tracking is running but this doesn't seem to be enough to keep the app alive either :(
Anyone have any ideas?
Thanks.
There is no way to achieve your desired behavior. The app will be deactivated under anye of following conditions:
The app stops actively tracking location. An app stops tracking location by removing event handlers for the PositionChanged and StatusChanged events of the Geolocator class or by calling the Stop() method of the GeoCoordinateWatcher class.
The app has run in the background for 4 hours without user interaction.
Battery Saver is active.
Device memory is low.
The user disables Location Services on the phone.
Another app begins running in the background.
Source: Running location-tracking apps in the background for Windows Phone 8
What you could do is to show a toast notification before app is deactivated advising the user, and make him navigate back to the app, extending the period for other 4 hours that way.
There is no way to keep it running without any user interaction.
I have written an entire application to do one and only one thing, notify the people on a shared folder in drive that a new file has been added to the folder. the fact i had to write the application is baffling to me but whatever.
The person generating the content clicks on the notify button when he adds a new file, which on a good day would be about 2 or 3 hundred times, the system will go out, find the new files, get the list of people its shared with based on the folder, and generate an email for those people saying their file is ready to download via the link in the email.
my problem is he starts work about 8 in the morning and about 9 in the morning he gets a notification that he has hit the email quota for the day.
so, just to save time let me answer some of the mundane questions
he has a google apps for business account
no, he can not simply click the notify button less each day. he typically works on
a 5 to 15 minute turn around time for the files
in a given year he averages about 14,000 files added to the system with 200 clients
and i would guess about 600 emails a day.
yes, i have rewritten the app several times now to minimize the number of times the api's are called. I can't go any less than i am currently calling them because the toolset just isn't that good.
the server that ran this system previously was a P4 1 gig processor with 2 gigs of ram
and a 500 gig hard drive that sits in his basement on the end of a
128k ISDN line. that server handled this task well for over 10
years, i think google can handle the load
none of his clients have gmail accounts to be notified of new files as a shared folder
i have his credit card ready to upgrade the quota for the gmailapp api and the driveapp api inside the google app script language and i only need to know what screen to enter it to upgrade these quotas.
Am i going to have to rewrite this app yet again as a GAE app to make this work as expected?
thanks
As an update, it turns out no-one is sure if these limits can be increased. Therefor I rewrote the app in GAE. At least with that framework and Drive API, if he ever hits any of the limits for the free account, he can be back up and running in minutes with a credit card, not have his entire business unceremoniously shut down for 24 hours with App Script.
Thank you all