Did you check if you service is being destroyed (onDestroy) or being killed (entire service process is being killed by Android) and re- created later at points in your code that are unexpected?
Put break-points in your service's onCreate, onDestroy and onBind and see what's going on. Another question: Do you run your service in a different process or in the same process as your Activities? On Feb 8, 5:58 am, Florian Lettner <fl.lett...@gmail.com> wrote: > > It's unclear from your description just where you're storing your non- > > static variables. The right way would appear to be in your > > ServerConnection instance, since that's the static singleton. Your > > activity will have a much shorter lifespan. > > The variables are stored as class members in the server connection > class, which is the static singleton. The singleon works fine, I > checked that. The private ctor is only called once, if the > getInstance() function is called for the first time. If a call > setProperty(x); the x value is transported properly to the server > connection class and applied to the member variable. Checked that too, > after calling the method the member variable has the desired value. If > afterwards connect() is called which uses the member variable, the > member has got its initial value again, like it is a different object. > However, only one server connection object exists for the application > (ctor is definitely called only once): > > > There's a fair bit more that's unclear to me from your description as > > well. It may be that you need to create and bind a service > > (android.app.Service). I'm not sure you're using "ServerConnection", > > and "server connection" in the sense of a connection to an > > android.app.Service, or to a service on some other system accessed via > > your socket connection. > > The service is needed to keep the application up and running since > there is additional hardware used for device input (Anoto Pen). It is > quite complex, but however the service is needed to react on any > action of the pen also if the application is not in foreground. The > server connection is needed to send input data to the server (using > sockets), however, the server connection is not the service. In a > previous version (before the server connection became a singleton) the > background service owned a server connection object. Both work well, > the server connection connects to the external server, sends data and > receives data and the background service runs to keep track of the > anoto pen. Additionally the service receives status messages from the > server class (e.g. socket error, login error, data lost, ...). This > all works well. The only thing that does not work is that if I set the > port or IP from the background service or my activity, the data gets > lost although the debugger tells me that it is in the variable after > calling the setter. > > > I'm not sure why you had trouble passing data from your activity to > > your service. If it was an android.app.Service, look at aidl. > > > Without an android.app.Service, your entire application could be going > > away in between times, if it's not in the foreground. Be sure you > > understand the application and activity lifecycle. Your choice of > > whether to use an android.app.Service should be based on how the > > application lifecycle matches up with when you need this connection to > > exist and what you're doing with it. > > Life cycle is clear and correctly implemented (works on other > platforms like Qt, Symbian and J2ME). Service is needed because of > background communication with external hardware that is connected via > bluetooth. Has actually nothing to do with the server connection. Its > only purpose regarding the server connection is to re-login if the > connection is lost. > > > If you need it to persist solely to avoid authentication, consider > > getting a time-limited authentication token back instead, and > > persisting that. This would allow your activity, service, connection, > > and entire application to go away, and be restarted, and the user > > would still avoid re-authenticating. You can refresh the token with a > > new time-limited token on each reconnect or access, so timeout will > > only happen if the user is idle for an extended period. This can give > > a more robust user experience. > > I would prefer that solution, however the server is developed and > provided by Vodafone since this is a bigger university related > project. So I have to work with their protocol although I would love > to change some things. > > > I hope this helps, somehow. I know it's hard to do when you're lost, > > but if you can better describe your circumstance, you can get more > > useful answers. (Sometimes, doing so even leads you to your own > > answer!) > > Thank you very much for the detailed explanations, however I am still > trapped. Never had such a problem before. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
