So I have tried with pure XML files and also by using the onEvent options in the Java files. Both fails to do what I want.
What I need is to add onPressed events to View objects in order to change the background depending on the state. It does work, or at least it is changing the background. However in all the applications I have seen for Android, there is some kind of delay on the Views onPressed state, so in case the user presses the screen and start scrolling, the background does not change. In my case however they always do. So I get this annoying blinking of the View objects every time I attempt to scroll.
How do I go about this to make the onPressed work correctly?
Related
I would like to modify every Button's property, but I can't target them all. I can target only one at a time. I tried to use the Any Component menu's Any Button block, but still, I can target only one Button. I can't perform modifications manually (block by block), because I'm working with many buttons (254, to be exact). I tried putting every Button in a list, but dragging 254 blocks (one-by-one) takes too much time. Any solutions?
One good way to effectively change several properties of components ( of the same type. i.e Buttons), is to use a for-each loop then incorporating it with the any-button.property.
To use a for-each loop, you must first populate a list of components, however, buttons cannot be directly added to lists (structure limitations..), but fret not! there is a way to bypass this, which is to first create an empty list, named buttonsList (or whatever you like, labeled clearly), then to populate the list at screen initialization, with all buttons (to automate the process, this must be done manually at least once
After populating the list with all buttons, you'll then be able to change all properties using the for each loop.
initiate global-buttonsList : create empty list;
when screen1.initialize
do add item to 'buttonsList'
add all buttons here
Button1
Button2
Button#...etc.
At trigger event
for each - 'buttons/component name' in - Global 'buttonsList'
set anyButton.property (e.g, text?)
of component - 'buttons/component name'
to - "property change"
(i.e: text- Hello World!)
This should get the job done. Nevertheless, like #Taifun mentioned...that's a lot of buttons, and if there's one thing appInventor is really good at, it's crashing, so restructuring of the app would be great if possible.
Just change the "Horizontal Arrangements" with your buttons (sorry only manually)
then change "Any-component" with the property for the button (color,text-color...)
and target them with the numbers from the Loop (for each number)
The buttons in my app immediately display their state_pressed drawable when I tap them quickly, but only after about 300ms when I touch and hold them. I'm using a drawerlayout, and have noticed the same behavior in other apps with the drawerlayout. Other apps, eg, the calculator, display their state_pressed drawable immediately. Where is this determined?
I suspect it has to do with detecting longclicks or flings, possibly to enable opening the navigation drawer.
I'm only interested in increasing the responsiveness of the visual feedback when touching and holding a button, not its function. So it seems like the simplest solution might be to somehow manually display the drawable immediately, even though the system is still waiting to see what kind of gesture it is.
Thanks!
(Edit) Figured it out:
public boolean shouldDelayChildPressedState ()
Added in API level 14
Return true if the pressed state should be delayed for children or descendants of this ViewGroup. Generally, this should be done for containers that can scroll, such as a List. This prevents the pressed state from appearing when the user is actually trying to scroll the content. The default implementation returns true for compatibility reasons. Subclasses that do not scroll should generally override this method and return false.
Background
There are some nice apps out there that show some layout on top , while the user is making a call or answering one (like "current caller id").
I need to create an app with the ability to show something on top , during a call, and allow it to be interactive.
The problem
Using broadcastReceiver ,foreground service and SYSTEM_ALERT permission, I've succeeded showing something on the screen during calls.
As long as the content being shown is static, I have no problems.
However, I've noticed that when I try to make the content being shown to be interactive , I face some problems:
Everything is jumpy and this includes not only animations, but also setting visibility to visible/gone. I hate to think how it would work like when I need to make things draggable.
Not sure if this is the reason, but using the SlidingDrawer make the entire width belong to the SlidingDrawer and you cannot click through it. This means that if its location is at the bottom, you can't touch the "answer" button when someone calls you.
The question
What is the reason for those problems?
How can I fix them and be able to show things right?
How do other apps handle it right ?
EDIT: about the SlidingDrawer , it seems that it has terrible bugs about its location and size, and the content area, even when it's not shown to the user and the user can see through, it cannot be touched through. Still, I don't know why, and how to fix it, and I also don't know why things are so jumpy compared to normal apps (probably because of over-drawing, but it's really really slow).
Maybe this question should be more general: how to make a floating window like on AirCalc, that can be moved easily yet still be quite fast.
For the dragging functionality, I've tried to get the layoutParams of the root view (which is of type WindowManager.LayoutParams ) that I show, update it and set it again, but for some reason it didn't do anything. Wonder what I'm doing wrong.
EDIT: it seems that i should be using windowManager.updateViewLayout for updating the layoutParams. Using this post , I've made it perfectly draggable.
Ok, I've come up to some conclusions about this, first to answer my original questions:
it's probably because of overdraw and the views i've used. I wanted to try out libraries that could replace the slidingDrawer , but each had a different problem. using simple views proved that the idea in general works.
in the case of visibility changes, it was jumpy because the size of the view wasn't able to fit using the current WindowManager.LayoutParams size.
slidingDrawaer does have issues since it uses the whole size it get when closed or opened.
now to the rest of the issues :
unable to drag ? instead of the regular setLayoutParams , use windowManager.updateViewLayout .
unable to touch outside of the view ? set its minimal size according to your needs. you can also set the window flags so that touch event would go through .
want to listen to calls events ? you can use the broadcastReceiver for triggering the showing of the app, but I suspect that hanging the call might cause the intent be received later sometimes. I think you can use telephonyManager and listen to events there, using the service you run in the foreground (that i've created just to make sure the app won't close in the middle).
if anyone else has questions, i can help.
I'm writing an app using Titanium. I want to be able to automatically dismiss the keyboard anytime something outside of the text field is clicked. I have yet to find an elegant solution for this issue.
Couple things that I've thought about, but am still looking for a better solution:
Assign event listeners to basically everything else present in the view, and dismiss the keyboard (using textField.blur()). I want to avoid this since it results in a LOT of code just to dismiss the keyboard. Also, if I end up adding anything else to the view, I'll have to add a click listener to that object as well, so it's not very maintainable.
Create a large transparent view, and have it take up the entire screen. Place it directly beneath the text field and add to it one click listener on that which will dismiss the keyboard. This is a better solution than #1, but still isn't great because I've had a lot of trouble getting zIndexes to work properly. It's also inefficient for my purposes because I've got views with a specific width and height that encapsulate text fields. I've used these for the sake of code simplicity and I re-use them throughout my application.
I've tried adding a listener for the "blur" event for the text field but that doesn't seem to get fired appropriately.
That's about it. I'm sort of at a loss. The zIndexing also behaves strangely on the iPhone, and I haven't tried on Android yet. Also, as I mentioned above, many of the text fields I use are encapsulated within small views with set widths/heights-- so I think that will affect the functionality of Z-indexes.
So the root question is: What's the best way to dismiss a keyboard whenever anything outside the text field that's in focus is clicked?
If I'm correct the click event propagates through all views and windows therefore your #1 option could be modified to check for clicks on the bottom most layer (view or window), check for its source then decide what to do.
When system enters into TouchMode, I'd like to know which widget will lose focus. When system quits TouchMode, I'd also like to know which widget will get focus. Overriding onFocusChange() didn't satisfy me, since it couldn't tell TouchMode change, since it could happen in every mode, touch, trackball, key navigation, etc.
SDK said only one API View.isInTouchMode() there it is. So, is it possible to detect TouchMode change?
Long shot but you probably need to maintain states manually. So you keep a a flag , lets say isTouchMode which you can set every time any of the widgets are touched and unset when something gets focus.
Use ViewTreeObserver.addOnTouchModeChangeListener(). It will tell you when the mode changes.
http://developer.android.com/reference/android/view/ViewTreeObserver.html