Thanks Imran, It helps, but there are still conflicts in case you use REST service, for example, you can accomplish different requests with the same url (depending on what you send in entity) but well I think the original problem is mitigated. Now it's up to each app to use the information in their way.
Thanks to all, Oleksandr On Tuesday, 29 May 2012 13:37:58 UTC+1, imran ali wrote: > > Hi, > I don't know which request generated that response. > > while to BroadCast you must have been passing intent, so put your url in > that intent using putExtra(Key,your url); > on BroadCastReceiver, you will have onReceive( Context c, Intent intent); > so extract that from intent, like intent.getString(Key); > In that way you can identify the response of particular request. > > hope will help you. > > Regards > Imran Ali > > On Tuesday, May 29, 2012 5:29:38 PM UTC+5:30, Oleksandr Kruk wrote: >> >> Thanks Kristopher, >> >> Actually that's exactly what I have, an API which provides the developer >> with access >> to all necessary data structure and manipulation. >> >> I made a draft just to explain better whats the problem: >> >> >> <https://lh3.googleusercontent.com/-_NG1V3-5Rck/T8S4hnlIxWI/AAAAAAAAAD4/kGPgsRqkBxE/s1600/requestExec.png> >> The number 1 is a broadcast receiver that reacts on an action of request >> execution >> by Queue Manager service. The problem is that in the receiver (1) I have >> no way >> to know what I am supposed to do with that response, because I don't know >> which >> request generated that response. I guess I must pass some context >> information >> from "Some App" to "Queue Manager App" and then back after executing. It >> can be a name of >> method to execute or something like that. >> >> >> >> >> >> >> On Tuesday, 29 May 2012 10:31:01 UTC+1, Kristopher Micinski wrote: >>> >>> It sounds like what you want is basically a message queue.. >>> >>> However, for a cross app solution, I think you'd want something that >>> stores the data persistently somewhere, such as on disk. I'd probably >>> make an API backed by a service that apps would interface to >>> implementing this, if I were you... >>> >>> kris >>> >>> On Tue, May 29, 2012 at 5:06 AM, Oleksandr Kruk <[email protected]> >>> wrote: >>> > Thanks for your answer TreKing! >>> > >>> > I am sorry, that was an unclear expression, by "apps offline" I meant >>> they >>> > are not running. >>> > >>> > Exactly, you understood well, but I think I failed to explain that the >>> time >>> > frame between storing requests and executing them can be >>> > anything like an hour, a day, a month, etc.. So in this context, when >>> an >>> > application receives a response, lets say through a broadcast intent >>> > it wont know for which request that response was received. Thats why >>> having >>> > a callback method associated to request would be better than simply >>> > an intent with the result. >>> > >>> > Imagine a situation: >>> > You are in a remote area with no network, you take a landscape photo, >>> open >>> > facebook app and >>> > simply post that photo (without network). This post would remain in my >>> > framework until you have network, which is indefinite time. >>> > Now, at the moment you connect to network, lets say two days, it will >>> be >>> > posted on facebook (by ManagerApp) and facebook app will get a >>> response from >>> > ManagerApp. >>> > If you send that response as a broadcast to facebook app, how it is >>> supposed >>> > to know that that response is related to that specific photo post you >>> made >>> > days ago. >>> > >>> > Remember that I don't want to make developers to maintain mappings >>> between >>> > their app requests and future response in order to solve this >>> situation, >>> > all the information must be on the side of the framework (it's cleaner >>> I >>> > guess). >>> > >>> > >>> > Thanks again >>> > >>> > >>> > >>> > >>> > On Tuesday, 29 May 2012 09:16:50 UTC+1, TreKing wrote: >>> >> >>> >> On Mon, May 28, 2012 at 10:55 AM, Oleksandr Kruk <[email protected]> >>> >>> >> wrote: >>> >>> >>> >>> How can this IntentService update each App information using their >>> >>> business logic when >>> >>> the Apps are offline? >>> >> >>> >> >>> >> What do you mean "when the apps are offline"? >>> >> >>> >> If I understand you correctly, you would simply have to launch an >>> intent >>> >> or trigger a broadcast from your IntentService that has the >>> information the >>> >> other apps care about. The other apps would have to know the details >>> of the >>> >> intent or broadcast structure in order to properly listen for it. >>> >> >>> >> The intent would contain the data the app in question was requesting, >>> in >>> >> some known format. You would not have to know anything about their >>> business >>> >> logic, that would be up to them. >>> >> >>> >> >>> >> >>> ------------------------------------------------------------------------------------------------- >>> >>> >>> >> TreKing - Chicago transit tracking app for Android-powered devices >>> >> >>> > -- >>> > 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 >>> >> >> On Tuesday, 29 May 2012 10:31:01 UTC+1, Kristopher Micinski wrote: >>> >>> It sounds like what you want is basically a message queue.. >>> >>> However, for a cross app solution, I think you'd want something that >>> stores the data persistently somewhere, such as on disk. I'd probably >>> make an API backed by a service that apps would interface to >>> implementing this, if I were you... >>> >>> kris >>> >>> On Tue, May 29, 2012 at 5:06 AM, Oleksandr Kruk <[email protected]> >>> wrote: >>> > Thanks for your answer TreKing! >>> > >>> > I am sorry, that was an unclear expression, by "apps offline" I meant >>> they >>> > are not running. >>> > >>> > Exactly, you understood well, but I think I failed to explain that the >>> time >>> > frame between storing requests and executing them can be >>> > anything like an hour, a day, a month, etc.. So in this context, when >>> an >>> > application receives a response, lets say through a broadcast intent >>> > it wont know for which request that response was received. Thats why >>> having >>> > a callback method associated to request would be better than simply >>> > an intent with the result. >>> > >>> > Imagine a situation: >>> > You are in a remote area with no network, you take a landscape photo, >>> open >>> > facebook app and >>> > simply post that photo (without network). This post would remain in my >>> > framework until you have network, which is indefinite time. >>> > Now, at the moment you connect to network, lets say two days, it will >>> be >>> > posted on facebook (by ManagerApp) and facebook app will get a >>> response from >>> > ManagerApp. >>> > If you send that response as a broadcast to facebook app, how it is >>> supposed >>> > to know that that response is related to that specific photo post you >>> made >>> > days ago. >>> > >>> > Remember that I don't want to make developers to maintain mappings >>> between >>> > their app requests and future response in order to solve this >>> situation, >>> > all the information must be on the side of the framework (it's cleaner >>> I >>> > guess). >>> > >>> > >>> > Thanks again >>> > >>> > >>> > >>> > >>> > On Tuesday, 29 May 2012 09:16:50 UTC+1, TreKing wrote: >>> >> >>> >> On Mon, May 28, 2012 at 10:55 AM, Oleksandr Kruk <[email protected]> >>> >>> >> wrote: >>> >>> >>> >>> How can this IntentService update each App information using their >>> >>> business logic when >>> >>> the Apps are offline? >>> >> >>> >> >>> >> What do you mean "when the apps are offline"? >>> >> >>> >> If I understand you correctly, you would simply have to launch an >>> intent >>> >> or trigger a broadcast from your IntentService that has the >>> information the >>> >> other apps care about. The other apps would have to know the details >>> of the >>> >> intent or broadcast structure in order to properly listen for it. >>> >> >>> >> The intent would contain the data the app in question was requesting, >>> in >>> >> some known format. You would not have to know anything about their >>> business >>> >> logic, that would be up to them. >>> >> >>> >> >>> >> >>> ------------------------------------------------------------------------------------------------- >>> >>> >>> >> TreKing - Chicago transit tracking app for Android-powered devices >>> >> >>> > -- >>> > 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 >>> >> >> On Tuesday, 29 May 2012 10:31:01 UTC+1, Kristopher Micinski wrote: >>> >>> It sounds like what you want is basically a message queue.. >>> >>> However, for a cross app solution, I think you'd want something that >>> stores the data persistently somewhere, such as on disk. I'd probably >>> make an API backed by a service that apps would interface to >>> implementing this, if I were you... >>> >>> kris >>> >>> On Tue, May 29, 2012 at 5:06 AM, Oleksandr Kruk <[email protected]> >>> wrote: >>> > Thanks for your answer TreKing! >>> > >>> > I am sorry, that was an unclear expression, by "apps offline" I meant >>> they >>> > are not running. >>> > >>> > Exactly, you understood well, but I think I failed to explain that the >>> time >>> > frame between storing requests and executing them can be >>> > anything like an hour, a day, a month, etc.. So in this context, when >>> an >>> > application receives a response, lets say through a broadcast intent >>> > it wont know for which request that response was received. Thats why >>> having >>> > a callback method associated to request would be better than simply >>> > an intent with the result. >>> > >>> > Imagine a situation: >>> > You are in a remote area with no network, you take a landscape photo, >>> open >>> > facebook app and >>> > simply post that photo (without network). This post would remain in my >>> > framework until you have network, which is indefinite time. >>> > Now, at the moment you connect to network, lets say two days, it will >>> be >>> > posted on facebook (by ManagerApp) and facebook app will get a >>> response from >>> > ManagerApp. >>> > If you send that response as a broadcast to facebook app, how it is >>> supposed >>> > to know that that response is related to that specific photo post you >>> made >>> > days ago. >>> > >>> > Remember that I don't want to make developers to maintain mappings >>> between >>> > their app requests and future response in order to solve this >>> situation, >>> > all the information must be on the side of the framework (it's cleaner >>> I >>> > guess). >>> > >>> > >>> > Thanks again >>> > >>> > >>> > >>> > >>> > On Tuesday, 29 May 2012 09:16:50 UTC+1, TreKing wrote: >>> >> >>> >> On Mon, May 28, 2012 at 10:55 AM, Oleksandr Kruk <[email protected]> >>> >>> >> wrote: >>> >>> >>> >>> How can this IntentService update each App information using their >>> >>> business logic when >>> >>> the Apps are offline? >>> >> >>> >> >>> >> What do you mean "when the apps are offline"? >>> >> >>> >> If I understand you correctly, you would simply have to launch an >>> intent >>> >> or trigger a broadcast from your IntentService that has the >>> information the >>> >> other apps care about. The other apps would have to know the details >>> of the >>> >> intent or broadcast structure in order to properly listen for it. >>> >> >>> >> The intent would contain the data the app in question was requesting, >>> in >>> >> some known format. You would not have to know anything about their >>> business >>> >> logic, that would be up to them. >>> >> >>> >> >>> >> >>> ------------------------------------------------------------------------------------------------- >>> >>> >>> >> TreKing - Chicago transit tracking app for Android-powered devices >>> >> >>> > -- >>> > 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 >>> >> -- 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
