I'm using RxBluetoothKit 3.0.6 and have this code in a view controller:
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
DDLogDebug("DEviceChooser viewDidLoad")
self.navigationItem.rightBarButtonItem = self.editButtonItem
//let timerQueue = DispatchQueue(label: "com.polidea.rxbluetoothkit.timer")
//scheduler = ConcurrentDispatchQueueScheduler(queue: timerQueue)
scheduler = MainScheduler.instance
if let favs = EmaxProfile.getFavourites() {
DDLogDebug("Got \(favs.count) favourites")
var uuids: [UUID] = []
for (s) in favs {
if let uuid = UUID(uuidString: s) {
uuids.append(uuid)
}
}
DDLogDebug("Got \(uuids.count) uuids")
if (!uuids.isEmpty) {
let cbcm = CBCentralManager()
let devs = cbcm.retrievePeripherals(withIdentifiers: uuids)
DDLogDebug("Direct call to CBCentralManager.retrievePeripherals returned \(devs.count) entries")
self.manager.retrievePeripherals(withIdentifiers: uuids)
.subscribeOn(MainScheduler.instance)
.subscribe(onNext: {
DDLogDebug("Got \($0.count) devices from RXBluetoothKit")
//var list = self.devices[self.favourites]
for (dev) in $0 {
DDLogDebug("Adding device \(dev.name)")
let btDev = BTDevice(dev)
btDev.suitable = true
self.devices[self.favourites].append(btDev)
}
if (self.devices[self.favourites].isEmpty) {
self.startScanning()
} else {
self.tableView.reloadData()
}
}, onCompleted: {
DDLogDebug("Retrieve complete")
}).addDisposableTo(disposeBag)
} else {
startScanning()
}
} else {
startScanning()
}
}
So in viewDidLoad() I'm retrieving a list of previously scanned devices, stored by their UUIDS, and trying to retrieve them without scanning. If I call the Core Bluetooth retrievePeripherals it works correctly every time. However using the Rx BluetoothManager call fails the second time - i.e. when I run the program, the first time this view is shown it works correctly. If I hit Back then immediately reopen the view, neither the onNext: closure nor the onComplete: closure executes. The log output is:
2017-01-12 19:55:13.824088 BlueMAX[559:216265] DEviceChooser viewDidLoad
2017-01-12 19:55:13.835820 BlueMAX[559:216297] Got 1 favourites
2017-01-12 19:55:13.836196 BlueMAX[559:216265] Got 1 uuids
2017-01-12 19:55:13.838832 BlueMAX[559:216265] Direct call to CBCentralManager.retrievePeripherals returned 1 entries
2017-01-12 19:55:13.846427 BlueMAX[559:216265] Got 1 devices from RXBluetoothKit
2017-01-12 19:55:13.846927 BlueMAX[559:216312] Adding device Optional("DEV")
2017-01-12 19:55:13.849145 BlueMAX[559:216265] Retrieve complete
2017-01-12 19:55:13.909986 BlueMAX[559:216312] [CoreBluetooth] XPC connection invalid
2017-01-12 19:55:21.515795 BlueMAX[559:216269] Saved 1 favourites, now exiting DeviceChooser
2017-01-12 19:55:22.054481 BlueMAX[559:216335] [CoreBluetooth] XPC connection invalid
2017-01-12 19:55:24.650717 BlueMAX[559:216269] DEviceChooser viewDidLoad
2017-01-12 19:55:24.651417 BlueMAX[559:216269] Got 1 favourites
2017-01-12 19:55:24.651646 BlueMAX[559:216312] Got 1 uuids
2017-01-12 19:55:24.654465 BlueMAX[559:216335] Direct call to CBCentralManager.retrievePeripherals returned 1 entries
2017-01-12 19:55:24.679889 BlueMAX[559:216269] [CoreBluetooth] XPC connection invalid
I'm not sure if the "XPC connection invalid" messages are connected with this or not.
Is this a bug, or am I doing something wrong?
Could you tell me whether self.manager is injected from the outside, or maybe recreated in the init of VC?
And exactly how it is created?
What is RxBluetoothKit doing under the hood is simply calling the same method as you in the example above and mapping it to the Observable sequence.
Could you jump to the source code and debugger and see whether this line:
return self.centralManager.retrievePeripherals(withIdentifiers: identifiers)
is called every time?
And maybe for convenience - please report this as an issue for Github, since it may require to take a while to reproduce the issue.
Thanks,
Related
I'm trying to figure out how to make a network extension so that my iOS app can programmatically open an custom VPN tunnel in C#, but looking at some similar Obj-C projects I'm not sure if it's possible in Xamarin (as I don't see a network extension project in Visual Studio) and how to port a what I gather is a required PacketTunnelProvider class which I think must be present and listed as an extension in the plist.info first...I'm in particular having most trouble in how to port the parts of that class which appear at the end as an extension and some event handlers named like this func Adapter(adapter: Adapter, configureTunnelWithNetworkSettings networkSettings: NEPacketTunnelNetworkSettings, completionHandler: #escaping (AdapterPacketFlow?) -> Void) and func Adapter(adapter: Adapter, handleEvent event: AdapterEvent, message: String?) as they both have a different signature than an event handler in C# which accepts sender and eventArgs (or something derived)…if anyone did this in C# I'd like to know at least if it's possible if not how to port such a class?
I've found this one project https://github.com/ss-abramchuk/OpenVPNAdapter (since it seems to do most of what I want) that I managed to translate into a Xamarin binding library but I'm unsure how and if to incorporate its PacketTunnelProvider class in Xamarin (as that is what the readme says you should use to incorporate something like that adapter)...I gather one should add to plist.info something like this first:
<key>NSExtension</key>
<dict>
<key>NSExtensionPointIdentifier</key>
<string>com.apple.networkextension.packet-tunnel</string>
<key>NSExtensionPrincipalClass</key>
<string>$(PRODUCT_MODULE_NAME).PacketTunnelProvider</string>
</dict>
but where do you go from there to use the binding library? This is the Obj-C code that says and seemingly does what I want to do to after i.e. add that custom VPN protocol tunnel to an app using the library:
import NetworkExtension
import OpenVPNAdapter
class PacketTunnelProvider : NEPacketTunnelProvider
{
lazy var vpnAdapter: OpenVPNAdapter = {
let adapter = OpenVPNAdapter()
adapter.delegate = self
return adapter
}
()
let vpnReachability = OpenVPNReachability()
var startHandler: ((Error?) -> Void)?
var stopHandler: (() -> Void)?
override func startTunnel(options: [String: NSObject]?, completionHandler: #escaping (Error?) -> Void)
{
// There are many ways to provide OpenVPN settings to the tunnel provider. For instance,
// you can use `options` argument of `startTunnel(options:completionHandler:)` method or get
// settings from `protocolConfiguration.providerConfiguration` property of `NEPacketTunnelProvider`
// class. Also you may provide just content of a ovpn file or use key:value pairs
// that may be provided exclusively or in addition to file content.
// In our case we need providerConfiguration dictionary to retrieve content
// of the OpenVPN configuration file. Other options related to the tunnel
// provider also can be stored there.
guard
let protocolConfiguration = protocolConfiguration as? NETunnelProviderProtocol,
let providerConfiguration = protocolConfiguration.providerConfiguration
else
{
fatalError()
}
guard let ovpnFileContent: Data = providerConfiguration["ovpn"] as? Data else
{
fatalError()
}
let configuration = OpenVPNConfiguration()
configuration.fileContent = ovpnFileContent
configuration.settings = [
// Additional parameters as key:value pairs may be provided here
]
// Apply OpenVPN configuration
let properties: OpenVPNProperties
do
{
properties = try vpnAdapter.apply(configuration: configuration)
}
catch
{
completionHandler(error)
return
}
// Provide credentials if needed
if !properties.autologin {
// If your VPN configuration requires user credentials you can provide them by
// `protocolConfiguration.username` and `protocolConfiguration.passwordReference`
// properties. It is recommended to use persistent keychain reference to a keychain
// item containing the password.
guard let username: String = protocolConfiguration.username else
{
fatalError()
}
// Retrieve a password from the keychain
guard let password: String = ... {
fatalError()
}
let credentials = OpenVPNCredentials()
credentials.username = username
credentials.password = password
do
{
try vpnAdapter.provide(credentials: credentials)
}
catch
{
completionHandler(error)
return
}
}
// Checking reachability. In some cases after switching from cellular to
// WiFi the adapter still uses cellular data. Changing reachability forces
// reconnection so the adapter will use actual connection.
vpnReachability.startTracking { [weak self] status in
guard status != .notReachable else { return }
self?.vpnAdapter.reconnect(interval: 5)
}
// Establish connection and wait for .connected event
startHandler = completionHandler
vpnAdapter.connect()
}
override func stopTunnel(with reason: NEProviderStopReason, completionHandler: #escaping () -> Void)
{
stopHandler = completionHandler
if vpnReachability.isTracking {
vpnReachability.stopTracking()
}
vpnAdapter.disconnect()
}
}
extension PacketTunnelProvider: OpenVPNAdapterDelegate {
// OpenVPNAdapter calls this delegate method to configure a VPN tunnel.
// `completionHandler` callback requires an object conforming to `OpenVPNAdapterPacketFlow`
// protocol if the tunnel is configured without errors. Otherwise send nil.
// `OpenVPNAdapterPacketFlow` method signatures are similar to `NEPacketTunnelFlow` so
// you can just extend that class to adopt `OpenVPNAdapterPacketFlow` protocol and
// send `self.packetFlow` to `completionHandler` callback.
func openVPNAdapter(_ openVPNAdapter: OpenVPNAdapter, configureTunnelWithNetworkSettings networkSettings: NEPacketTunnelNetworkSettings, completionHandler: #escaping (OpenVPNAdapterPacketFlow?) -> Void)
{
setTunnelNetworkSettings(settings) {
(error) in
completionHandler(error == nil ? self.packetFlow : nil)
}
}
// Process events returned by the OpenVPN library
func openVPNAdapter(_ openVPNAdapter: OpenVPNAdapter, handleEvent event: OpenVPNAdapterEvent, message: String?)
{
switch event {
case .connected:
if reasserting {
reasserting = false
}
guard let startHandler = startHandler else { return }
startHandler(nil)
self.startHandler = nil
case .disconnected:
guard let stopHandler = stopHandler else { return }
if vpnReachability.isTracking {
vpnReachability.stopTracking()
}
stopHandler()
self.stopHandler = nil
case .reconnecting:
reasserting = true
default:
break
}
}
// Handle errors thrown by the OpenVPN library
func openVPNAdapter(_ openVPNAdapter: OpenVPNAdapter, handleError error: Error)
{
// Handle only fatal errors
guard let fatal = (error as NSError).userInfo[OpenVPNAdapterErrorFatalKey] as? Bool, fatal == true else
{
return
}
if vpnReachability.isTracking {
vpnReachability.stopTracking()
}
if let startHandler = startHandler {
startHandler(error)
self.startHandler = nil
} else
{
cancelTunnelWithError(error)
}
}
// Use this method to process any log message returned by OpenVPN library.
func openVPNAdapter(_ openVPNAdapter: OpenVPNAdapter, handleLogMessage logMessage: String)
{
// Handle log messages
}
}
// Extend NEPacketTunnelFlow to adopt OpenVPNAdapterPacketFlow protocol so that
// `self.packetFlow` could be sent to `completionHandler` callback of OpenVPNAdapterDelegate
// method openVPNAdapter(openVPNAdapter:configureTunnelWithNetworkSettings:completionHandler).
extension NEPacketTunnelFlow: OpenVPNAdapterPacketFlow {}
How do I port to C# then or maybe I'm doing it all wrong (because of the comment bellow - the binding dll is bigger than 15MB - or is that limit in regard to use of memory which isn't related to file size)? Should I actually be just referencing the custom VPN library to open up a VPN tunnel from code directly and go on from there like it's business as usual (as I also found a project/app https://github.com/passepartoutvpn which uses a TunnelKit cocoapod, but that app's lib won't work with sharpie to make the binding library, and if so would the app like that even be admissible to the AppStore)? Thank you for any help in advance.
Per #SushiHangover advice, I've tried binding TunnelKit, as that project seemed smaller, and succeeded, partially... I've managed to build ~3MB dll, which seems much smaller than 21MB OpenVPNAdapter, and I think I'm almost there with the NetworkExtension project...I've got just to figure out the did I do ok with #escaping completionHandler and how to get some group constants which I guess should be set within the Host app somehow?
public override void StartTunnel(NSDictionary<NSString, NSObject> options, Action<NSError> completionHandler)
{
//appVersion = "\(GroupConstants.App.name) \(GroupConstants.App.versionString)";
//dnsTimeout = GroupConstants.VPN.dnsTimeout;
//logSeparator = GroupConstants.VPN.sessionMarker;
base.StartTunnel(options, completionHandler);
}
I've commented out the groupcontants for now but at least I'm hoping that's good enough porting of Swift3's:
override func startTunnel(options: [String : NSObject]?, completionHandler: #escaping (Error?) -> Void) {
appVersion = "\(GroupConstants.App.name) \(GroupConstants.App.versionString)"
dnsTimeout = GroupConstants.VPN.dnsTimeout
logSeparator = GroupConstants.VPN.sessionMarker
super.startTunnel(options: options, completionHandler: completionHandler)
}
If anyone else knows about the group constants and how to get them I'd be grateful (but I should also note that sharpie pod didn't give/expose any of those fields I should be assigning. Maybe I did it wrong as that's TunnelKit is a completely Swift3 project unlike the OpenVPNAdapter :/
Should I actually be just using the a custom VPN library to open up a VPN tunnel and go from there, but would the app then be admissible to the AppStore?
For iOS 12+, you absolutely have to use the Network Extension framework to be Store eligible.
The Xamarin.iOS build task (ValidateAppBundle) correctly identifies com.apple.networkextension.packet-tunnel as a valid extension (.appex) so yes you can build an NEPacketTunnelProvider extension.
You are correct the VS does not have build-in templating for Network Provider .appex's for tunnels, dns proxy, filter control|data, proxy types, but that does not mean you can not just use another one of the templates (or create the project from scratch) and modify it (I create an Xcode iOS project and start adding extension targets and just mirror those changes in VS).
(FYI: That is Swift code in your example, not ObjC...)
Now due to limitations in .appex size (and performance issues in some cases), a lot of extensions are very difficult to do via Xamarin.iOS. Most devs that encounter this, go native using ObjC/Swift for at least the appex development...
I am using PFQueryTableViewController as part of ParseUI to load a table of objects based on the currentUser's geolocation. I have seen several other (older) forum posts (like here) detailing that the queryForTable function should return nil if a value like currentLocation:PFGeoPoint? is nil. Then wait on the background process in viewDidLoad to get the PFGeoPoint and loadObjects(), thus calling the queryForTable function again.
I am seeing others say that Swift's ParseUI libraries may not have a queryForTable function that allows nil returns.
var currentLocation:PFGeoPoint? = nil
override func viewDidLoad() {
if currentLocation == nil {
PFGeoPoint.geoPointForCurrentLocationInBackground {
(geoPoint: PFGeoPoint?, error: NSError?) -> Void in
if error == nil {
print("Got the user's current location!")
self.currentLocation = geoPoint
print("Reloading table using user's location")
self.loadObjects()
}
}
}
}
override func queryForTable() -> PFQuery {
if self.currentLocation != nil {
print("Generating query based on user's location!")
let query = PFQuery(className:self.parseClassName!)
query.whereKey("taskLocation", nearGeoPoint: self.currentLocation!, withinMiles: 50)
if(self.objects?.count == 0)
{
query.cachePolicy = PFCachePolicy.CacheThenNetwork
}
return query
}
print("User's current location is not known")
return nil
}
Obviously, this fails to build because the function is not (note the question mark):
override func queryForTable() -> PFQuery? {
...
}
My attempted workaround was to return PFQuery() instead of nil, but I believe it returns after the viewDidLoad self.loadObjects(). The behavior I see is a momentary flash of a table with cell results, and then an empty table.
Here is a link to the Google Group discussion about this very issue, with Hector Ramos saying that it works with Objective-C but not Swift (...yet?). I'm running the latest ParseUI as of this posting (1.1.6).
Is there an option yet to do this in Swift? If not, when?
If this isn't an option, what are some workarounds people have tried successfully?
I actually figured this issue out - nothing to do with the code itself. Apparently, when you set a fake location on the iOS Simulator, it also enforces that different location when you use a real iOS device plugged in. My results were not showing up because there legitimately wasn't an object with a PFGeoPoint near my location (because it thought I was in London!)
Anyway, moral of the story is to make sure you always know your preset location in both Simulator and physical iOS devices.
PS - The code above does work when my location is set correctly.
I'm not clear on how to use this properly but had seen other people doing this type of thing:
func application(application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: () -> Void) {
manager.sharedInstance.backgroundCompletionHandler = completionHandler
}
In our similar implementation, at this point completionHandler is partial apply forwarder for reabstraction thunk helper...
Where manager is (despite being a singleton) essentially:
let configuration = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.ourcompany.app")
let manager = Alamofire.Manager(configuration: configuration)
However this causes the following warning to be printed in the console:
Warning: Application delegate received call to -application:handleEventsForBackgroundURLSession:completionHandler: but the completion handler was never called.
I set a breakpoint here and at this point the message is already visible in the console and backgroundCompletionHandler is nil.
We're building against the iOS 9 SDK with Xcode 7.0 and currently using Alamofire 2.0.2
I originally thought this was introduced when we merged our Swift 2.0 branch but I'm also seeing the message with an earlier commit using Xcode 6.4 against the iOS 8 SDK.
Update 1
To address #cnoon's suggestions:
The identifier matches - the configuration and manager are set inside a singleton so there's no way for it to be wrong.
When adding and printing inside of didSet on backgroundCompletionHandler in the Manager class, the message is logged before the warning.
When printing inside of the closure set to sessionDidFinishEventsForBackgroundURLSession on the delegate inside the Manager class, the message is printed after the warning.
When overriding sessionDidFinishEventsForBackgroundURLSession and printing inside of it before calling backgroundCompletionHandler, the message is printed after the warning.
As for verifying I have my Xcode project set up correctly for background sessions, I'm not sure how to do that and couldn't find any documentation on how to do so.
I should note that when trying to upload some screenshots from my phone I was initially unable to reproduce this issue in order to try these suggestions.
It was only after trying to share some photos that I was able to reproduce this again. I'm not sure or the correlation (if any) but it may be related to the photos taking longer to upload.
Update 2
The UIBackgroundModes are set exactly as #Nick described, and calling completionHandler() directly inside of application:handleEventsForBackgroundURLSession:completionHandler: does not display the warning.
Update 3
So, it appears I overlooked an small but important detail. There's a wrapper around Alamofire.Manager that doesn't expose it directly. The relevant part of its implementation looks like this:
private var manager: Manager
public var backgroundCompletionHandler: (() -> Void)? {
get {
return manager.backgroundCompletionHandler
}
set {
manager.backgroundCompletionHandler = backgroundCompletionHandler
}
}
and setting the completion handler in the AppDelegate executes that code path.
func application(application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: () -> Void) {
myManager.sharedInstance.backgroundCompletionHandler = completionHandler
}
I've confirmed that the following change to expose the instance of Alamofire.Manager and access it directly does not produce the warning:
public var manager: Manager
// public var backgroundCompletionHandler: (() -> Void)? {
// get {
// return manager.backgroundCompletionHandler
// }
// set {
// manager.backgroundCompletionHandler = backgroundCompletionHandler
// }
// }
and in the AppDelegate:
func application(application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: () -> Void) {
myManager.sharedInstance.manager.backgroundCompletionHandler = completionHandler
}
Based on this it appears that using a computed property to proxy the completion handler is the cause of the issue.
I'd really prefer not to expose this property and would love to know of any workarounds or alternatives.
It appears as though everything you are doing is correct. I have an example app that does exactly what you've described that works correctly and does not throw the warning you are seeing. I'm guessing you still have some small error somewhere. Here are a few ideas to try out:
Verify the identifier matches the identifier of your background session
Add a didSet log statement on the backgroundSessionHandler in the Manager class temporarily to verify it is getting set
Add a log statement into the sessionDidFinishEventsForBackgroundURLSession to verify it is getting called as expected
Override the sessionDidFinishEventsForBackgroundURLSession on the delegate and manually call the backgroundSessionHandler
Verify you have your Xcode project set up correctly for background sessions
Update 2
Your computed property is wrong. Instead it needs to set the backgroundCompletionHandler to newValue. Otherwise you are never setting it to the new value correctly. See this thread for more info.
I was working through Core Data Stack in Swift - Demystified but when I got to the line
self.context = NSManagedObjectContext()
I got the warning
`init()` was deprecated in iOS 9.0: Use -initWithConcurrencyType: instead
I see that I can do one of the following for self.context =
NSManagedObjectContext(concurrencyType: NSManagedObjectContextConcurrencyType.ConfinementConcurrencyType)
NSManagedObjectContext(concurrencyType: NSManagedObjectContextConcurrencyType.MainQueueConcurrencyType)
NSManagedObjectContext(concurrencyType: NSManagedObjectContextConcurrencyType.PrivateQueueConcurrencyType)
but since ConfinementConcurrencyType is also deprecated now that leaves me MainQueueConcurrencyType and PrivateQueueConcurrencyType. What is the difference between these two and how should I choose which one to use? I read this documentation, but I didn't really understand.
You essentially will always have at least 1 context with NSMainQueueConcurrencyType and many contexts with NSPrivateQueueConcurrencyType. NSPrivateQueueConcurrencyType is used typically for saving or fetching things to core data in the background (like if attempting to sync records with a Web Service).
The NSMainQueueConcurrencyType creates a context associated with the main queue which is perfect for use with NSFetchedResultsController.
The default core data stack uses a single context with NSMainQueueConcurrencyType, but you can create a much better app by leveraging multiple NSPrivateQueueConcurrencyType to do any work that does not affect the UI.
Replace these two function with the following one:
lazy var managedObjectContext: NSManagedObjectContext = {
// Returns the managed object context for the application (which is already bound to the persistent store coordinator for the application.) This property is optional since there are legitimate error conditions that could cause the creation of the context to fail.
let coordinator = self.persistentStoreCoordinator
var managedObjectContext = NSManagedObjectContext(concurrencyType: .MainQueueConcurrencyType)
managedObjectContext.persistentStoreCoordinator = coordinator
return managedObjectContext
}()
// MARK: - Core Data Saving support
func saveContext () {
if managedObjectContext.hasChanges {
do {
try managedObjectContext.save()
} catch {
// Replace this implementation with code to handle the error appropriately.
// abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.
let nserror = error as NSError
NSLog("Unresolved error \(nserror), \(nserror.userInfo)")
abort()
}
}
}
I am using ReactiveCocoa in an app which makes calls to remote web APIs. But before any thing can be retrieved from a given API host, the app must provide the user's credentials and retrieve an API token, which is then used to sign subsequent requests.
I want to abstract away this authentication process so that it happens automatically whenever I make an API call. Assume I have an API client class that contains the user's credentials.
// getThing returns RACSignal yielding the data returned by GET /thing.
// if the apiClient instance doesn't already have a token, it must
// retrieve one before calling GET /thing
RAC(self.thing) = [apiClient getThing];
How can I use ReactiveCocoa to transparently cause the first (and only the first) request to an API to retrieve and, as a side effect, safely store an API token before any subsequent requests are made?
It is also a requirement that I can use combineLatest: (or similar) to kick off multiple simultaneous requests and that they will all implicitly wait for the token to be retrieved.
RAC(self.tupleOfThisAndThat) = [RACSignal combineLatest:#[ [apiClient getThis], [apiClient getThat]]];
Further, if the retrieve-token request is already in flight when an API call is made, that API call must wait until the retrieve-token request has completed.
My partial solution follows:
The basic pattern is going to be to use flattenMap: to map a signal which yields the token to a signal that, given the token, performs the desired request and yields the result of the API call.
Assuming some convenient extensions to NSURLRequest:
- (RACSignal *)requestSignalWithURLRequest:(NSURLRequest *)urlRequest {
if ([urlRequest isSignedWithAToken])
return [self performURLRequest:urlRequest];
return [[self getToken] flattenMap:^ RACSignal * (id token) {
NSURLRequest *signedRequest = [urlRequest signedRequestWithToken:token];
assert([urlRequest isSignedWithAToken]);
return [self requestSignalWithURLRequest:signedRequest];
}
}
Now consider the subscription implementation of -getToken.
In the trivial case, when the token has already been retrieved, the subscription yields the token immediately.
If the token has not been retrieved, the subscription defers to an authentication API call which returns the token.
If the authentication API call is in flight, it should be safe to add another observer without causing the authentication API call to be repeated over the wire.
However I'm not sure how to do this. Also, how and where to safely store the token? Some kind of persistent/repeatable signal?
So, there are two major things going on here:
You want to share some side effects (in this case, fetching a token) without re-triggering them every time there's a new subscriber.
You want anyone subscribing to -getToken to get the same values no matter what.
In order to share side effects (#1 above), we'll use RACMulticastConnection. Like the documentation says:
A multicast connection encapsulates the idea of sharing one subscription to a signal to many subscribers. This is most often needed if the subscription to the underlying signal involves side-effects or shouldn't be called more than once.
Let's add one of those as a private property on the API client class:
#interface APIClient ()
#property (nonatomic, strong, readonly) RACMulticastConnection *tokenConnection;
#end
Now, this will solve the case of N current subscribers that all need the same future result (API calls waiting on the request token being in-flight), but we still need something else to ensure that future subscribers get the same result (the already-fetched token), no matter when they subscribe.
This is what RACReplaySubject is for:
A replay subject saves the values it is sent (up to its defined capacity) and resends those to new subscribers. It will also replay an error or completion.
To tie these two concepts together, we can use RACSignal's -multicast: method, which turns a normal signal into a connection by using a specific kind of subject.
We can hook up most of the behaviors at initialization time:
- (id)init {
self = [super init];
if (self == nil) return nil;
// Defer the invocation of -reallyGetToken until it's actually needed.
// The -defer: is only necessary if -reallyGetToken might kick off
// a request immediately.
RACSignal *deferredToken = [RACSignal defer:^{
return [self reallyGetToken];
}];
// Create a connection which only kicks off -reallyGetToken when
// -connect is invoked, shares the result with all subscribers, and
// pushes all results to a replay subject (so new subscribers get the
// retrieved value too).
_tokenConnection = [deferredToken multicast:[RACReplaySubject subject]];
return self;
}
Then, we implement -getToken to trigger the fetch lazily:
- (RACSignal *)getToken {
// Performs the actual fetch if it hasn't started yet.
[self.tokenConnection connect];
return self.tokenConnection.signal;
}
Afterwards, anything that subscribes to the result of -getToken (like -requestSignalWithURLRequest:) will get the token if it hasn't been fetched yet, start fetching it if necessary, or wait for an in-flight request if there is one.
How about
...
#property (nonatomic, strong) RACSignal *getToken;
...
- (id)init {
self = [super init];
if (self == nil) return nil;
self.getToken = [[RACSignal defer:^{
return [self reallyGetToken];
}] replayLazily];
return self;
}
To be sure, this solution is functional identical to Justin's answer above. Basically we take advantage of the fact that convenience method already exists in RACSignal's public API :)
Thinking about token will expire later and we have to refresh it.
I store token in a MutableProperty, and used a lock to prevent multiple expired request to refresh the token, once the token is gained or refreshed, just request again with new token.
For the first few requests, since there's no token, request signal will flatMap to error, and thus trigger refreshAT, meanwhile we do not have refreshToken, thus trigger refreshRT, and set both at and rt in the final step.
here's full code
static var headers = MutableProperty(["TICKET":""])
static let atLock = NSLock()
static let manager = Manager(
configuration: NSURLSessionConfiguration.defaultSessionConfiguration()
)
internal static func GET(path:String!, params:[String: String]) -> SignalProducer<[String: AnyObject], NSError> {
let reqSignal = SignalProducer<[String: AnyObject], NSError> {
sink, dispose in
manager.request(Router.GET(path: path, params: params))
.validate()
.responseJSON({ (response) -> Void in
if let error = response.result.error {
sink.sendFailed(error)
} else {
sink.sendNext(response.result.value!)
sink.sendCompleted()
}
})
}
return reqSignal.flatMapError { (error) -> SignalProducer<[String: AnyObject], NSError> in
return HHHttp.refreshAT()
}.flatMapError({ (error) -> SignalProducer<[String : AnyObject], NSError> in
return HHHttp.refreshRT()
}).then(reqSignal)
}
private static func refreshAT() -> SignalProducer<[String: AnyObject], NSError> {
return SignalProducer<[String: AnyObject], NSError> {
sink, dispose in
if atLock.tryLock() {
Alamofire.Manager.sharedInstance.request(.POST, "http://example.com/auth/refresh")
.validate()
.responseJSON({ (response) -> Void in
if let error = response.result.error {
sink.sendFailed(error)
} else {
let v = response.result.value!["data"]
headers.value.updateValue(v!["at"] as! String, forKey: "TICKET")
sink.sendCompleted()
}
atLock.unlock()
})
} else {
headers.signal.observe(Observer(next: { value in
print("get headers from local: \(value)")
sink.sendCompleted()
}))
}
}
}
private static func refreshRT() -> SignalProducer<[String: AnyObject], NSError> {
return SignalProducer<[String: AnyObject], NSError> {
sink, dispose in
Alamofire.Manager.sharedInstance.request(.POST, "http://example.com/auth/refresh")
.responseJSON({ (response) -> Void in
let v = response.result.value!["data"]
headers.value.updateValue(v!["at"] as! String, forKey: "TICKET")
sink.sendCompleted()
})
}
}