Detected issues at BetaTest iOS version 2.64.4 8)

The aia to test:
ACENTOS.aia (1.1 KB)

Ok. I've taken a look at the codegen and it is producing UTF-16 to be compatible with the Java layer. I'll need to adjust the iOS side to be able to parse the UTF-16 and convert it into UTF-8 for compatibility with the iOS libraries.

OK. In this aia test you can see 2 issues more:
1-The vertical-center alignement screen for the label not runs.
2-The font size labels not runs.

Other question @ewpatton :
Can I use the ActivityStarter with only the android.intent.action.VIEW in the iOS platform?

Why not? I've no issues with that:

Tested with the last Versions of Firefox and Companion. I receive the error code 601

The aia to test:
AS.aia (1.6 KB)

Ok. It is with a workaround for iOS. In Android is not necesary the arrangement to have the same result. For me is a issue in iOS vs Android. I have solved several more iOS issues with workarounds.

There is a space at the end:

so remove it and it will work!

1 Like

Of course, and there are many more. But as long as there are simple and uncomplicated workarounds, we should come to terms with it in order to FINALLY (after so many years) get a build server that can also be used to publish apps in the Apple AppStore. If we want to wait until even the smallest discrepancy has been resolved, we will most likely NEVER experience it.

AS_2.aia (1.7 KB)

Ups¡¡¡You have right. I don't see this space at the ende.
Is not a issue. Is my mistake.

I agree it.

Only for help:
This ActivityStarter return a 601 code error. Only to have a speace in the text ob ?subject=

This other runs well: (it has not spaces). Attention: The parameter ?body= will be a part of the parameter ?subject=

Remark: The ActivityStarer is very fien sensible to spaces in all the parameters. In Android that not happens.

For the URLs, I think they need to be proper URLs, which don't typically allow for spaces. Try substituting %20 for the spaces and see if it works then.

For the label issues, it seems like both the font problem and the UTF-8 problem are due to the use of HTMLFormat. I have come up with fixes for both.

1 Like

Perfect. Thanks. They ara not a big issues only are Design issues and we can have workarounds for all but will be better to correct for a right compatibility platforms. In the issue of the fonts also change always the Design colours to black color (we can write the font color on the Blocks).

You are right. With the ASCI character %20 runs well the spaces in iOS and Android. And for the \n character we can use %5Cn.

Line Break = %5Cn