I'm trying out iBeacons now.
I have 2 devices that I'm using as beacons and 1 device to do the ranging.
When I implemented this method call locationManager:didRangeBeacons:inRegion:, in the documentation it says that "didRangeBeacons" takes an array of beacons in the proximity.
However, what I'm noticing is that locationManager:didRangeBeacons:inRegion: is getting called twice by each individual beacons. Is it supposed to behave that way?
Thanks,
Tee
You are supposed to get one call per second to locationManager:didRangeBeacons:inRegion for each CLBeaconRegion that you are ranging, and this callback includes an array of the CLBeacon objects that are seen inside that region.
So if you have set up two CLBeaconRegion objects and are ranging on both of them, you should two callbacks per second, each with a single beacon in its array.
If you have set up a single CLBeaconRegion for ranging that matches both beacons, then you should only get one callback per second and it should contain two beacons in its array.
You're right that locationManager:didRangeBeacons:inRegion gets called multiple times - when the proximity of beacons changes. I thought I read that this was usually once per second (and my testing would seem to align with this) but I can't find a reference for it at the moment.
You can of course decide what action you want to take whenever the method gets called (or even to take no action at all). You could also call stopRangingBeaconsInRegion: if you only want to be notified once.
Related
I would like to create a kind of a "smart" MoveIteratorFactory for my VRP (time windowed) example based app. This move factory should return an Iterator that would generate each time a CompositeMove based on the current solution state.
Is it possible for the MoveIteratorFactory to create an Iterator that generates moves based on current solution state?
AFAIK MoveIteratorFactory's methods accept a ScoreDirector object, and it seems that the returned Iterator should generate moves using instances retrieved from the ScoreDirector's working solution. But are these instances being updated while the solver process is undergoing? Do they have all planning variables set according to the current working solution state, when hasNext and next methods are called? Or should an iterator have a field with a ScoreDirector instance, and generate moves using instances retrieved each time from the ScoreDirector?
Yes, just make sure sure that the cacheType isn't PHASE or higher (by default it's fine because by default it's JUST_IN_TIME). See docs chapter 7.
At the beginning of every step it will call createRandomMoveIterator(), which can take into account the state of the current workingSolution.
I would like to call the event/alert API but filter the results by Device Type or Device Group, or as a last resort with multiple sources. Is there a way to make a sigle call to the API to achieve this result? At the moment I use /inventory/managedObjects with a device type first to get a list of devices, and then loop through the results and make a call to events/alarms for every device but this doesn't seem like a good way to do it.
Currently there is no way to query event and alarm APIs for a collection of source IDs. You can only query by a single ID.
If you are completly unhappy with calling for every device in the group there are two workarouns that come to my mind:
You query all and filter on the client (the more groups you have the worse this method will be).
You can create an event processing rule that adds an additional fragment to every created alarm and event based on the device group (incoming alarm -> check source -> check parents of the source (there is a function findAllManagedObjectParent). E.g. you add:
"myDeviceGroupName": {}
to all alarms and events.
Afterwards you can query the APIs not by source but by fragmentType.
My app needs to know the rough location of a user, with a resolution of their state/province. This way we know what the default tax rate should be in a simple tax calculator. They can still pick it after that, but its always nice to try to get it right.
Is there an easy way to get this sort of resolution without all the rigamarole of callbacks and such? I don't need updates, a single rough location will do, and an old one is likely perfectly fine.
There are no short simple ways to get current location.
That means that you need init CLLocationManager object, call startUpdatingLocation method and retrieve result in delegate method.
It's impossible to get current location synchronously by using one line of code because retrieving location info could take much time (For example turning on GPS sensor and so on.). That's why you get info by asynchronous delegate methods.
is the only way,
but to get a single user position
within the method locationManager:didUpdateLocations: call stopUpdateLocation:
[locationManager stopUpdatingLocation]
I’m trying to patch an application that resizes windows using the accessibility API.
I need to maintain a dictionary with the previous sizes of windows. The key needs to identify the currently active window. At the moment, this active window is retrieved via NSAccessibilityFocusedWindowAttribute upon the press of a hotkey.
However, every time this method is called, the returned AXUIElementRef which identifies the window is different! This of course means that I cannot use it as a dictionary key – the dictionary won’t find the corresponding entry.
The following code reproduces the problem:
-(IBAction)testWindowIdentification:(id)sender{
AXUIElementRef focusedApp;
AXUIElementRef focusedWindow;
AXUIElementCopyAttributeValue(_systemWideElement,
(CFStringRef) kAXFocusedApplicationAttribute,
(CFTypeRef*) &focusedApp);
AXUIElementCopyAttributeValue((AXUIElementRef) focusedApp,
(CFStringRef) NSAccessibilityFocusedWindowAttribute,
(CFTypeRef*) &focusedWindow);
CFShow(focusedWindow);
}
_systemWideElement has been initialised in the init method using a call to AXUIElementCreateSystemWide().
The CFShow statement clearly shows different IDs every time the method is called (even though the same window is active), which is useless for me:
<AXUIElement 0x47e850> {pid=42463}
<AXUIElement 0x47e890> {pid=42463}
<AXUIElement 0x47e2c0> {pid=42463}
…
The documentation on AXUIElement shows no method that retrieves a unique attribute for the UI element, and neither does that of the NSAccessibility protocol.
The unique PID is not enough for me, since a process can have multiple windows.
How can I retrieve some unique identifier of the active window in Cocoa?
(By the way, the real code is checking the return codes in the above calls; there is no error, the calls succeed.)
Rob Keniger has the right strategy with his answer here. The only thing missing from this answer (and indeed, the reason for the bounty placement) is a workable implementation that takes the current active window and translates it into a unique key suitable for indexing in the context of the current working application.
Rob's solution sketches this out through use of the CGWindowID given in the context of Quartz Window Services. It is, of course, strongly implied that this window reference is only useful for your current application.
Getting this window reference is tricky, because no strong guarantees exist between the Accessibility API and Quartz Window Services. However, you can work around this in the following ways:
Use extern "C" AXError _AXUIElementGetWindow(AXUIElementRef, CGWindowID* out);, as documented here. This isn't guaranteed to work, but it works as a ground-floor test to get things started if it works in your version of OSX.
Get the CGWindowID directly, using, for example, HIWindowGetCGWindowID(). More details about selecting the active window and extracting the ID can be found in the reference manual for the Carbon Window Manager (warning: large PDF).
Catalog your CGWindowID set using something like CGWindowListCreateDescriptionFromArray, exactly as Rob suggested. The goal here is then to find some scheme for bridging the Accessibility API and Quartz, but this is conceivable by utilizing, for example, a callback bound to the context of your current active window. I honestly don't know an optimal example of this that's properly future-proofed, however.
Of the options, I recommend going with 2. for your current needs, if you're unable to create some other decorator for your windows to uniquely identify them. It's currently defined in the legacy code base, but it will do what you desire.
Best of luck with your application.
I think you might be able to use the Quartz Window Services functions, specifically CGWindowListCreateDescriptionFromArray to enumerate the currently active windows in a particular app.
This call is lower-level than AppKit and isn't going to tell you which is the active window, but it will give you window IDs that are unique for the current user session. It's not a great solution, but you could compare the window bounds information with what you receive from the accessibility APIs to associate windows with their real IDs.
I'm working on a web application that enables users to login, only at specific locations. I'm using CLLocationManager and I initialized and called startUpdatingLocation at AppDelegate -didFinishLaunchingWithOptions. My UIWebView is supposed to pull the location at initialization to determine whether user's within the specified locations. However, at the launch of my application, [locationManager location] is always null and updates after my UIWebView is initialized and displayed therefore already sending an error message to the user.
How do I make my locationManager update its location at initialization?
Sounds like you've coded the location stuff correctly. What you are missing (but have seen) is that the update most certainly does not happen instantaneously. You need to "gate" the rest of your UI's presentation (i.e. your webview) on the location information becoming available. There are a lot of ways to do this. A common tactic is to present a full-screen "HUD" or veil with some indicator to the user that the app is initializing or locating them (with an activity indicator, too, is always a nice touch.) Behind that (out of sight to the user) you can be waiting for the location result and then kickoff the appropriate UI update, and then drop the veil.
Any of that make sense or give you some ideas? I've done this plenty of times. Synchronizing async activities (like location updates) with real-time UI updates that make sense can be challenging, but isn't impossible. :-)
You will need to account for an initial nil value in your applications UI and wait for the first location update.
-location
Discussion
The value of this property is nil if no location data has
ever been retrieved.
It is a good idea to check the timestamp of the location that is
returned. If the receiver is currently gathering location data, but
the minimum distance filter is large, the returned location might be
relatively old. If it is, you can stop the receiver and start it again
to force an update
Also you should check out Region Monitoring since you would like for you users to only be able to login at specific locations.