> 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
