Can anyone explain the difference between the "Time in App" vs "Session Length" metric?
The Time in App metric started showing up as a metric in May 2017 and is significantly higher than the Session Length metric, so they are clearly different, but it's not clear as to how.
Mike from Fabric here. "Session length" is the median length across all daily active users. A session is considered complete when the app has been sent to the background for more than 30 seconds. Time in App" is a measure of how long the typical daily active user is active in the app on a specific day.
A user could, and often do, have multiple sessions in a day which would then be included in the time in app. For example, if I look at a calendar app for 30 seconds each time, I use, but I use it 6 times a day, then my time in app would be 3 minutes, but my session length would be 30 seconds.
Reference: https://docs.fabric.io/apple/answers/answers-metrics.html
Related
Hi there I am trying to conduct stress and scalability testing for a web application. One of the problem is that it is not clear how many users the website can handle. So first I am conducting a stress testing with different user number. Consider below picture:
In the picture first I am starting with 100 user by gradually increasing the load. So i have requirement for example:
Response time should not be 7 sec
throughput should not fall under 35 request per second
Percentage of error should not be more than 10 percent of the total request
So if this 100 user satisfies the requirement I will continue the test with 150 user and will go on until it breaks at least 2 requirement out of 3. And with that user I will perform the scalability test. Is this approach right? Please give me advise and how should I simulate user if not right?
The approach is more or less right. However you could save your time and efforts for finding the breaking point of the system with a single test only, just start with 1 user and gradually increase the load until the maximum.
JMeter's theoretical limit for a single Thread Group is 2,147,483,647, your actual limit will be less as most probably your hardware resources are limited, check out What’s the Max Number of Users You Can Test on JMeter? article for more details.
Whatever, if you put a reasonably high number of threads in the Thread Group and configure the load to increase gradually you can run your test and pay attention to the following charts:
Active Threads Over Time - shows the number of active users
Response Times Over Time - shows the system response time
Transactions Per Second - shows the throughput (the number of requests per second)
At first stage of the test response time will be the same and the throughput will be growing as you increase the load. At the certain point of test the response time will start increasing and throughput will be going down - that would be the limit of your system (so called "bottleneck")
I want my TG bot to have continuous access to a user’s live location. Is this possible?
I understand that TG can be given continuous access - but it seems to me that this privilege is not relayed to bots running on TG. Is this correct?
For the record, I don’t have a problem with an additional pop up requesting for such a permission.
As you can see here :
sendLocation:
Use this method to send point on the map. On success, the sent Message is returned.
So the user can share it's location via bot.
But you are looking for "Live Location" right? so you can do it :-)
Period in seconds for which the location will be updated (see Live Locations, should be between 60 and 86400.
86,400 Seconds / 60 Seconds = 1,440 Minutes.
1,440 Minutes / 560 Seconds = 24 Hours
So you can have live location of your user but there is only "24Hrs" limit.
Thanks in advance
With Microsoft Band and Windows Phone app I want to get from the MSBand the steps taken in the current day. Today, when I subscribe to the pedometer, the totalsteps attribute returns the steps taken overall. For example, my MSBand is returning 1M 444K steps. Does anyone knows how to get only the total daily steps?
The Band SDK does not expose the number of steps (by its internal count) taken by the wearer in the current day. The closest approximation to your goal would be to register a time-triggered background task that retrieves a pedometer sensor reading every n-number of minutes/hours and then calculates the number of steps taken on the current day based on a delta between successive readings. Obviously this implies a certain margin of error, based on how often (and when) that background task executes.
(On Windows Phone (8.1), for example, a background task can execute at most every ~30 minutes and isn't necessarily aligned to any given minute of the hour, which means steps could be attributed to one day or the next based on which side of the "midnight" hour the task happens to run.)
If you are accessing microsoft health cloud API. You can get the step counts(Per day) from the Summary URL Cloud API. refer my post https://stackoverflow.com/questions/32221481/android-get-active-minutes-for-the-step-counts-in-microsoft-band Else if you want it from the band SDK alone, Its good to go with Phil's above suggestion. Hope this may help who use health cloud API.
I've searched Google and the Twitter documentation for a very straightforward answer for how the following scenario would play out. Specifically, I'm wanting to understand how Twitter's rate limiting works on a "per user" and "per app" basis. Can someone take a look at the example below and explain to me what would happen. And please don't just refer me to a Twitter documentation URL! Thanks in advance.
Example:
The "GET friends/list" API call is currently limited to 15/user and 30/app within the 15 minute window (See https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-friends-list).
If I have 4 users who all make the "GET friends/list" API call 10 times each within a 15 minute window (i.e. 40 calls made) does that mean I violate the 30/app limit? I'd still be within my limits for each of my 4 users, but do their individual calls eat away at the app limit too? Or is the app limit entirely separate and related solely to my app's token/secret?
The number of users (aka user tokens for your app that you've saved in your app store/config) give you that many times the specified per user limit (different for different APIs) for your app.
In your example, you're well within your limit if you make 10 calls per 15 minutes per user to the 'GET friends/list' API call since you have 60 (4 X 15) calls you can make per 15 minutes.
App limit applies if you don't have user tokens via user authZ/consent and are calling in application context only.
You should try your scenario with a 15 minute sleep after iterating over the 4 users and making 10 (upto 15) calls each in the user context (on the user's behalf) and you'll see that all works fine.
I have an IOS app that needs to track duration of free usage per day. Once it crosses a threshold, the user would have to purchase the app or wait for the next day to unlock his free-usage minutes for that day.
Is there a native way to detect if the user has set his clock back? Assume there is no Internet connection to sync with a time server
UIApplicationDelegate can get the following method called on significant time changes:
- (void)applicationSignificantTimeChange:(UIApplication *)application
You can try that one. From my point of view, I'd recommend to check current date on every application launch or willBecomeActive and store those dates as list somewhere securely. If current date is different from the last date, add it to your list. If list has more than 30 items (or how many you need) disable trial functionality.