01-05-2010 09:30 PM
I have created two entry points for my app as per examples here and in the SDK docs.
Now my question is how do these two communicate? I have some assumptions and suggestions of my own listed below. I'd appreciate if someone verified them or provided best practices. thanks jeff
- Runtime store: this is the recommended way for entry points to exchange state
- GlobalEvents: should they be registerting themselves as globalevent listeners?
- IPC methods: since they run in different processes InterProcessCommunication should apply. The only available method here is Sockets
Solved! Go to Solution.
01-06-2010 04:03 AM
I agree with ydaraishy and realize that this Thread has been marked as Solved, but wanted to add a couple of comments anyway.
Given that your application is already closely coupled, in that you have two different entry points to the one piece of code, unless you have a specific need to swap processes ( in other words, have some data in one process that is acted upon by the other process), then I do not see the need for Global Events. I would argue that this is the best approach when you are interacting with another process - for example, the telephone listener passing information back to another application.
Also you could consider the use of Persistent Store as well. For example, your background task could provide networking processing for the GUI, so all the GUI does is write message to be sent into a Persistent Store Queue, this Queue is processed by the Background Application (not a good example, you don't need a Background application to do this, but you get the idea). .
01-06-2010 10:44 PM
As closely as the entry points are coupled they're still running in separate processes? So if i need the interactive part communicate with the non-interactive part I still have to come up with some sort of mechanism for this to happen.
As far as I know setting some static variables won't do the trick. Also a simple call to a method within the same application won't trigger anything.
PersistentStore and Runtime store may be great for these entry points to share data but "messaging" or "signaling" amongst them is still an issue.
There is something very possible and that is my whole premise of what entry points are and how they should be used is incorrect. That is I really don't get the entry points. What I understood is that they are needed if an application is ever switch to background from the foreground. It may also be true that I won't ever need to let the "background" entry point to every have to do anything. I can let my main or gui entry point do all foreground and background processing period.
All in all I definitely need some insight into the rationale for having them. And I haven't obtained that insight by browsing the posts in this forum yet. It would be great if someone from RIM or not just broke down what they really mean.
01-07-2010 07:25 AM - edited 01-07-2010 07:10 PM
This is sore point for me too, because I think Alternate Entry points are used incorrectly/inappropriately at times.
In brief, an alternate entry is another Application, which, as you rightly point out, means static variables are not shared (and nor are Application level listeners like Global Event Listeners). However code is shared, so you can easily communicate between the two processes.
However there is no problem with having a background process (Thread) in an application. So most of the time, you don't need to use an Alternate Entry. With just one Entry, running at start-up, you can start your Thread and your UI and leave it in the background. Then, when the user clicks on your icon, it just brings your UI to the Foreground. When the user 'closes' your Ui, you don't remove the Screen or exit the Application, you just move your Application to the background.
Assuming you do this, you can, as I have said, without using an Alternate Entry, have some 'background Thread (for example a network Thread that is continuously sending data or listening for pushes), Clearly there is a need for this Thread to communicate with the foreground processing, but this is, in fact, exactly the same sort of communication that you would have with a Background Application. For example, you can, in both cases, use wait/notify mechanisms, and queues of data. In the single Application case, it is a lot easier to find the shared objects, becuase there is only one instance of static objects.
But it seems that most people think that they need an Alternate Entry to have a background process. And while there are some cases where this is a good thing, there are some for which it is completely unnecessary and complicates the process.
So when are Alternate Entry points useful?
a) When the startup processing does not need to start an application (for example, to change the icon).
b) When you want to have multiple 'icons' associated with the one application - we do this in one case when the customer wanted two icons, one to add/delete data and another to search the same stored data. With two icons (i.e. two applications), they can actually do both of these at the same time, which is cool.
c) When you really want to completely shut down the Ui, but still have the background process continuing. I must admit I can't think of a use case for this, but I'm sure someone can.
OK enough for one post. let me know if this doesn't make sense or doesn't cover the ground as well as you would like.
01-07-2010 05:25 PM
that's all i needed to get set. Obviosuly I was going down the wrong path. All i needed was the capability to run in the background.
I think your post probably combined with some other related ones should be set as a sticky in this forum because this topic is a real "stikcy" one and others will sure benefit more directly
01-07-2010 06:02 PM - edited 01-07-2010 06:04 PM
Just for completeness, since it looks like you may not need to use two processes:
Signalling isn't an issue. You set up threads in either process, that block and wait on the presence or absence of data. Once the data gets placed in one process, the other process's thread unblocks and you can process a signal.
Re the situations where entry points are good: I think having things start at device bootup is another one, (unless there is the ability to start a UI application at startup that I'm unaware of?)
01-07-2010 07:08 PM - edited 01-07-2010 07:17 PM
As noted in my previous post, I start UI applications in Background at device startup. You just have to be careful. But then you can't start a network Thread until the device is fully awake anyway, so no change there.....
Edit, just realized, I've been ambiguous in my use of the word background!
An Application that is not currently displayed is in the Background (as compared with the foreground).
A Thread that is running doing some 'background' activity, like waiting for pushes, I also describe as running in the background.
Sorry I really can't think of another word to describe either of these two cases. So I think you are going t have to determine from context in this and my last post, exactly what I mean when I say background.
But a UiApplication can be in the foreground or the background, and can be running background Threads in either place. Make sense? Probably not.