I want to create my customized own controls apart from standard Android views/widgets including View, ScrollBar, TextView, EditText, ...
And already completed others but not TextView/EditText yet.
The two controls interact with soft-keyboard on focus or not. Plus, you can type/edit the text of the control by the keyboard. More challenging part is about controlling the caret. These problems happen because the control inherits View, not TextView/EditText.
You may ask why I chose such difficult way, not using standard ones and customize only some part of them?
That's because of one fatal problem that standard TextView/EditText cannot support large files(a few MB files) and are lagging with them. Additionally, some of the important member functions are private, not protected or public. So we cannot customize fully them as we want.
That's why I created one customized text viewer/editor that supports large files (even over 100 MB). Viewer feature already has been implemented and works well.
Now the editor feature is remaining and it's the reason why I'm here to request your help.
Please let me know what's the best solution and I'd appreciate if you can provide with some sample codes.
Thanks
P.S. This is what I've done so far.
screenshot
apk
Related
In my Android app I have a custom layout that is being used as a button - it consists of some TextViews and an ImageView, additionally it has some gradient background.
I'm aligning my app now to conform to the Accessibility rules. In order to do so, I would need to convert this layout into a button, so that TalkBack can correctly indicate the action, that this whole layout is clickable and serves like a button.
I know that on iOS there is a possibility to set the UIAccessibilityTraits to treat such view as a button - this kind of solution would save me a huge amount of work in terms of migration.
Is there any similar solution on Android for that? What approach should I follow in order to make this layout recognized correctly by TalkBack?
No, there's no concept of accessibility traits on Android - but you can still get a good accessibility experience without needing to specifically convert your layout into a Button.
Generally, it's most important that TalkBack (or whatever accessibility service is being used - remember, it's not just TalkBack) is able to detect that the widget is clickable and to be able to read a coherent description of what it does. The additional information that it's a button, specifically, isn't super useful, especially because there are so many different kinds of UI elements that it's often a very ambiguous question whether something even is a button.
You can test this by selecting it in TalkBack and confirming that it reads the content description properly, says something along the lines of "Double tap to activate," and performs the correct action when you double tap.
If it's not correct, make sure the content description, clickable flag, and click action are set correctly on the widget's AccessibilityNodeInfo.
I need to make an android app that has a very dynamic ui.
For example imagine we have an activity with only one button inside that in center. Then when someone clicks the button. The button converts to edittext. When user enters some text, the editText converts to textview. And then under the textview, two new buttons automatically Appear. This proccess will go on untill user create a binary-tree like structure. I want this kind of UIs.
I Hope you Undrestand My Problem.
My question is, how can i achieve this kind of UIs?
Can you give any suggestion?
It depends on what the requirements are, are we talking about simple animations like fading out and fading in, maybe some pulsation and then edit text appearance. It depends because it might be enough to use existing tools like using the ObjectAnimator or even xml or you will have to do some fancy stuff as in writing animation code that meets your particular requirements. Apart from that a factor is what versions of Android are you trying to support JellyBean and above or Lollipop and above.
I am targeting mobile using FlashBuilder, I am using TileLayout to view items of data, I am setting useVirtualLayout to "true"
I have some questions please:
Is item renderer resued by default? or shall I set it to true my self?
How can I control the range of items being virtualized?
Is there any tips on boosting performance of building child items of TileLayout ?
If native TileLayout is slow, is there alternative control to use? if building my own would be better, is there any example to build custom layout?
It is set to true by default. There are a few instances where they are not virtualized, however. If you have the list sizing to fit its contents, I don't believe virtualization occurs. If I am not mistaken, virtualization only occurs when an ItemRenderer leaves the viewport of the parent List control. So if you have a list on a page and that page is controlling the scrolling and not the list, I don't believe virutalization occurs. That is what I have seen in the past. Not sure if that is how it actually works, but that is the impression I have gotten. Easy way to find out is to throw a trace statement in your DataChange handler. If it traces out after initialization, you know virtualization is working
I'm not sure you can control this. You may be able to write a custom layout that does it, but that is likely more trouble than it is worth
The TileLayout itself is likely not the issue you are having, it is the ItemRenderer.
On mobile, do not extend any ItemRenderer class except LabelItemRenderer and IconItemRenderer.
Do not write a renderer in MXML. Write in AS3.
Utilize the proper renderer life-cycle. This means you should do very little in your constructor. Maybe set a few properties, but do not instantiate any DisplayObject. Instead, override createChildren() and do it there. Override layoutContents() for positioning and sizing. Override drawBackground() for handling the background. I highly suggest reading this post from Flextras (you'll see him going by Reboog77 on SO) about writing mobile item renderers. https://www.flextras.com/blog/index.cfm/2011/6/24/Building-a-Mobile-ItemRenderer-in-Flex
Keep the renderers as simple as possible. If you can get away with drawing directly into the object using the Graphics class, do that instead of using a Rect or similar.
Text is slow to render. Do not change it often and keep the text seen in the renderer to a minimum
Use ContentCache for any images outside of the iconDisplay in IconItemRenderer. ContentCache will negate the need for reloading images every single time.(iconDisplay/icon already utilizes this by default)
I am new to Android programming, and I need some advice. I want to create an app that teaches children the alphabet and numbers. I want each letter to have their own screen which you can scroll to and from other letters, but each screen will be similar in that it will have the current letter, pictures of objects that start with that letter, and sounds corresponding with the letter and the objects in the background. Should I make one XML layout for these and somehow changed what letter and objects show up in on the layout using Java, make an XML layout per letter, or is there a way to create a base layout in Java and have all of the letters and numbers inherit these qualities and methods. If that is the case, would that require a Java class per letter as well? I am sorry if these seem like stupid questions, but most of my education in Android has come from internet video tutorials. I appreciate any and all help. Thank you for your help in advance!
v> I want each letter to have their own screen which you can scroll to and from other letters, but each screen will be similar
You probably want to check out ViewPager and Fragments for this.
This website usually seems to have pretty good tutorials. The docs and SO usually have good examples of getting started also.
Note These both require API >= 11 or using a compatibility package which you can find a tutorial Here. so that may be something to take into consideration. If that is an issue then you could simply have one layout with TextView, ImageView, etc... which retrieves its data from a DB and load them when a certain event happens such as a click.
Well, if you want a screen for each of the letters that you could swipe to, but each letter is going to have its own set of properties, I recommend you start looking for a ViewPager with custom Fragments. I think that is a good start. Then, you could focus on some other fancy features like sound.
I just started my work as an Android developer. My first assignment is to fix several bugs of an App call DailyFinance.
One bug is UI related, if you click a button on a certain page, a dialog will pop up, but the dialog is not displayed properly. My question is how can I locate the code (xml layout file as well as activities) related to the dialog quickly in the codebase which I am not familiar with?
Couple approaches come in mind:
Search for any text that displayed on the target dialog.
Search button text and locate the xml layout file that that contains the button which launch the target dialog
Once find the xml layout file, determine the button 'id' as xxxxx, then you can further search for source contains references to 'R.id.xxxxx'
Set breakpoints on methods in files that implement the dialog. So maybe search for dialog and then put breakpoints inside the dialog. See it it gets hit when your dialog gets pulled up. Or just see where the layouts are set in files that have the word dialog in them. look for R.layout.someLayoutName.
One other suggestion is for some difficult layouts where its tough to see whats going on you can use the HierachyViewer to see the runtime view layouts: http://developer.android.com/tools/help/hierarchy-viewer.html Its worth running on your app to see the structure of the layouts at runtime which is often hard to see these relationships in the layout files before they have been inflated.
BTW, I was a student of CS and the biggest mistake I ever made was not to learn the debugger inside and out. Its without a doubt the most powerful ally you have to learn as well as fix bugs. If you think about it, code really is only an abstraction until you see it running inside the debugger.