My app written with Codename One involves showing a camera preview In a main form. I have used the native interface implementation to make it work on Android (iOS later).
The app also includes in app purchase to upgrade to full version. That's why a form is shown regularly to suggest the user to upgrade. They can also choose to upgrade later which causes this upgrade to full version form to disappear and make the main form with the camera preview to appear.
Yet on real devices sometimes the upgrade to full version form does not completely disappears and there are reminiscences of it on the main form. In that case the camera preview is displayed on part of the screen and the app buttons do not show. However after some seconds if the user touch the screen the main form gets completely shown and the reminiscence of upgrade form are gone.
It looks like there may be too much things done on the UI thread but I am just calling new MainForm(theme).show() when the user hits the button to close the upgrade form. So this should be OK shouldn't it? Please note that the CN1 simulator does not show edt violation (but there is no camera preview in the simulator).
Or do I have to call revalidate () in the MainForm after adding the components into the layout ? What should I do actually to make these reminiscences disappear ?
Any help really appreciated,
These things are always hard to track but I'm guessing the peer component collides in some way with the new form.
Make sure you don't call postInvalidate unless you really have to and even then you should generally limit and avoid it when possible as it might conflict with our drawing logic.
Also make sure you didn't change the opacity of the parent forms e.g. if you changed the form UIID.
It looks like the solution has been found. Indeed I had a native method that initialized the camera and the surfaceview. I was running this method on the EDT and then showing the new MainForm.
Indeed I embraced the initialization method in an invokeAndBlock() block. Now it looks like the kind of lag is far less visible (I could not see it). In my own logic I can explain it with the fact that the invokeAndBlock() will do the initialization job on a separate thread and when it's fully ready (so the camera and surfaceview are ready to be shown), the MainForm can be shown.
Could it be the actual solution #Shai ?
Related
I am trying to add DnD support for touch enabled devices for react-ui-tree and it seems to be behaving weirdly. While dragging seems to start with touchmove event and stops abruptly. But if you pickup from the same position and move, then things seem to work. Here is the GIF file just to show that.
Observations so far:
Seems react is somehow not happy with tree being modified with
tree.move() inside drag() method.
Seems react is somehow not happy with setState().
When drag starts and suddenly stops, we see the page scrolls so guessing the event has stopped midway by
react but not sure.
All my changes are in this repo https://github.com/venugopalkathavate/react-ui-tree.git if you want to check. NOTE this can be reproduced with Chrome dev tools.
Problem
I call setState to add a new recipe to my recipe list
The recipe is a new panel in a Foundation accordion
The accordion title pops up immediately
There is no functionality until page refresh
I have tried everything i can think of including Foundation's reInit, their manual toggle, up, and down methods for accordions, and re constructing the whole accordion
nothing works
This is the solution I came up with.
i was able to call $("#element").foundation("toggle",$target,true) from the console and programmatically open and shut the accordion tab.
element is the accordion wrapper and target the specific tab, true is a param to indicate reflow needed
implementing that function into my app was more trouble than it was worth, for a number of reasons.
i ended up just calling location.reload() and which essentially is like pressing the refresh button. with a modal animation running at the same time it is barely noticeable
so when all else fails manual over-ride could be a viable solution depending on what your individual page is
There is a real answer
in my research i came across quite a few similar github issues that had to do with Foundation plus some sort of dynamic rendering and/or third party framework/library. every situation is a bit different so there isn't one answer
if someone has specific knowledge of what why Foundation or React(possibly), wouldn't let me reInit,reflow,$(document).foundation or do any of the various supposed solutions: I would love to know.
perhaps I could have done something different but if you look at my code I keep state to one component, I init my js plugins in componentDidMount - as far as i know this is what i am supposed to do. thanks
I had my app working just fine a few days ago and then I noticed the first problem. I had to tap twice in order to make a button go to the next screen. Also happened to the checkBoxes. Had to tap twice to make them change.
But now it got serious. Since yesterday when I tap on a TextField the app freezes and then crashes.
The only significant changes I remember I did were 2: I uploaded an image for the App Icon and I edited the TitleArea UIID. I removed the TOP and BOTTOM margins. It also affected some of my label and button UIID, because now they don't show on the device
When I run the simulator, the doble tap also occurs, but the TextFields work fine and the Button and Label UIID look the way they should.
Any ideas why this happens?
I am right now working with old versions to try to determine the reason, but no luck so far. Thanks
Use a solid color rather than a gradient with the same colors. Gradients are slow and problematic across platforms so you are paying a lot for something that you aren't even using.
We'll need a better test case to reproduce crashing, I think that what you initially saw when you submitted the issue was a regression in the text input that we since resolved in the build servers.
I have an application that manipulates with some files in certain matter and have progressbar and textbox. When I debug (VS2010), the app window is not visible, but the app does all the work that it suppose to. If I wanted to create invisible winform application I would probably have to bust my brains out to do so. Now I have one I don't want. How about that? Any ideas how to fix this?
The OP is performing work in the form's initialization phase. During that phase, the form is not yet shown and will not be shown untill all the work is done.
The solution is to move the work code from the form's initialize method to a separate method, that is called only after the form is shown. This method should perform the work on a separate thread to ensure the GUI stays repsonsive, the process can be cancelled and reports back to update the progress bar.
I have a certain UI element, which when clicked should navigate to another URL.
I tried handling the mouse down event and execute something like this:
System.Windows.Browser.HtmlPage.Window.Navigate(new Uri("http://google.com"), "_blank");
However, this gets blocked by the browser (I tried both Chrome and Firefox) unless I disable the popup blocker.
I did some research and it seems that the browser blocks navigations that don't occur as a result of user interaction and as far as the browser is concerned this navigation is initiated by a plugin (Silverlight), not a user.
OK, makes sense. But then I tried using a HyperlinkButton instead and it was NOT blocked.
I wonder why these two approaches get different treatment from the browser. Any idea?
I actually worked around the problem by wrapping the navigation triggering UI with a HyperLinkButton, but I'm still very curious...
I'm going to pull a fancy corporate quote and say "It is a feature, not a bug."
The Silverlight team is obviously worried about Security. They don't want crazy haxorz like you and I to do crazy things with our apps--you know, like popping up a bunch of browser windows all routing people to Zombo.com. Just imagine the choir! Zombo!
Summarized from their documentation: They want us to only use the HyperlinkButton to go outside of their application. In fact, they went the extra step, and depending on our settings, they will even throw a SecurityException for us if we navigate to an outside page--Even from a HyperlinkButton. How nice.
The real question: Why the Hyperlink Button and not something else?
Only one "thing" can navigate. this take saves time for Microsoft while testing Silverlight. This one thing can navigate to both internal XAML pages and external web pages--Might as well be consistent and have only one way to do navigation.
It is a UIElement. It's code behind likes to run in the primary visual thread. It can promise the browser that a Visual Element wants to go somewhere. Microsoft can also put its limiting logic in a control that requires a mouse-click/keyboard-input event tree.
All in all, it makes sense to start simple by making a control do the work.
Fun stuff! Hope this helps you.