Android Tutorial When to use activities and why.

Why use Activities?

In B4A as in Android, an activity is like a form in other languages such as Delphi, C++ Builder, VB, etc. Activities can start other activities, use code modules, classes, and views (components). This is not intended to be a tutorial on writing activities, but as a suggestion of when to use activities and why.

The Main activity carries all of the code to run the app, and is the first activity created in the project. Other activities added to the project are like chapters in a book. They can do most of the same things that the main activity can, and are basically stand alone applications. They are used to separate and modularize apps into more manageable sections of code to make maintaining the project easier. All modules and activities in a project have access to the libraries that you include, as well as access to any code modules used.

It's up to you if and when you use separate activities. You might create a new activity inside your project to handle configuration screens, or file management, or contact management. You can use them for just about anything you want. You can even import an existing B4A app, but that takes a bit more work.

Some use Panels to do the same things, and that is what I prefer in smaller apps. The problem is that once an app starts getting a few thousand lines of code in the main activity, it becomes a nightmare to maintain a month or a year from now when you want to release an update.

Activities (and code modules) help keep your code broken into logical sections that handle specific tasks. At the same time, they make coming back a year later to do that update much easier since you laid out your activities and modules into logical sections to begin with when the project was originally written and updated.

As an example, consider a fleet management app for a cab company. The main activity might handle a menu and loading any configuration files that are used throughout the app. It might display information about the cabs that are in service now. Another activity might display GPS data and current call status on all or a selected cab. Another might handle all setup and configuration options, or scheduling, or vehicle maintenance. It can be designed the way you want so that it is easier to maintain in the future.

Activities can share variables that are declared in their Process_Globals section. This makes it easier to reference variables throughout the app. You must prepend variables from other modules with the name of that module. If I want to use a custom type (like a Record in Delphi or a Stuct in C) variable from the Setup activity named cars, I would have to use Setup.cars to access the information stored in it. The same is true when you want to access a Process_Global variable from the main activity in another activity. In that case, we would use Main.variablename.

You start an activity using an Android intent just like you would if you called another app from within yours. Don't panic, it isn't as scary as it sounds. In this case we use StartActivity("youractivityname"), and it does all of the work for you. You can also design your app so that other apps can access the activities in your app through intents like the Android Settings app does, but for now, lets concentrate on using activities in our own apps.

Don't forget about code modules while designing apps. Activities can't share their subs with other activities, so code that you use a lot should be in code modules or class modules. There is no sense in re-writing the same sub or having to copy frequently used subs when you can use modules to share those routines throughout your app.

The only drawback to using activities in your app is a slight delay the first time one is loaded. This delay is only noticeable on older slow running devices, but it is there. Once it is loaded, it stays in memory unless the device runs low on resources. Remember that the whole point to using activities is to make smaller, more manageable sections of code. If you design large activities, that delay in loading the first time will be greater, so test and decide if that drawback applies to your app. Test it on the Android emulator. It runs slower than death and can be considered a worse case scenario most of the time.

Happy coding.

--- Jem
 

inakigarm

Well-Known Member
Licensed User
Longtime User
Try Genymotion instead AVD, It's very fast, easy to install and free (I usually work with the device or Genymotion, never with AVD)
 

thedesolatesoul

Expert
Licensed User
Longtime User
Try Genymotion instead AVD, It's very fast, easy to install and free (I usually work with the device or Genymotion, never with AVD)
I dont think your reply is relevant here. He is recommending to test on the AVD for worst case scenario.
 

HotShoe

Well-Known Member
Licensed User
Longtime User
Jem says:
But you can use CallSub and callSubDelayed between activities to access subs between them.

Good point! That completely slipped my mind.

Thanks,

--- Jem
 

thedesolatesoul

Expert
Licensed User
Longtime User
Jem says:
But you can use CallSub and callSubDelayed between activities to access subs between them.
No you cant (as far as I know). CallSub cannot access another activity as it is not loaded in the foreground (and only one activity can be foreground). CallSubDelayed would try to start the other activity.
 
Top