I am having an issue with a small blackberry application where touch events are being processed by 1 of 2 certain fields that has focus.
In my case, I have 2 images, one at the top (first element on the screen) and at the bottom (last element added to the screen. Both are subclasses of the BitmapField. Their purpose is to display a web site when the user taps (clicks with the trackpad/ball).
The issue is when either of these has focus, no matter where the user taps on the screen (i.e. in an EditField, another custom button, or just a part of the background), the BitmapField that has focus consumes the event calls the web browser. This obviously only an issue on the BB Torch simulator, and I building for BB OS 5.0.
I have the BitmapField consuming both navigation clicks and touch events.
Also, any direction on where to get a good (as in not written by RIM) event handling guide for the Blackberry API would be helpful.
UPDATE:
I have tried:
public boolean isFocusable() {
return false;
}
But, ideally I would like this to work on devices such as the Curve and Bold.
UPDATE 2:
There a couple of LabelFields inside layout managers that can receive focus, but they do not cause this issue, it only happens when the BitmapFields have focus.
I'd suggest to create a custom image button field by subclassing from Field. Override paint(Graphics graphics) to draw image and focused border (or background). Then just override navigationClick(int status, int time). The BB UI framework will call that method when user clicks your field on a touch screen. As well it'll work for a non-touch screen devices. As a great benefit - you will not need to bother yourself with TouchEvents at all.
Make sure that on the touchEvent() you are checking the location of the touch. If it is outside of your BitmapField's extent, you should be returning super.touchEvent(message). Regardless of where the touch is, when a field has focus it is sent to it first to determine if it should be handling it at all.
Related
I have a Xamarin.Forms application with a login screen. I have added code to move the controls out of the way, when one of the Entry fields gets focus. I move the views back down in the Unfocus event handlers. In the simulator I can prevent the software keyboard from popping up. Unfortunately my event handlers still move the view up and down even without the keyboard.
Is there a way to detect the keyboard's appearance in Xamarin.Forms, while in the event handlers on the ContentPage?
I don't think there is support for this out of the box and thus I'd go with DependencyService and implement it by myself.
You could use ContentPage.LayoutChanged event.
It works because the keyboard doesn't display over the content page as one would guess, but under it, in the same layer, so it push the page up.
In android, there is a function call Toast and it show instantly without involve in time. I tried to use Status in RIM but it must run in the invokeLater and cannot set the time less than 1 second. So it cannot display instantly.
Any other built in that same with Toast or Status?
No there is not afaik. Toast was "invented" in a way by Android.
Previous OS's have used popup boxes with confirmation buttons. A Toast is almost like a popup box with a timer attached to it.
Of course, #Signare gives the common replacement correctly for what you would "normally" do on BlackBerry. Dialog.alert(String)
If you want something more "Androidy", this is something we want to implement at Cobi, but have not gotten around to yet due to time constraints working on client work.
There are 2 unique aspects to a Toast compared to the "old" way of doing things:
the popup only shows for a short time
the popup does not block the user from interacting with the background screen at all
To create the popup screen, look at the PopupScreen class - and you pass in a layout manager of your own that will be displayed.
You could start a timer when the screen is shown (we have not implemented this yet) and that could close the screen for you.
As far as not blocking the user - this is the major difference - and I do not know if it can be done if you use the PopupScreen class. Perhaps if your PopupScreen passes all keypresses through to the underlying screen, this may be possible.
In some of our apps, we have a custom field, defined in our base MainScreen subclass, that can be positioned over the rest of the fields on the screen. This allows the user to continue interacting with the screen while the field is displayed. I cannot share that code at the moment here.
Context: Web app on MobileSafari/iPad, both full-screen and embedded in iframe
Goal: Technique that provides custom event handlers for Press and Tap but not Pinch (zoom) or Drag (scroll/pan). We want to provide custom behavior for Press, but to let Safari handle Scroll/Pan/Zoom still.
Problem: The two goals seem to be mutually exclusive. To prevent the default behavior for a Press gesture, event.preventDefault must be called in immediate response to ontouchstart. However, to let the default behavior proceed on a Drag, we must not call event.preventDefault on the initial ontouchstart. Once preventDefault is called, there is no way of getting the default behavior back during that gesture sequence (i.e. until all fingers come off). Drag is not recognized until some movement has occurred.
Drag is illustrated as the simplest example, but we care about getting the default behavior for Pinch and Double-tap as well. We never want the default MobileSafari Press behavior of "Copy Image" or selecting text.
Attempts thus far:
Save the ontouchstart event and, after a timeout, call preventDefault on it later (just before Press would be recognized). No effect.
Listen for 'oncontextmenu'. Nope, the default Press behavior is not being signaled or routed through this event.
Prevent the default in all of our ontouch* handlers, and then when we recognize a Drag/Pinch gesture, simulate new events using initTouchEvent and/or initGestureEvent. The programmatically created events hit all of our callbacks, but Safari seems to pay no attention to them, triggering no default behavior.
Break up Safari's Press recognition with a fake move. Safari cancels a press on the slightest move, but we allow for a bit of slop. Simulating a move event (as above) just after the ontouchstart does not cause Safari to fail to recognize Press if the finger is not moved "for real".
We have a fully featured set of gesture recognizers implemented (in Javascript, ontouch*) in the style of Apple's native iOS gesture recognizers. We have no problem recognizing any gestures, we just don't know of a good way to replicate the Zoom/Pan/Double-tap behavior that Safari provides for free.
We don't need code; we're looking for any theoretical solution (beyond "just implement pan/zoom yourself too", though if you have a slick way of doing that we're interested) that leads to reasonable success. We're also interested in learning about other similar attempts to do this - surely we can't have been the first to try this?
Alternate TL;DR: Is there any way to prevent a default Press (also known as tap-and-hold) other than in touchstart?
Success: Prevent "default press" behavior entirely through CSS instead of preventDefault. This answer was provided by Safari Technologies Evangelist Vicki Murley over here (registration required)
I see in your stackoverflow post that
you say your ultimate goal is that:
"We never want the default
MobileSafari Press behavior of "Copy
Image" or selecting text."
These behaviors can be disabled in CSS
(+ one bonus property, since people
often want to turn off the highlight
if they're turning off these other
behaviors):
/* behavior */
-webkit-user-select: none; /* disable cut copy paste */
-webkit-touch-callout: none; /* disable callout, image save panel */
-webkit-tap-highlight-color: transparent; /* "turn off" link highlight */
Commentary: We assumed that Safari's Press behavior was event-based, not driven by CSS. Calling preventDefault ontouchstart does cancel the press behavior (which is what led us astray, really), but that seems to be an unintended side-effect. Really, Mobile Safari does not execute a "press event" so much as "CSS on press".
Disabling the Press behavior with CSS has allowed us to once again call preventDefault only where and when we actually need it.
Ugly Possibility: Don't prevent a press - make a default press do nothing. Try to use a glass-pane div that catches all touches and doesn't prevent anything on touchstart.
Divs do have default Press behavior (some kind of selection), but perhaps that can be turned off, not via preventDevault but via <body style="-webkit-user-select:none">? ref
This would mean we'd have to do our own hit-testing to determine what DOM nodes to pass our recognized events to, since we can't just let events bubble up the DOM ancestor chain.
I have to do a clean up of some app generated files, when the application is completely closed. The close can happen from any screen. Which method or where should i override globally to caputure Menu Close event, rather than overriding onClose() on each screen of the application ?
And when the application is closed using Menu Close in the middle of the application, is onClose() called for each screen on the stack and are popped off the stack, or it just removes the application from memory ?
I don't believe there's a method that does exactly what you want but I think you can get the behavior you want. First off, based on the testing I've done the close menu item simply calls onClose() for the current screen. The default close menu item does not close the entire application, it just closes one screen.
The closest method I can think of is deactivate(), this is called when the app is sent to the background but not when it's actually closed (i.e. this method will be called if you press the red "end call" button but not if you press close in the menu). This would probably be overkill but what you could do is select "Auto-run on startup" and "Do not display the application icon on the BlackBerry home screen" in your BlackBerry App Descriptor. This would make the app invisible to the user so that it's always in the background, to have an icon on the homescreen and display a GUI you would create an alternate entry point that will bring up the UI. Then when the user selects the close menu item all it's really doing is sending the application to the background and you can put your cleanup code in deactivate().
A much better approach would be to just override onClose() in a parent class and then just make all of your screens inherit from that class. You can put your cleanup code in there. Or if you want the close menu item to close all screens override the makeMenu() method and add a MenuItem that will execute the appropriate cleanup code before calling System.exit().
In my app, I just have all the screens inherit from a common parent class. In that parent class, I implement my standard exit handling.
The correct place to put code that runs when a screen is popped is Screen.onUiEngineAttached(boolean). That method gets called when a screen is actually pushed or popped from the display stack. The other methods are only relevant if you are overriding the behavior of menu items or dirty screen handling.
Another option would be to have a single listener object that handles all this behavior, and use Screen.addScreenUiEngineAttachedListener() to subscribe it to all screens before pushing them on the display stack.
I'm having some difficulty showing the virtual keyboard I want for the Blackberry Storm. I have an option to toggle the keyboard's visibility on a certain screen. Whenever the user types a number, it's handled by the screen, rather than any particular field (there are no textfields on this screen). This much works fine. I can show and hide the keyboard when the user chooses to.
My question is this: How do I make the keyboard that shows up the same as what would appear had the focus been on a BasicEditField with a numeric filter applied, without using a BasicEditField for the input?
I don't think BlackBerry has exposed any APIs to allow for programmatic control over the type of virtual keyboard that is shown. I seem to remember reading about it in the BB forums (although unfortunately I can't find it now).
One thing you could try doing is using a BasicEditField with a numeric field, but place it offscreen so that it isn't visible. When you want to capture numeric input from the user, put focus on that element. I haven't tried this, it's just a thought.