Multipeer Connectivity Doesn't Connect Second Time - objective-c

I'm using the Multipeer Connectivity Framework to transfer files between devices. I'm using the standard MCAdvertiserAssistant and MCBrowserViewController to connect the devices. On the first try from device A to device B things work fine. Same things on the first transfer from device B to device A.
If you try either direction again, after MCBrowserViewController presents its dialog to choose a peer and you select one, the popup to accept the request on the other device never appears. No error messages, no calls to delegate methods - just nothing. Has anyone come across this and any ideas?

I had the same problem and solved it with initiating all the necessary components every time I start advertising or browsing for peers. It isn't the cleanest solution but in my case it works 100%.
The code below is how I implemented it, so this is without the build-in ViewController provided by Apple.
Please be aware that [session disconnect] is an async method which sometimes take a few seconds to complete.
- (void)startBrowsing
{
// Initiate new advertiser
isAdvertising = YES;
_peerID = [[MCPeerID alloc] initWithDisplayName:#"Wallet"];
_session = [[MCSession alloc] initWithPeer:_peerID];
_session.delegate = self;
_advertiser = [[MCNearbyServiceAdvertiser alloc] initWithPeer:_peerID discoveryInfo:nil serviceType:#"made2pay"];
_advertiser.delegate = self;
// Start advertiser
[_advertiser startAdvertisingPeer];
}
- (void)stopBrowsing
{
[_advertiser stopAdvertisingPeer];
[_session disconnect];
_session = nil;
_peerID = nil;
_advertiser = nil;
isAdvertising = NO;
}

Related

Native cellular call fails on VoIP incoming call in iOS 13

I have implemented CallKit for audio and video call with VoIP PushKit in iOS and it is working fine in iOS 12 and prior versions, and also it is working fine normally in iOS 13 and 13.1.
But it is failing in 2 scenarios:
1) Our App is in foreground state. When cellular call is running and VoIP push is received, then Call kit incoming call screen is showing for 5 - 10 seconds, and then both Cellular and VOIP calls are failing with Alert "Call Failed".
2) Our App is in Background or Killed state. When cellular call is running and VoIP push is received, then both Cellular and VOIP calls are failing with Alert "Call Failed". No incoming call UI is showing this time.
I am showing my code here:
- (void)registerAppForVOIPPush {
PKPushRegistry *pushRegistry = [[PKPushRegistry alloc] initWithQueue:dispatch_get_main_queue()];
pushRegistry.delegate = self;
pushRegistry.desiredPushTypes = [NSSet setWithObject:PKPushTypeVoIP];
}
Then Push delegates
#pragma mark PKPushRegistryDelegate ----
- (void)pushRegistry:(PKPushRegistry *)registry didUpdatePushCredentials: (PKPushCredentials *)credentials forType:(NSString *)type {
NSString *newToken = [self hexadecimalStringFromData:credentials.token];
//Make a note of this token to a server to send VOIP for a particular device
NSLog(#"VOIP token ::: %#", newToken);
_voipToken = newToken;
}
- (void)pushRegistry:(PKPushRegistry *)registry didReceiveIncomingPushWithPayload:(PKPushPayload *)payload forType:(PKPushType)type {
//available(iOS, introduced: 8.0, deprecated: 11.0)
[self pushRegistryDidReceivedPushWithPayload:payload forType:type withCompletionHandler:NULL];
}
- (void)pushRegistry:(PKPushRegistry *)registry didReceiveIncomingPushWithPayload:(PKPushPayload *)payload forType:(PKPushType)type withCompletionHandler:(void (^)(void))completion {
//available(iOS 11.0, *)
[self pushRegistryDidReceivedPushWithPayload:payload forType:type withCompletionHandler:completion];
}
- (void)pushRegistryDidReceivedPushWithPayload:(PKPushPayload *)payload forType:(PKPushType)type withCompletionHandler:(void (^)(void))completion {
//Call kit configration
CXProviderConfiguration *providerConfig = [[CXProviderConfiguration alloc] initWithLocalizedName:#"my app Call"];
providerConfig.supportsVideo = NO;
providerConfig.maximumCallGroups = 1;
providerConfig.maximumCallsPerCallGroup = 1;
providerConfig.supportedHandleTypes = [[NSSet alloc] initWithObjects:[NSNumber numberWithInteger:CXHandleTypeGeneric], nil];
providerConfig.iconTemplateImageData = UIImagePNGRepresentation([UIImage imageNamed:#"IconMask"]);
CXProvider *provider = [[CXProvider alloc] initWithConfiguration:providerConfig];
[provider setDelegate:self queue:nil];
//generate token
NSUUID *callbackUUIDToken = [NSUUID UUID];
//Display callkit
NSString *uniqueIdentifier = #"Max test";
CXCallUpdate *update = [[CXCallUpdate alloc] init];
update.remoteHandle = [[CXHandle alloc] initWithType:CXHandleTypeGeneric value:uniqueIdentifier];
update.supportsGrouping = FALSE;
update.supportsUngrouping = FALSE;
update.supportsHolding = FALSE;
update.localizedCallerName = uniqueIdentifier;
update.hasVideo = NO;
[provider reportNewIncomingCallWithUUID:callbackUUIDToken update:update completion:^(NSError * _Nullable error) {
NSLog(#"reportNewIncomingCallWithUUID error: %#",error);
}];
if (completion) {
dispatch_async(dispatch_get_main_queue(), ^{
completion();
});
}
}
I have implemented CXProvider delegate method perfectly
- (void)provider:(CXProvider *)provider performAnswerCallAction:(CXAnswerCallAction *)action{
[action fulfill];
}
- (void)provider:(CXProvider *)provider performEndCallAction:(CXEndCallAction *)action{
[action fulfill];
}
and also managed other delegate methods to manage call and everything, and it is working perfectly in all conditions.
I have checked these two scenarios with other apps like Google Duo, Whatsapp and FaceTime and it's showing CallKit properly without failing, but in my app it is failing. I have no clue where it is failing.
So, I have this 2 stated issues for iOS 13 and later versions. Any help will be appreciated.
Thanks.
This is probably an iOS 13 bug and, if you haven't already done it, you should report it to Apple.
I think that the reason why apps like Whatapp (and the one I develop) are working, is that we build the app against the iOS 12 SDK. We do this because of the limitations of VoIP push notifications introduced in iOS 13. So, you can try to work around the issue—at least until April 2020—building against the iOS 12 SDK. Hopefully, Apple we'll soon fix this issue.
#Max I have faced the same issue that you faced in iOS version 13.0 to 13.2.0.
As many developers have reported this issue to Apple. The latest iOS version that released last week(iOS 13.2.2) has this bug resolved. So, now instead of building from older SDK, you can start working with latest SDK and xCode 11.2.1.

Multipeer Connectivity Disconnect

I'm having trouble with staying connected using the Multipeer Connectivity Framework in iOs7. Currently my app is programmatically handling the browsing and advertising using MCNearbyServiceAdvertiser and MCNearbyServiceBrowser. I have an alert view that asks the user if he is a browser or an advertiser. On the return from that view I instantiate either an MCNearbyServiceAdvertiser or Browser accordingly.
#pragma - Alert Delegate
-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex
{
if (buttonIndex == 0)
{
_browser = [[MCNearbyServiceBrowser alloc]initWithPeer:_peerID serviceType:#"Context-xl"];
[_browser setDelegate:self];
[self.detailViewController setRemote:YES];
[_browser startBrowsingForPeers];
} else
{
_advertiser = [[MCNearbyServiceAdvertiser alloc]initWithPeer:_peerID discoveryInfo:nil serviceType:#"Context-xl"];
[_advertiser setDelegate:self];
[self.detailViewController setRemote:NO];
[_advertiser startAdvertisingPeer];
}
[self.detailViewController configureView];
}
My session delegate method peer:...DidChangeState... is getting called twice, once for the connect and again for the disconnect. I'm not stopping the advertiser or browser at all after the session is started. Should I stop browsing/advertising?
EDIT Used a support ticket with Apple and they confirmed that calling sendData with too much data or too often can cause disconnects.
EDIT My hypothesis is that Apple has a thread or queue that is polling to check if peers are connected. If this thread / queue stalls (i.e. a breakpoint is hit or the app pegs the CPU or does something that takes a while on the main thread) it appears that this causes a disconnect.
Creating my session without encryption seems to have helped performance and with the disconnects, although they still happen.
MCPeerID* peerId = [[MCPeerID alloc] initWithDisplayName:self.displayName];
self.peer = [[MultiPeerPeer alloc] initWithDisplayName:peerId.displayName andPeer:peerId];
self.session = [[MCSession alloc] initWithPeer:peerId securityIdentity:nil encryptionPreference:MCEncryptionNone];
In addition, I have found calling sendData too often (more than 30-60 times a second) can cause the framework to get in a bad state and cause freezes and disconnects.

Why does my MCSession peer disconnect randomly?

Im using MCNearbyServiceBrowser and MCNearbyServiceAdvertiser to join two peers to a MCSession. I am able to send data between them using MCSession's sendData method. All seems to be working as expected until I randomly (and not due to any event I control) receive a MCSessionStateNotConnected via the session's MCSessionDelegate didChangeState handler. Additionally, the MCSession's connectedPeers array no longer has my peers.
Two questions: Why? and How do i keep the MCSession from disconnecting?
This is a bug, which I just reported to Apple. The docs claim the didReceiveCertificate callback is optional, but it's not. Add this method to your MCSessionDelegate:
- (void) session:(MCSession *)session didReceiveCertificate:(NSArray *)certificate fromPeer:(MCPeerID *)peerID certificateHandler:(void (^)(BOOL accept))certificateHandler
{
certificateHandler(YES);
}
The random disconnects should cease.
UPDATE After using a support ticket to Apple, they confirmed that calling sendData too often and with too much data can cause disconnects.
I have had disconnects when hitting break points and when backgrounding. Since the break points won't happen on the app store, you need to handle the backgrounding case by beginning a background task when your app is about to enter the background. Then end this task when your app comes back to the foreground. On iOS 7 this gives you about 3 background minutes which is better than nothing.
An additional strategy would be to schedule a local notification for maybe 15 seconds before your background time expires by using [[UIApplication sharedApplication] backgroundTimeRemaining], that way you can bring the user back into the app before it suspends and the multi peer framework has to be shutdown. Perhaps the local notification would warn them that their session will expire in 10 seconds or something...
If the background task expires and the app is still in the background, you have to tear down everything related to multi-peer connectivity, otherwise you will get crashes.
- (void) createExpireNotification
{
[self killExpireNotification];
if (self.connectedPeerCount != 0) // if peers connected, setup kill switch
{
NSTimeInterval gracePeriod = 20.0f;
// create notification that will get the user back into the app when the background process time is about to expire
NSTimeInterval msgTime = UIApplication.sharedApplication.backgroundTimeRemaining - gracePeriod;
UILocalNotification* n = [[UILocalNotification alloc] init];
self.expireNotification = n;
self.expireNotification.fireDate = [NSDate dateWithTimeIntervalSinceNow:msgTime];
self.expireNotification.alertBody = TR(#"Text_MultiPeerIsAboutToExpire");
self.expireNotification.soundName = UILocalNotificationDefaultSoundName;
self.expireNotification.applicationIconBadgeNumber = 1;
[UIApplication.sharedApplication scheduleLocalNotification:self.expireNotification];
}
}
- (void) killExpireNotification
{
if (self.expireNotification != nil)
{
[UIApplication.sharedApplication cancelLocalNotification:self.expireNotification];
self.expireNotification = nil;
}
}
- (void) applicationWillEnterBackground
{
self.taskId = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:^
{
[self shutdownMultiPeerStuff];
[[UIApplication sharedApplication] endBackgroundTask:self.taskId];
self.taskId = UIBackgroundTaskInvalid;
}];
[self createExpireNotification];
}
- (void) applicationWillEnterForeground
{
[self killExpireNotification];
if (self.taskId != UIBackgroundTaskInvalid)
{
[[UIApplication sharedApplication] endBackgroundTask:self.taskId];
self.taskId = UIBackgroundTaskInvalid;
}
}
- (void) applicationWillTerminate
{
[self killExpireNotification];
[self stop]; // shutdown multi-peer
}
You'll also want this handler in your MCSession delegate due to Apple bug:
- (void) session:(MCSession*)session didReceiveCertificate:(NSArray*)certificate fromPeer:(MCPeerID*)peerID certificateHandler:(void (^)(BOOL accept))certificateHandler
{
if (certificateHandler != nil) { certificateHandler(YES); }
}
There are many causes of this, and the two answers thus far are both correct in my experience. Another which you'll find in other similar questions is this: Only one peer can accept another's invitation.
So, to clarify, if you set up an app where all devices are both advertisers and browsers, any devices can freely invite any others found to join a session. However, between any two given devices, only one device can actually accept the invitation and connect to the other device. If both devices accept each others' invitations they will disconnect within a minute or less.
Note that this limitation does not prevent the desired behavior because - unlike what my intuition stated before I built my multipeer implementation - when one device accepts an invitation and connects to another device they both become connected and receive connection delegate methods and can send each other messages.
Therefore, if you are connecting devices which both browse and advertise, send invitations freely but only accept one of a pair.
The problem of only accepting one of two invitations can be solved a myriad of ways. To begin, understand that you can pass any arbitrary object or dictionary (archived as data) as the context argument in an invitation. Therefore, both devices have access to any arbitrary information about the other (and of course itself). So, you could use at least these strategies:
simply compare: the display name of the peerID. But there's no guarantee these won't be equal.
store the date your multipeer controller was initialized and use that for comparison
give each peer a UUID and send this for comparison (my technique, in which each device - indeed each user of the app on a device - has a persistent UUID it employs).
etc - any object which supports both NSCoding and compare: will do fine.
I've been having similar problems. It seems though that if I have run my app on one iOS device, and connected to another, then quit and relaunch (say when I rerun from Xcode), then I am in a situation where I get a Connected message and then a Not Connected message a little later. This was throwing me off. But looking more carefully, I can see that the Not Connected message is actually meant for a different peerId than the one that has connected.
I think the problem here is that most samples I've seen just care about the displayName of the peerID, and neglect the fact that you can get multiple peerIDs for the same device/displayName.
I am now checking the displayName first and then verifying that the peerID is the same, by doing a compare of the pointers.
- (void)session:(MCSession *)session peer:(MCPeerID *)peerID didChangeState:(MCSessionState)state {
MyPlayer *player = _players[peerID.displayName];
if ((state == MCSessionStateNotConnected) &&
(peerID != player.peerID)) {
NSLog(#"remnant connection drop");
return; // note that I don't care if player is nil, since I don't want to
// add a dictionary object for a Not Connecting peer.
}
if (player == nil) {
player = [MyPlayer init];
player.peerID = peerID;
_players[peerID.displayName] = player;
}
player.state = state;
...
I was disconnecting immediately after I accepted the connection request. Observing the state, I saw it change from MCSessionStateConnected to MCSessionStateNotConnected.
I am creating my sessions with:
[[MCSession alloc] initWithPeer:peerID]
NOT the instantiation method dealing with security certificates:
- (instancetype)initWithPeer:(MCPeerID *)myPeerID securityIdentity:(NSArray *)identity encryptionPreference:(MCEncryptionPreference)encryptionPreference
Based on Andrew's tip above, I added the delegate method
- (void) session:(MCSession *)session didReceiveCertificate:(NSArray *)certificate fromPeer:(MCPeerID *)peerID certificateHandler:(void (^)(BOOL accept))certificateHandler {
certificateHandler(YES);
}
and the disconnects stopped.

Dealing with background location updates and Core Data file protection

I've been experimenting with CLLocationManager's startMonitoringSignificantLocationChanges and I've run into some problems with Core Data. It turns out that since iOS 5.0, Core Data defaults to using NSFileProtectionCompleteUntilFirstUserAuthentication. This means that if a passcode is set, the persistent store is unavailable from the time the device is turned on until the time the passcode is first entered. If you're using location updates, it's possible your app may get launched during that time, and Core Data will get an error trying to load the persistent store.
Obviously switching to NSFileProtectionNone would be the easiest way to solve this. I'd prefer not to though—I'm not storing anything super sensitive in the database, but these location updates aren't super critical either.
I know I can use [[UIApplication sharedApplication] isProtectedDataAvailable] to check whether the data has been unlocked yet, and I can use applicationProtectedDataWillBecomeUnavailable: in my application delegate to respond appropriately once it is unlocked. This seems messy to me though—I'll have to add in a bunch of extra checks to make sure nothing goes wrong if the persistent store is unavailable, re-setup a bunch of things once it does become available, and so on. And that extra code doesn't offer much benefit—the app still won't be able to do anything if it launches in this state.
So I guess I'm just not sure which is the more "proper" way to deal this:
Switch to NSFileProtectionNone.
Add in the extra checks to skip over things if the store is unavailable, and use applicationProtectedDataWillBecomeUnavailable: to set things up again once it is.
If the app is launched in the background ([[UIApplication sharedApplication] applicationState] == UIApplicationStateBackground) and protected data is unavailable ([[UIApplication sharedApplication] isProtectedDataAvailable] == NO)) just call exit(0) (or something similar) to quit the app. On one hand this seems like the simplest solution, and I don't really see any downsides. But it also seems… "wrong"? I guess I can't decide if it's a clean solution or just a lazy one.
Something else I'm just not thinking of?
After thinking this over for a while I've come up with a solution I'm happy with. One thing to consider with the exit(0) option is that if the user takes a while to unlock the device, the app could be continually loading, quitting, and reloading. Whereas if you simply prevent the app from doing much, it will probably only have to load once, and will most likely be more efficient. So I decided to try my option 3 and see how messy it really was. It turned out to be simpler than I thought.
First I added a BOOL setupComplete property to my app delegate. This gives me an easy way to check if the app was fully launched at various points. Then in application:didFinishLaunchingWithOptions: I attempt to initialize the managed object context, then do something like this:
NSManagedObjectContext *moc = [self managedObjectContext];
if (moc) {
self.setupComplete = YES;
[self setupWithManagedObjectContext:moc];
} else {
UIApplication *app = [UIApplication sharedApplication];
if ([app applicationState] == UIApplicationStateBackground && ![app isProtectedDataAvailable]) {
[app beginIgnoringInteractionEvents];
} else [self presentErrorWithTitle:#"There was an error opening the database."];
}
setupWithManagedObjectContext: is just a custom method that finishes setting up. I'm not sure the beginIgnoringInteractionEvents is necessary, but I added it to be on the safe side. That way when the app is brought to the front, I can be sure the interface is frozen until setup is complete. It might avoid a crash if an eager user is tapping anxiously.
Then in applicationProtectedDataDidBecomeAvailable: I call something like this:
if (!self.setupComplete) {
NSManagedObjectContext *moc = [self managedObjectContext];
if (moc) {
self.setupComplete = YES;
[self setupWithManagedObjectContext:moc];
UIApplication *app = [UIApplication sharedApplication];
if ([app isIgnoringInteractionEvents]) [app endIgnoringInteractionEvents];
} else [self presentErrorWithTitle:#"There was an error opening the database."];
}
That finishes the setup and re-enables the interface. That's most of the work, but you'll also need to check through your other code to make sure nothing that relies on Core Data is getting called before your persistent store is available. One thing to watch out for is that applicationWillEnterForeground and applicationDidBecomeActive may get called before applicationProtectedDataDidBecomeAvailable if the user launches the app from this background state. So in various places I've added if (self.setupComplete) { … } to make sure nothing runs before it's ready. I also had a couple of places where I needed to refresh the interface once the database was loaded.
In order to (partially) test this without a lot of driving around, I temporarily modified application:didFinishLaunchingWithOptions: to not set up the database:
NSManagedObjectContext *moc = nil; // [self managedObjectContext];
if (moc) {
self.setupComplete = YES;
[self setupWithManagedObjectContext:moc];
} else {
UIApplication *app = [UIApplication sharedApplication];
// if ([app applicationState] == UIApplicationStateBackground && ![app isProtectedDataAvailable]) {
[app beginIgnoringInteractionEvents];
// } else [self presentErrorWithTitle:#"There was an error opening the database."];
}
Then I moved my code in applicationProtectedDataDidBecomeAvailable: over to applicationWillEnterForeground:. That way I could launch the app, make sure nothing unexpected happens, press the home button, open the app again, and make sure everything was working. Since the actual code requires moving a significant distance and waiting five minutes each time, this gave me a good way to approximate what was happening.
One last thing that tripped me up was my persistent store coordinator. A typical implementation might look something like this:
- (NSPersistentStoreCoordinator *)persistentStoreCoordinator {
if (_persistentStoreCoordinator != nil) return _persistentStoreCoordinator;
NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:#"Test.sqlite"];
NSError *error = nil;
_persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];
if (![_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:nil error:&error]) {
NSLog(#"Unresolved error %#, %#", error, [error userInfo]);
}
return _persistentStoreCoordinator;
}
This is loosely based on Apple's sample code, which does explain in comments that you need to handle the error appropriately. My own code does a bit more than this, but one thing I hadn't considered is that if there's an error loading the persistent store, this will return a non-nil result! That was allowing all my other code to proceed as though it was working correctly. And even if persistentStoreCoordinator was called again, it would just return the same coordinator, without a valid store, instead of trying to load the store again. There are various ways you could deal with this, but to me it seemed best to not set _persistentStoreCoordinator unless it was able to add the store:
- (NSPersistentStoreCoordinator *)persistentStoreCoordinator {
if (_persistentStoreCoordinator != nil) return _persistentStoreCoordinator;
NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:#"Test.sqlite"];
NSError *error = nil;
NSPersistentStoreCoordinator *coordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];
if ([coordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:nil error:&error]) {
_persistentStoreCoordinator = coordinator;
} else {
NSLog(#"Unresolved error %#, %#", error, [error userInfo]);
}
return _persistentStoreCoordinator;
}
I have experienced, that you have to check
[[UIApplication sharedApplication] isProtectedDataAvailable]
and process
applicationProtectedDataWillBecomeUnavailable
to be sure you don't access a protected file.
Checking for
managedObjectContext
did not work for me.

GameKit: who's the Master?

I'm building an application (already on the app store by the way, called MotAMot): a boggle, free app.
This game proposes several playing modes: standalone, multi players using the same iDevice and MULTI in which 2 players play the same gameboard at the same time but each using his own iDevices.
I'm using a GKPeerPickerController instance to manage the connection between the 2 devices.
My only concern is that I can't decide who's iPhone will play the server role and who's the client. When a player sends an invitation to the other, its cool, I can decide that this player will be the server.
Say for instance that player 1 invites player 2 to join the game. But at the same time (or just a few seconds after), player 2 invites player 1 before he gets the invitation popup displayed on his device. My question: how can I be sure that player 1 invited player 2 first (or the opposite)? I mean, of course I got some callbacks because I'm implementing the GKPeerPickerControllerDelegate protocol. But it seems that I get the same messages on both devices, regardless of who really initiates the connection.
// New connection
- (void)peerPickerController:(GKPeerPickerController *)picker
didConnectPeer:(NSString *)peer
toSession:(GKSession *)session
{
// Set the session
[self setCurrentSession:session];
// I'm implementing the GKSessionDelegate protocol
[session setDelegate:self];
// I'll handle any received data from my enemy
[session setDataReceiveHandler:self withContext:nil];
// I'm cleaning the room
[myPicker setDelegate:nil];
[myPicker dismiss];
[myPicker autorelease];
myPicker = nil;
}
// A peer changed its state
- (void)session:(GKSession *)session peer:(NSString *)peer didChangeState: (GKPeerConnectionState)state
{
switch (state)
{
case GKPeerStateConnected:
[self peerConnected:peer];
break;
case GKPeerStateDisconnected:
// Libération de la session
[currentSession release];
currentSession = nil;
break;
case GKPeerStateAvailable:
break;
case GKPeerStateConnecting:
break;
case GKPeerStateUnavailable:
break;
}
}
Would someone have any idea on this?
Why can't you solve this the old fashioned way? Civilization IV for example puts you into a server-room screen, in which case you are the server waiting for clients and it makes sense for you to not accept any new connections.
I would do something akin to that. it turns out this person had a problem (slightly related) and in my understanding it is solved in a similar way.