Killing the app while creating a post does weird things

[koke]

Video at: https://cloudup.com/iOZ-BQXHqyx

When you relaunch the app, there's an empty post

If you try to trash it, it will fail, because it was never published

If you open it, it says there are unsaved changes

If you discard them, you still have an empty post with unsaved changes

The only way to delete that post is to actually publish it (or save as a draft), and then delete it.

Also found this

Not sure if this is the new post list changes, the new editor, or a little bit of both, so cc @aerych @bummytime @diegoreymendez

[koke]

@aerych A couple UI details for you (in super slow-mo 😛), which aren't a big deal and might not be worth fixing, but I noticed them

In the post list, the bottom banner animates but new cells don't

When you create a post, the empty post is briefly visible on the list, and it's after the oldest one

[aerych]

Not sure if this is the new post list changes, the new editor, or a little bit of both,

I don't think that would be due to changes in either feature.

A couple UI details for you [...]

I'll add these to #3673. I noticed the new cell issue earlier. We expect the new cell to appear but its out of order and I think I know why. The animating footer is interesting. :)

[diegoreymendez]

The problem of properly restoring the GUI-state for posts is very closely related to how we handle the post's publication-state locally.

This is a good starting point to try and find the issue: https://github.com/wordpress-mobile/WordPress-iOS/blob/develop/WordPress/Classes/ViewRelated/Post/WPPostViewController.m#L203

[aerych]

We'll handle the empty post, and publish issues in #3786. Leaving just the wonky date picker layout.

[diegoreymendez]

Removed my last 2 comments since they weren't accurate.

PS: I'm testing state restoration, which seems to be playing a key role here... when opening the app as shown in @koke's video, the app should go back to the post the user was editing directly.

[diegoreymendez]

From Apple's documentation:

If you want to test your app’s ability to restore its state, you should not use the
multitasking bar to kill the app during debugging. Instead, use Xcode to kill the
app or kill the app programmatically by installing a temporary command or
gesture to call exit on demand.

When following these guidelines for testing this is the behavior I'm getting in the App.

We should still fix this though, in the case that state information is reset for any reason.

[kwonye]

Also related: long video uploads. This is a hard problem to solve. From what I last know, Apple's watchdog (guard prevent apps from using too much battery in the background) only gives a 10 minute window max to allow for background processes to finish. 24 minutes of video, depending on the quality, can easily exceed that. Google Photos solves this by showing a pop up saying "Please stay on this app for optimal uploading of photos".

Same possible situation since we'll get killed mid-way during a post if the user backgrounds.

[rachelmcr]

We've resolved the main issue reported here (killing the app while creating a post now saves a local draft) and long media uploads are improved with async uploads. Closing as resolved.