What I meant by that was doing without native transitions, but trying to optimize what you had before using a pure web-based approach. Many developers seem happy with sticking to web technologies and manage to achieve impressive results. I don’t think it will get you all the way to a native user experience, but especially if you use an existing UI framework the difference in time investment might be worth it.
I’m not sure how many hybrid apps implement all their navigation using web technologies. From the screen shot in this article for instance, I would say Instagram combines native navigation elements with a web view for its timeline.
Ah I see. Thank you so much. I am going to give it a few more trys. What do you think of the following way?
Before transitioning to PostsShowVC create another webView inside PostsListVC and load the same url /posts, and move the initial webView to PostsShowVC. When I transition back to PostsListVC, I destroy the webView that was used inside PostsShowVC and show the user the one I created before. Do you think this approach works?
I think using webViews gets tricky because it only starts loading in viewDidLoad and there aren’t that many ways to prefetch data.
I’m not sure how that would help, but maybe I’m misunderstanding. The best approach still seems to be to replace the web view with a screen shot in the source view controller, which shouldn’t be too hard. Just make sure you take the screen shot first and only transition to the new page after.
@woniesong: I am working on the very same thing (building a Meteor Cordova app with native iOS extensions), as described here:
I haven’t read through this whole thread yet, but regarding the re-usage of the web view, I’ve described how I did this in the thread linked above. I would be interested in sharing experiences on this, as this is indeed quite challenging.
At the moment, I am trying to find a solution to send messages from the web view to my native code, as described here:
How did you solve this?
PS: On the native side, I am focusing on iOS only, since I am a single developer with limited time. For Android, I plan to use standard Cordova, and accept that it might not run that smooth as on iOS.
Regarding Android: why exactly do you think native code is inevitable there? At least on my fairly new devices (Nexus 7, HTC One), everything runs smoother than on my iPad 3 actually. Just for instance, whereas the iPad takes ages to react to a hot code reload, on the Nexus 7 it is much faster. And while HCR tends to break the whole app beyond restoration on the iPad, this never happened to me on Android.
The only problem I had with Android so far is that my custom fonts are not loading if the app is run for the first time. Fonts only appear after a first Hot Code Reload, and I have absolutely no clue why this is the case.
@wonisong: I am wondering why you are passing the web view from one controller to the other programmatically. I am using container views, and this does the trick for me automatically. All you have to do is to embed the same web view into different containers using an embed segue. One of the advantages of this approach also is that you get a better feeling of your app’s structure in your storyboard.
And instead of using two different view controllers to maintain smooth transitions, I would try to apply the trick mentioned in the link @nilsdannemann posted: https://hansoftx.com/blog/building-an-ultra-responsive-ui These guys just render two templates at the same time (i.e. in the same layout template) and switch between those templates using CSS visibility. That’s a really clever idea, as this switch nearly happens instantly. Of course there’s the drawback of having a quite long page, but if you combine this with infinite scroll techniques like these guys did, the overall experience should still be good.
Thank you for sharing your experience! It’s good to know someone else is trying to do the same thing that I am trying. In my experience, iPhone was in a usable state even without the native wrapper. Pure Meteor + Meteoric approach worked pretty well with the introduction of WKWebView. However, when we tried Android, we saw the result above (https://youtu.be/u0ebeev2fcE). Android phones use different webviews based on the device, and I heard Samsung Galaxy tends to have poor webview performance. Crosswalk is supposed to be the solution for this problem, but in our case, it made the performance worse.
We resorted to wrapping our Meteor app with a native container. The transitions and scrolling behavior seem to be much better. I just looked at your link (https://hansoftx.com/blog/building-an-ultra-responsive-ui) and I don’t understand how they managed to not load when they go back from a postShow view to postIndex view. How come they don’t have to load their data again? In other words, how come they don’t have to wait for the subscriptions to get ready?
@martijnwalraven your idea of taking a screenshot worked perfectly.