Keeping output stream open
I wonder how to deal with OutputStreams in codenameone, which have to be kept open for a long time. There are many places, where they get written and it's be neither efficient nor error-proof to try to flush the stream everywhere. So I wrote this:
private boolean needsFlush;
private void write(byte data) throws IOException {
assert Display.getInstance().isEdt();
out.write(data);
if (!needsFlush) {
needsFlush = true;
Display.getInstance().callSerially(this::flush);
}
}
private void flush() {
try {
out.flush();
needsFlush = false;
} catch (final IOException e) {
throw new RuntimeException(e); // UGLY!
}
}
which should ensure that after every write, there'll be a flush sometime. Unless the app gets closed or alike.... that's why I need to ask.
- Is it OK? Is there's better way of handling stream flushing?
- Do they closed then properly, when the app gets terminated?
- Do I have to add stream closing code to
stop()of the "main" class? - Or only to
destroy()? - What about the ugly try-catch?
java io codenameone flush
asked Nov 12 '18 at 7:25
maaartinus
26.8k2193226
add a comment |
I wonder how to deal with OutputStreams in codenameone, which have to be kept open for a long time. There are many places, where they get written and it's be neither efficient nor error-proof to try to flush the stream everywhere. So I wrote this:
private boolean needsFlush;
private void write(byte data) throws IOException {
assert Display.getInstance().isEdt();
out.write(data);
if (!needsFlush) {
needsFlush = true;
Display.getInstance().callSerially(this::flush);
}
}
private void flush() {
try {
out.flush();
needsFlush = false;
} catch (final IOException e) {
throw new RuntimeException(e); // UGLY!
}
}
which should ensure that after every write, there'll be a flush sometime. Unless the app gets closed or alike.... that's why I need to ask.
- Is it OK? Is there's better way of handling stream flushing?
- Do they closed then properly, when the app gets terminated?
- Do I have to add stream closing code to
stop()of the "main" class? - Or only to
destroy()? - What about the ugly try-catch?
java io codenameone flush
asked Nov 12 '18 at 7:25
maaartinus
26.8k2193226
You only need to flush when you are about to read a response. If that doesn't answer your question it is unclear what you're asking.
– user207421
Nov 12 '18 at 9:32
@user207421 I don't need to read it until next start. So you think that not flushing the stream is safe? You may be right...., but do you have any evidence?
– maaartinus
Nov 12 '18 at 12:41
@user207421 On the second thought.... whileFileOutputStreammay need no flushing as it gets closed when program terminates, there's buffering in my streams and I can't rely on getting called when the app get closed/killed. Or can I?
– maaartinus
Nov 13 '18 at 3:40
add a comment |
I wonder how to deal with OutputStreams in codenameone, which have to be kept open for a long time. There are many places, where they get written and it's be neither efficient nor error-proof to try to flush the stream everywhere. So I wrote this:
private boolean needsFlush;
private void write(byte data) throws IOException {
assert Display.getInstance().isEdt();
out.write(data);
if (!needsFlush) {
needsFlush = true;
Display.getInstance().callSerially(this::flush);
}
}
private void flush() {
try {
out.flush();
needsFlush = false;
} catch (final IOException e) {
throw new RuntimeException(e); // UGLY!
}
}
which should ensure that after every write, there'll be a flush sometime. Unless the app gets closed or alike.... that's why I need to ask.
- Is it OK? Is there's better way of handling stream flushing?
- Do they closed then properly, when the app gets terminated?
- Do I have to add stream closing code to
stop()of the "main" class? - Or only to
destroy()? - What about the ugly try-catch?
java io codenameone flush
asked Nov 12 '18 at 7:25
maaartinus
26.8k2193226
I wonder how to deal with OutputStreams in codenameone, which have to be kept open for a long time. There are many places, where they get written and it's be neither efficient nor error-proof to try to flush the stream everywhere. So I wrote this:
private boolean needsFlush;
private void write(byte data) throws IOException {
assert Display.getInstance().isEdt();
out.write(data);
if (!needsFlush) {
needsFlush = true;
Display.getInstance().callSerially(this::flush);
}
}
private void flush() {
try {
out.flush();
needsFlush = false;
} catch (final IOException e) {
throw new RuntimeException(e); // UGLY!
}
}
which should ensure that after every write, there'll be a flush sometime. Unless the app gets closed or alike.... that's why I need to ask.
- Is it OK? Is there's better way of handling stream flushing?
- Do they closed then properly, when the app gets terminated?
- Do I have to add stream closing code to
stop()of the "main" class? - Or only to
destroy()? - What about the ugly try-catch?
java io codenameone flush
java io codenameone flush
asked Nov 12 '18 at 7:25
maaartinus
26.8k2193226
asked Nov 12 '18 at 7:25
maaartinus
26.8k2193226
asked Nov 12 '18 at 7:25
maaartinus
26.8k2193226
asked Nov 12 '18 at 7:25
maaartinus
26.8k2193226
asked Nov 12 '18 at 7:25
maaartinus
26.8k2193226
26.8k2193226
You only need to flush when you are about to read a response. If that doesn't answer your question it is unclear what you're asking.
– user207421
Nov 12 '18 at 9:32
@user207421 I don't need to read it until next start. So you think that not flushing the stream is safe? You may be right...., but do you have any evidence?
– maaartinus
Nov 12 '18 at 12:41
@user207421 On the second thought.... whileFileOutputStreammay need no flushing as it gets closed when program terminates, there's buffering in my streams and I can't rely on getting called when the app get closed/killed. Or can I?
– maaartinus
Nov 13 '18 at 3:40
add a comment |
You only need to flush when you are about to read a response. If that doesn't answer your question it is unclear what you're asking.
– user207421
Nov 12 '18 at 9:32
@user207421 I don't need to read it until next start. So you think that not flushing the stream is safe? You may be right...., but do you have any evidence?
– maaartinus
Nov 12 '18 at 12:41
@user207421 On the second thought.... whileFileOutputStreammay need no flushing as it gets closed when program terminates, there's buffering in my streams and I can't rely on getting called when the app get closed/killed. Or can I?
– maaartinus
Nov 13 '18 at 3:40
You only need to flush when you are about to read a response. If that doesn't answer your question it is unclear what you're asking.
– user207421
Nov 12 '18 at 9:32
You only need to flush when you are about to read a response. If that doesn't answer your question it is unclear what you're asking.
– user207421
Nov 12 '18 at 9:32
@user207421 I don't need to read it until next start. So you think that not flushing the stream is safe? You may be right...., but do you have any evidence?
– maaartinus
Nov 12 '18 at 12:41
@user207421 I don't need to read it until next start. So you think that not flushing the stream is safe? You may be right...., but do you have any evidence?
– maaartinus
Nov 12 '18 at 12:41
@user207421 On the second thought.... while
FileOutputStream may need no flushing as it gets closed when program terminates, there's buffering in my streams and I can't rely on getting called when the app get closed/killed. Or can I?– maaartinus
Nov 13 '18 at 3:40
@user207421 On the second thought.... while
FileOutputStream may need no flushing as it gets closed when program terminates, there's buffering in my streams and I can't rely on getting called when the app get closed/killed. Or can I?– maaartinus
Nov 13 '18 at 3:40
add a comment |
1 Answer
1
active
oldest
votes
I would suggest closing the output stream on stop() and re-opening it on start(). Notice that if the stream points to FileSystemStorage you can append to the end of the stream using CN's: OutputStream os = openFileOutputStream(filePath, lengthOfFile);.
You need to close on stop() as the app is sent to the background. In that state you should avoid open connections as they might be terminated suddenly by the OS. The entire app can be killed because of a wayward stream.
If you have background support in the app you should open and close the stream every time you need it.
answered Nov 13 '18 at 4:02
Shai Almog
39.9k52555
This sounds good, but opens two side questions: 1. Can I make the simulator invokestop()andstart()? 2. When my process gets killed, does the previousflushensure no data gets lost?
– maaartinus
Nov 13 '18 at 7:05
Another question: Are theFileSystemStoragestreams somehow buffered or should I add buffering myself?
– maaartinus
Nov 13 '18 at 8:31
1
Sure, suspend/resume in the simulator menu triggersstop()/start(). Flush writes to the disk so it gives a "good chance" but "guarantees" is a string word. All streams in Codename One are buffered by default.
– Shai Almog
Nov 14 '18 at 3:56
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53257524%2fkeeping-output-stream-open%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I would suggest closing the output stream on stop() and re-opening it on start(). Notice that if the stream points to FileSystemStorage you can append to the end of the stream using CN's: OutputStream os = openFileOutputStream(filePath, lengthOfFile);.
You need to close on stop() as the app is sent to the background. In that state you should avoid open connections as they might be terminated suddenly by the OS. The entire app can be killed because of a wayward stream.
If you have background support in the app you should open and close the stream every time you need it.
answered Nov 13 '18 at 4:02
Shai Almog
39.9k52555
This sounds good, but opens two side questions: 1. Can I make the simulator invokestop()andstart()? 2. When my process gets killed, does the previousflushensure no data gets lost?
– maaartinus
Nov 13 '18 at 7:05
Another question: Are theFileSystemStoragestreams somehow buffered or should I add buffering myself?
– maaartinus
Nov 13 '18 at 8:31
1
Sure, suspend/resume in the simulator menu triggersstop()/start(). Flush writes to the disk so it gives a "good chance" but "guarantees" is a string word. All streams in Codename One are buffered by default.
– Shai Almog
Nov 14 '18 at 3:56
add a comment |
I would suggest closing the output stream on stop() and re-opening it on start(). Notice that if the stream points to FileSystemStorage you can append to the end of the stream using CN's: OutputStream os = openFileOutputStream(filePath, lengthOfFile);.
You need to close on stop() as the app is sent to the background. In that state you should avoid open connections as they might be terminated suddenly by the OS. The entire app can be killed because of a wayward stream.
If you have background support in the app you should open and close the stream every time you need it.
answered Nov 13 '18 at 4:02
Shai Almog
39.9k52555
This sounds good, but opens two side questions: 1. Can I make the simulator invokestop()andstart()? 2. When my process gets killed, does the previousflushensure no data gets lost?
– maaartinus
Nov 13 '18 at 7:05
Another question: Are theFileSystemStoragestreams somehow buffered or should I add buffering myself?
– maaartinus
Nov 13 '18 at 8:31
1
Sure, suspend/resume in the simulator menu triggersstop()/start(). Flush writes to the disk so it gives a "good chance" but "guarantees" is a string word. All streams in Codename One are buffered by default.
– Shai Almog
Nov 14 '18 at 3:56
add a comment |
I would suggest closing the output stream on stop() and re-opening it on start(). Notice that if the stream points to FileSystemStorage you can append to the end of the stream using CN's: OutputStream os = openFileOutputStream(filePath, lengthOfFile);.
You need to close on stop() as the app is sent to the background. In that state you should avoid open connections as they might be terminated suddenly by the OS. The entire app can be killed because of a wayward stream.
If you have background support in the app you should open and close the stream every time you need it.
answered Nov 13 '18 at 4:02
Shai Almog
39.9k52555
I would suggest closing the output stream on stop() and re-opening it on start(). Notice that if the stream points to FileSystemStorage you can append to the end of the stream using CN's: OutputStream os = openFileOutputStream(filePath, lengthOfFile);.
You need to close on stop() as the app is sent to the background. In that state you should avoid open connections as they might be terminated suddenly by the OS. The entire app can be killed because of a wayward stream.
If you have background support in the app you should open and close the stream every time you need it.
answered Nov 13 '18 at 4:02
Shai Almog
39.9k52555
answered Nov 13 '18 at 4:02
Shai Almog
39.9k52555
answered Nov 13 '18 at 4:02
Shai Almog
39.9k52555
answered Nov 13 '18 at 4:02
Shai Almog
39.9k52555
39.9k52555
This sounds good, but opens two side questions: 1. Can I make the simulator invokestop()andstart()? 2. When my process gets killed, does the previousflushensure no data gets lost?
– maaartinus
Nov 13 '18 at 7:05
Another question: Are theFileSystemStoragestreams somehow buffered or should I add buffering myself?
– maaartinus
Nov 13 '18 at 8:31
1
Sure, suspend/resume in the simulator menu triggersstop()/start(). Flush writes to the disk so it gives a "good chance" but "guarantees" is a string word. All streams in Codename One are buffered by default.
– Shai Almog
Nov 14 '18 at 3:56
add a comment |
This sounds good, but opens two side questions: 1. Can I make the simulator invokestop()andstart()? 2. When my process gets killed, does the previousflushensure no data gets lost?
– maaartinus
Nov 13 '18 at 7:05
Another question: Are theFileSystemStoragestreams somehow buffered or should I add buffering myself?
– maaartinus
Nov 13 '18 at 8:31
1
Sure, suspend/resume in the simulator menu triggersstop()/start(). Flush writes to the disk so it gives a "good chance" but "guarantees" is a string word. All streams in Codename One are buffered by default.
– Shai Almog
Nov 14 '18 at 3:56
This sounds good, but opens two side questions: 1. Can I make the simulator invoke
stop() and start()? 2. When my process gets killed, does the previous flush ensure no data gets lost?– maaartinus
Nov 13 '18 at 7:05
This sounds good, but opens two side questions: 1. Can I make the simulator invoke
stop() and start()? 2. When my process gets killed, does the previous flush ensure no data gets lost?– maaartinus
Nov 13 '18 at 7:05
Another question: Are the
FileSystemStorage streams somehow buffered or should I add buffering myself?– maaartinus
Nov 13 '18 at 8:31
Another question: Are the
FileSystemStorage streams somehow buffered or should I add buffering myself?– maaartinus
Nov 13 '18 at 8:31
1
1
Sure, suspend/resume in the simulator menu triggers
stop()/start(). Flush writes to the disk so it gives a "good chance" but "guarantees" is a string word. All streams in Codename One are buffered by default.– Shai Almog
Nov 14 '18 at 3:56
Sure, suspend/resume in the simulator menu triggers
stop()/start(). Flush writes to the disk so it gives a "good chance" but "guarantees" is a string word. All streams in Codename One are buffered by default.– Shai Almog
Nov 14 '18 at 3:56
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53257524%2fkeeping-output-stream-open%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You only need to flush when you are about to read a response. If that doesn't answer your question it is unclear what you're asking.
– user207421
Nov 12 '18 at 9:32
@user207421 I don't need to read it until next start. So you think that not flushing the stream is safe? You may be right...., but do you have any evidence?
– maaartinus
Nov 12 '18 at 12:41
@user207421 On the second thought.... while
FileOutputStreammay need no flushing as it gets closed when program terminates, there's buffering in my streams and I can't rely on getting called when the app get closed/killed. Or can I?– maaartinus
Nov 13 '18 at 3:40