[Lazarus] Hints for Android

[Sven Barth]

Am 12.04.2013 10:46, schrieb Felipe Monteiro de Carvalho:
> On Fri, Apr 12, 2013 at 10:18 AM, Sven Barth
> <pascaldragon at googlemail.com> wrote:
>> Every form should have it's own Activity and
>> the global state should be mapped through an extension of the
>> android.app.Application class.
> Do you have any link to the docs that say that every window should
> have a new Activity? Window does not descend from Activity. It does
> not look correct to me... but I will study the issue.
This is how all those Java examples work. You want to show another view? 
Do a new activity...
>
> For dialogs at least I am 100% sure they don't use one Activity per
> dialog. Nothing in the docs here about this:
> http://developer.android.com/reference/android/app/AlertDialog.Builder.html
>
> Also: if I don't do it like that what's the difference for my user? I
> haven't see one so far.

A main problem is the lifetime of activities: if the user changes the 
activity (e.g. from your app to the phone app) it is more or less normal 
that the activity will be closed and restarted when the user switches 
back. The native library won't be unloaded however, because the process 
will continue to run until the OS decides that it needs the resources 
(or shuts down). In the current implementation this restarting of an 
activity also means a reinitialization of the application, because the 
ActivityOnCreate handler will be called again. This normally also means 
that the CreateForm calls will be run again which can result in memory 
leaks if done "right". This could be solved by using a descendant of 
android.app.Application to hold the global state.

And for multiple activities: if you use multiple activities you can 
still use the approach of using only one activity for all forms by 
reparenting forms or using frames. You can't go the other way round 
currently. Also using multiple activities can simplyfy/clarify the 
registration for intents.

> Also, I know applications with millions of downloads in the store
> which don't use one Activity per window and never saw a problem with
> it. We use one activity for the main application and another for the
> crash logger, but not one per form AFAIK, thought I am not 100%
> knowledged in the source code.
>
> Anyway, even if I went to change this (which so far I am not convinced
> of), it is hardly a "rewrite". Something like 0,1% of the code would
> need to be changed.
If you think only a little part needs to be changed for this, then the 
better :)
>
>> Also you didn't seem to notice that the only
>> fixed exports that are really necessary are JNI_onload and JNI_onunload. The
>> other ones can be inserted using JNI which you already provide a possiblity
>> for but you've added the comment "apparently not needed" there and didn't
>> complete that. Of course, if you manually export all functions you don't
>> need that, but if you use this dynamic JNI approach you reduce the amount of
>> functions that the user needs to export to just two basic functions.
> Ok, now this is something interrested that I just learned! I had no
> idea about this.
Now you know it :)
> This is trivial to change, the only work will be
> testing in all the devices if it still works afterwards. I tested the
> current implementation in dozens of devices.
>
And then there are the usual problems that the CustomDrawn-Android 
widgetset is still experimental (so not necessarily a problem of the 
interface design). There are different problems with resizing, etc., but 
this could probably be a problem inherent to the LCL itself, because 
it's originally based of fixed pixel designs... When I find the time 
again I can try to report bugs regarding these.

Regards,
Sven