GitHub Issue | n/a |
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2014-01-10T21:34:20.000+0000 |
Affected Version/s | Release 3.2.0 |
Fix Version/s | 2013 Sprint 22, 2013 Sprint 22 Core, 2014 Sprint 01, 2014 Sprint 01 API, Release 3.2.1, Release 3.3.0 |
Components | Android |
Labels | SupportTeam, module_textarea, qe-testadded, regression, triage |
Reporter | Dan Tamas |
Assignee | Hieu Pham |
Created | 2013-10-17T17:33:37.000+0000 |
Updated | 2014-01-23T06:12:06.000+0000 |
The textArea behaves like a textFieled - only one line is displayed and you can scroll the text horizontally instead of going vertically and break the words.
I'm attaching the testcase and screenshots (3.1.3.GA and 3.2.X)
var win = Ti.UI.createWindow({
backgroundColor:'red'
});
var ta = Ti.UI.createTextArea({
backgroundColor:'yellow',
top:0,
width:200,
height:200,
value:'A long text that should go on more then one line but it seems it doesn\'t'
});
win.open();
var vl = Ti.UI.createLabel({
font:{
fontSize:'20dp'
},
color:'#fff',
top:250,
text:"Ti SDK "+Ti.version
})
win.add(vl);
win.add(ta);
Thank you.
Hi Dan, I have just tested this with an Android device running 4.2 and Emulator with 4.0.3, Which device did you use to produce this issue? Are you able to reproduce on the Android Emulator?
Hi Jamie, here is more info about my environment: Ti SDK 3.2.0.v20131016191202 Ti CLI 3.2.0 devices: HTC One V with 4.0.3 Galaxy Tab 7+ with 3.2 (new screenshot) Emulator 4.0.2 - (new screenshot) Emulator 4.2.2 - (new screenshot) Please be sure you are selecting the sdk to be 3.2.x and in the CLI to select the sdk as well with *ti sdk select 3.2.x*
Tested in genymotion emulator with 4.1.1 too (shot)
I can confirm the issue using: TiSDK 3.2.0.v20131017152001 Ti CLI version 3.2.0 ("bleeding edge" install from GitHub master on 18 October 10:40 EST) Galaxy Nexus running Android 4.2.2 Please make sure you're testing with version 3.2 of the SDK, as textareas render multiline text as expected in 3.1.3 and 3.1.4.
https://github.com/appcelerator/titanium_mobile/pull/4825
Any news on this? We need this to be able to push further the android app. Thank you :)
CR + FR
Verified and fixed on: Mac OSX 10.9 Mavericks Titanium Studio, build: 3.2.0.201310312257 Titanium SDK, build: 3.2.0.v20131031141643 CLI:3.2.0 Alloy: 1.2.2 Android Emulators: 2.3.3, 4.0.3, 4.2.2 Android Device, Samsung Galaxy Nexus 4.2.2 Textarea goes over multiple lines successfully. Closing.
Regression, after installing SDK 3.2 the textarea stopped wrapping its content (for caption and entered text). tested on GalaxyS3 and Sony Xperia P running Android 4.1.2
[~sameeh.harfoush] Do you have a different test case than the one mentioned above? If so, could you please provide the test case so we can take a look at it? Thanks.
sure please check the code below...
Any update on this? Any app using textarea in any meaningful way is unable to move forward with the Titanium SDK.
^^^ Seconded. I'm trying to release the android version of my app and this textarea issue is keeping me from being able to release. Can we get at least an update of how long this will take to fix so I can tell my teammates?
Thirded, so to speak. TextArea no longer multiline with Titanium SDK 3.2.0.GA and Android 4.1.1. Enter key does nothing and text scrolls left/right without wrapping. Major loss of function.
I'm having the exact same issue. Has this really been known since October and not been fixed yet? It works fine on IOS with the Titanium SDK 3.2.0 GA but Android is a no go. This is this last piece I need to work before I can release on Android. Need this fixed ASAP please! Kind of disappointed and let down right now :(
Looking at the source: https://github.com/appcelerator/titanium_mobile/blob/master/android/modules/ui/src/java/ti/modules/titanium/ui/widget/TiUIText.java ... the only reference to TYPE_TEXT_FLAG_MULTI_LINE is now to disable it: // current (8 Jan 2014) code public void handleReturnKeyType(int type) { // ... int currentInputType = tv.getInputType(); //FLAG_MULTI_LINE will display enter key, therefore disables our ime options. if (!field && (currentInputType & InputType.TYPE_TEXT_FLAG_MULTI_LINE) != 0) { currentInputType &= ~InputType.TYPE_TEXT_FLAG_MULTI_LINE; } //Set input type caches ime options, so whenever we change ime options, we must reset input type tv.setInputType(currentInputType); // ... } where "field" is a boolean that is true for a TextField and false for a TextArea. So the code appears to be forcing the Android multiline flag off for TextAreas (the opposite of what one might expect). There is no other mention of TYPE_TEXT_FLAG_MULTI_LINE in this GitHub repository apart from in the Label code (android/modules/ui/src/java/ti/modules/titanium/ui/widget/TiUILabel.java). So I think this is part of the problem. The other is that in an older (2012) version, there was this code: // old (2012) code public void processProperties(KrollDict d) { // ... if (d.containsKey(TiC.PROPERTY_KEYBOARD_TYPE) || d.containsKey(TiC.PROPERTY_AUTOCORRECT) || d.containsKey(TiC.PROPERTY_PASSWORD_MASK) || d.co ntainsKey(TiC.PROPERTY_AUTOCAPITALIZATION) || d.containsKey(TiC.PROPERTY_EDITABLE)) { handleKeyboard(d); } else if (!field) { tv.setInputType(InputType.TYPE_TEXT_FLAG_IME_MULTI_LINE); } // ... } public void handleReturnKeyType(int type) if (!field) { tv.setInputType(InputType.TYPE_TEXT_FLAG_IME_MULTI_LINE); } // ... } .. which obviously used to set the TYPE_TEXT_FLAG_IME_MULTI_LINE flag. This code seems to have gone, though there is this: public void handleKeyboard(KrollDict d) { // ... if (!field) { tv.setSingleLine(false); } // ... tv.setInputType(textTypeAndClass); // } The Android reference ( http://developer.android.com/reference/android/widget/TextView.html#setSingleLine(boolean) ) says: - public void setSingleLine (boolean singleLine) ... If true, sets the properties of this field (number of lines, horizontally scrolling, transformation method) to be for a single-line input; if false, restores these to the default conditions. Note that the default conditions are not necessarily those that were in effect prior this method, and you may want to reset these properties to your custom values. - android:singleLine ... Constrains the text to a single horizontally scrolling line instead of letting it wrap onto multiple lines, and advances focus instead of inserting a newline when you press the enter key. The default value is false (multi-line wrapped text mode) for non-editable text, but if you specify any value for inputType, the default is true (single-line input field mode). I wonder if the problem is that tv.setInputType is called AFTER tv.setSingleLine(false) ? The Android docs suggest that the tv.setInputType might make the default single-line input. And then there's some code to disable TYPE_TEXT_FLAG_IME_MULTILINE explicitly. All of this has changed from a previous working version. I'm happy to be proved wrong as to the cause but the bug is a very important one. all the best, Rudolf.
I am also having the same issue as above. It might be worth mentioning, unless you already know that is. That this issue is not present when building for iOS, not sure about the other platforms as our application is only built for Android and iOS
Hi All, we are investigating this issue now. If we can come up with a simple fix, we will attempt to get it out ASAP.
Agree with Rudolf. Developers know TextArea return key can't be customized. That doesn't seem like a bug at all. Multi-line functionality, however, is the main reason a developer chooses to use TextArea. Hieu and Ingo: Hieu's comment doesn't tell us the plan for this ticket. Are we to individually dive into Java and fix this ourselves, or are we going to get multi-line functionality for TextArea back on Android? Perhaps the final solution is allowing both solutions, allowing the developer to choose between: A) A TextArea with multi-line functionality and a carriage return returnKey B) A TextArea without multi-line functionality but with a customizeable returnKey I don't know why option B would be chosen over a TextField, though, which is why Rudolf and I (and probably the rest of the watchers on this ticket) are confused by lack of clarity on resolution for this ticket. 3.2 has Android camera parity functionality I've been waiting months for. I'd love to upgrade to 3.2 and close a slew of bug tickets for our Android users. This ticket is the blocker.
Hieu's comment is not a resolution, just a developer's note. We're still deciding the best option. Your suggestions are helpful.
PR: https://github.com/appcelerator/titanium_mobile/pull/5202 3_2_X PR: https://github.com/appcelerator/titanium_mobile/pull/5208
Thank you, Ping, Ingo. I installed [latest 3_2_X](http://builds.appcelerator.com.s3.amazonaws.com/index.html#3_2_X), version 3.2.1.v20140110140111, and textarea wrapping is restored. Super excited! I removed a ton of code to make up for hideCamera not being available on android. Android camera still seems to zoom in when using overlay, but I'll put together a ticket for that.
My thanks also! And thank you, Alejandro, for the link to pre-release versions; I had created a module to implement the fix, which was clearly unnecessary.
Np, Rudolf
Verified the fix , hence closing the issue Environment Used: Device : Google Nexus 7, Android Version: 4.4.2 SDK: 3.3.0.v20140117222449 SDK: 3.2.1.v20140117222448 CLI version : 3.2.1 OS : MAC OSX 10.9 Alloy: 1.3.1-beta2 ACS: 1.0.11 npm:1.3.2 Appcelerator Studio, build: 3.2.1.201401151647 titanium-code-processor: 1.1.0 XCode : 5.0.2
Ingo and Appcelerator Team, just wanted to thank you for resolving this and for the camera updates for android in 3.2. Our camera experience for android is usable for more devices now, and much improved for the devices it already worked for. There are a couple of lingering things I'll open tickets for (camera zooms in with overlay, and also with overlay it seems to take much worse low light photos than the native camera), but we're in such a better place.
You are welcome guys and thanks for the prompt support :) Good luck :)