Does anyone know how Fabric calculates the Time in App per User metric?
We are cross referencing a couple of analytics platforms and trying to compare time in app and session lengths. The numbers from Fabric are consistently around 50% that of other analytics platforms.
Is it possible Fabric is doing more beyond just average? Dropping the top and bottom %'s maybe?
Zubair form Fabric/Firebase here - Time in App per User is a measure of how long the typical daily active user is active in the app on a specific day. Fabric calculate this ;
Time in App per User = (median session duration * total session count) / active users
You can find out more on how fabric calculate session here
Related
I'm building a Zoom integration with the Zoom API.
After a call, I would like to access the call transcript within 5 minutes. However, Zoom API only provides this later. I often experience 15-60 minutes delays.
How could I get the call transcript faster at a reasonable cost?
Options I have considered:
Don't build for Zoom
But my target users are here
Send bots to meetings
But it's costly and having a bot in a meeting can be a bad experience
Get people to use Zoom in their browser and capture captions from there
But requires a significant user behavior change
Build Mac and Windows apps that use Zoom local recordings and captions
But increases build complexity significantly
Wait until Zoom speeds up the availability of their transcript after a call
But they might do this only after several years
Educate users that waiting for 15-60 minutes is OK
But they will likely not agree
Use a 3rd party transcription service
But this gets expensive
I have a complication that may need to update every 5 minutes. this could easily sum up to 120 updates per day. Is there a way to only update when the user wake up the watch?
I belief the answer to your question in NO, there is currently no way to only update the complication when the user wakes up the watch.
The reasons:
The idea of a complication is that the user sees it as soon as he or she raises the watch and activates the display.
There is simply no time to activate or launch an app, nor to download a real-time value to display it as a complication.
Thus, the data must be present before the user watches the watch face with the complication.
In many cases, this can be ensured, if the data don’t change too often:
On watchOS, it is possible to schedule background tasks at certain intervals that download actual data from a server. In your case, you would like to schedule regularly (in your case about every 5 min) a WKApplicationRefreshBackgroundTask to download the actual value, but due to power consumption reasons, the number of tasks is limited:
Background app refresh tasks are budgeted. In general, the system
performs approximately one task per hour for each app in the dock
(including the most recently used app). This budget is shared among
all apps on the dock. The system performs multiple tasks an hour for
each app with a complication on the active watch face. This budget is
shared among all complications on the watch face. After you exhaust
the budget, the system delays your requests until more time becomes
available.
So there is no way to do this at rate of 1 per 5 min on watchOS.
One could try to do this via iOS, and send the new complication data using func transferCurrentComplicationUserInfo(_ userInfo: [String : Any] = [:]) -> WCSessionUserInfoTransfer, but the docs say:
If the complication is on the active watch face, you are given 50
transfers a day.
So I do not see any way to preload complication data at this rate before a user raises the watch.
I have created an app which uses location updates in the background. I have submitted my app to apple but it got rejected by apple on the ground that you are using location updates in background rather than using significant location update and shape based region monitoring.
My app takes location updates and provided user with specific updates, which works perfectly for my scenarios and have made code to better save battery. With Apple's suggested approach the problem I'm getting with significant location update and shape based region monitoring is location accuracy. With significant location update I get events fired for all the region within that cell tower range or say 100 m - 3000 m rather than when user enters a region say lat long with 100 m radius.
I've had many conversations with apple and they don't seem to care about the developers and new technologies they are creating.
Is there any developer who faced same problem of using background location update to do something other than navigation and got accepted or has anyone used significant location update with shape based monitoring to provide precise updates with better location accuracy.
Any help is much much appreciated.
Varun welcome to SO community.
Here is some lines from docs
Any app that requests background location services should use those services to provide a tangible benefit to the user. For example, a turn-by-turn navigation app would be a likely candidate for background location services because of its need to track the user’s position and report when it is time to make the next turn.
So if you are using standard location service and whenever you get updates and you are not doing anything with that update (in terms of user not coding) then there are very high chances that Apple may reject your app, which they already did.
So what's the solution then?
1. Answer is try submitting the app with other approach.
2. Try submitting the app with other name :D
Solution Number 1. Instead of using standard services use significant location service which gives the accuracy of around hundreds of meters say 200-1700 m and track if user is moving near to your spot or far away from your spot.
If user is moving near to your spot and user is around 500m (depends upon you) near to your spot just start standard location services and track where user is going if user enters you spot then show user "Catch you" or if user moves away from your spot (>500m) then stop standard location service and start significant location service.
I am developing an iOS application for iPod Touch in which my application displays the server time always. I always sync the application time with server time whenever the application comes to foreground by making a web service call to the server. If there is a connectivity loss between my server and client for few hours I wont be able to sync the application time. I read iOS does not support running a timer when the application is in background other than few limited cases mentioned below:
Apps that play audible content to the user while in the background, such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
So how can I keep track of application time? Whenever the user switches to my application he needs to look at the server time so I need to run a timer to update the last synced server time.
A combination of other answers, create a class in charge of obtaining the server time and maintaining the last time the application was synced to the server using a combination of NSDate* lastSync and applicationDidBecomeActive. For example:
-(void)applicationDidBecomeActive:(UIApplication*)application {
[ServerTimeSync sharedInstance] resync];
}
ServerTimeSync will maintain an NSDate* property with the last sync time (you'll want to convert what the server gives you to an NSDate*).
You can store the NSDate when the app goes into the background. When it resumes, get the current NSDate again, and add the difference to your stored server time.
You don't need a timer for this at all.
I would suggest that when you sync time with your server, you have it return its current UNIX timestamp. You can then do:
[[NSDate date] timeIntervalSince1970];
...to get the device's current UNIX timestamp. Then what you can do is store the difference between these two timestamps. This is the clock skew between the server time and the device time.
You can now compute the server's approximate time by taking the device's current UNIX timestamp and adding the clock skew to it. Adjust for time-zone when displaying it (if you want), and you're done. Whenever you sync time with the server, you can just refresh the stored clock skew value.
If you want to get fancy, you can also attempt to measure and take network latency into account when determining the clock skew.
This approach should work much better than trying to store the server's absolute timestamp and then track how much time has elapsed using a timer (or any other mechanism).
we are creating a location-enabled app where users use this app to record certain events in the field.
The important part of the event data is when an event happened. This is no issue when user is online, but we also support situations when user is offline (by remembering & later syncing events).
There could be situations when users are offline and they change the time on the phone, so that event times are wrongly recorded.
So, what would be the best way to ensure we get a correct time, independent of user actions, given that device could be offline. Some ideas:
GPS time. Is it possible to acquire it?
Tracking system time changes made by user?
Any other idea?
Note: time does need second accuracy, approximately minute accuracy would be ok.
Note2: we are creating mobile apps for Android and iPhone, so I'm interested for generic solutions and also solutions that are specific to any of those two platforms.
I, personally, wouldn't worry so much about this scenario. The liklihood of someone intentionally changing the time on their Android (which periodically throughout the day syncs to a time server automatically) while offline seems low to me. That being said, the only way I could see compensating for this is to keep a service running in the background that keeps a running tally of the seconds passed since recording the location data offline. Once uploaded to your servers you could use the elapsed seconds to calculate a time offset from current UTC time. It's an awful lot to go through, but it would work.
GPS time is an interesting idea, but Android allows users of the SDK to send mock locations to their devices. I'm not sure you could reliably track changes to system time either, and even if you could you'd be capturing them after the fact without the current real time as context.
We use GPS times in our app for very similar reasons. Since our users are in different time zones and we want local times, we define from our server what time zone they are in at installation time (they don't move very far). Hadn't thought of the mock GPS locations, but you would need to be a fairly advanced user to do that.