Support SDK for iOS => Pre-selected attachments

Hey Eric. Thanks for the response. What do you mean with "a simple example application"? Should I create a demo application (which also requires me to create a demo Zendesk Support account), build it, and then distribute it to TestFlight, so you can install and reproduce the issue? Maybe I just should create a demo project, push it to Github, and then give you a link to the repo, so you can clone the project and build it?

You can reproduce the issue easily, if you have an example app, which uses the `fileAttachments` field. I guarantee you will face the same problem.

I've created a simple demo project (also a free-trial demo account), which illustrates the problem. Can you please take a look? Thanks!

link to the repo: https://github.com/TimurDyushaliev/zendesk_support_ios_demo

Okay. Thank you Eric. Much appreciated!

Why did you delete my last reply, where I explained why your workaround doesn't solve the problem (and even makes worse)? And you guys really call this "Community" after it? 

That's weird... I was able to see the message for about 15-30 minutes. Even when I closed the web page and opened again via a link after some short period of time. But, after several hours, when I opened the web page again, my message just disappeared. Idk the reason, but nvm, that doesn't matter now.

So.. about the workaround. I didn't try it yet, but what I see from the code:

@objc private func submitRequestCompleted(notification: NSNotification){
        let helpCenter = HelpCenterUi.buildHelpCenterOverviewUi(withConfigs: [])
        self.navigationController?.popToRootViewController(animated: true)
        self.navigationController?.pushViewController(helpCenter, animated: true)
    }

The callback is called whenever a ticket is submitted. So, inside the callback we just close the current Zendesk support page and open it again, but without pre-selected file. I see 2 problems here:

1.  This (closing and reopening) will be seeable to a user because of the animations. That sounds not good.
2. Okay, the first ticket is submitted with pre-selected file. Okay, a user was able to see that the page suddenly reopened. But what about new tickets? The wanted file won't be attached to them automatically, because the reopened page will be with a new config, which doesn't include the file. We expect the file will be automatically attached to every new ticket (but not for replies), as it works on your Android SDK.

Because of these - I don't think it is a solution for us. But again.. I didn't try it yet. These are just my theoretical thoughts from what I see from the code. If I'm wrong, please let me know. I will try it in our project, but after the new year. I'm tired and took a rest from the job.

By the way. It was unpleasant to me to read that you won't fix the bug, because I'm the only one, who faced this. A problem is a problem, no matter how many people are facing it. I've even created the sample project, which illustrates the problem, so you were able to reproduce the issue and agreed there is a bug. We've been using your services for several years and paying for them. This case gives us a thought, that you won't fix problems, when we meet them.

And also, our crashes have been growing since I implemented attaching a file automatically (as a pre-selected file) on Android.

Logs:

CellBindHelper.java line 31
zendesk.support.request.CellBindHelper.openAttachment

Fatal Exception: android.os.FileUriExposedException: file:{path_to_file_here} exposed beyond app through Intent.getData()
       at android.os.StrictMode.onFileUriExposed(StrictMode.java:2141)
       at android.net.Uri.checkFileUriExposed(Uri.java:2391)
       at android.content.Intent.prepareToLeaveProcess(Intent.java:11179)
       at android.content.Intent.prepareToLeaveProcess(Intent.java:11128)
       at android.app.Instrumentation.execStartActivity(Instrumentation.java:1724)
       at android.app.Activity.startActivityForResult(Activity.java:5444)
       at androidx.activity.ComponentActivity.startActivityForResult(ComponentActivity.java)
       at android.app.Activity.startActivityForResult(Activity.java:5395)
       at androidx.activity.ComponentActivity.startActivityForResult(ComponentActivity.java)
       at android.app.Activity.startActivity(Activity.java:5795)
       at android.app.Activity.startActivity(Activity.java:5748)
       at zendesk.support.request.CellBindHelper.openAttachment(CellBindHelper.java:31)
       at zendesk.support.request.CellBindHelper.access$000(CellBindHelper.java)
       at zendesk.support.request.CellBindHelper$1.onClick(CellBindHelper.java:8)
       at android.view.View.performClick(View.java:7507)
       at android.view.View.performClickInternal(View.java:7484)
       at android.view.View.access$3600(View.java:839)
       at android.view.View$PerformClick.run(View.java:28689)
       at android.os.Handler.handleCallback(Handler.java:938)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at android.os.Looper.loop(Looper.java:236)
       at android.app.ActivityThread.main(ActivityThread.java:8037)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:656)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:967)

I wasn't able to reproduce this. Maybe it's a known issue and you know the reason? Or should I open a new post?

Aahh.. I've got this. Now I know the reason, why my message "disappeared". Its status was "Pending approval" (as well as my current reply about the workaround) and it didn't pass. But another question raises in my mind: "Why?".

Hey Timur,

I could see your latest post in the moderation queue, though your initial message we still have no history of. Our system flagged your latest message due to a particular combination of characters in the comment that have been being used recently in spam. I've tuned the alert so it shouldn't happen again.

---

For the workaround your understanding of whats happening is actually a bit off. The process is happening in the background and the user isn't made aware of the swap as it happens during the request view change to place their comment into the conversation body. Additionally this function does the swap upon completion of the ticket submission. So it only affects the ticket that threw the notification. If a user wants to submit a ticket again, the attachment will be added again as anticipated. 

I'd highly suggest testing this all for yourself in the demo that you provided. Though for your ease I've included a screen recording. 

Lastly, I can understand why you found it unpleasant to read that we wouldn't be picking up this bug. Our team has a large list of priorities and we want to continue making improvements to the SDK's. When encountering issues such as this where we are able to find a solution to a minor problem / edge case without having to make any changes to the core service. Then we elect to provide the workaround to the customer and continue spending our time on making improvements to the SDK.

For your Android crash issue - It's tough to say without seeing your implementation and you being unable to replicate. I'd ask that you create a new post with a bit more information about your build as well as the SDK version that you're running.

Thanks!

Thank you, Eric, for the explanation and for the video, which shows that the workaround solves the issue. I will try it later and let you know. But for now, the crashes on Android is more important for us and I'm working on that. If we look to the stacktrace:

       at android.os.StrictMode.onFileUriExposed(StrictMode.java:2141)
       at android.net.Uri.checkFileUriExposed(Uri.java:2391)
       at android.content.Intent.prepareToLeaveProcess(Intent.java:11848)
       at android.content.Intent.prepareToLeaveProcess(Intent.java:11797)
       at android.app.Instrumentation.execStartActivity(Instrumentation.java:1722)
       at android.app.Activity.startActivityForResult(Activity.java:5377)
       at androidx.activity.ComponentActivity.startActivityForResult(ComponentActivity.java)
       at android.app.Activity.startActivityForResult(Activity.java:5335)
       at androidx.activity.ComponentActivity.startActivityForResult(ComponentActivity.java)
       at android.app.Activity.startActivity(Activity.java:5721)
       at android.app.Activity.startActivity(Activity.java:5674)
       at zendesk.support.request.CellBindHelper.openAttachment(CellBindHelper.java:31)
       at zendesk.support.request.CellBindHelper.access$000(CellBindHelper.java)
       at zendesk.support.request.CellBindHelper$1.onClick(CellBindHelper.java:8)
   ...

we can see this function (from the "CellBindHelper" class) was called:

private void openAttachment(Context context, StateRequestAttachment requestAttachment) {
    final Intent intent = Belvedere.from(context)
            .getViewIntent(requestAttachment.getParsedLocalUri(), requestAttachment.getMimeType());
    final PackageManager manager = context.getPackageManager();
    if (manager.queryIntentActivities(intent, 0).size() > 0) {
        context.startActivity(intent);
    }
}

If I understood correctly, this function opens the file picker page. So, I think, our app crashes, because it can't in some cases pass a file's URI to the file picker page (Belvedere package) according to the docs: https://developer.android.com/reference/kotlin/android/os/FileUriExposedException

 The exception that is thrown when an application exposes a file:// android.net.Uri to another app.

But is Belvedere another app? I mean it just opens another app (for example some system app, which serves to browse files)? If it is, I can't understand why we can't reproduce this in our side. Maybe in some devices (or maybe settings, installed apps and etc) it opens another app, and in other devices it's just a page (which is within the app scope). Or maybe it's just about some privacy settings.. idk..

I want to debug this issue inside your Android SDK code to understand completely and to try to fix it. The fact that your Android SDK repository is in  jfrog, instead of usual github makes things harder to me (I wasn't able to find the repo in github). I will create a new post about this, when I collect more information and maybe come up with a fix. For now, I just think replacing "file://" prefix in URI to "content://" solves the problem, as described in docs:

Instead, apps should use content:// Uris so the platform can extend temporary permission for the receiving app to access the resource.