The document discusses Codename One's threading model and the Event Dispatch Thread (EDT). It explains that the EDT hides the native main thread across platforms to provide a consistent threading model. It describes three key methods: callSerially runs code on the next EDT cycle; callSeriallyAndWait blocks until the serial call completes; and invokeAndBlock stops the EDT and runs code in a new thread, restoring the EDT when complete. Developers are advised to minimize blocking the EDT and use these methods appropriately to maintain responsiveness while performing intensive operations.

1. Threading & the EDT

2. Threading & the EDT
✦Threading is a difficult subject, even experts can
miss some of the nuance
✦It’s a powerful and crucial tool in building
performant apps
✦Codename One has some unique functionality
related to threading both above and below the
surface

3. Event Dispatch Thread (EDT)
✦All major OS’s use a single thread to access UI
features
✦That thread is the OS Native Main Thread
✦The EDT hides the existence of that thread
✦This increases portability - OS threads behave
very differently
✦This allows features that don’t exist in the target
platform (e.g. invokeAndBlock)

4. What’s the EDT?
While
Codename One Is
Running
Paint,
Handle events
& Animations
Sleep if
nothing else is
needed

5. Almost Everything is on the EDT
✦All paint methods, events and callable code happens
on the EDT
✦ConnectionRequest callbacks happen on the network
thread
✦invokeAndBlock uses it’s own thread
✦The browser component’s navigation listener exposes
the native OS thread (for a special reason)

6. Why only on the EDT?
✦Our code can make assumptions and avoid
expensive synchronized calls
✦This increases performance and allows us to utilize
threads in a more effective/consistent way

7. callSerially
© Codename One 2017 all rights reserved

8. callSerially
✦callSerially adds a runnable element to a list within the
EDT. The run() method will be invoked on the next
EDT loop cycle
public void callSerially(Runnable r){
if(codenameOneRunning) {
synchronized(lock) {
pendingSerialCalls.add(r);
lock.notifyAll();
}
} else {
r.run();
}
}

9. int size = pendingSerialCalls.size();
if(size > 0) {
Runnable[] array = null;
synchronized(lock) {
size = pendingSerialCalls.size();
array = new Runnable[size];
pendingSerialCalls.toArray(array);
if(size == pendingSerialCalls.size()) {
// this is faster
pendingSerialCalls.clear();
} else {
// this can occur if an element was added during the loop
for(int iter = 0 ; iter < size ; iter++) {
pendingSerialCalls.remove(0);
}
}
}
for(int iter = 0 ; iter < size ; iter++) {
array[iter].run();
}
// after finishing an event cycle there might be serial calls waiting to return
synchronized(lock){
lock.notify();
}
processSerialCalls

10. int size = pendingSerialCalls.size();
if(size > 0) {
Runnable[] array = null;
synchronized(lock) {
size = pendingSerialCalls.size();
array = new Runnable[size];
pendingSerialCalls.toArray(array);
if(size == pendingSerialCalls.size()) {
// this is faster
pendingSerialCalls.clear();
} else {
// this can occur if an element was added during the loop
for(int iter = 0 ; iter < size ; iter++) {
pendingSerialCalls.remove(0);
}
}
}
for(int iter = 0 ; iter < size ; iter++) {
array[iter].run();
}
// after finishing an event cycle there might be serial calls waiting to return
synchronized(lock){
lock.notify();
}
processSerialCalls
Array Copy
Copy all elements to an array
and remove them otherwise
invokeAndBlock from
within a callSerially() can
cause an infinite loop...

11. Usage
✦There are two use cases for callSerially
✦If you opened a thread (or were invoked from a
thread) and need to make changes to the UI
✦If you need to postpone an operation to the next cycle
of the EDT
new Thread() {
public void run() {
byte[] data = Util.readToByteArray();
Display.getInstance().callSerially(() -> updateUIWithData(data));
}
}.start();

12. callSeriallyAndWait
✦callSeriallyAndWait will block until the call serially
completes
public void callSeriallyAndWait(Runnable r){
if(isEdt()) {
throw new RuntimeException("This method MUST NOT be invoked on the EDT");
}
RunnableWrapper c = new RunnableWrapper(r, 0);
callSerially(c);
flushEdt();
synchronized(lock) {
while(!c.isDone()) {
try {
// poll doneness to prevent potential race conditions
lock.wait(50);
} catch(InterruptedException err) {}
}
}
}

13. Usage
✦It isn’t used as often but makes sense when you need
a result
new Thread() {
public void run() {
downloadFile();
Display.getInstance().callSeriallyAndWait(() -> promptUserForOverwrite());
if(userAgreed) {
overwriteFile();
} else {
createNewFile();
}
}
}.start();

14. invokeAndBlock
© Codename One 2017 all rights reserved

15. invokeAndBlock
✦This is probably one of the hardest concepts for
developers to grasp as most frameworks/OS’s don’t
have an equivalent of invokeAndBlock
✦It’s the exact opposite of callSeriallyAndWait
✦invokeAndBlock stops the EDT and winds it manually,
it then opens a new thread and restores the EDT
when that new thread completes
✦invokeAndBlock powers api’s like Dialog,
addToQueueAndWait etc.

16. Remember This?
While
Codename One Is
Running
Paint,
Handle events
& Animations
Sleep if
nothing else is
needed

17. This is invoke and block
While
Codename One Is
Running
Paint,
Handle events
& Animations
Sleep if
nothing else is
needed
invokeAndBlock
open new thread
Did the
thread finish
running?
No
Return from
method
Yes

18. // this class allows a runtime exception to propogate correctly out of the internal thread
RunnableWrapper w = new RunnableWrapper(r, 1);
RunnableWrapper.pushToThreadPool(w);
// loop over the EDT until the thread completes then return
while(!w.isDone() && codenameOneRunning) {
edtLoopImpl();
synchronized(lock){
if(shouldEDTSleep()) {
impl.edtIdle(true);
try {
lock.wait(10);
} catch (InterruptedException ex) {
}
impl.edtIdle(false);
}
}
}
// if the thread threw an exception we need to throw it onwards
if(w.getErr() != null) {
throw w.getErr();
}
invokeAndBlock Implementation

19. Usage
✦This code would execute on the EDT but allow you to
do intensive things in between
if(!Dialog.show("Do this?", "Are you sure", "Yes", "No")) {
return;
}
Display.getInstance().invokeAndBlock(() -> doLongRunningIOTask());
label.setText("We are nearly there...");
form.revalidate();
Display.getInstance().invokeAndBlock(() -> anotherLongRunningIOTask());
label.setText("Done!");
form.revalidate();

20. Guidelines
© Codename One 2017 all rights reserved

21. General Guidelines
✦Don’t block the EDT when possible
✦Opening another thread doesn’t necessarily fix the
problem see https://www.codenameone.com/blog/
performance-true-story.html
✦Intensive operations must yield to keep an app
responsive
✦Some operations (e.g. image manipulation) can work
off the EDT but not on all platforms (e.g. iOS)

22. Debugging
✦Use the EDT violation
detection tool
✦It can detect “false positives”
and can’t guarantee the
detection of every error but
it’s a good start

23. What did we learn?
✦Why we have the EDT
✦How we can rely on it and on the fact that our
code is single threaded inherently
✦The difference and importance of callSerially,
callSeriallyAndWait & invokeAndBlock
✦How to detect errors and what we should be
careful of

24. Thank You