how to handle cancelled and failed states of AVAssetWriter? - swift

Some of my users experience crash when they finish recording video. I setup everything correctly and this is happening only for %0.2 of the users. The crash happens when finishWriting is called.
I finally decide to check AVAssetWriter's status before I call below code;
videoInput?.markAsFinished()
videoWriter?.finishWriting
now it is;
if videoWriter?.status == .writing {
videoInput?.markAsFinished()
videoWriter?.finishWriting
// some ui configurations
}
But what about the other cases .cancelled & .failed ? Is it necessary to call the following code again? What should I do if videoWriter?.status == .cancelled or videoWriter?.status == .failed?
videoInput?.markAsFinished()
videoWriter?.finishWriting

Related

XCUITest verify that ui interruption handler occurred

I'm very new to swift and xcuitest. I recently came across addUIInterruptionMonitor for handling alerts that can pop up. What I would like to know is how I can verify that the alert happened and that the handler was dealt with. Take the following for example
addUIInterruptionMonitorWithDescription("Location Services") {
(alert) -> Bool in
alert.buttons["Allow"].tap()
return true
}
app.buttons["Request Location"].tap()
app.tap() // need to interact with the app again for the handler to fire
// after this if the handler never gets called I want the test to fail
I would like to test that the alert actually happens, but as far as I understand, after my last tap() if the alert never gets triggered my handler wont be called. I need to test that the alert actually happened and then maybe add some assertions to the contents of the handler
I seem to have answered my own question on further investigation. For asynchronous testing with xcuitest I can use a XCTestExpectation which will when created, cause the test to wait until the expectation is fulfilled, or fail after a certain timeout. With that my above code becomes:
let expectation = XCTestExpectation(description: "Location Service Alert")
let locationMonitorToken = addUIInterruptionMonitorWithDescription("Location Services") {
(alert) -> Bool in
alert.buttons["Allow"].tap()
expectation.fulfill() // test waits for this before passing
return true
}
app.buttons["Request Location"].tap()
app.tap() // alert triggered here
wait(for: [expectation], timeout: 3.0)
removeUIInterruptionMonitor(locationMonitorToken)
Update: forgot to put in the wait(for: [expectation], timeout: 3.0) after alert triggered to ensure handler is called.

addUIInterruptionMonitor is not getting called on macOS

I want to test my macOS application. It uses your Macbook's camera, and want to handle this in my UITest. However I cannot get it working. Here is my NOT working code. This code triggers to notification, and I'm presented an alert to allow access to my camera, but the closure is not getting called. Thanks fo any help.
There are many solutions for iOS, but I need it on macOS.
let alertHandler = addUIInterruptionMonitor(withDescription: "Camera Permission Alert") { (alert) -> Bool in
if alert.buttons.matching(identifier: "OK").count > 0 {
alert.buttons["OK"].click()
self.app.click()
return true
} else {
return false
}
}
XCTAssertTrue(startButton.waitForExistence(timeout: 1.0))
startButton.click()
XCTAssertTrue(recordButton.waitForExistence(timeout: 20.0))
recordButton.click()
wait(for: 8)
recordButton.click()
removeUIInterruptionMonitor(alertHandler)
}
I managed to make interruption monitor work on macOS by adding an extra interaction after the interaction that triggers the system dialog (be it camera access or else). So in your example I would add an action after startButton.click() (if that is what triggers the camera access dialog).
Example:
func testCamera() {
let alertHandler = addUIInterruptionMonitor(withDescription: "Camera Permission Alert") { (alert) -> Bool in
if alert.buttons.matching(identifier: "OK").count > 0 {
alert.buttons["OK"].click()
self.app.click()
return true
} else {
return false
}
}
useCameraButton.click()
// try to interact with the app by clicking on the app's window
app.windows.first().click()
// at this point the handler should intercept the system interruption
// and blocks further execution until handler does return
// try to use the camera again
useCameraButton.click()
removeUIInterruptionMonitor(alertHandler)
}
Hint about this behaviour in Apple's documentation:
When an alert or other modal UI is an expected part of the
test workflow, don't write a UI interruption monitor. The test won’t
use the monitor because the modal UI isn’t blocking the test. A UI
test only tries its UI interruption monitors if the elements it needs
to interact with to complete the test are blocked by an interruption
from an unrelated UI.
https://developer.apple.com/documentation/xctest/xctestcase/handling_ui_interruptions

Chartboost with Swift - Interstitial: prefetch if NOT complete. wait... but no ad?

I am trying to integrate Chartboost ads in Swift into my project and have followed the tutorial verbatim:
https://answers.chartboost.com/hc/en-us/articles/205853276
Everything is imported and in App delegate I have:
Chartboost.startWithAppId(//stuff)
Chartboost.setShouldRequestInterstitialsInFirstSession(false)
Chartboost.cacheMoreApps(CBLocationHomeScreen)
//Chartboost
class func showChartboostAds()
{
Chartboost.showInterstitial(CBLocationHomeScreen);
}
func didFailToLoadInterstitial(location :String!, withError error: CBLoadError)
{
}
func didDismissInterstitial(location :String! )
{
if(location == CBLocationHomeScreen)
{
Chartboost.cacheInterstitial(CBLocationMainMenu)
}
else if(location == CBLocationMainMenu)
{
Chartboost.cacheInterstitial(CBLocationGameOver)
}
else if(location == CBLocationGameOver)
{
Chartboost.cacheInterstitial(CBLocationLevelComplete)
}
else if(location == CBLocationLevelComplete)
{
Chartboost.cacheInterstitial(CBLocationHomeScreen)
}
}
Then in my main view controlleR:
AppDelegate.showChartboostAds()
I have my app in test mode in the dashboard and am running on a real device but I just get Interstitial: prefetch if NOT complete. wait... in the console.
Why won't it show any ads?
Just an aside, the reason this solution works is because of the prefetch method. It seems when you call the ad the Chartboost prefetch isn't completing on time, which is causing the show call to fail.
Chartboost does have a delegate method that will give you the all-clear when prefetch completes, that may be worth a look: - (void)didPrefetchVideos;
Here's a link to the rest of the page.
Hope this helps.
I think you're trying to show the AD to quickly. Try delaying the AD, that solved it for me.

Testing iOS: Calling init() the first time an app is opened triggers 2 PURCHASE_CANCELLED events

The ios user account password pops up also. This doesn't happen if called again while app is still opened, but repeats if app is closed and reopened.
Thanks
Sounds like you have unfinished purchases that you need to finish.
Purchases will remain in a pending state until your application calls finish on them. This is to ensure that your application processes and verifies a purchase.
You should call InAppBilling.service.finishPurchase when you have process a purchase and either delivered the product or handled the cancellation/failure:
https://gist.github.com/marchbold/851359b9e456e1a85d65#file-distriqt-extension-inappbilling-makepurchase-as
private function purchase_cancelledHandler( event:PurchaseEvent ):void
{
// This transaction was cancelled so you should notify your user and finish the purchase
trace( "purchase cancelled" + event.errorCode );
if (event.data && event.data.length > 0)
InAppBilling.service.finishPurchase( event.data[0] );
}
At start up you can retrieve the pending purchases after the SETUP_SUCCESS event:
private function setupSuccessHandler( event:InAppBillingEvent ):void
{
var pending:Array = InAppBilling.service.getPendingPurchases();
// Iterate over and handle as required
}
http://docs.airnativeextensions.com/inappbilling/docs/com/distriqt/extension/inappbilling/InAppBilling.html#getPendingPurchases()

What's the best way to cancel an upload in progress using filepicker.io?

I'm using filepicker.makeDropPane to play around with some simple uploads. One thing that I cannot find in the docs at filepicker.io's web documentation is a method for canceling an upload that is in progress.
Intuitively I feel that the onStart function should be passed an additional parameter. An object that represents the upload that has a cancel() function which when called would immediately cancel the file uploads. Something like this does not seem to be available.
we don't actually have this functionality yet, but it makes sense. I'll take a look at adding something along these lines and let you know
Here's an ugly hack I figured out to protect against unwanted returned files as well some other fancy stuff around progress and multiple files etc. You definitely want to use a static js file include so it doesn't get changed on you and break this.
Use this in your progress handler:
var event = event || window.event;
// For firefox, go and grab the XHR progress event object.
if (typeof event == 'undefined' || event == null) {
if (typeof arguments.callee.caller.arguments[0] == 'object') {
event = arguments.callee.caller.arguments[0];
}
else {
event = arguments.callee.caller.arguments.callee.caller.arguments.callee.caller.arguments[0];
}
}
var sUploadId;
if (event.type.toLowerCase() == 'progress') {
// if we haven't already tagged this XHR object (one per file), tag it now
// if we receive further progress from this file, it will already have been tagged
if (!('id' in event.currentTarget)) {
sUploadId = goUploadProgress.files.length;
event.currentTarget.id = sUploadId;
goUploadProgress.files.push({id: sUploadId, total:event.total});
}
else {
sUploadId = event.currentTarget.id;
}
// get the loaded bytes for this file
goUploadProgress.files[sUploadId].loaded = event.loaded;
}
else {
// ignore readystatechange events
return;
}
I modified this to make more sense for this context, so I may have made a logical mistake, but this is the gist. You can get the event in Firefox by looking up the call stack, and you can append an id to each file's XHR upload object, which will exist until it finishes.
I repeat, this is a hack! Don't trust that it won't break.