B4X : Some suggestions and ideas for Erel

[netkomm]

Hi Erel,

I have some suggestions about B4X and, given that for necessity I had to move away from B4A/B4I and jump ship to Ionic and soon Flutter, this is my feedback I can offer so that B4X could be a valid alternative to those environments especially for many of us who are a 1 man show and have to create applications cross-platform:

1. Unify the language on all platforms so that the same code fits all. Let the program (like a "transpiler") create then the correct version of the code for the platform.

2. Use only native interface elements. While B4X elements are commendable, they still lack the "native" feel and this has an impact on the end product as force the end-user to think while the tendency is - following the books by Steve Krug - "Don't make them think". Once again, when the compiler creates the application for a given platform, should compile and adapt the code for that platform.

3. Unify all the platform under a single application (likely B4X) so that we can really "write once, deploy everywhere".

I know that's not an easy feat but I feel that the base will follow you on this and support you in all possible ways if you want to make an effort in that sense.

Again, I have been forced away from B4A/B4I because I can't deploy apps fast enough and I am achieving that with Ionic. But I would come back to "our" platform if I had a tool that could help me deploy that fast.

 

[Erel]

Thank you for the feedback/

2. Use only native interface elements. While B4X elements are commendable, they still lack the "native" feel and this has an impact on the end product as force the end-user to think while the tendency is - following the books by Steve Krug - "Don't make them think". Once again, when the compiler creates the application for a given platform, should compile and adapt the code for that platform.

All the views in B4A and B4i are 100% native.

 

[Star-Dust]

In fact I didn't understand what he meant by point 2. Maybe it would be better to explain it with more details

 

[Alexander Stolte]

3. Unify all the platform under a single application (likely B4X) so that we can really "write once, deploy everywhere".

I like this point very much!

 

[Sandman]

In fact I didn't understand what he meant by point 2

I'll let @netkomm answer for himself, but my interpretation of that point was like this:

While the actual interface elements are native, the assembled b4x interface elements are themed in a way that they are neither looking like Android nor iOS:

Case in point, while I do love the ability to have a preference dialog (to just pick one nice thing from the b4x ui elements) to use this easily, it has never looked like this anywhere before. And personally, I've made a conscious decision to use B4i and B4a so that I can get the fully native look and not trigger a "oh, that's just a wrapped webpage" reaction that some B4x competitors causes. And if this b4x ui look catches on, I'm certain that it at some point would trigger a "oh, that's just a b4x app".

I want my users to use my apps and focus entirely on their task at hand, not wasting a single brain cycle on thoughts about how my apps are made. In a way the app is transparent, if you understand what I mean.

(For those here that haven't studied typography (I have), there is a saying among typographers:
”If the reader comments that a typeface is ugly, it's a bad typeface decision.
If the reader comments that a typeface is beautiful, it's a bad typeface decision.
If the reader just reads the text without even considering the typeface, it's a perfect typeface decision.”)

Bottom line is that for me the b4x ui elements are not usable at all at the moment. I haven't had time to investigate them, but as far as I think I've understood it I will be able to unpack them and make adjustments and then repack them. If that's correct, then that's what I will have to do with them all before I use them. That said, I do love that they exist. My only issue with them is that their theming isn't working for me at all.

 

[Erel]

BTW, the language (B4X) is the same in all platforms. The APIs are not always the same as the platforms are very different. The XUI library hides most of the UI related differences.

There are many things that you can do in Android and cannot do in iOS (and also things that you can do in iOS and are not the same as in Android). Not all differences can be hidden. With B4X you can share most of the code and also access all of the platforms unique features. There is a balance between allowing developers to access all of the platform features and abstracting the platforms differences.

 

[Erel]

Case in point, while I do love the ability to have a preference dialog (to just pick one nice thing from the b4x ui elements) to use this easily, it has never looked like this anywhere before. And personally, I've made a conscious decision to use B4i and B4a so that I can get the fully native look and not trigger a "oh, that's just a wrapped webpage" reaction that some B4x competitors causes. And if this b4x ui look catches on, I'm certain that it at some point would trigger a "oh, that's just a b4x app".

The UI screenshot is made of:
native labels, native text fields and a switch that is not native but looks very similar to iOS native switch.
The fonts and colors can be changed or improved. PreferencesDialog solution is a very young one.

Note that it will look different in B4J and B4A as the text fields (or EditText) look different.

Don't confuse XUI or B4X with "XUI Views". XUI Views is just a single library with a collection of cross platform extended views. You are never forced to use it and especially never forced to use all of its views.

XUI by itself is an abstraction layer above the native views.

 

[alwaysbusy]

There are many things that you can do in Android and cannot do in iOS, (and also things that you can do in iOS and are not the same as in Android)

Agreed. I prefer it the way it is now. Else you end up having to use the least common denominator like many tools do and you loose a lot for specific platform features.

 

[Sandman]

Don't confuse XUI or B4X with "XUI Views".

Yeah, sorry, I always mix those up.

 

[BillMeyer]

Maybe I'm just an old"f@rt" who is set in his ways, but I can never understand this.

I will use a parable to explain.
You buy a car and pay it off over a period of 60 months. You get the closest colour to your hearts desire and a reasonable economy of let's presume 8.0l/100km out of it.
At month 35, a new model catches your eye, exactly the colour you want, leather seats, a superior sound system and does 7.0l/100km, but is R100 000 more than your current car was at purchase time.
So You trade your old car and buy this new beaut !! You have NOT considered that you have all the teething problems ironed out, already have invested 36 odd months of payments in your current car and at R15 a litre for fuel - is that 1 litre saving actually a saving ? And your payments start at month one again for another 60 months !!

Are you really better off ? Or is it just a man things that the eye candy has caught your eye and clouded your vision ?

I recently had to undergo an argument with a client, whose 3rd party adviser to my app, suggested to the client that I was using Ionic and that he had a more modern instrument in the likes of Xamarin. When he heard that I used "Basic" for Android, I was called "geriatric" and stuck in the previous century - not knowing of course that B4A compiles to Java and B4i to Xcode or Objective-C - you don't get more modern than that !! My deployment of this said app also included the mySQL server via jRDC2 and CKvS - can Ionic or Flutter or Xamarin for that fact do that ? Can you then take what ever you have written as a back-end and deploy it on a Mac, a Win PC or a RPi ?

To say that you need "write once, deploy everywhere" is actually a dream that everyone has and a dream that will never happen until Google buys Apple or the other way around. You work with 2 different operating systems (if we consider mobiles alone) and Never, in my humble opinion, will your ever get a "One Size Fits All" whilst this is the case.

I am in the privileged position that my little team consist of two programmers. When we get a project in, one of us usually starts on a platform and then hands it to the other to complete in the alternate platform. We pay particular attention to UI as this is where most of the differences come in AS WELL AS knowing the policies of the two major players BEFORE we even start the project. As an example can you send an email automatically (without user intervention) from Android and iOS ? Think carefully before you answer - remember your client wants this and on both platforms !!

There is an old English idiom: "Better the Devil you Know than you Don't Know !!"

No where else, that I know of at this stage, do you get an "eco-system" as integrated as B4x and if you follow this forum carefully and observe you will see that all the new items now are "B4X" and if you can put pieces of the puzzle together to form a picture, and I am making a prediction here, B4X - Cross Platform - all in one place will be launched in due course !!

Just my 2 cents

 

[BillMeyer]

least common denominator

Beautiful words those - has a tendency to get the garden hose out and water things down, doesn't it ??

 

[Sandman]

There are many things that you can do in Android and cannot do in iOS (and also things that you can do in iOS and are not the same as in Android). Not all differences can be hidden.

I just want to state that I agree (as I think most do) that we shouldn't strive for the least common denominator, which would guarantee sub-par apps that nobody would love.

However, I would like to point out that from a conceptual perspective, there's nothing stopping us from having a single B4X IDE where we somehow could make special platform specific modules, for the things that are special for iOS/Android/Java - while still have the bulk of the app as a common codebase in the same IDE. That said I don't have the first clue on how challenging that would be technically to create such an IDE. I imagine it's brain-melting. Then again, Erel has a proven track record of handling extremely hot situations, so who knows.

 

[alwaysbusy]

When he heard that I used "Basic" for Android, I was called "geriatric" and stuck in the previous century

I never use the word Basic in front of clients. I always use B4X and IF they ask what it is, I explain it as Build For X so it builds for Java, builds for Object-c etc.

 

[Erel]

while still have the bulk of the app as a common codebase in the same IDE

You can already do it right now. All of the modules, except of the main module, can be shared between the projects. Check the XUI2D examples pack which includes 15 games: https://www.b4x.com/android/forum/threads/xui2d-example-pack.96454/#content
All of the game code is shared between the three platforms. In this case even the assets files are shared.

The 4 IDEs themselves share at least 90% of the code. They are very similar to each other. While a single B4X IDE might be implemented one day, I don't think that the benefits will be dramatic.

 

[Sandman]

I never use the word Basic in front of clients. I always use B4X and IF they ask what it is, I explain it as Build For X so it builds for Java, builds for Object-c etc.

I don't have clients that way, but if I did I sure would do the same. Except that I would probably say "yep, it's a real native app, compiled java and obj-C all the way". I can't imagine they would press for more details, but if they did, I would probably add something like what you said, seems perfect.

There's no coming around it: There's a stigma connected to the word Basic. Your choice of using Build instead is brilliant.

(Xojo felt that pain for many years, and probably still feel it today, even though they changed their name several times.)

 

[Sandman]

You can already do it right now. All of the modules, except of the main module, can be shared between the projects.

Yep, I know. And this is already awesome so I'm grateful for that.

The 4 IDEs themselves share at least 90% of the code.

I didn't know that. Very impressive!

While a single B4X IDE might be implemented one day, I don't think that the benefits will be dramatic.

Perhaps not for you, you live and breathe B4x and juggle everything with such ease. But for me, I'd say it would be significantly less cognitive load to just have one IDE and one codebase to juggle. (Albeit with special platform-specific modules, like I wrote earlier.) I don't know if I'm representative though, perhaps I'm the outlier and most are like you.

 

[udg]

Build For X

+1

Ionic:
Ionic Framework is an open source UI toolkit for building performant, high-quality mobile and desktop apps using web technologies (HTML, CSS, and JavaScript).

Xamarin (from Wikipedia):
Xamarin 2.0 was released in February 2013[29] Xamarin.Android and Xamarin.iOS that make it possible to do native Android,[30] iOS, and Windows development in C#, with either Visual Studio or Xamarin Studio.

React Native:
The apps you are building with React Native aren't mobile web apps because React Native uses the same fundamental UI building blocks as regular iOS and Android apps. Instead of using Swift, Kotlin or Java, you are putting those building blocks together using JavaScript and React.

 

[Mashiane]

Ionic Framework is an open source UI toolkit for building performant, high-quality mobile and desktop apps using web technologies (HTML, CSS, and JavaScript)

Why would anyone compare B4X with a web framework as per post 1 above? This is comparing apples to oranges... you cant and me thinks this is an unfair comparison. A brilliant man here came up with ABM and now BANAno for us to do beautiful web things. Like everything new, one always need to learn.

I think I am confused with the statement that says *deploy that fast* what does this really mean? I originally learned android to create Android Apps, I struggled until I found B4A which cut my programming time by ions. I had personally ran away from xcode until B4I came, I personally dont think its a *deployment issue* here but rather something else that the user can clarify. I do understand that when one is faced with tight deadlines, one would always prefer to use quicker alternative shortcuts, a homefront that one is already familiar with.

Ohh yes, in terms of 3, me thinks Mr Erel's b4x universe will eventually touch base there.

#My2Cents

 

[udg]

Why would anyone compare B4X with a web framework

That's why I pasted here their claims.
One can choose to use fundamentally a WebView to show a whole app or go native (even partially native) using building blocks offered by each platform.
I prefer the latter so long live B4X!

 

[netkomm]

Why would anyone compare B4X with a web framework as per post 1 above?

Ionic is much more than a "framework": the underlying language (Javascript/Typescript) is unique across the platforms and 99.5% of a cross-platform application can be done without even being bothered to address something on a specific platform.

p.s.: Ionic is compatible with Windows platform (but let's forget about this anyway... )

Controls look like android on android and ios in ios without anything that looks "weird" to the end user. And this has, at the end of the day a cost...

Point #2 - all libraries work across the board on all the platforms without the need to have a specific version for a specific platform.

Here the issue is to have a tool that allows minimizing the time we spend on a project.

B4(A/X/J/R) have different strong points but when I want to use it I have also to face the reality of the clients that expect a product for both platforms in a given timeframe and can't just say... "wait I have to make a version for XXX platform". Then specs change and I have to go back and forth between 2 projects to keep in synch.

At the end of the day when you think about it, you will need to think twice before using such a tool, because you may risk not to be profitable or become more expensive respect to your competitors.

Erel mentions that applications share 90% of the code. True. But we need to achieve a 99.5% compatibility of code because to go figure out the remaining 10% takes almost the same time as writing an app from scratch (which you still need to do...) while on Ionic it's just 10 seconds to prepare and compile...

--- and I haven't talked about Flutter that in coming releases is going to put Ionic to shame.

Maybe I'm just an old"f@rt" who is set in his ways, but I can never understand this.
To say that you need "write once, deploy everywhere" is actually a dream that everyone has and a dream that will never happen until Google buys Apple or the other way around. You work with 2 different operating systems (if we consider mobiles alone) and Never, in my humble opinion, will your ever get a "One Size Fits All" whilst this is the case.

It depends very much what is that you need to achieve... If we are talking in absolute terms... yes you are right: but here we are talking about being practical and trying to bring a rice bowl home to feed our family so... we can use specific "cross-platform" tools depending on what project we need to create. One thing is the theory one thing is the practice.

I had a (very big) project where I tried to use B4X tools - the value of the project was going to reach 250K dollars. After changing first to Ionic then React.JS we managed to bring down the cost to 150K dollars... enough said... but this is the sad reality I am facing. It's either adapt to the market or die.