Application lifecycle

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Application lifecycle

neugens
The list on http://jsr377.github.io/site/ has a few of elements that are
quite related to each other, in my opinion:

* common application structure
* application life-cycle.
* decouple state from UI (binding).
* action management.
* component life-cycle.

And, to some form:
* dependency injection via JSR330.
* application extensibility via plugins (implies modularity).

In particular:

* common application structure
* application life-cycle

Although they can be seen as "components" in the framework, they are
very tied together.

Life cycle leads to a common application structure to define the life
cycle states, and their relationship with each other and with the main
application.

As far as I understood we are trying to go over annotations to define
binding and to some degree the life cycle (again @PostConstructor and
co.). I think we should probably start discussing our idea of life cycle
then, since this seems to be pretty linked to our other discussion about
the annotations related to the MVC (which in turn means "common
application structure").

I would like to come with some kind of formal requirement for each step
in the life cycle and then either make an annotation for that, or have a
proper API.

What are your thoughts here?

Cheers,
Mario


Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

aalmiray
Administrator
Just a quick note, by "Application Lifecycle" I meant this

    http://www.oracle.com/technetwork/articles/javase/index-141957.html#lifecycle

as defined by JSR296. I think we can use that as a starting point.

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

raniejade
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

neugens
On Thu, 2015-02-19 at 04:13 -0700, raniejade [via jsr377-api] wrote:

> As for JavaFX it has the init and stop methods. It's common for an
> application to load some resources at the beginning and unload them
> when the application stops. Also we need to define where these methods
> are called (in the toolkit or main thread).

Good question. Let's try some brainstorming here.

First, we probably need to define what those methods really should do.

In JavaFX (which is a direct emanation of what JSR296 defines in that
regard) they are called in the UI thread and they are used to initialise
the scene graph. Here "Application" is really a Graphical JavaFX
application.

I would like our framework to be more generic, but at the same time more
specific. For example, I see "Application" as a skeleton of what should
be handled strictly by the platform, just letting the user perform
global tasks that are not appropriate elsewhere.

For this, the platform would invoke the life cycle of the Application,
which is a singleton, in the Application Thread (or main thread
basically). This can be a simple command line client for example, like
an audio service on an embedded device.

The Application itself may be composed of multiple MVC triplets (let's
call them that way for now, we can decide on the specifics of the MVC
implementation later).

The MVC triplets would have their own lifecycle, perhaps mostly defined
by the View requirements, but this is probably for later to discuss.

Maybe, the Application could have a way to retrieve the triplets. I'm
not convinced this is a good idea though, since it poses a problem
related to the threading model (however, we can do some magics to ensure
that every message is delivered to the appropriate threads).

This is mostly similar to what Android does, with Application and
Activities.

The problem with this approach, is that Application may not be as a
necessity, and in fact, we could even provide a default implementation.

If this is the case, is it then needed at all?

> One question that comes in my mind is, what happens when an uncaught
> exception is thrown? Should the lifecycle provide a way to handle
> this?

I don't know, we could add a default exception handler, but an exception
means something is going wrong, better to let it propagate, especially
if it's unexpected.

Cheers,
Mario

Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

raniejade
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

Sébastien Bordes
In reply to this post by neugens
Don't forget that JavaFX API has its own preloading system, that cold be used to display a slash screen with a progress bar


As a reminder JavaFX APplication has these  methods:

init()
start(Stage)
stop()

JRebirth uses the init method in conjunction with a custom Preloader providing some custom hooks (with user ones):

switch (messageCode) {
            case 100:
                res = "Initializing";
                break;
            case 200:
                res = "";// Provisioned for custom pre-init task
                break;
            case 300:
                res = "";// Provisioned for custom pre-init task
                break;
            case 400:
                res = "Loading Messages Properties";
                break;
            case 500:
                res = "Loading Parameters Properties";
                break;
            case 600:
                res = "Preparing Core Engine";
                break;
            case 700:
                res = "Preloading Resources";
                break;
            case 800:
                res = "Preloading Modules";
                break;
            case 900:
                res = "";// Provisioned for custom post-init task
                break;
            case 1000:
                res = "Starting";
                break;
            default:

The start method shows the stage with the first view and start the event bus


The stop method try to to stop the event bus to achieve all pending tasks before exiting the application (closing all threads)

Models have heir own lifecycle too into JRebirth, like Commands and Services that share common code
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

aalmiray
Administrator
In reply to this post by neugens
I agree with you Mario.

Let's say we begin by defining the steps an Application must follow (regardless of UI toolkit constraints).

Assuming there's a launcher class provided by an implementation (time for tweaking environment and system properties for example), the javax.application.base.Application class gets to work and launches the real application class.

During the launch the application locates its configuration and setups any required beans (this can be done via a SJR-330 compatible injector). This would be the BOOTSTRAP phase and happens inside the main thread.

Next comes the STARTUP phase, where the MVC triplets are constructed. The key here is that while M and C can surely be built inside the main thread, the V cannot; it must be built inside the UI thread (which ever it may be). Here's where a proper abstraction over the UI thread comes in.

Now comes the time for showing the UI (configurable starting window perhaps?). This has to happen inside. the UI thread again. JSR-296 called this the READY phase, giving developers the chance to do anything before and after.

We're no inside the MAIN phase. This is the normal operation of the application. If new MVC triplets must be created they follow the same rules as the starting ones, that is, M and C built in the main/current thread (as long as it's not the UI thread) and the V built inside the UI thread.

At any time the application may quit. This triggers the SHUTDOWN phase _if_ no bean/component aborts the shutdown sequence.

WDYT?


Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

neugens
On Mon, 2015-02-23 at 02:35 -0700, aalmiray [via jsr377-api] wrote:

> I agree with you Mario.
>
> Let's say we begin by defining the steps an Application must follow
> (regardless of UI toolkit constraints).
>
> Assuming there's a launcher class provided by an implementation (time
> for tweaking environment and system properties for example), the
> javax.application.base.Application class gets to work and launches the
> real application class.
>
> During the launch the application locates its configuration and setups
> any required beans (this can be done via a SJR-330 compatible
> injector). This would be the BOOTSTRAP phase and happens inside the
> main thread.
>
> Next comes the STARTUP phase, where the MVC triplets are constructed.
> The key here is that while M and C can surely be built inside the main
> thread, the V cannot; it must be built inside the UI thread (which
> ever it may be). Here's where a proper abstraction over the UI thread
> comes in.
>
> Now comes the time for showing the UI (configurable starting window
> perhaps?). This has to happen inside. the UI thread again. JSR-296
> called this the READY phase, giving developers the chance to do
> anything before and after.
>
> We're no inside the MAIN phase. This is the normal operation of the
> application. If new MVC triplets must be created they follow the same
> rules as the starting ones, that is, M and C built in the main/current
> thread (as long as it's not the UI thread) and the V built inside the
> UI thread.
>
> At any time the application may quit. This triggers the SHUTDOWN phase
> _if_ no bean/component aborts the shutdown sequence.
>
> WDYT?

Yes, I agree, it seems very logical.

We could add another optional lifecycle methods when application are
meant to pause (and then restore) their execution, but not quit. I
believe this would be mainly necessary for use within embedded
application frameworks (i.e. Android and iOS).

Should we start putting this as a skeleton class on Git Hub for further
refinement?

As for the MVC part, I believe we should also define a threading model
for M and C. This does not mean necessarily a single threading model for
them (which may be a configurable option though), but even simply
stating something like: "the thread on which M and C are instantiated
and run is not defined and may be different for each method" (define by
non defining!), to avoid programmers to rely on side effects specific to
a single implementation (which we should anyway try to limit, of
course).

Cheers,
Mario


Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

johanvos
I was about to reply that at least in the case of Android, the surrounding container will call lifecyle methods on the application. There is no 1-1 relation between an Android Application and e.g. a JavaFX Application. A JavaFX app can be coupled to an Activity or to a Fragmemt, see http://developer.android.com/training/basics/activity-lifecycle/starting.html  and http://developer.android.com/guide/components/fragments.html#Lifecycle 

- Johan

2015-02-23 12:05 GMT+01:00 neugens [via jsr377-api] <[hidden email]>:
On Mon, 2015-02-23 at 02:35 -0700, aalmiray [via jsr377-api] wrote:

> I agree with you Mario.
>
> Let's say we begin by defining the steps an Application must follow
> (regardless of UI toolkit constraints).
>
> Assuming there's a launcher class provided by an implementation (time
> for tweaking environment and system properties for example), the
> javax.application.base.Application class gets to work and launches the
> real application class.
>
> During the launch the application locates its configuration and setups
> any required beans (this can be done via a SJR-330 compatible
> injector). This would be the BOOTSTRAP phase and happens inside the
> main thread.
>
> Next comes the STARTUP phase, where the MVC triplets are constructed.
> The key here is that while M and C can surely be built inside the main
> thread, the V cannot; it must be built inside the UI thread (which
> ever it may be). Here's where a proper abstraction over the UI thread
> comes in.
>
> Now comes the time for showing the UI (configurable starting window
> perhaps?). This has to happen inside. the UI thread again. JSR-296
> called this the READY phase, giving developers the chance to do
> anything before and after.
>
> We're no inside the MAIN phase. This is the normal operation of the
> application. If new MVC triplets must be created they follow the same
> rules as the starting ones, that is, M and C built in the main/current
> thread (as long as it's not the UI thread) and the V built inside the
> UI thread.
>
> At any time the application may quit. This triggers the SHUTDOWN phase
> _if_ no bean/component aborts the shutdown sequence.
>
> WDYT?
Yes, I agree, it seems very logical.

We could add another optional lifecycle methods when application are
meant to pause (and then restore) their execution, but not quit. I
believe this would be mainly necessary for use within embedded
application frameworks (i.e. Android and iOS).

Should we start putting this as a skeleton class on Git Hub for further
refinement?

As for the MVC part, I believe we should also define a threading model
for M and C. This does not mean necessarily a single threading model for
them (which may be a configurable option though), but even simply
stating something like: "the thread on which M and C are instantiated
and run is not defined and may be different for each method" (define by
non defining!), to avoid programmers to rely on side effects specific to
a single implementation (which we should anyway try to limit, of
course).

Cheers,
Mario





If you reply to this email, your message will be added to the discussion below:
http://jsr377-api.40747.n7.nabble.com/Application-lifecycle-tp69p90.html
To start a new topic under jsr377-api, email [hidden email]
To unsubscribe from jsr377-api, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

Sébastien Bordes
In reply to this post by aalmiray
Andres,

If the View doesn't contain a WebView it can be built into any thread you want, but the View shall be attached to the scene into the UI thread.

The WebView node is an exception that make the Node api a little bit ugly...

But it could make sense to build complex View into another thread than the UI one to avoid some lags and to take advantage of multi-processors platforms.

It's possible to add a flag to the MVC triplet to force the view intialization into the UI thread.
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

aalmiray
Administrator
Sebastien,

That sounds too specific for a particular UI tookit (JavaFX) in this case. Swing and SWT will punish you if widgets and properties are not create/accessed in the right thread. Perhaps the default is to perform the initialization of the V component inside the UI thread leaving implementors the choice to parallelize and further refine how this type of component is initialized given its current environment and toolkit settings.

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

Sébastien Bordes
Yes you are right Andres, I have forgotten this fact : "The set of APIs proposed by this JSR will sit on top of any UI toolkit without requiring a bridge from a toolkit in particular; that is, none of the target UI toolkits (Swing, JavaFX, SWT) need to implement new APIs. If for some reason a bridge is required it will be provided from the RI side."

Isn't this overly ambitious to target all toolkits ?

2015-02-23 14:38 GMT+01:00 aalmiray [via jsr377-api] <[hidden email]>:
Sebastien,

That sounds too specific for a particular UI tookit (JavaFX) in this case. Swing and SWT will punish you if widgets and properties are not create/accessed in the right thread. Perhaps the default is to perform the initialization of the V component inside the UI thread leaving implementors the choice to parallelize and further refine how this type of component is initialized given its current environment and toolkit settings.

Cheers,
Andres


If you reply to this email, your message will be added to the discussion below:
http://jsr377-api.40747.n7.nabble.com/Application-lifecycle-tp69p93.html
To start a new topic under jsr377-api, email [hidden email]
To unsubscribe from jsr377-api, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

Sven Reimers
In reply to this post by aalmiray
Are you really sure?  How should a mixed mode framework,  e.g. Swing and JavaFX figure this out?

Shall every view have an annotation indicating initialization vs. modification thread preference?

Let's go into more detail in the discussion..

-Sven
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

aalmiray
Administrator
@Sven,

A mixed mode application requires one toolkit to be in command. With Java8 it's possible for Swing, JavaFx and SWT to share the same UI thread given the right configuration. Using different UI threads with mixed toolkits is just asking for trouble ;-)

This means that the main toolkit drives the selection of the UI thread abstraction,.

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

aalmiray
Administrator
In reply to this post by Sébastien Bordes
Ambitious? Yes. Impossible? No. This feat has been accomplished by Griffon and Eclipse 4.
The key is a proper UI abstraction and leave the rendering as is, this means, no abstractions over widgets -> no common Button class for example; this leads to full fidelity of the chosen I toolkit.

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

neugens
In reply to this post by Sébastien Bordes
On Mon, 2015-02-23 at 09:38 -0700, Sébastien Bordes [via jsr377-api]
wrote:
> Yes you are right Andres, I have forgotten this fact : "The set of
> APIs proposed by this JSR will sit on top of any UI toolkit without
> requiring a bridge from a toolkit in particular; that is, none of the
> target UI toolkits (Swing, JavaFX, SWT) need to implement new APIs. If
> for some reason a bridge is required it will be provided from the RI
> side."
>
>
> Isn't this overly ambitious to target all toolkits ?

Yeah, perhaps it is, and we may be called on the need to adjust this
goal at some point, but I believe it's possible to have a very good
abstraction that delegates the idiosyncrasies of the various toolkits to
minimal parts of the API while retaining maximum portability.

It isn't easy of course, I believe we all have tried some sort of home
made solution to this problem and I bet hitting the same blockers at
some point :)

One way to solve this is in my opinion to keep the general issue about
the specific of the UI frameworks to the side, until the very moment we
need to write an abstraction for that (not as in not caring about that,
but just keep it under the eye enough to not make mistakes, but without
really addressing it until it is time).

To the specific of this issue, keeping a single UI thread model seems a
sensible solution since it's the default model for most UI as this helps
maintaining the internal state of the components coherent, from that is
quite easy to spawn multiple threads for maximum flexibility, the
opposite is not quite true though.

We may easy this up within our own API of course.

Cheers,
Mario


Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

raniejade
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

Benjamin Gudehus
In reply to this post by neugens
>The MVC triplets would have their own lifecycle, perhaps mostly defined
by the View requirements, but this is probably for later to discuss.

I really like this idea from a testing perspective, where we run through a complete lifecycle for each test case/method.
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

Tom Schindl
In reply to this post by neugens
It might make sense to document what lifecycle events Eclipse 4 current defined (I don't say they are good/bad nor I think they are complete enough)

* Application lifecycle
  - init: The framework has just booted and at a minimum the UI-Framework has been initialized which
           means e.g. SWT-Display has been created, JavaFX has been bootstrapped, ...
  - contribution components/modules have been registered and last shutdown state has been restored
    (where did windows, views have been displayed)
  ...
  - framework is shuting down - can be used to step in to modify what has been restored for the next
    startup, ....

* UI-Component lifecyle
  - @PostConstruct: Called once all @Inject stuff is done
  - @PreDestry: Called when the component is destroyed and you can clean up resources, at least on
    SWT you can not rely on GC
  - @PersistState: Called *before* the component is destroyed so that you can remember the state of the
    component e.g. what line in a table was selected, ... for the next time you get back
  - @Focus: Where do you want the focus to got when you activate the component which is important
     when you eg click on the Tab-Header you most likely want e.g. the first text-field to take focus so that
     you can type immediately

I myself miss some more lifecycle stuff. e.g. tracking when a window is about to close / closed, a perspective in eclipse is about to close / closed, ... where all "about to close" are vetoable
Reply | Threaded
Open this post in threaded view
|

Re: Application lifecycle

Hendrik Ebbers
Tom Schindl wrote
* Application lifecycle
  - init: The framework has just booted and at a minimum the UI-Framework has been initialized which
           means e.g. SWT-Display has been created, JavaFX has been bootstrapped, ...
  - contribution components/modules have been registered and last shutdown state has been restored
    (where did windows, views have been displayed)
  ...
  - framework is shuting down - can be used to step in to modify what has been restored for the next
    startup, ....
I think an init and stop step are the minimum. Should we provide a "wants to close" step that is vetoable?
About restoring the state: I think that we need to define how we want to save and load application states. Once this is done we can decide if we need a specific step in the application lifecycle.


Tom Schindl wrote
* UI-Component lifecyle
  - @PostConstruct: Called once all @Inject stuff is done
  - @PreDestry: Called when the component is destroyed and you can clean up resources, at least on
    SWT you can not rely on GC
  - @PersistState: Called *before* the component is destroyed so that you can remember the state of the
    component e.g. what line in a table was selected, ... for the next time you get back
  - @Focus: Where do you want the focus to got when you activate the component which is important
     when you eg click on the Tab-Header you most likely want e.g. the first text-field to take focus so that
     you can type immediately
I think persisting the state is normally an action that will be part of the PreDestroy phase of the lifecycle. A method that is annotated with PreDestroy will be called before the view / controller will be destroyed and I think that this is the perfect point to store the state. Maybe we will define a special state handler interface that can be injected and used to store the state of views. But this will only work if storing the state will be a blocking call. Mmmh
@Tom: Can you describe in a few words how the application & component state can be stored / loaded in e4?

@Focus: I don't know if we should add the focus to the lifecycle. If you need a specific behavior you can listen to the focus property. I had similar thoughts about "added to SceneGraph" and "Removed from SceneGraph" steps that can be used to start and stop animations for example. But I don't know if a general lifecycle should define all these steps.