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
Related
I am trying to set up an app that will be able to check people's locations in the background, see if they are at a given location, and send a ping to a server if they are. We do not want to drain the energy of our users, so we are attempting to figure out the best solution.
I've done substantial reading and I have not found very much information on these methods. I'll go through the pros and cons as I understand them right now
startMonitoringForSignificantChanges
Description: Based off of wi-fi and cell tower changes the system wakes up the app.
Docs:
Apps can expect a notification as soon as the device moves 500 meters
or more from its previous notification. It should not expect
notifications more frequently than once every five minutes. If the
device is able to retrieve data from the network, the location manager
is much more likely to deliver notifications in a timely manner.
Pros:
Most battery efficient
Cons:
Dependent on wi-fi/cell tower changes
Can only assume that this will be called every 200m to 2km (if not more in certain areas)
More on accuracy
Thus, inconsistent and imprecise
10-minute start-updating or "n-minute updating":
Description: This basically asks the app for more time, when that extra time is about to expire, it calls [self.locationManager startUpdating], grabs the location and extends the background thread for 10 more minutes.
Pros:
Consistent
Can be as accurate as you want it to be as consistently as you
want it
Cons:
Has to do a call every ten minutes or less to keep the app running in the
background (ie n can't be greater than 10 for the calls)
Questions:
What effect does this have on the battery? Does waking up the GPS and shutting it off hurt the battery more? I couldn't imagine running a brief location check in the background would drain the battery that much... but then again, I don't know what goes into powering up the GPS and getting a usable signal.
startMonitoringForRegion (geo-fencing):
Simply put, your app gets woken up when you enter into a pre-defined region. This is the oddball of them, it is more recent and there is less documentation on it. I can't find a good description on how the "system monitors" the boundary crossing. For all I know it is some really smart algorithm, or they are constantly pinging the GPS which would make it less effective than the other methods for doing this.
Pros:
Simple implementation
Managed by the system so you don't have to invent your own ad hoc geo-fences Only triggers on boundary crossing... no unnecessary data to just throw out in exchange for a battery hit
Thus, should be the best for this sort of thing, accurate, managed by the system
Cons:
People question its effectiveness
Huge conflicts on whether or not it is good for battery life or if it
drains battery life terribly.
How is the system monitoring this!?
Basically, indeterminate behavior.
I guess my question boils down to how does startMonitoringForRegion: compare to these other methods of testing user location in the background when it comes to battery life, consistency, and precision. Has anyone thoroughly tested this? Or used it in their app and gotten at least some feedback? Likely, for my purposes, the trade-off is between geo-fencing and the 10 minute update method. (Also given what Apple has publicly said about iOS7 there will be some background tasks... will this change the calculus for the trade-off between these two methods?) Does anyone have an idea of how these two compare?
Thanks so much! Looking forward to seeing if we can get to the bottom of how to compare these methods.
I've been working on vehicle tracking using GPS for 2 years. Learned a lot the hard way... In my experience startMonitoringForRegion or Geo-fencing depends upon cell change events, didEnter or didExit events doesn't fire up until there is a cell/wifi change event. So it doesn't make any difference w.r.t battery consumption. However it does extra computation which depends on how many regions currently are being monitored. Even Apple's Reminder app doesn't give good results for location based reminders because it uses geo-fencing.
The other approach starting GPS for n minutes after each m-minutes is good option, it should not affect the battery life, if done wisely. What exactly effect the battery is constant GPS activation in high precision mode. Like for instance If you enable GPS with kCLLocationAccuracyBest and distance-filter = 0, you can literally observe battery drainage and soon your device will also start getting hotter.
If I was you, I would go for activating GPS after every 10 minutes for 5 sec with kCLLocationAccuracyBest (or may kCLLocationAccuracyNearestTenMeters to use less battery, if accuracy is not that much important) and distance-filter = 5 (meters). Battery consumption in this case will be unnoticeable. You can play around with similar settings which can address your specific case and finally find out what is best you.
BTW: iPhone uses AGPS, A-GPS additionally uses network resources to locate and use the satellites in poor signal conditions. So, when you do startUpdatingLocation it will also use nearby cell tower information. see http://en.wikipedia.org/wiki/Assisted_GPS
I am planning to add a feature where users on Wi-Fi can downloading files sized between 150mb and 1gb so that they can use the app offline.
The download manger will take a time between 2 mins and A few hours to get the content depending on the size of file and the Wi-Fi connection speed.
Many users have an auto lock which will activate after a period of inactivity. When the device is locked the network connection is killed to preserve battery life (Im fairly sure this is correct as of iOS5?). This would be frustrating for users as it would frequently suspend their downloads unless they kept the device active.
To get round this I am considering 2 options:
Set idleTimerDisabled = YES while the app is downloading to prevent the screen locking. I don't think this is a good use of the properly since the documentation seems to suggest this should only be set for apps. Also it would unnecessarily keep the screen on, which is not good for battery.
Use the background task completion API. Its its a bit vague how long this will last for, it might not be long enough for the users, but it could be better than nothing.
Are either or both of theses options viable?
What I want to do:
I want to have my iPhone to frequently (formally defined later) upload my GPS location to a central server. I want to do this in the most battery efficient way.
Research I'm aware of:
Apple Documentation:
https://developer.apple.com/library/ios/#documentation/CoreLocation/Reference/CLLocation_Class/CLLocation/CLLocation.html#//apple_ref/doc/uid/TP40007126
Stack Overflow Links:
Response 1
Response: proof of existence; some other tool can do it
How to reduce iPhone battery consumption while using GPS
Response 2
Response: track only cell tower changes
iPhone GPS - Battery Draining Extremely Fast
iPhone running periodical process in the background - battery optimized way
Question
My question is a bit vague in that my definition of "frequently" is really dependent on what the battery life can tolerate. For example, if the battery can take updates of every 5 minutes, I'd like to do it every five minutes; if the battery could do this every 10 seconds, I'd like to do it every 10 seconds.
I really want to understand
the different ways (change on significant location, timer, background?) continuously uploading GPS locations can be implemented
advantages / disadvantages
approximately how long the battery life can last in each case
This seems like a fairly generic and common problem. Does anyone know of either:
an in depth analysis of the various methods
or if there is a single "optimal" way to do this?
[Moderators: feel free to mark this comment wiki. I'd love to just get lots of different answers + cost benefit analysis of them.]
Have a look at the Apple Documentation Here.
The significant-change location service offers a low-power location service for devices with cellular radios. This service is available only in iOS 4.0 and later and can also wake up an application that is suspended or not running.
It all depends on the use case. If the user will stay at a certain location and all you want to do is to track if he is leaving the country, tracking the significant location changing will be most suitable. However, this will not be precise enough for navigation apps.
One advantage of choosing the "Apple-Algorithm" is that they'll optimize it for you, if battery issues occur. (-:
I have Android application where service running 24/7 Phone get's GPS position every 5 minutes and sends to server. This is requirement.
Can I write same service for iPhone? I'm not sure if it's possible.
Can I write same service for WP7? I think it wasn't possible to run service before. Did anything change in 7.5?
EDIT:
I'm not sure why somebody downvoted. This is concrete Yes/No question.
It is possible in WP7 with the introduction of background tasks in Mango. In fact, there is a built in mechanism for polling the GPS provided by the API that is more battery efficient.
Not sure if it goes down to 5 minutes, think it is something larger like 30 minutes. It is also not comparable to a Windows Service - so don't go fowards with that mind set. Background tasks are heavily constrained to keep the phone responsive for the user - to make use of them, you need to play nice with the requirements.
Background tasks introduction, it also talks about the GPS thing I mentioned. The entire series is well worth your bandwidth and time downloading and watching:
http://channel9.msdn.com/Series/Mango-Jump-Start/Mango-Jump-Start-06-Windows-Phone-Multi-tasking--Background-Tasks
Can't answer for iPhone.
It is also possible on ios4+ but it wont be time-triggered. Either you register for precise (gps) or vague location (wifi and wan location) which is available to get in background but it is not always possible to send that data to a server because after 10 minutes in background your app is not allowed to keep a network-connection alive. So you have to buffer that data and have to wait until the user launches your app.
The ios pushes notifications to your app depending on the needed accuracy and depending on a distance-filter
ios-apps do not differ between services and activities (like in android). it is all combined in one app.
There are "some limitations"(a lot) here too, but maybe Microsoft Push services works for you:
Push Notifications Overview for Windows Phone
Because polling is not a good practice for this, push works better in this cases.
In WP7 Mango you can't get a fresh location from a background agent. The following code will return the latest available location (up to 15 minutes old):
private GeoPosition<GeoCoordinate> GetCachedLocation()
{
GeoCoordinateWatcher geoWatcher;
geoWatcher = new GeoCoordinateWatcher(); //Start a new watcher with default level of accuracy
geoWatcher.Start();
//Get latest cached position
GeoPosition<GeoCoordinate> position = geoWatcher.Position;
geoWatcher.Stop();
return position;
}
As you can see, this uses GeoCoordinateWatcher. According to MSDN (http://msdn.microsoft.com/en-us/library/hh202962(v=vs.92).aspx):
This API, used for obtaining the geographic coordinates of the device,
is supported for use in background agents, but it uses a cached
location value instead of real-time data. The cached location value is
updated by the device every 15 minutes.
Other than that, I haven't been able to find much information. You could create a GeoCoordinateWatcher with a self-defined accuracy, but I haven't tested this. Perhaps it would return the latest available cached location that satisfies the accuracy requirement.
I'm currently testing the latest iOS4 Feature to put my location aware app in the background. Well, it does work! But on the other hand it's quite hart to handle the immense power usage.
The app consumed about 50% battery power in the last four hours. It read the entire official documentation by Apple on this topic but I'm still not sure which parts of my application are still running and which functionality is suspended (beside the UI Drawing, which should be clear).
I don't use any real boilerplate code but extended libraries like ASIHTTPRequest to talk to my webservice. Tests with a friends car did you show that the Network Connectivity and and the Location Services is still running when I'm using i.e.
[locationManager startMonitoringSignificantLocationChanges];
Apples Documentation on the different application states
Background: The application is in the background and executing code
[...]
Should I write a "bare metal" functions to receive and send this location data? Should I remove all other objects for the time the application resides in the background to reduce the memory footprint? It seems there isn't any best practice yet.
Any ideas? Maybe you guys can provide me with some of your insights. Thanks.
Edit:
There's a new Instruments tool called Energy Diagnostics Instruments to record any power usage (for iPhone 3GS and later) with an attached device. Also there's another service on the device in the Settings App -> Developer -> Power Usage. It's great to test your power usage in field. The created logs can be pulled later in instruments.
Reference: WWDC 2010 Session 309 - Advanced Performance Analysis with Instruments
Sounds like your app is transmitting location data over the cellular network. Turning on the cellular radio is one of the most rapid causes of power drain, especially if the user has a weak signal connection to the cell tower.
You might want to save and package up a bunch of location data, and send the data in a quick burst as seldom as possible (twice per day, when the user stops moving for 30 minutes, only after the user gets to one of their favorite restaurants, etc.) Turning on the radio less than half as often could get you close to doubling the battery life (unless the user is doing something else with the device as well).