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 <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. >> > 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 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
