Developing for mobile

Discussion and feedback on Construct 2

Post » Mon Oct 23, 2017 12:26 am

After using C2 for many many years, my wife asked me to develop a mobile app for her work. It involved entering some numbers into a textbox and it would do some calculations.

The thing is, it's not acting how I expected.

If the textbox ever goes off screen or gets covered up by the keyboard, the keyboard is immediately pulled down. This was caused by the scale not being perfect on the mobile device, so it would scale the screen appropriately. I had the textbox at the top, so it would sometimes disappear.

However, I've seen a few examples where the textbox could be placed at the bottom, and if the keyboard was summoned it would slide the textbox up... but in my experience (and this thread I found: https://www.scirra.com/forum/problem-with-textbox-and-mobile-keyboard_t185196), the keyboard just overlaps the textbox and, as I said, that causes it to close the keyboard as the textbox is no longer in focus. Strangely, in the linked experience, their keyboard remains, but they can't see what they're typing.

In addition to this, I can't press the enter button on the soft keyboard to confirm that I'm done entering details. Why is that exactly? The enter button does nothing at all. People have to press the back button or onto the layout in order to close the keyboard.

Is it possible to have events for the software keyboard?

Construct 2 has typically been promoted as being great for mobile development since my time here, and finally when I do decide to make use of that functionality, it's missing what I consider pretty basic functions? Colour me very surprised.
B
98
S
20
G
8
Posts: 1,066
Reputation: 12,758

Post » Mon Oct 23, 2017 12:44 am

Seriously, I'd make my own keyboard out of sprite frames.
Image ImageImage
B
179
S
50
G
207
Posts: 8,719
Reputation: 128,306

Post » Mon Oct 23, 2017 1:05 am

newt wrote:Seriously, I'd make my own keyboard out of sprite frames.

Hey Newt! Yeah, I've thought about that, but I'm also looking at allowing names to be entered, which would require all the letters added. Seems like a lot of effort just to enter names JUST because the enter key and focus don't work.

I was hoping that I was missing something basic... rather than Construct missing something basic.
B
98
S
20
G
8
Posts: 1,066
Reputation: 12,758

Post » Mon Oct 23, 2017 3:03 am

AnD4D wrote:
newt wrote:Seriously, I'd make my own keyboard out of sprite frames.

Hey Newt! Yeah, I've thought about that, but I'm also looking at allowing names to be entered, which would require all the letters added. Seems like a lot of effort just to enter names JUST because the enter key and focus don't work.

I was hoping that I was missing something basic... rather than Construct missing something basic.


I've spent a lot of time battling this, and usually do either one of two things:

1. Design my own keyboard.
2. Make sure all HTML textfields are in the top half of the screen.

The problem is that with Construct's screen scaling, browser manufacturers are too inconsistent to make sure things are always done the same way. The only surefire way to avoid these issues is to build your own keyboard.
www.simbucket.com - HTML5 Science Simulations / https://www.airconsole.com/#!play=com.n ... obotrumble - Robot Rumble on AirConsole
B
61
S
22
G
27
Posts: 456
Reputation: 19,336

Post » Mon Oct 23, 2017 4:12 am

cjbruce wrote:
AnD4D wrote:
newt wrote:Seriously, I'd make my own keyboard out of sprite frames.

Hey Newt! Yeah, I've thought about that, but I'm also looking at allowing names to be entered, which would require all the letters added. Seems like a lot of effort just to enter names JUST because the enter key and focus don't work.

I was hoping that I was missing something basic... rather than Construct missing something basic.


I've spent a lot of time battling this, and usually do either one of two things:

1. Design my own keyboard.
2. Make sure all HTML textfields are in the top half of the screen.

The problem is that with Construct's screen scaling, browser manufacturers are too inconsistent to make sure things are always done the same way. The only surefire way to avoid these issues is to build your own keyboard.


@cjbruce Yeah... keeps coming back to that, but the fact that it appears to be a requirement is absurd. I originally used the "Scale Inner" scale, but when I put the texbox at the top, it vanished, and recentred my screen, no mater my scroll to point. In the end, I had to use "Scale Outer", which results in a teeny tiny layout when the keyboard appears. It's as though it zooms out.

It's annoying, looks stupid is and unprofessional, but it works.

I'm also aware that with my app exported with Cordova and built with PhoneGap, whenever I touch a textbox, the toolbar/status bar at the top of mine and 2 other phones I've tested it on appears it will never go away again. So if I touch the textbox, I can't get rid of the little clock. Even though I check the box at export.

So that's 3 bugs with mobile development in relation to the textbox.

1) The return button does nothing
2) The soft keyboard vanishes if the keyboard overlaps it or if it goes off screen (often caused by scaling)
3) The status bar appears and won't go away

@Ashley - Are you aware of any of these issues? Or do you not consider them issues?

When the best answer is "Make your own keyboard", I struggle to believe that there's not a problem here. Are these things fixed in Construct 3?
B
98
S
20
G
8
Posts: 1,066
Reputation: 12,758

Post » Mon Oct 23, 2017 11:04 am

Android or iOS? They handle this differently. On iOS generally it keeps the viewport the same size and shifts the text field in to the visible part of the viewport and everything works OK. On Android though currently the keyboard changes the viewport size, which kicks off a fullscreen scaling resize, which then changes the textbox size. Then you get in to all sorts of awkward situations where you can't see the input, or it scrolls away and therefore hides the field so the keyboard closes, etc. It's made harder by the fact browsers do not provide any way to detect if the keyboard is currently showing, and just to throw another spanner in the works, Android is currently changing the way they handle this, so if we fix it now it could be broken again shortly. All in all, a big headache.

Generally we don't fix bugs unless there's a report filed for them - can you link me to any relevant bug reports so I can take another look? It's probably going to involve some kind of ugly hack though...
Scirra Founder
B
415
S
248
G
92
Posts: 25,288
Reputation: 200,960

Post » Mon Oct 23, 2017 1:03 pm

Seems like the obvious solution would be an on screen keyboard object.
A: A lack of a standard ensures no two different browsers handle it the same way.
B: You get customisable keyboards.
Image ImageImage
B
179
S
50
G
207
Posts: 8,719
Reputation: 128,306

Post » Mon Oct 23, 2017 1:37 pm

@Ashley I didn't see it as a bug, just a missing feature. As I said, I've not really looked into mobile development really until recently.

I've just done my own keyboard, but it's not ideal because if players make an error they have to delete all the characters after the error to fix it, rather than just edit the text.

It's not a big deal, really, but it's not great.
B
98
S
20
G
8
Posts: 1,066
Reputation: 12,758


Return to Construct 2 General

Who is online

Users browsing this forum: rush4545 and 6 guests