Jump to content
Sign in to follow this  
recursiveElk

[FIXED] Resizing Form (Mobile)

Recommended Posts

Hi, attached is an example of resizing a basic form on an iphone with ios11

 

It seems that the Form/Resize event has a hard time getting/updating the right screen dimensions when switching between landscape and portrait mode.

 

The Resize event has not been changed and is just a generic 'inherited' default.

 

I've tried using tw3dispatch.settimeout to delay the resize, but that didn't work, any solutions to make sure the resize only runs (or reruns) after the self.height and self.width are changed?

 

PS. This seems to affect portrait mode a lot more than landscape resizing.

 

Thanks,

 

Direct Download Link: https://puu.sh/xJODH/2e66ed0933.MOV

Share this post


Link to post
Share on other sites

At the previous version (SMS 2.2.2), I suspect the bottleneck is coming from the Resize event. Resize is firing multiple times, and this will reduce the browser's workload. When you re-size the browser window, you get two successive on Resize firing all the time. f.i. when you click at Next Form (goto form2)or you switch between portrait/landscape - the resize event is called. I don't know if they fixed this on the new alpha. The problem is the alpha does not like the XP, and XP is like old shoes. Anyway, I'll suggest you use handwritten HTML/CSS code using flexible layouts in the main screen.

Share this post


Link to post
Share on other sites

Sorry, should have clarified that this was indeed done on the new Alpha.

 

>> I'll suggest you use handwritten HTML/CSS code using flexible layouts in the main screen.

 

Could you potentially clarify what you mean here? I'm currently using TLayout and custom CSS. How would i go about positioning the components with CSS given the SMS components are absolute positioned in the html on compile?

Share this post


Link to post
Share on other sites

I had a look at the resizes yesterday and was able to eliminate the extra resize during the device flip. There were also other bugs that i fixed in the resize, so the next Alpha update should work a lot smoother. I'll let you know when the update is available in SmartUpdate. And I hope that you'll let me know if this all is fixed.

 

Using HTML/CSS to make flexible layouts is possible if you use percentages: https://jonlennartaasenden.wordpress.com/2017/02/02/smart-pascal-cool-tricks-for-better-code/

 

However, if you use these perventages-tricks, bare in mind that the RTL will not trigger OnResize for you any more, when the size changes.

Share this post


Link to post
Share on other sites

The issue has been largely resolved for the application i need it for (tablets) so that's excellent, but the bug still persists on mobile ios where it hangs as shown in the clip.

 

This is occurring both in my heavier project and the fresh project with only a few divs and no resizing code. Potentially something to have a look into at a later date.

Share this post


Link to post
Share on other sites

Also of note: this same example when tested on various mobile devices seems to have very choppy scrolling with quite low fps w/ TW3ScrollBox implemented.

Note:

Devices tested:

- ios : smooth on iphone 7(new), choppy on ipad 3 (old).

- android : choppy on samsung s8 (new), samsung tablet (old)

 

The older devices understandably might struggle a bit more for whatever reason but the s8 should handle it more than fine.

 

I have tested toggling UseTransform property on/off as well.

Share this post


Link to post
Share on other sites

This is really strange. Chrome on Android is jerky while Firefox on the same device is a lot smoother.

 

Oh, and I can't reproduce the resizing problem with my iPhone or my Android phone.

Share this post


Link to post
Share on other sites

Hopefully a solution can be found soon, this is pretty critical to our application.

 

As for the resizing bug, Did you try reproduce with the link provided as well? The issue doesn't happen on pretty much any device except my iphone now, only on chrome and not safari too.

Share this post


Link to post
Share on other sites

Hopefully a solution can be found soon, this is pretty critical to our application.

 

As for the resizing bug, Did you try reproduce with the link provided as well? The issue doesn't happen on pretty much any device except my iphone now, only on chrome and not safari too.

Please give me exact steps: For example, how many panels should I create?

 

BTW, when running the RetroBalls -demo, I noticed that the frame rate for Chrome on Android was way slower than Firefox on the same device. I'm going to investigate, if the problem happens to be in RequestAnimFrame.

Share this post


Link to post
Share on other sites

The exact reproduction is as follows:

 

If there are no panels added or displayed on screen, the screen resizes correctly(on orientation change).

If there are panels added that are visible on screen, the screen resizes sporadically, and incorrectly often(on orientation change).

If there are panels added to the scrollbox but not directly visible ( scroll down ) then the resizing seems to correct back(on orientation change).

 

Example: https://puu.sh/xPmc6/a222eea879.mp4

 

As you can see it seems to be a direct relationship between number of components visible and speed of resize.

 

It seems to be sporadic but commonly occurs with some of my bigger projects where layouts and several components are resized. Seems to only occur currently on testing with ios 11 but have had similar issues on chrome/android in the past.

 

BTW, when running the RetroBalls -demo, I noticed that the frame rate for Chrome on Android was way slower than Firefox on the same device. I'm going to investigate, if the problem happens to be in RequestAnimFrame.

Thanks, please keep us updated, as if no solution can be found i might have to switch back to setting overflow-y for the body, which leads to issues with chromes built in pull-to-refresh on mobile, etc.

Share this post


Link to post
Share on other sites

Ahh, now I get it. You're using Chrome on iOS. I had been testing with Safari. Gonna see what goes wrong here. Weird thing is, that Chrome/Android works flawlessly.

Share this post


Link to post
Share on other sites

Now that was a tricky bug. It only happened on iPhone and Chrome. The bug actually is in Chrome. It sends the resize -event too fast, while the window height is still wrong. When I googled around, there were suggestions of reacting to the resize after a delay, but I found a more elegant solution that does not require any delays.

 

Run SmartUpdate and the resize bug is gone.

Share this post


Link to post
Share on other sites

Great work! I realise some of these bugs i've found have been particularly bothersome to deal with haha.

 

Any update on the choppy scrolling by the way?

I can confirm the issue exists across [safari + Chrome on iOS] as well as [Chrome on Android].

Seems to affect slower devices much worse, but iOS 11/iPhone 7 handles perfectly while Android7/SamsungS8 is choppy.

 

Edit 0:

After Updating my Project compiles but is completely black!

is there a way i can rollback? Working on finding the issue now.

Edit 1: RESOLVED(redundant "position: fixed" line was causing issues)

Share this post


Link to post
Share on other sites

@Jarto, any progress on your investigation (see RetroBalls post above)? I am finding the slow frame rate on Chrome on Android to be a real hassle and it is making our App experience quite unpleasant.

Share this post


Link to post
Share on other sites

Ha! Got the Android Chrome to run fast!

 

Try setting this:

 

w3_setStyle(ScrBox.Content.Handle, 'will-change', 'transform');

 

AND set ScrollController.UseTransForm to true

 

It did miracles on my Android device.

 

DISCLAIMER: We'll include this improvement into the SMS itself, so you do not need to set it yourself in the future.

Share this post


Link to post
Share on other sites

Will test and report back thank you!

 

Edit 1: This worked on first testing! Order of magnitude improvements!

Edit 2: Slight issue found with the momentum aspect of scrolling on iOS iPad 3 only, investigating whether this is an internal bug or not.

Edit 3: iOS iPad 3 Chrome/Safari - performance struggles(but much much improved) scrolling over sections that have a lot of content. (a series of panels with 25 child components - editboxes, panels, labels for example, when scrolling further down the same form with no content displaying its smooth scrolling again.)

 

On faster iOS devices its completely fine. (iphone 6 + 7)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×