Primary app view not loading when tapping on a new push notification message about sunshine-conversations-ios HOT 14 CLOSED

Hi Pauli,

We haven't seen this one before and I can't seem to reproduce it either.
Do you see the behaviour occur when you run our Demo app (https://github.com/radialpoint/SupportKit/tree/master/DemoApp) ?

Thanks,
Mike

from sunshine-conversations-ios.

I can confirm that this does not happen with the Demo app, but something I noticed another problem that's happening with both the Demo app and my app.

I was trying to replicate the problem on my end and it seems like I need to quit the app entirely after sending a support message.

Now, when I receive a push notification and tap on it, both my app and the Demo app open the Messages screen, but there are no messages visible.
EDIT: If I wait long enough (5-10 seconds, maybe more) the messages will eventually appear.

From here, in my apps case the app stays all white, while the Demo app shows up fine.
In both apps, if I then open SupportKit with the gesture again, the previous/current messages are visible.

So, there's at least one problem that's also affecting the Demo app, but I have a feeling that both of these problems are related.

I'll keep trying to figure out what's causing this and at least try to get the white background bug fixed. :)

from sunshine-conversations-ios.

Additionally, is SupportKit running on the main thread? Asking, because I just got this and my entire app froze:
<SupportKit: ERROR> An unexpected error occurred when validating the app token.
Error: The operation couldn’t be completed. (NSURLErrorDomain error -1001.)
Response: (null)
Retrying in 10 seconds...

EDIT: Apparently the Demo app works with my app token, but my own app does not, no idea what could be causing it.

from sunshine-conversations-ios.

@Dids I'll try to shed some light on what's happening here. The delay you're seeing when launching the app from a push notification is expected behavior - since we don't store any conversation information on the device, the messages screen will be empty until the initial fetch to retrieve messages completes. In high-speed network environments, this usually takes less than 1 or 2 seconds. We have an improvement coming up soon in a future release that will partially address this issue and display a loading indicator while messages are being fetched.

The "unexpected error" means a timeout happened (code -1001) when validating the app token, likely caused by either a slow / flaky network connection, or very heavy load on our servers. The fact that it freezes your app is surprising! We do, in fact, do some work on the main thread during app boot (to perform initial setup and prepare for the gesture), but network activity is not done on the main thread. I'll do some digging on what could be causing your app to freeze.

Now, the white screen issue. It's possible that SupportKit is presenting the messages screen before your UI has been fully loaded in the main view controller. Your app may then be trying to update a view that is no longer onscreen, and this can cause UI glitches like the one you are seeing. If you add a breakpoint in your view controller's 'viewDidAppear:' method, is it called before or after the messages screen appears?

EDIT: Quick follow-up, I did some testing in our debug app and I'm actually seeing some odd behavior - viewWillDisappear: is being called before viewDidAppear: on the main view controller. This is a sign that we are indeed presenting the conversation view controller a little bit too early.

from sunshine-conversations-ios.

@Dids I've compiled a build I think will fix the white screen issue. You can download it here

Could you please try this and let me know if the issue is fixed?

from sunshine-conversations-ios.

Why don't you guys cache the conversations locally and display that until you can display locally?

from sunshine-conversations-ios.

@mspensieri Thanks, I'll give it a try!

As @williamsjj said, caching would indeed be a nice feature to have, but if you prefer not to cache/store any conversation data, at least showing a progress/loading indicator would be nice, so users don't get all confused on slower connections. :)

from sunshine-conversations-ios.

@Dids @mspensieri I think both are needed for a user not to feel frustrated when they open a push notification. Caching gives them context and keeps them from thinking the conversation was lost (they'll be less likely to wait I think on a blank screen), and the loading indicator lets them know the new response is loading right now. I know synchronization is difficult so I'd be perfectly happy with the loading operation replacing the conversation history that was loaded from the cache (as opposed to any sort of incremental update).

from sunshine-conversations-ios.

@mspensieri Unfortunately the new framework didn't change a thing, still having the same issue. Is SupportKit overriding the initialization of itself when a push notification is tapped (and if the app is not currently running)?

from sunshine-conversations-ios.

@Dids The initialization process is the same when launching the app clean and launching from a push notif - the only difference is when the initialization process is complete, if the app was launched from a push notif, we then present the messages screen on top of the app's main view controller.

This may be a difficult request, but is there any way you could create a minimal sample app that reproduces the problem?

@williamsjj Thanks for the suggestion! I'll definitely bring it up with the team.

from sunshine-conversations-ios.

@mspensieri I added a breakpoint to viewDidAppear and even with the new framework you linked to it only gets called after SupportKit has been closed.

from sunshine-conversations-ios.

@mspensieri A good solution would be to adopt a property/method ".showNotificationOnActive" like the Mixpanel component that lets the app disable showing notifications until it's ready and then can re-enable them.

from sunshine-conversations-ios.

@Dids If you have some time you could hop into our live chat channel and I can try and debug the issue further

from sunshine-conversations-ios.

Closing the loop here, this has turned into an issue with jondanado's TheSidebarController

from sunshine-conversations-ios.