Other [new feature] Three birds with one stone

[Erel]

B4A v5.80 includes a new attribute named #ExcludeClasses.

Example:

#ExcludeClasses: com.google.ads, anywheresoftware.b4a.phone.RingtoneManager

During compilation, all classes from all referenced libraries, that their full name (package + class) starts with one of the above prefixes, will not be included in the APK.

Why is it useful?

1. Smaller APK, faster compilation and faster installation. This is especially useful when referencing the large google play services library.
2. Removing libraries based on the selected build configuration. Like all other attributes you can use compilation symbols to add or remove this attribute.
   
3. Removing unsupported classes. For example, Amazon rejects APKs that include the RingtoneManager classes. So instead of modifying the Phone library, you can exclude the problematic classes.

As google play services is the main candidate for this feature, any prefix that starts with a dot will be converted to google play services package (com.google.android.gms).

If you are only interested in the maps functionality of google play services:

#ExcludeClasses: .games, .drive, .ads, .fitness, .wearable, .measurement, .cast, .auth, .nearby
#ExcludeClasses: .tagmanager, .analytics, .wallet, .plus, .vision, .gcm

 

[ArminKH]

isn't it better if unused classes removed automatically by compiler? like a future which is exist in b4a named Clean Project ?
i know maybe this is headache(or not for u) when compiler need to looking for relations between classes and need it's own strategy,but u can have this in your mind as a wish for the next version of the next version.
any way this is really great future at all and thank u.

 

[DonManfred]

The next version of B4A

Do you know an ETA for the new B4A Version? Asking about the new CustomProperties for CusomViews-Feature in next B4A Version

 

[Erel]

isn't it better if unused classes removed automatically by compiler?

This feature allows you to strip out classes from the referenced jars not from your project. The compiler cannot know which classes are not required.

Do you know an ETA for the new B4A Version?

The beta version will be released in a week or two.

 

[Erel]

Another important new feature:

CreateResource command in the manifest editor.

SetApplicationAttribute("android:theme", "@style/AppTheme")
CreateResource(values, theme.xml,
<resources>
  <style name="AppTheme" parent="android:Theme.Material.Light">
  <item name="android:colorPrimary">#FFEAC80E</item>
  <item name="android:colorPrimaryDark">#FFEA0ED7</item>
  <item name="android:colorAccent">#FFF8F8F8</item>
  </style>
</resources>
)

CreateResource creates an XML resource file. In the above example a file named theme.xml will be created under res\values.

This makes it easier to customize the themes, all from the manifest editor.
Remember that the manifest editor supports conditional compilation. So it is also possible to change the resources based on the selected build.

 

[LucaMs]

This feature allows you to strip out classes from the referenced jars not from your project. The compiler cannot know which classes are not required.

I suppose you are sure about this. The compiler knows if a routine of a my class module is unused: cannot it "explore" the jar, search for unused public routines in the project and exclude them?

[I also suppose, the answer: "No" ]

 

[lemonisdead]

I also suppose, the answer: "No"

Seems to be very costly since we can do it by hand

Edit: sorry, what I mean is : the compiler should do this each compilation time // we do it one time when we create the app and can change it after to adapt

 

[Erel]

The full answer is that the compiler can strip unused classes but not without mistakes. With mistakes I mean that it will remove required classes. Think about the usage of reflection inside a library (and there are such usages). A static analyzer will not be able to know which classes are used.

For further discussions about this topic, please start a new thread.

 

[LucaMs]

Seems to be very costly since we can do it by hand

Edit: sorry, what I mean is : the compiler should do this each compilation time // we do it one time when we create the app and can change it after to adapt

I know, but we will spend more time than the compiler and we could make mistakes.
If necessary, we could choose an "exclusionary compilation" only for the final release

 

[LucaMs]

The full answer is that the compiler can strip unused classes but not without mistakes. With mistakes I mean that it will remove required classes. Think about the usage of reflection inside a library (and there are such usages). A static analyzer will not be able to know which classes are used.

For further discussions about this topic, please start a new thread.

To understand this answer I need more time, and I'm running

Thank you

 

[sorex]

Excellent! I've been waiting for this for decades with other compilers that added too much unused stuff.

 

[LucaMs]

The full answer is that the compiler can strip unused classes but not without mistakes. With mistakes I mean that it will remove required classes. Think about the usage of reflection inside a library (and there are such usages). A static analyzer will not be able to know which classes are used.

To understand this answer I need more time, and I'm running

Thank you

I got it

 

[Robert Valentino]

Will the new version offer SPACES instead of TABS?

BobVal

 

[Informatix]

I will continue to use ProGuard as it shrinks my APK automatically, but it's a great feature anyway. The new version is more and more attractive.

 

[Erel]

Will the new version offer SPACES instead of TABS?

It is better to start a new thread for such questions. The answer is no.

 

[Erel]

Example of using CreateResource to set the native light theme on Android 4+:

SetApplicationAttribute(android:theme, "@style/LightTheme")
CreateResource(values-v20, theme.xml,
<resources>
  <style
  name="LightTheme" parent="@android:style/Theme.Material.Light">
  </style>
</resources>
)
CreateResource(values-v14, theme.xml,
<resources>
  <style
  name="LightTheme" parent="@android:style/Theme.Holo.Light">
  </style>
</resources>
)

 

[ArminKH]

Example of using CreateResource to set the native light theme on Android 4+:

SetApplicationAttribute(android:theme, "@style/LightTheme")
CreateResource(values-v20, theme.xml,
<resources>
  <style
  name="LightTheme" parent="@android:style/Theme.Material.Light">
  </style>
</resources>
)
CreateResource(values-v14, theme.xml,
<resources>
  <style
  name="LightTheme" parent="@android:style/Theme.Holo.Light">
  </style>
</resources>
)

also can be used for animation xml files?

 

[Erel]

Yes, it can be used to create any text based resource file.

 

[Guardian17]

For #ExcludeClasses, does there exist some list of all classes that can be excluded, so that I can examine the list and then determine what I can Exclude?

 

[Erel]

You can always open the jar file with a tool such as 7zip and see all the classes and packages.

Specific to google plays services then the list I posted in the first post covers all the non-small packages. The only one missing is .maps.