But in that case the ctor of the singleton class must have been called a second time, right? Since I've only got one single call of the ctor I guess the instance only exists one time!?
I thought of that too. So what I do is, I call the startService() method from my acivity to create a new service. I'm using logcats every where in the application to produce output whenever I can. On 8 Feb., 17:35, Michael MacDonald <[email protected]> wrote: > On 02/08/10 10:30, Streets Of Boston wrote: > > > 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 <[email protected]> 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. > > That kind of matches my guess-- > > Maybe the service is running in a separate process, so it has its own > copy of the singleton ServerInstance. So when the application updates > its singleton, the service does not see it. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
