Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (7)
to General by teroyk - 17 hrs, 59 mins ago - more...
|
2010-05-31
, 11:35
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#2
|
This is typically done using lock files. The directory /var/run can be used. Or /tmp for lock files that should not survive a reboot.
As far as I know, there are POSIX defined functions to handle this. Depending on your framework, there might be implementations there too.
You could use gconf for ease of use but then you must take into account that it might not be thread safe on the same level as files in the file system.
As far as I know, there are POSIX defined functions to handle this. Depending on your framework, there might be implementations there too.
You could use gconf for ease of use but then you must take into account that it might not be thread safe on the same level as files in the file system.
| The Following User Says Thank You to Joorin For This Useful Post: | ||
 |
|
2010-05-31
, 11:47
|
|
Posts: 1,637 |
Thanked: 4,424 times |
Joined on Apr 2009
@ Germany
|
#3
|
Originally Posted by Joorin
Isn't that handled by the osso application framework anyway.
This is typically done using lock files. The directory /var/run can be used. Or /tmp for lock files that should not survive a reboot.
Most builtin applications are running with one single instance
only. For example you can not open multiple instances of the
clock or calculator applications.
nicolai
| The Following User Says Thank You to nicolai For This Useful Post: | ||
|
|
2010-05-31
, 11:54
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#4
|
Originally Posted by nicolai
As far as I know, the osso application framework is a bit more complicated than that with watchdogs keeping track of things and restarting applications and, potentially, rebooting the device to get back to a known state. But I'm sure there is already framework functionality in place to use.
Isn't that handled by the osso application framework anyway.
Most builtin applications are running with one single instance
only. For example you can not open multiple instances of the
clock or calculator applications.
nicolai
(Just as I wrote later on in my comment...)
Last edited by Joorin; 2010-05-31 at 11:55. Reason: Typo
| The Following User Says Thank You to Joorin For This Useful Post: | ||
|
|
2010-05-31
, 12:15
|
|
Posts: 13 |
Thanked: 0 times |
Joined on May 2010
|
#5
|
Okay, so the cows are still not flying. I mean that there is no simple way like a flag in the .desktop file or something. I have to do it the hard way, as usually. Probably a lock file then... Thank you for the hints! 
|
|
2010-05-31
, 12:18
|
|
Posts: 605 |
Thanked: 137 times |
Joined on Nov 2005
@ La Rochelle, France
|
#6
|
if your app handles DBus request properly, osso should not let it run several times ...
|
|
2010-05-31
, 12:24
|
|
Posts: 1,208 |
Thanked: 1,028 times |
Joined on Oct 2007
|
#7
|
Yes there is a simple way. Launch application via DBus (use .service file) and register application with osso_init(). Documentation is found for example from the wiki.
| The Following User Says Thank You to mikkov For This Useful Post: | ||
 |
|
2010-05-31
, 12:25
|
|
Posts: 4,274 |
Thanked: 5,358 times |
Joined on Sep 2007
@ Looking at y'all and sighing
|
#8
|
If you've created an osso_context and have set the X-Osso-Service field in the desktop file correctly, Hildon Desktop will call the "top_application" mehod on an already running instance instead of starting a new one.
|
|
2010-05-31
, 12:28
|
|
Posts: 13 |
Thanked: 0 times |
Joined on May 2010
|
#9
|
In fact, lock file isn't very good: if the program is killed before it exits voluntarily, the lock file may not be deleted. That forbids the program to start any more!
Better way would be to examine process list and check if the binary is already running. How to do that, then?
Better way would be to examine process list and check if the binary is already running. How to do that, then?
|
|
2010-05-31
, 12:31
|
|
Posts: 13 |
Thanked: 0 times |
Joined on May 2010
|
#10
|
Originally Posted by qwerty12
Sounds reasonable, but I haven't. Maybe I can do that, any pointers to a simple example?
If you've created an osso_context and have set the X-Osso-Service field in the desktop file correctly, Hildon Desktop will call the "top_application" mehod on an already running instance instead of starting a new one.
I have a computational intensive animation application that I want to run only as a single instance. In other words, if user tries to start the same application again, it should not start. How to do that? Hopefully there is a simple way, though I don't believe so
...