This question is referring to Codename One only.
Short story: I'm debugging a strange bug that occurs only in real devices but not in the Simulator. There is method that is called every second in a particular circumstance, so I suspected a timer. But which timer? To investigate who is calling this method:
I enabled setEnableAsyncStackTraces(true) (https://www.codenameone.com/blog/better-error-logging.html)
I inserted this exception in the method: throw new IllegalStateException("Who Is Calling me?");
After that, I discovered which timer is calling my method. However, this way to debug is not always praticable, because it forces me to insert an exception that crashes the app.
Do you have a suggestion? Do you think that a new API like Log.printAsyncStackTrace() can be useful in these cases?
Thank you
You can use something like this:
try {
throw new RuntimeException("This is the caller");
} catch(RuntimeException e) {
Log.e(e);
Log.sendLogAsync();
}
It's not as efficient as it should be but a log won't be much more efficient and might be abused by developers. At least this looks bad enough so developers know not to leave it in production.
Related
Are ConnectionRequest methods named pause() and resume() really implemented?
Looking at the sources, I imagined that they are "fake", in the sense they actually do nothing, except setting an internal flag:
https://github.com/codenameone/CodenameOne/blob/master/CodenameOne/src/com/codename1/io/ConnectionRequest.java
So, my question is if Codename One offers any way to pause and then resume a large download (for example 10MB or 100MB, that could be the size of a video). My idea is to pause the download when the app goes to background and then resume it when the app returns to foreground, without re-downloading the already downloaded data: this could circumvent the issue described in my previous question: How to improve the behavior of ConnectionRequest?
Thank you
It looks like they are implemented but notice you need to override isPausable() to return true which currently no ConnectionRequest does.
It might make sense to add a setDefaultPausable(boolean) method to ConnectionRequest to make this usage easier and more universal e.g. with the Rest API.
I am working on a CoProcessFunction that uses a third party library for detecting certain patterns of events based on some rules. So, in the end, the ProcessElement1 method is basically forwarding the events to this library and registering a callback so that, when a match is detected, the CoProcessFunction can emit an output event. For achieving this, the callback relies on a reference to the out: Collector[T] parameter in ProcessElement1.
Having said that, I am not sure whether this use case is well-supported by Flink, since:
There might be multiple threads spanned by the third party library (let's say I have not any control over the amount of threads spanned, this is decided by the library)
I am not sure whether out might be recreated or something by Flink at some point, invalidating the references in the callbacks, making them crash
So far I have not observed any issues, but I have just run my program in the small. It would be great to hear from the experts whether my approach is correct and how could this be approached otherwise.
As an update based on Arvid's comments. Since my current process function already works well for me, except for the fact I don't have access to the mailbox executor, I have simply created a custom operator for injecting that:
class MyOperator(myFunction: MyFunction)
extends KeyedCoProcessOperator(myFunction)
{
private lazy val mailboxExecutor = getContainingTask
.getMailboxExecutorFactory
.createExecutor(getOperatorConfig.getChainIndex)
override def open(): Unit = {
super.open()
userFunction.asInstanceOf[MyFunction].mailboxExecutor = mailboxExecutor
}
}
This way I can register callbacks that will send mails to be processed one by one. In the main application I use it like this:
.transform("wrapping function in operator", new MyOperator(new MyFunction()))
So far everything looks good to me, but if you see problems or know a better way, it would be great to hear your thoughts on this again. In particular, the way of getting access to the mailbox executor is definitively a bit clumsy...
If you have asynchronous callbacks, you really should use asyncIO. So use your CoProcessFunction to emit a Tuple2 and have a asyncIO directly following it.
Op now added that he may not get a result back at all which makes asyncIO difficult to use. You could rely on the timeout to trigger such that the element gets removed but that may slow down processing as asyncIO has a limited queue of "active" elements.
So, the way to go in Flink 1.10 would probably to implement a custom operator using the MailboxExecutor.
Getting the executor is still a bit clumsy, but you could check AsyncWaitOperator and the AsyncWaitOperatorFactory.
Code sketch for using executor
// setup is optionally but if you use timestamped records, you usually do that
void setup(StreamTask<?, ?> containingTask, StreamConfig config, Output<StreamRecord<OUT>> output) {
super.setup(containingTask, config, output);
this.timestampedCollector = new TimestampedCollector<>(output);
}
void processElement(record) {
externalLib.addElement(record, (match) -> {
mailboxExecutor.execute(() -> {
timestampedCollector.collect(match);
});
});
}
Note that this involves quite a bit #PublicEvolving code and we already have some changes on our agenda. So be prepared to adjust code for 1.11.
Within a Codename1 app, I'm getting a CrashReport: java.lang.NullPointException: Attempt to invoke virtual method 'void android.graphics.Point.setAntiAlias(boolean)' on a null object reference. This seems to occur after I invoke a "show()" on the main form of my application.
Note that the code runs fine in the simulator, but consistently gets this error prior to doing the "show()" on Android.
Interestingly, if I put a Dialog like this:
Dialog.show("Wait a sec", "Showing interrupt point", "OK", null);
before the .show(), and then click "OK", then everything runs well with no exceptions at all.
But a sleep(5000) instead of the Dialog does not help - still get the exception. So it at least seems like its not a race condition.
I have try-catches wrapped around all of the potentially offending code, and have NOT been able to isolate this. It always gets caught by the CrashReport, and only when running on the Android device.
Any ideas?
The symptoms to this one are pretty strange (i.e. workaround with a Dialog), and it would be interesting to have an explanation. However, since deprecated cn1 (Map) code has seemingly been implicated, I'm going to let this one go and replace this code with the latest Google native maps code. If it recurs, I will post another question then.
I am trying to run a simple test on multiple browsers, here is a mock up of the code I've got:
String url = "http://www.anyURL.com";
WebDriver[] drivers = { new FireFoxDriver(), new InternetExplorerDriver,
newChromDriver() };
#Test
public void testTitle() {
for (int i = 0; i < drivers.length; i++) {
// navigate to the desired url
drivers[i].get(url);
// assert that the page title starts with foo
assertTrue(drivers[i].getTitle().startsWith("foo"));
// close current browser session
drivers[i].quit();
}// end for
}// end test
For some reason this code is opening multiple browsers seemingly before the first iteration of loop is completed.
What is actually happening here? and what is a good/better way to do this?
Please understand that I am by no means a professional programmer, and I am also brand new to using Selenium, so if what I am attempting is generally bad practice please let me know, but please don't be rude about it. I will respect your opinion much more if you are respectful in your answers.
No it's not.
In fact, most of the test frameworks have convenient ways to handle sequential/parallel executions of test. You can parametrize test class to run the same tests on multiple browsers. There is an attribute in TestNG called Parameters which can be used with setting.xml for cross browser testing without duplicating the code. An example shown here
I would no do that.
Most of the time it is pointless to immediately run your test against multiple browsers. Most of the problems you run into as you are developing new code or changing old code is not due to browser incompatibilities. Sure, these happens, but most of the time a test will fail because, well, your logic is wrong, and it will not just fail on one browser but on all of them. What do you gain from getting told X times rather than just once that your code is buggy? You've just wasted your time. I typically get the code working on Chrome and then run it against the other browsers.
(By the way, I run my tests against about 10 different combinations of OS, browser and browser version. 3 combinations is definitely not good enough for good coverage. IE 11 does not behave the same as IE 10, for instance. I know from experience.)
Moreover, the interleaving of tests from multiple browsers just seems generally confusing to me. I like one test report to cover only one configuration (OS, browser, browser version) so that I know if there are any problems exactly which configuration is problematic without having to untangle what failed on which browser.
I discovered by experimenting that creating a timer with a duration of 0 allows me to defer work into the event queue. I really like this feature, because it allows avoiding a lot of nasty reentrancy issues. Is this intentional functionality that will not change? Can it be added to the documentation? If not, is there a supported way to do this?
Current Answer
The proper way to do this is with scheduleMicrotask(Function callback).
See the API documentation here: https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-async#id_scheduleMicrotask
A great article on async tasks and the event loop is here: https://www.dartlang.org/articles/event-loop/
Old Answer (pre Dart 1.0)
For now, the answer is yes, new Timer(0, callback) is the easiest way to defer a function call.
Soon, hopefully, http://dartbug.com/5691 will be fixed and there will be a better way. The problem with Timer is that the HTML spec says that the callback should happen no sooner than 4ms later. Depending on what you're doing that can be on issue.
Microsoft introduced setImmediate() to solve this. It invokes the callback at the beginning of the next event loop, after any redraws. My preferred solution in Dart is to have Future.immediate() defer until the next event loop, and possibly a function like defer() that takes a callback.
But new Timer(0, f) will still work, even after a better solution is available. I wouldn't mind a lint warning for it though.