I'm building a mobile application using Flex.
I'm trying to set softKeyboardInputAreaOfInterest on each inputs to include the button underneath. The area of interest is smaller than the remaining screen space left by the soft keyboard, and I've set it on viewActivate, ensuring that the correct dimensions are passed.
However, I'm testing in iOS and it just doesn't seem to be working. The correct dimensions are being traced when I set the rect, but the panning behaviour is incorrect.
I've found one or two unanswered posts on this in other threads too. Surely this property wasn't created and documented, but not actually implemented. It seems to do absolutely nothing.
At this stage, I can't get find a way of guaranteeing that both the input field and the button at the bottom of the form are panned into view.
Please help if you can!
It's a bug – softKeyboardAreaOfInterest doesn't work on iOS. I was in contact with the Adobe AIR team during the AIR prerelease in July. They confirmed the bug and added a sentence to the online AS3 docs ("This property is not available on iOS").
I just tested it again today with the newest version of AIR (version 3.5.0.600) and it's still not working on iOS, but the online AS3 docs have removed the sentence about softKeyboardAreaOfInterest not working on iOS. I'm guessing this is an oversight.
Update, Nov 19 '12: For AIR 3.5, the removal of "not available on iOS" in the AS3 docs turned out to be an oversight which has been corrected. This property still doesn't work on iOS with AIR 3.5.
Update, Nov 20 '12: And today's word from Adobe is that it's not a bug, softKeyboardAreaOfInterest is just not enabled on iOS.
Related
Before we start, I'd like to clarify...
This question isn't about how to include emoji on labels. I'm aware that has been asked and answered before. I am able to get the emoji on the label just fine.
This question isn't about whether we can/should include emoji on labels. I am aware of the issues around that too. We'll discuss as a team whether we want to proceed with emoji, but it doesn't make me any less curious about the issue below.
With the disclaimers out of the way, our situation is as follows: We have an iOS app that deploys back to iOS 12. In it, we'd like to include the warning sign on a UILabel to signal certain situations. The text of the label comes from this bit of code (including picture, because pasting emoji doesn't come through):
This line isn't setting someLabel.text directly but it's the relevant bit. I can promise you that surrounding code simply prepends this snippet to other text and slaps it onto a label.
The first character of that literal string at the end of the line is the "warning sign" emoji inserted into the source code via hitting Ctrl+Cmd+Space and choosing it from the resulting picker. Then we have the unicode code point \u26A0.
I get the following when this code runs:
At this point I'm really curious about...
What changed between iOS 12.4 and 13.7 such that the same source code produces different output? Was the different treatment of unicode code points announced somewhere on some release notes?
Is one side somehow "more correct"? Does the "yellow-triangle-with-black-exclamation-in-it" symbol and \u26A0 technically represent different things, iOS 12 mistakenly visualized them as the same, and iOS 13 fixed that issue? Or vice versa; they are actually meant to represent the same thing, iOS 12 did so, and iOS 13 broke something? Or does the concept of correctness not even apply, since they are different representations?
Is there any code point I can type into my source file (e.g. \u<something>) that will render as the yellow-triangle-with-black-exclamation-in-it emoji consistently on iOS 12 and later? If so, what is it? If not, is using the actual emoji in my source code the only way to achieve this?
There are two variants, 26a0fe0f and 26a0fe0e. The former is the emoji variant; the latter is the text variant. In iOS 13 you are using both of them. I don't know why it chooses the second one as a fallback in iOS 13 but the first one as a fallback in iOS 12; the iOS 13 behavior seems more correct to me.
I think I figured it out, but leaving question and answer up in case it helps others.
The crux of the issue is that the "yellow-triangle-with-black-exclamation-in-it" symbol and the "black-bordered-triangle-with-black-exclamation" symbols are not the same entity. We see these in the character viewer built into macOS:
And sure enough, the representation \u26A0\uFE0F renders as "yellow-triangle-with-black-exclamation-in-it" on both iOS versions:
If \u26A0 wasn't supposed to be the "yellow-triangle-with-black-exclamation-in-it" emoji, I still can't explain why it renders as such on iOS 12...
Credit actually belongs to user matt. He had a comment which hinted at these being different, which led me down this path. The comment is no longer there for some reason (got deleted?) so I don't know how to properly attribute.
My old iPad (ios9.3) refuses to load any reveal.js slides. It only shows the "Fork me on Github" image on the top corner. I suppose it will be that ios 9.3 does not support some new features of html5+js+css (I am not a developer, my skills are quite limited, so please excuse me if I say something stupid).
I am very interested in using it on an iPad due to the chalkboard plugin.
Any of you know what can be causing the trouble? Could I disable any of these features/files and make it work?
Thank you.
aimar
During all this weekend I was trying to figure out a solution. Finally, I manage to debug iOS safari from my windows laptop following this procedure and found that an "Unexpected identifier" was impeding "chalkboard" plugin to load.
A variable was defined with "let" command that, as I learnt, was not recognized by safari 9. I changed 4 "let"s with 4 "var"s commands in "plugin.js" (chalkboard plugin) and now it works in my old iPad, even with reveal v4.
Now I have another issue with the menus (menu plugin) not showing properly, but I will try also to fix it.
Having an iOS 12 model rending issue.
My app loads OBJ models with associated MTLs and textures.
On iOS 11 we were able to load up the models and they looked good:
On iOS 12, they look completely different:
We are able to make some changes after the model loads initially to make it look good, but it takes time for the iPhone to load the better looking version.
Has anyone heard about/experienced this issue and know what has changed in iOS 12 (and potentially MacOS Mojave) that is causing it?
There might be two issues: 1- texture issue (as seen in chair on left) and 2- Material/MTL issue as seen in the ‘delivery drone’ on the right
I don't have any code at this moment as I am not one of the developers on the project - I have been tasked with reaching out here. If you have any questions regarding the specific code I could definitely try to get some to show here. It seems to me like this might not be a code issue or bug, but rather some settings that have to changed due to changes made in iOS 12, but I can't find documentation for something that matches this.
I know this is not an answer, but I was asked for a screenshot. For the moment I use the OpenGL renderer instead of Metal as a workaround.
I solve the same issue by convert .obj file to .scn files in Xcode, and use this scenes as nodes. Editor -> Convert to SceneKit file format (.scn)
screenshot of this menu
We are using Sencha1.0 for our webapp development. In IOS9 version we are facing the following issues.
On initial page load, the page looks fine. When you try to change the device orientation to landscape and back to portrait, all images icons and texts are resized(small).
We tried -webkit-transform : rotate(-90); its doesnt work.
Please suggest the cause and any solution for this.
Sencha Touch 1.1.1 is really quite old version of the framework.
And there is a lot of bug fixes already applied to the framework. The new version of the mobile OS often break a thing or two. You will be also probably seeing an issue on Android devices which runs Chrome 43+
If you already have an App finished and this is the only problem you see, you might fix this by applying override. ( You can check the newer version of the framework and took the part which fixes the issue ) - but it might be really hard to find. Also you probably can't even reach to Sencha support, as the Touch 1 is no longer supported.
But if you are developing the new App, best option for you is to upgrade to Touch 2.4.2
The major release of Sencha Touch should be free to download.
I know that this won't fix the issue but by answer is too long for a comment.
I have no idea how to call these and so I'm having a hard time googling for it. I've seen these a several times in iOS and MacOS apps to think they might be an OS feature. I'm talking about the blue tags or groups in text field controls. See the images below.
That's an NSTokenField on Mac. On iOS there's no official implementation (file a request if you want one) so you'd have to go with a third-party implementation. If I remember correctly, the Three20 framework has one...
Googling found these iOS versions:
JSTokenField
TTMessageRecipientField (I think)
This helper class is SO much better... https://github.com/thermogl/TITokenFieldView