Wish b4x or b4e - a true cross platform solution

[Jack Cole]

The b4x tools are amazing. I can think of only one thing that would be better. I am thinking of a new tool called b4x or b4e that is truly cross platform. Imagine a visual designer that only includes XUI cross platform UI elements. Imagine cross platform libraries that include code for each platform, but require only one set of code in the actual code base. When you go to run, you choose the target platform and the system builds the app for that platform. This would put the b4x system in league with other popular cross platform solutions, but I think b4x would be better. Thank you for considering this option.

 

[Erel]

The next version of the IDE (already available in B4J v6) makes it much simpler to share modules between different platforms and projects. Referenced modules are linked and are updated automatically when there are changes.

Android <> iOS <> desktops (and Arduino is a completely different story)

The nice thing about the XUI framework is that you are not limited to the XUI available features.
Forcing developers to treat them as identical platforms means that developers are limited to the lowest common denominator of all three platforms. That's not good. It is better to be able to share 90% of the code and have full access to the unique features of each platform.

 

[Jack Cole]

I understand the philosophy of maximizing access to platform specific features over portability. I do think it is reasonable to maximize portability first and build in the options to extend to any native platform feature. What I mean is that you could have a XUI designer and also platform specific designers. In your code, you could do something like:

#if iOS
panel.LoadLayout("ios_layout")
#else if Android
panel.LoadLayout("android_layout")
#end if

To load an XUI layout, you'd just have one line of code.

What I am suggesting is that you get the lowest common denominator by default, but it can be fully extensible to platform specific features. This would be akin to what is done in some development systems.

 

[Jack Cole]

I took a look at the shared modules feature of b4j. That will make it much easier to share code between projects and platforms! My main source of pain is how to manage sharing code across very large cross platform projects. That will help! Any idea when the new ide will be released for b4a/b4i?

 

[Erel]

Any idea when the new ide will be released for b4a/b4i?

B4A beta will be released tomorrow morning. B4i will be released a few weeks later.

 

[Jack Cole]

Looking forward to seeing the b4a beta and the b4i release.

Please consider an XUI designer that would take one of the following forms. I'm sure you could probably think of something even better.

1). An XUI compatibility mode menu option in the existing designers. This would limit the views and define the view references with the XUI views. It would save to a bxl file that could be used across platforms.
2). An XUI designer as an option in the designer menu (just a separate designer available in b4j, b4a, and b4i). Again, saves a compatible file.
3). A standalone XUI designer released separately. Either saves a compatible file or allows you to generate bal, bil, etc..

Anyway, just some possibilities to consider. Thanks for all your work on this marvelous product.

Jack

 

[Jack Cole]

One last thought (hopefully). To expand on your innovation with file grouping, it would be nice to have an option to "Link a folder." This would help with cross platform development where the files could be shared between cross platform projects.

 

[mrred128]

The problem is that further cross platform optimization will degrade the finer points in the targeted device.

An example is the arduino uno. With only 2k of ram, b4r becomes useless with any amount of string usage, constants or otherwise. Much beyond "blink", you have to go back to C++ or use a bigger device (like an ESP8266). This us not a fault if B4R, but a side effect if RAD. They just produce fat code beceause of what they are.

Sure, B4I or B4A can bloat some more with little side effects...... But I am old enough to remember coding windows apps with as little as 10 lines if C code.

I think there us just enough RAD in there already.

My 2 cents.

 

[Erel]

With only 2k of ram, b4r becomes useless with any amount of string usage, constants or otherwise. Much beyond "blink", you have to go back to C++ or use a bigger device (like an ESP8266)

This is not really related to this topic however while B4R does add some overhead, in most cases the overhead is small. Strings in B4R will not take more memory than strings in C.

 

[mrred128]

It was just showing an example of what RAD tools do. This is an extreme case and in no way a fault of B4R.

I know IOS and Android are drastically different from each other and to effectively meld them together into one gui interface would be insanity.

The biggest differences between the two is that IOS is made to serve the interests of Apple and Android is meant to be functional; often polar opposites when interfacing. RAD is productive to a point. When you wind up curcenventing the RAD to get some finer interfacing (or flow) done, it gos down hill fast.

I program with all B4X tools and they work well. Conditional compiling picks up the slack and is enough for me. Expanding on that (and macros) could be an improvement.

 

[mmanso]

I think there's no doubts when we're writing a full app for the iOS or Android world, we'll need to use the custom aspects of each platform.

Where I think XUI (and a possible simple designer based on it) could be VERY powerfull is when we're developing simple applications to show concepts or ideas and we want to quicky show them on different devices and platforms. That would be very good to have out of the box. At the stage, we don't know yet where that idea or concept will end up and if needed and evolved, we would then focus on the particular aspects or both platforms.

It's in this "world" I would see XUI very usefull...

Cheers.