says:
Called when Application storage is changed by the other running instance app
I understand situation that background process change storage app but what can else change it? is it possible to run 2 instances of the same app?
says:
Called when Application storage is changed by the other running instance app
I understand situation that background process change storage app but what can else change it? is it possible to run 2 instances of the same app?
Maybe this will clarify things:
Applications can register for background services. Services can be registered to run when various events occur. These events include when the user reaches goal targets, when sleep and wake times occur, when a steps threshold is reached, or at a scheduled time. Modules available to background processes differ from those of their parent application.
When background services are started, the getServiceDelegate() is run from the Application object. This method returns a System.ServiceDelegate and the method corresponding to the event that triggered is invoked. Once a background service has finished any necessary tasks, it should exit using the Background.exit() method. This method takes a argument containing data to be sent to the main process. Use null to provide no data.
I know how app is notified then background.
I still ask what does mean vice-versa?
When the storage is written from the background process,Application.onStorageChanged()callback will be invoked for the foreground process if the background and foreground process are active at the same time and vice-versa.
for me "vice-versa"="the same way" but I don't think so.
It's simple the same like in set/getProperty, both background and app has access to the same "properties/storage" and background isn't inform like app but can check if something was changed.
Vice versa means exactly what we've been saying. It means "the other way around."
- onStorageChanged() will be called for the foreground process if the background process changes storage
"and vice versa" in this context means:
- onStorageChanged() will be called for the background process if the foreground process changes storage
Both the background process and foreground process share common *code* in the app class that inherits from AppBase, such as onStart(), onStop() and onStorageChanged(). If I'm not mistaken, onStart() and onStop() run for both the foreground and background process, so I'm not sure why you don't believe that onStorageChanged() could run for both the foreground and background process.
But I don't develop apps with background processes, so maybe Jim can correct me if I said something wrong or misunderstood something.
So my understanding of the "flow" for the foreground and background process is:
Foreground: AppBase.onStart() => AppBase.getInitialView() => (other stuff) => AppBase.onStop()
Background: AppBase.onStart() => AppBase.getServiceDelegate() => AppBase.onStop()
In both cases they are based on AppBase(), and any other applicable methods, like onStorageChanged(), can also be called.
I don't think so...
there is "no based", there is inheritance
background can't call app function!
there is bag.exit() and system calls app.onBackgroundData
ok, let's finish this thread, simple documentation isn't clear.
I'm looking to find solution (resulting limitation of platform) to write app but maybe is better to wait for Garmin gives simple solution in ciq and to this time stop developing. Maybe there is error in firmware in battery draining for app that do nothing.
background can't call app function!
So you don't believe that your background process calls onStart() and onStop() (which are also in AppBase)???
Why not put a System.println() in onStart() and onStop() and test your theory in the simulator? Schedule a temporal event and also put a println in the OnTemporalEvent() handler. I think you should see all 3 printlns, but you would only expect to see the 1 println, correct?
A lot of these questions you are asking could be resolved by testing things yourself, especially when you don't believe the answers that are being given. Skepticism is healthy, but there's a point when you can either believe what people are saying, or find out for yourself.
I'm happy to be proven wrong if you find out differently.
there is "no based", there is inheritance
Right, and the background process and foreground process both inherit from AppBase. They share some of the same code.
so if each app.function has also background I have to check if I'm background ore foreground?
If you have shared code that could run in either the foreground or background process, yes. And not each app function, but certain app functions (like onStart(), onStop() and supposedly, onStorageChanged()).
I'm just telling you my understanding of how it works based on the docs and discussions in the forum. I'd be happy to be proven wrong and to learn something new.
If what I'm saying is wrong, why would someone ask the following question:
However, if I put this code into myApp.initialize() or myApp.onStart(), these methods get called when the background service initializes as well - and calling setProperty will lead to a crash of a background service.
What is a correct check for 'Am I currently in an app or in a background service'?
And why would Jim give this answer:
In AppBase there are things that run for both the main app and the background, things that only run in the main app, and things that only run for the background.
I said this before, but you have to think of the foreground and background processes as separate (single-threaded) programs that share some of the same code. If you think of it that way, it would answer a lot of your questions about shared global variables, concurrency, etc.
Maybe there is error in firmware in battery draining for app that do nothing.
Yeah, sorry I gave you bad advice on that. I don't dev watchfaces myself.
I can only guess that Garmin optimizes CIQ watchface battery consumption compared to app battery consumption, since watchfaces run 24/7 and apps are only supposed to run for maybe a few hours at a time.
because there is no declaration class on background like
class testwidgetApp extends Application.AppBase
{
}
and
AppBase is the base class for an app.
All apps inherit from this class and use it's methods to manage the life cycle of an app.
Your app overrides the class to provide entry points with the following methods:
These functions are called in the following order:
as you see onStart() is called first (no view) so how to know about if I'm background or app?????
mayby i can check (has :getInitialView) but it's not important because all what can happen in background there is on serviceDelgate, background don't have to know anything about app the communication is by properties/storage/bag.exit/app.regstisterForTemporary... I somebody would want to do the way you describe he tell you to make class BackgroundClass and write in onStorageChange() onStart etc, instead of you have serviceDelegate to serve background task
and ona thing more, when background exit system calls app.onStart() then onBackgroundData not getInitialView() so you have to save data for view
