Hello, i have a swing app that uses javamail to send mail when connected to internet. when not connected the button use for mail sending is not available.
My question is : is there a way to know when i m connected to internet or when it s possible to send mail ?
Thanks for helping find some solution
If I were doing it I would just send an e-mail when the user asked me to do that, and catch any exceptions that occurred. I certainly wouldn't do something like running a thread that did a test connection every two minutes to see if the server was up. But then I am working in an environment where the SMTP server is up 99.99% of the time. Do you have a hostile environment you have to deal with?
No its not question about hostile environnement, There are two applications one webapp in which the send mail button could always be available and if a pb occurs with the server or other pb with mail the exception is catch, display in a popup and logged. That is for the webapp. Then fromthis webapp is generated a swing application for person who have laptop computer using swixml and for this swing appli i have to care about the button. It shouldnt be clickable or visible if there is no connection to the server. I have no much idea on doing it the proper way. Maybe each time before the panel with this button is going to be displayed i have to do the check to the server or another solution would be to let the user send email (fake send) and store them in some kind of pile then send all email when there is a connection, but anyway i still have to check for this connection in any case, i dont know if its possible or what would be the best.
Message was edited by:
JusteUneQuestion
I'm confused about the reason for developing two versions of this app. I assume that the swing version is for when the user has no internet availability, because it's 1) for laptop users and 2) not a webapp. If so, isn't it safe to assume they don't have access to the mail server most of the time? It would make more sense to me to have a way for the user to check availability when they want, instead of having a continual monitor running.
Hello and thank you for answering.
The reason for having a swing app is for laptop users.
Yes it is safe to assume that they dont have access to any server. So i m looking for a way to check for the availability of the server, if the server is available then the button for sending mail can be visible. I want it to be as transparent as possible for the user.
Thanks
> Hello and thank you for answering.
> The reason for having a swing app is for laptop
> users.
> Yes it is safe to assume that they dont have access
> to any server. So i m looking for a way to check for
> the availability of the server, if the server is
> available then the button for sending mail can be
> visible. I want it to be as transparent as possible
> for the user.
> Thanks
Well in that case, I think your only option is to have a thread running that continually polls the server to check if it's available like DrClap said. This is a bad design imo, as you're doing nothing but reimplementing the internet connectivity functionality their os already provides. I think your time would be better spent trying to get this requirement changed than implementing the monitor.
I'm confused about the design requirements too. Most applications that I have seen, that need to connect to a server on the Internet for something, start by assuming the connection will work. Then when it doesn't, they tell the user that it didn't work. (Or they hang, or crash painfully, but that's just a failure of design.)
So why is there a requirement for the user to know in advance if the connection is going to work? The only reason I can see is because there is a good chance it isn't going to work. That's what I meant by "hostile environment" -- you have an SMTP server that isn't reliably accessible.
To me the solution to this problem is to work on the server so that it doesn't go offline so often. But maybe I have drawn the wrong conclusion and this really isn't the problem at all.
> I'm confused about the design requirements too. Most
> applications that I have seen, that need to connect
> to a server on the Internet for something, start by
> assuming the connection will work. Then when it
> doesn't, they tell the user that it didn't work. (Or
> they hang, or crash painfully, but that's just a
> failure of design.)
>
> So why is there a requirement for the user to know in
> advance if the connection is going to work? The only
> reason I can see is because there is a good chance it
> isn't going to work. That's what I meant by "hostile
> environment" -- you have an SMTP server that isn't
> reliably accessible.
>
> To me the solution to this problem is to work on the
> server so that it doesn't go offline so often. But
> maybe I have drawn the wrong conclusion and this
> really isn't the problem at all.
I think you're right about the hostile environment, but instead of the server being offline, it's the user, ie, they're mobile, and usually don't have internet access. I'm picturing traveling business people. You're right about having the design backwards though, most users are savvy enough to know when they're connected without a specific application telling them. (if not, they need to have their laptop license revoked :)
