Backward compatibility = the ability to open projects developed with older version of the IDE in a newer version of the IDE.
Backward compatibility is a critical feature for programming languages and IDEs.
There are several aspects for backward compatibility:
Source compatibility - This is the most obvious aspect and the most important one. The ability to load existing source code and run it without changes.
B4A was released 7 years ago. You can open projects developed with B4A v1.00 and they work as-is. Example: https://www.b4x.com/android/forum/threads/catch-the-bouncing-smiley.6442/#content
Over the years there were very few cases where existing code required changes. The changes required were minimal.
A few cases that I remember:
- In the new IDE (B4A v5.0) subs must start and end in a new line. You cannot write a sub like this:
This assumption is critical for the IDE performance.
- Bug fix of a relatively new feature which corrected the feature behavior.
- Panel_Touch event behavior was slightly changed when Android 4.1 was released due to changes in Android.
Overall you can be assured that there is highest priority for source compatibility and that we are doing our best to allow you to run your existing projects in newer versions of the IDE.
Binary compatibility - There are two different types of binaries. Standard Java / Objective C libraries that are based on native code and only use the "BA" object to raise events. Such binaries are not affected by newer versions of B4X and are always backward compatible (assuming that the OS itself is backward compatible). This covers most libraries.
The second case are libraries compiled with B4X or native libraries that access the core libraries APIs. These binaries are more sensitive to changes. There are many changes that are transparent to the B4X compiler but are rejected by the native layer. So the source code itself doesn't require any change but the compiled objects will break.
When possible the old API is kept. For example:
In most cases libraries will not be broken when a new version is released. There were some mistakes in the past and there were some cases where it was not reasonably possible to avoid breaking some libraries.
I recommend developers who distribute libraries developed with B4X to also include the source code. This will make their work future-proof (and will also allow other developers to port it to other platforms).
Backward compatibility is a critical feature for programming languages and IDEs.
There are several aspects for backward compatibility:
Source compatibility - This is the most obvious aspect and the most important one. The ability to load existing source code and run it without changes.
B4A was released 7 years ago. You can open projects developed with B4A v1.00 and they work as-is. Example: https://www.b4x.com/android/forum/threads/catch-the-bouncing-smiley.6442/#content
Over the years there were very few cases where existing code required changes. The changes required were minimal.
A few cases that I remember:
- In the new IDE (B4A v5.0) subs must start and end in a new line. You cannot write a sub like this:
B4X:
Sub Sum (x As Int, y As Int) : Return x + y : End Sub- Bug fix of a relatively new feature which corrected the feature behavior.
- Panel_Touch event behavior was slightly changed when Android 4.1 was released due to changes in Android.
Overall you can be assured that there is highest priority for source compatibility and that we are doing our best to allow you to run your existing projects in newer versions of the IDE.
Binary compatibility - There are two different types of binaries. Standard Java / Objective C libraries that are based on native code and only use the "BA" object to raise events. Such binaries are not affected by newer versions of B4X and are always backward compatible (assuming that the OS itself is backward compatible). This covers most libraries.
The second case are libraries compiled with B4X or native libraries that access the core libraries APIs. These binaries are more sensitive to changes. There are many changes that are transparent to the B4X compiler but are rejected by the native layer. So the source code itself doesn't require any change but the compiled objects will break.
When possible the old API is kept. For example:
B4X:
public void setText(CharSequence Text) {
getObject().setText(Text);
}
@Hide
public void setText(Object Text) { <---- this is the old API.
setText(BA.ObjectToCharSequence(Text));
}I recommend developers who distribute libraries developed with B4X to also include the source code. This will make their work future-proof (and will also allow other developers to port it to other platforms).
Last edited: