I have been tracking flurry events in my iOS app and they show up in the dashboard. I tried to add a new parameter to an existing event, and then activated the event on my phone a bunch of times yesterday, but I still don't see any occurrences of the new parameters on that event in the dashboard.
Does flurry not allow you to add new parameters to an existing event?
We noticed this too a little bit ago, and emailed support#flurry.com about it. Here's what they said:
Typically, Flurry sessions never completely report back to Flurry until the next time the app is launched. So, be sure to launch the app one more time after you complete a testing session. Furthermore you should make sure you launch the same build of the app. If you make a new build between sessions you may be removing incomplete sessions before they get reported. If you are running tests via an emulator, please ensure that the home button is pressed before closing the app. Then you should relaunch the app one more time with the same build to ensure all session data is reported.
If the app pauses or moves to the background for more than 10 seconds, the NEXT time the app runs, Flurry agent will automatically create a new session and end the previous session. Otherwise, Flurry agent will continue the same session. This can be updated via the setSessionContinueSeconds method. If the app is terminated, a new session will be created when the app runs again.
When we receive the complete session data (after the app is relaunched) the event logs should update first within 10 minutes or so. Please allow about 6 hours for this to populate to the dashboard, parameters pie chart etc.
Basically, what we were doing is just booting up the app, doing the thing that would send an analytic event, then quitting the app or whatever. Which wasn't giving the flurry agent enough time to actually send the event. (turns out that, contrary to the log events, flurry wasn't sending the log event right then :/)
Hope that helps!
The Flurry SDK only communicates with our servers twice per session. The first time is when the session is started and sets the timestamp for the session, counts a new user or updates an existing user as active. The second time is when the session ends and all event data is sent in one batch.
In cases where we do not receive the second report we refer to this as an "incomplete session". This arises in a few scenarios but mainly
-No network connection when the session ends
-The app is sent to the background for >10 seconds and the session continues running
In these cases the event data is stored on the device's disk and sent the next time the app is launched.
Related
Problem
I am developing an application that can track workout sessions for multiple paired Apple Watches (multiple watches paired to a single phone). I have implemented Watch Connectivity for multiple watches as per Apple Documentation, and that part of the application seems to be working okay. The application allows the user to initiate a workout session and pulls data from HealthKit so the user can view it in the future. I am having an issue with the application crashing (or at the very least, the handleActiveWorkoutRecovery method is called) after starting a workout following a pairing switch of the watches. As a sample timeline to what occurs:
Time (minutes)
Event
0
User starts workout session on Watch 1
5
User stops workout session on Watch 1
5
User switches pairing from Watch 1 to Watch 2
5
User starts workout session on Watch 2
6
The application "crashes" on Watch 2
I would include Crash logs, but the crash does not seem to show up anywhere. I have tried finding the logs through the organizer for TestFlight versions, and manually through sysdiagnose and the Devices and Simulators tab in XCode, but they just aren't anywhere, leaving me to hypothesize that this is not actually a crash (or at least that crash logs are not being generated).
What I have tried
I initially hypothesized there was some issue with the way I had implemented WCSession, but all three of the required methods session(_:activationDidCompleteWith:error:), sessionDidBecomeInactive(_:) and sessionDidDeactivate(_:) have been implemented in the code appropriately, as have all delegates. I also tried switching multiple times without starting a workout session to see if the application would crash, but it did not. I do not think this is the problem.
I also hypothesized that perhaps I was not ending the workout sessions appropriately and maybe the issue was something related to that. However, I am calling the appropriate .end() and .stop() methods for the workout session and HealthKit queries respectively. Additionally, I can restart the session on a single device after stopping it immediately, and it does not cause any issues. I do not think this is the problem either.
Current hypothesis
Currently, I hypothesize that the problem lies somewhere in starting the session too early after switching. So for example, while doing testing, I discovered that this timeline of events DOES NOT cause a crash
Time (minutes)
Event
0
User starts workout session on Watch 1
5
User stops workout session on Watch 1
5
User switches pairing from Watch 1 to Watch 2
10
User starts workout session on Watch 2
However, this timeline of events, DOES cause a crash.
Time (minutes)
Event
0
User starts workout session on Watch 1
5
User stops workout session on Watch 1
10
User switches pairing from Watch 1 to Watch 2
10
User starts workout session on Watch 2
11
The application "crashes" on Watch 2
Notice in the previous test I had waited 5 minutes before initiating the session on the newly paired watch, and in this one, I waited 5 minutes before switching the pairing, but start the workout session immediately after the switch. To be absolutely clear, I always wait for the switch to complete (a tick mark appears in the watch app on the phone when the switch is complete) before starting a tracking session.
Question
To me, it seems like there is something going on after switching for at least a few minutes wherein starting a session will cause a crash. Unfortunately, I do not know what that is, so am wondering if there is a chain of events that occur after switching the watch pairing which will cause the workout session to crash if it starts too early. Right now the only workaround I can think of is not allowing the user to initiate a workout session for a specific period of time after a watch switch, but I want to know if there is some sort of event that I can tie that functionality to, instead of just blocking the user for a period of time.
This isn't an answer, but: your use of HealthKit will not be relevant here, unless it's simply contributing to your control flow in a way that's causing some other mismatch. HealthKit workout sessions are fully independent on different devices, and so session control on one cannot affect sessions on another.
I'm working with the Flurry API for iOS and I've come across a use case that doesn't seem to be supported:
I'm starting a timed event with -logEvent:timed: to track how long a user spends on a view. While the user is on that view a few parameters are being tracked that I plan to pass along to -endTimedEvent:withParameters: when the user navigates away from the view).
Here is the tricky part, if the user backgrounds the app while on the view, Flurry will automatically end the timed event after 10s without setting any parameters. One solution of course is to observe UIApplicationWillResignActiveNotification and call -endTimedEvent:withParameters: myself. However, I'd like to respect Flurry's setSessionContinueSeconds property and not end the event until the session is over. This way if the user returns to the app within 10s they are still under the same event that is tracking their time on the view.
Is there a way to do this?
For instance, is there a delegate method called when the session willEnd/didEnd where I could manually call -endTimedEvent:withParameters: before Flurry does? or alternatively is there a way to append parameters to a timed event while it is active (without ending it). That way when Flurry ends the session, the event already has the parameters set.
1) Flurry has a feature (only on iOS) to allow sessions to continue into the background that you can try for this use case.
[Flurry setBackgroundSessionEnabled:Yes]
You can find more details about these and other methods in the Analytics readme document that is included with our SDK.
[Flurry setBackgroundSessionEnabled:(BOOL)backgroundSessionEnabled];
This option is disabled by default. When enabled, Flurry will not finish the session if the app is paused for longer than the session expiration timeout. The session report will not be sent when the application is paused and will only be
sent when the application is terminated. This allows for applications that run in the background to keep collecting events data. The time application spends in the background contributes to the length of the application session reported when the application terminates.
[Flurry pauseBackgroundSession];
This method is useful if setBackgroundSessionEnabled: is set to YES. It can be called when application finishes all background tasks (such as playing music) to pause the session. A session report is sent if setSessionReportsOnPauseEnabled is set to YES. If the app is resumed before the session expiration timeout, the session will continue, otherwise a new session will begin.
2) You can keep the data in an array and place the parameters into a separate event that triggers after the timed event instead.
First of all i need to describe what i am going to do: when user launch my application the app start collecting statistics about the user activities and behavior, once the the user close the app (app enter background) the application upload all statistics to server.
the problem if the user presses home button twice and removes application from multitasking screen. then the application may not succeed to send statistics to server. because it will be terminated.
my solutions:
enable Background fetch , in background modes. but I don't think that will help because according to apple: the system does not relaunch apps after they are force quit by the user
using Executing Finite-Length Tasks , i tried it , it won't send the data if user remove the app from multitasking screen.
using NSURLSession to Downloading Content in the Background, but according to apple If the user terminates your app, the system cancels any pending tasks.
so all above solutions will not work if user terminate the application, any solution ?
I noticed that if i terminate the appstore app (remove it from multitasking screen ) while there is an application being downloaded , the application will continue downloading normally. is this just for appstore app ?
If the user terminates an app, the app terminates. There is nothing you can do about this. iOS devices are meant to be controllable by the user.
Depending on what you are trying to achieve, you might add all the statistics to a queue on disk, and empty that queue only after the app has successfully uploaded the data to the server.
If the user doesn't force-quit, this will work at once, in just the way you want.
If the user does force-quit, the data will not be uploaded and the queue will still be present on disk. When the app is started, it can check the queue and upload it immediately.
You ought to be doing something like this in any case, to deal with cases like the user going underground for an hour, or taking a long-distance flight.
I suspect that the App Store app does not install apps, but tells a system process to install them.
I am creating an app that's using a CLLocationManager to track my position and update it to a database with a Google Map. The sole purpose for this app is to stay in the background and continue to update your location as long as you've logged in and set an Available key to true.
The app works fine in the foreground and it updates my location every minute, but when it's in the background it stops after 15 minutes as the app suspends (I suspect). I've implemented the startMonitoringSignificantLocationChanges() method, but if I stay in one place for too long without opening the app manually after 15 minutes, the updates stops and my map only plots your location for so long without you updating and resetting the lastLogged timestamp.
Is there any way I can force-activate the app to a background state without actually opening the app itself? As the plan is for many people to start using this app, opening the app every 15 minutes is going to be a massive bother and I would love for some way to do this automatically.
Thanks for any help!
PushKit allow you to send messages directly to the people who have installed your app, even when the app is closed on a device or in background.
Its a new framework in iOS 8, is the new push notification mechanism which silently launch your app into the background without the need of user interact with the app.
Here is link in Apple:-
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Reference/PushKit_Framework/
I would like to add Flurry to an iPad app that is meant to stay running in the foreground for several weeks.
Flurry apparently only uploads information to its servers on events such as app start, app close, app pause, but I don't expect my app to enter those states very often. I need app feedback sooner.
Is it possible to force Flurry to send data on a timer, say every hour or two?
I found a way that seems to work. To test, I created an NSTimer that calls [FlurryAPI startSession:#"yourKeyHere"] every five minutes, then let my program run without stopping or pausing it in any way, and the event data is appearing on the Flurry server.
The comments above that method in the .h file do say "start session, attempt to send saved sessions to server", so in a sense it's documented, but it feels like a hack to have to call something called startSession more than once per application run. This is partly why I'm switching to MixPanel, which has a documented upload interval feature.