hello everyone. i am new to android (who isn't) and coming primarily from the java mobile area, i got one or two orientation issues. i am trying to find out how our library might be adjusted to be useful on android.
it's a lengthy read and maybe not of general interest. abstracted, i am looking for a "good" implementation for delayed callbacks from separate threads. about our java me/se solution: we have a working library as middleware for multiplayer games/apps based on http (we're talking about mobile devices). it offers the usual non-blocking methods (rpc-calls) like login() and sendData() and callbacks when the results are available (from a separate thread). any data sent by others is fetched as attachment to any rpc-call you make. the lib uses a callback to a (single) listener which implements our interface which defines functions like loginCB(). i think you get the idea (please ask if not). we are used to have a single listener which implements all screens and the like and which is usually also the "game" screen as well. it reacts to callbacks and events alike, keeping in mind which state it's in. this helps to "ignore" or postpone events if needed. in android, there are usually multiple activities and views and i have difficulties finding the best way to handle the library/network according to androids expectations. i tried some ideas and currently the solution is like this: i use an application to create the session and keep it alive (via handles). this application also implements a streamlined listener which gets all callbacks by the library. any activity can now access the session via getApplication() and start rpc-calls this way. to get a result, it needs to implement a "fullListener" interface and to get the results into the correct thread, each activity must have a networkHandler, which treats defined messages. this class could be part of the library. now, the library will callback to the application, which in turn puts all returned info (some int's and hashtable) into a message and sends one message to each registered handler. the handler then is then able to do the callbacks as known from other systems and still is in the correct thread-context. this way, the implemented listener functions can directly interact with the current view, set new intents or finish subactivities. it sounds like some overhead for me and maybe there is an easier way. is that OK for android? and does it sound usable? any better ways? i would be happy about any feedback. tobias --~--~---------~--~----~------------~-------~--~----~ 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] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
