Android Tutorial Modules Attributes

Erel

Administrator
Staff member
Licensed User
Basic4android v2.50 includes a new method for handling project and modules settings.

These settings are now set in the code itself. The menu items were removed.



The attributes syntax is simple. The hash sign (#) followed by the attribute name, a colon and the value.
Some attributes can appear more than once in the same module.

Different modules (activities, services, ...) support different attributes. The IDE will show a list with the supported attributes when you press on the hash key.

The project related attributes should be placed in the main activity.
Note that the #Region / #End Region directives are not required.

The attributes will be added automatically to existing projects when they are first loaded with the new version.

The purpose of this feature is to make it simpler to support new features that require advanced settings.

Project attributes (should be placed in the main activity)
  • CanInstallToExternalStorage - Whether the application can be installed to the external storage. Values: True or False
  • SupportedOrientations - Sets the supported orientations. Values (case is important): unspecified, portrait or landscape (other possible values)
  • ApplicationLabel - The application label that will appear in the applications list (string)
  • VersionName - Version name (string)
  • VersionCode - Version code. Must be an integer
  • Library compilation attributes. Covered in the library compilation tutorial
  • CustomBuildAction - See the Custom Build Actions section in this tutorial.
  • AdditionalRes - Specifies a folder with resource files. These resource files will be added to the APK. This attribute also accepts an optional parameter, the package name of an Android library project. This is required when wrapping a library that includes resource files. See this example: jfeinstein10 SlidingMenu libraryYou can use this attribute multiple times.
  • DebuggerForceFullDeployment - Forces the rapid debugger to redeploy the complete project every compilation. This can be useful if you see slow performance after modify the code. It will disable the quick redeployment feature of the rapid debugger.
    Values: True or False.
  • DebuggerForceStandardAssets - Disables the virtual assets feature of the rapid debugger. By default the rapid debugger doesn't use the standard assets folder. This allows the debugger to only redeploy updated files. Values: True or False.
  • ExcludeClasses - Can be used to strip library classes during compilation: https://www.b4x.com/android/forum/threads/new-feature-three-birds-with-one-stone.63127/

Activity attributes
  • FullScreen - Whether to show the top bar. Values: True or False
  • IncludeTitle- Whether to show the title. Values: True or False

Service attributes
  • StartAtBoot - Whether this service should start automatically after boot. Values: True or False
  • StartCommandReturnValue - (advanced) Sets the value that will be returned from onStartCommand. The default value is android.app.Service.START_NOT_STICKY. See this link for the possible values.

All modules support the following attributes:
  • ExcludeFromDebugger - Whether to exclude this module from the debugger. Debug information will not be added to this module. Values: True or False
    This attribute is only relevant to the legacy debugger.
  • IgnoreWarnings - A list of warnings numbers that will be ignored in this module.

Custom Build Actions

The build process is made of a number of steps. You can add additional steps that will run as part of the build process. For example you can run a batch file that will copy the latest resource files from some folder before the files are packed.

Another example. You can use this code to mark all files under res folder as read-only (and prevent the compiler from deleting them):
B4X:
#CustomBuildAction: 1, c:\windows\system32\attrib.exe, +r res\*.* /s
Note that you can add any number of build actions.
CustomBuildAction should be added to the main activity.
The running folder is set to the program objects folder.
The syntax is:
<step id>, <program to run>, <program arguments>

step id can be one of the following:
1 - Before the compiler cleans the objects folder (it happens after the code is parsed).
2 - Before R.java file is generated.
3 - Before the package is signed (the APK file at this point is: bin\temp.ap_).
4 - Before the APK is installed.
5 - After the APK is installed.
6 (new in v5.01) - After Java compilation.
 
Last edited:

airblaster

Active Member
Licensed User
Sounds very interesting!
Will it be possible to use variables in Attributes and Custom Build Actions?
 

Erel

Administrator
Staff member
Licensed User
Will it be possible to use variables in Attributes and Custom Build Actions?
The first version doesn't support any variables. However variables can be added later if needed.
 

Cableguy

Expert
Licensed User
This will make version managing very more simple... at least for me... I keep forgetting to update it in settings...

Variables would be nice, since we could set different attribute according to the hardware the app was installed on....
 

Jost aus Soest

Active Member
Licensed User
Realizing Plug Ins...

Wow, that's great! :icon_clap:

1. So I can finally realize some of my ideas mentioned here:
[Wish] Plug-Ins for IDE/Compiler?

2. So an #include-directive isn't far away, is it? ;)
(Implemented directly by Erel, or by myself using #CustomBuildAction...)

3. It would by nice to have the possibility to specify dependencies (libs, other moduls), so we must not remember such things personally, e. g.:
B4X:
#libs Reflection, Phone  'check libs, if not already checked
#uses mStrings, mHelper  'adds these modules, if not already loaded
 

Erel

Administrator
Staff member
Licensed User
So an #include-directive isn't far away, is it?
Like in C where the code gets added to the current module? It will be problematic to add it with a build action as build actions run after the parser step.
 

Peter Simpson

Expert
Licensed User
That is excellent, what a great simple feature :)

Anyway, Happy new year Erel and thank you for all your hard work and dedication to B4A :)

Sent from my Galaxy Nexus using Tapatalk 2
 

NJDude

Expert
Licensed User
Cool new features.

One request, instead of:
CanInstallToExternalStorage - Whether the application can be installed to the external storage. Values: True or False
Why not:
InstallLocation - internal, external, auto
That way I would avoid adding this line to my manifest:
B4X:
SetManifestAttribute("android:installLocation", "auto")
 

Erel

Administrator
Staff member
Licensed User
The only reason is backwards compatibility. It could have been solved, however I decided that it adds (mostly) unnecessarily complexity, and the solution you use with the manifest editor is not too cumbersome.
 

maleche

Member
Licensed User
Nice feature!

It would be great to have this available in a menu dropdown even though you can start the line with # to view the options.

GREAT JOB!
 

yo3ggx

Active Member
Licensed User
Attributes not automatically added

Basic4android v2.50 includes a new method for handling project and modules settings.

These settings are now set in the code itself. The menu items were removed.

....
The attributes will be added automatically to existing projects when they are first loaded with the new version.
Hi Erel,

First I want to thank you for you excellent work done with 2.50.
I have tried to load my projects in the new version and the attributes are not automatically added to the code.

It is something more to be done for this?
I can do it manually, but I need to load first in the previos version as I don't remember the value for all of them.

Thank you,
Dan
 

Erel

Administrator
Staff member
Licensed User
It should happen automatically. Can you send me your project by mail (erel@basic4ppc.com)?
 

yo3ggx

Active Member
Licensed User
Hi Erel,

It was my fault.
The section was by default shrinked and I haven't observe it.

Sorry for this.

Thank you,
Dan
 

RiverRaid

Active Member
Licensed User
Wow..

big changes, Thank you!! :sign0098:

Is it somehow possible, to use #ApplicationLabel for localisation? (My App has differnt names in different languages)?

And is there a plan to support the new lockscreen - widgets in the future?

Thanks,
Andi
 

Erel

Administrator
Staff member
Licensed User
Is it somehow possible, to use #ApplicationLabel for localisation? (My App has differnt names in different languages)?
No. Though you can do it with the manifest editor by supplying a reference to a resource file: How translate App Label

And is there a plan to support the new lockscreen - widgets in the future?
This question is not related to this thread. However it is already possible: Android 4.2 Widgets
 

CidTek

Active Member
Licensed User
Does the version number increment every compile or does it have to be edited manually in the attributes?
 
Top