Codename One - "app" lifecycle

[P5music]

My Android app is simple but it handles rotation, start from an intent (cold and warm) (old intent or new), start from home, and so on. The methods that are called are not always know, so sometimes more than a single method are called. For example onSaveInstanceState and onConfigurationChanged are not always independent.

My app has to manage editing data in the detail view. For example it tries to ask the user whether it has to save, before going back or choosing other records.

In many case this has to be done silently because the app is just undergoing some strange eevent or transformation.

Furthermore the app singleton sometime is lost.

Codename apps seem to be simpler from this point of view, but I need to know if there is some "singleton" class I can count on every time, unless the app is destroyed.

I see that there is not fragment and activity cycles so I think this is easy.

Thanks in advance

[Shai Almog]

Yes. Our activity works a bit as a singleton and simplified the horrendous Android app life cycle.

As a side note a few years ago in Google IO Romain Guy asked audience members for a show of hands if they know the Activity lifecycle. Hands were raised and he responded (I'm paraphrasing) "liars, I've been on the Android team since before it launched and I don't understand the Activity lifecycle".

I created a relatively simple app lifecycle diagram for the Uber clone book. The first two chapters (which include the diagram) are a free PDF download from here: https://uber.cn1.co/

[P5music]

1-So the Codename app singleton is recreated just in what cases?

I think device orientation at least, and then?
2-Where can I put some global data structure, in the main form I guess?

Thanks in advance

[Shai Almog]

Only in the case the app dies.

1. It's reused for device orientation.

2. You can put global data anywhere you want. I often just put settings in Preferences so they will remain between executions.

[P5music]

I am passing references to the Containers and Forms that are called from the main app class, for example the parentForm or global data.

Said that the app is the singleton and only can die in certain cases (if I am not wrong), I woud like to know whether I have to use WeakReference so to avoid circular reference or I can just use normal references.

I hope this makes sense.

Thanks in advance

[Shai Almog]

Use normal references. If the app dies it dies. We don't do the weird "partial death" behavior of Android.

You should try to respect stop() though and stop networking etc. in that case (with the special case of background processes).

[P5music]

I have things like this in code:

FormSubClass formToCall=new FormSubClass(Form mainForm, AppData appData,...)

then showBack() is used when the back command is called in the new form.

Does this impact on the references?

I mean, a for is created every time. Is this bad practice?

Thanks

[Shai Almog]

If you don't keep a reference to the form then it gets GC'd and it's a good practice to keep memory low. Recreating a form is relatively cheap.

[P5music]

I have to keep the reference because I have to handle the back command. So I have to use another method or use WeakReference<>, as I understand.

Is this correct?

[Shai Almog]

No. Keeping the reference to the parent form is fine (you don't recreate it). I meant don't keep the reference to the child form.

Weak references can get GC'd randomly. They're only meant for cache.