Jack Jia wrote: > I can give my app as an example. The app uses the camera API to catch a > bitmap and tries to pass the bitmap to the cropping activity.
Put it in a static data member. Or, create a custom Application object and cache it there. Or, create a service and cache it there. Then both activities in your application can access the byte array. Tactically, problem solved. Now, it would be nice if there were a variant on startActivity() with a signature like: startActivity(Class otherActivity, Object someRandomData) which optimized the start-an-activity-in-my-app path and allowed passing things that don't fit in Intent extras. The receiving activity could get the someRandomData object via some getter, akin to getLastNonConfigurationInstance(). However, I would not define that as "unlimited way of inter-activity memory sharing" or a "single process framework". > If...one of them (such as > the cropping) is a shared tool and provides only service (not data) then > there is no security concern. http://en.wikipedia.org/wiki/Buffer_overrun > By "single process framework", I mean I > can do everything in my process and at the same time to use libraries > and tools etc from the SDK. That is how Android works today: your application runs in a single process, and you can use libraries from the SDK. What precisely about your application running in a single process does not qualify as a "single process framework"? -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android Training in Germany, 18-22 January 2010: http://bignerdranch.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
