In my strategy, buy signal and Sell Exit signal overlaps during algotrading, what can be done to prevent this?
Related
I wish to build a timer with a start button that once pressed begins to monitor environmental decibel levels through HealthKit. And then once a decibel passes a threshold I wish to log event.
Is something like this available through health kit? Can I actively monitor decibel levels of my environment? Almost as how the native Noise app currently works on the Apple Watch. But I wish to gather this data when the user clicks a start button.
If so, how often can I sample this data? Can I get distinct decibel events that occur between each other within less than a second? A half second? A tenth of a second?
I'm making an Apple Watch app to record user acceleration. Currently, the user configures the session length to record for, and using a HKWorkoutSession, the app records acceleration for that time period.
My issue: I want the user to be able to remove their watch and charge it in the middle of a long session. In debugging the watch on Xcode, when I place the watch on the charger, I get the messages:
Message from debugger: Terminated due to signal 9
Program ended with exit code: 0
And the debugger is no longer connected. After a short while, the HKWorkoutSession ends as well, and the app is no longer recording.
Looking at https://medium.com/#gohnjanotis/apple-watch-battery-level-charging-notifications-eb7d0797a4d8, and the statement "While on the charger it seems these background refresh tasks are paused altogether.", I'm not sure I understand the Watch app life cycle fully. Is it even possible to have an app continue running in the background when the watch is set to charge?
Would appreciate any advice on this. Cheers.
It's unlikely that watchOS background tasks work similarly to iOS, where an iPhone can for example do expensive Photos operations when the device is charging. Why not pause and resume the workout session?
The "Recover from Crashes" at the bottom of Running Workout Sessions | Apple Developer Documentation might be helpful.
I am working on my home automation app. I am using estimotes iBeacons and what I want to do is give my Home Automation Control the ability to know my proximity in my home. Each iBeacon is given a virtual switch on my Home Controller and when I come in contact with a iBeacon my device either in foreground or background will update my control to turn on my switch for when I am near a beacon and turn it off when I have wondered away from my beacon. All of this works perfectly and I am loving it, however some of my conditions rely on me to be in a proximity for a period of time, and what I am noticing is after a couple of minutes or even after a half hour of being near a beacon, the iPhone 5s basically drops its connection and then fires it back up, causing it to perform an exit (turn off my virtual switch) and then immediately perform an enter (turn back on the virtual switch). As you can imagine this is very annoying to the wife and myself in the middle of the night when the bedroom lights start to flicker on and off because of the exit/enter. I have read about people having this problem and tried everything I have seen on the internet to no avail.
What I noticed is that whenever a monitor crossing has been crossed for a iBeacon, both the didDetermineState and the corresponding Enter/Exit call back functions are called. What can I do to get this to stop occurring? I can provide code examples if needed but this is more of a general question.
This is a common problem with iBeacons (and wives of geeks like us), and the simple solution is a software filter. You must ignore region exit events that last only a few seconds until you verify that there is no subsequent entry event.
You can do this by creating a variable (e.g justExitedRegion) that tracks these events. When you get an exit region notification, set justExitedRegion=YES and start a five second timer. When the timer goes off, if justExitedRegion==YES, perform your exit logic normally and set justExitedRegion=NO. Otherwise skip processing the exit logic.
Meanwhile, if you get an entry notification and justExitedRegion==YES, set justExitedRegion to NO and skip your entry processing.
If you just want to know whether you're at home or not at home, you could fire up the GPS on the phone and check your location.
Assuming you have a wifi network at home that your iPhone sees regularly, geolocation will work very well even inside the house where there will be no GPS signal. It will know no the latitude/longitude of the wifi base station and give that as your current location.
So use iBeacon as your primary location detection, but verify the data it gives you using GPS.
Also, you should contact Estimote to be sure you don't have a faulty unit or something. It is pretty new hardware, there could be issues.
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
Are we able to open any timely in-app (as consumable) for any time period like 1 day or even 1 hour? What is apple's reaction to such in-app?
If I am able to do it, and I don't want it to be a subscription type of in-app (not recurring) what is my in-app's type? Should it be consumable or subscription?
Any articles and tips on timely in-app purchases on iOS, consisting Apple's behaviour would be appriciated.
possible examples:
1 Hour Super Strength
1 Day Invisibility
That's a typical use of a consumable item. You might want to start the applicable time frame on first use instead of when bought.
Keep in mind that you will need to track the purchase and usage yourself, and it might involve your own server if it's tied to an application that the user can play on several devices or platforms.