Android Question code module life cycle

Discussion in 'Android Questions' started by leitor79, May 3, 2015.

  1. leitor79

    leitor79 Active Member Licensed User

    Hi,

    I have a project where I usq sql and keyvaluestore libraries.

    Since I'm using one instantiated object from the whole project, I'm thinking about the best (most optimal) way to use. I've thought using a code module like this:

    Code:
    'Code module
    'Subs in this code module will be accessible from all modules.
    Sub Process_Globals
        
    'These global variables will be declared once when the application starts.
        'These variables can be accessed from all modules.
        Private oSQL As SQL

    End Sub

    Public Sub GetSQL() As SQL
       
        
    Dim rSQL As SQL
       
        
    Try
       
            
    If oSQL=Null OR oSQL.IsInitialized=False Then
                
    If File.Exists(File.DirInternal,"database.db") = False Then
                    
    File.Copy(File.DirAssets,"database.db",File.DirInternal,"database.db")
                
    End If
                oSQL.Initialize(
    File.DirInternal, "database.db",  False)
            
    End If
            rSQL=oSQL

        
    Catch
            
    'doing stuff
        End Try

        
    Return rSQL
       
    End Sub
    So, wherever I need to use the SQL object, I get it using MyModule.GetSQL function. But since I'm not familiar with the code module life cycle, I'm wondering what happen with the oSQL object after the call ends or after the calling activity/service module ends. The idea is to get oSQL instantiated as long as possible, right?

    Same thing with the KeyValueStore object (not defined yet)

    Is a code module the right option to do something like this? Is this way a good option?

    Thank you very much!
     
  2. Erel

    Erel Administrator Staff Member Licensed User

    Code module is a good option here with one limitation. You will need be able to use the async methods as code modules (in B4A) do not support events.

    Code modules do not have a very interesting life cycle. Process_Global variables are kept as long as the process is running and they don't have any other context of their own (this is why they cannot handle events).
     
  3. leitor79

    leitor79 Active Member Licensed User

    Hi Erel, thanks for your answer!

    So, if my app has 3 services, the module process_global are kept as any of the services is alive, no matter which uses the module first?

    Thank you very much!
     
  4. DonManfred

    DonManfred Expert Licensed User

    process_global is not a module. It is a sub in a Activity or a Service for example.
     
    Last edited: May 5, 2015
    lemonisdead and eurojam like this.
  5. Harris

    Harris Well-Known Member Licensed User

    You are right on track.

    If I remember correctly, code modules was one of the first upgrades that Erel introduced after creating B4A (we only had activities to begin with).

    Code Modules are the repository for your ad hoc functions / procedures / methods (or whatever) that you may call from any other source (activity, service, etc).
    I have several code modules in my apps, named according to what specific task (group) they may perform.

    Prior to CM, duplicate code was required in each activity. One can only imagine the problem this caused with keeping them up-to-date.

    Making your app work full time, regardless of what app (or activity) is in view, you require a service. Frankly, my app would be USELESS without a service to keep things running while in the background - and started on first boot of a device.
     
  6. leitor79

    leitor79 Active Member Licensed User

    Hi DonManfred, thanks for your answer.

    I've missed a few words when I wrote the question; here I go again:

    So, if my app has 3 services, the module's variables declared at process_global are kept as any of the services is alive, no matter which uses the module first?

    And also, I add the following:

    oSQL must be declared as "Public", or an exception will rise sometimes when using it from other module (activity or service) than the one that instatiate it before.

    Thank Harris for your answer, too.

    I understand no service is guaranteed to be kept alive forever by android. So, as I have 3 services, maybe the chance that at least one of them is kept alive would suffice to keep some module's object instatiated. What do you think?

    Regards!
     
Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice