B4J Tutorial [BANano] Lessons learned whilst creating b4xlibs - trials & errors

L1: Creating BANano b4xlibs is a painstaking process

The art of creating a BANano b4xlib is very laborious. First you need to understand what your vision and intensions are and the value that such will add to the process. When you get a lib to make a BANano b4xlib, you need to study everything about that javascript library, understand how is it finicky, how content is related across the library as a whole.

This then has to be written as BANano code, some things might work and some things might not. Be prepared to research, google and find solutions. After-all anything that can be done in BANano can be done in javascript. The thing with that is knowing how to write the code in BANano. Also thanks to #if javascript, at times you can bypass that process of rewriting by just using the pure thing.

L2: Documentation is crucial

I remember, that before the BANano ebook came into being, one was learning and is still learning through asking questions, finding and reporting bugs, exploring and exploring and exploring. It is true, in most cases, the person who knows more about the library being created is the author, more that the end users. To help out other developers know as much as possible about the library, documentation is crucial as part of the delivery offering.

There are things that I only grasped after I read the BANano ebook for example, these at times made me realize that some things I did in my libraries could have been written / done differently. Yes at times asking a lot of questions is not thee viable solution, as users can and will find things from reading, better. Some questions might remain un-answered and one does not necessarily all the time get solutions quickly. This requires patience.

This documentation challenge has been evident with BVAD3, yes there are a vast number of tutorials, videos, threads etc, however people are receptive to content in different ways. Whilst releasing BVAD3, I should have also released a 'user manual', same time. This however is not always easy to achieve. These libraries are not always bread an butter issues but are there to help others achieve their dreams, something at times has to give, balancing a hobby vs source of income.

The Vuetify library which is the basis of BVAD3 is being re-written for Vue3, this provides a great opportunity to use the latest advanced features for BVAD3 and also attempt to create a "user manual" at the same time. In whatever way, a balance has to be reached.

L3: There are 2 types of Developers

There is always 2 types of developers, those who really like to use the Abstract Designer an those who are die hard, code every line kind. Understand the dynamics.

Initially BVAD3 was developed for the die had code every line scenario. This is evident with the single VueElement class which was the baseline for everything in the first versions of BVAD3. When the shift was made to balance the scale and explore the use of the Abstract Designer, more components were added. This additional bloat increased the size of the library.

A balance needs to be reached when creating b4xlibs so that a balance is reached for the end market, i.e developers. This balance affects how the b4xlib is designed and structured. These design choices need to be made before the first line is ever written for your b4xlib. Some b4xlibs are just easy to create and other complex. This was more evident for BVAD3 as the library evolved to make it easy to use whilst maintaining its simplicity internally.

Whilst the library now fully supports these types of developers fully, planning this process at the planning stage of b4xlib creation is crucial.

L4: Developers will not necessary ask questions when they are stuck

I have enjoyed the kind of questions that have been asked. I like the realization that the library is being used and for good things. There are some developers who like to find solutions themselves and will search and research until a solution is found.

A "Your Voice Matters" campaign was launched, a "Bug Finder" campaign was also launched, these received very few interactions. Whilst the feedback was very positive, some at times was not so positive. Whilst constructive criticism is welcome, after all, not each of one is perfect. I still believe that if as an end user, you have at least asked a single question when you were stuck, it helps, you.

Most of the issues raised in these campaigns have been attended to, the exception being post 3 above as that will be covered with the new version. Fortunately the Kitchen Sink WebApp is searchable for anything you need, has a section that explains the whole BVAD3 API in detail, each page one sees has a base code done using the abstract designer.

L5. Keep it Simple & Small

Vuetify in itself is for enterprise applications mostly. There is not a single thread that I have successfully seen with a mobile app fully implemented with cool awesome examples in the interweb. I stand to be corrected. Its a large library, and this does not mean you cant create mobile apps with it, you well can. This has been done with a vast number of them that I released here in the forum.

It was not so long ago that I learned that the "abstract designer" approach can give you bloated software. This came with the advise that the number of properties one uses in the abstract designer should be kept to a minimal that are mostly used. After transpilation, the whole abstract design becomes a JSON object in your code. In all the pages it is used in, it will always sit there with 5 or 6 properties out of 20 that are used.

Granted, there are some abstract designs that need this big property bag existing as found in some components I use. At times its just easy to set everything in the abstract designer at times. Remember there are 2 types of developers... Personally I try as much as possible to avoid having to write code and use the abstract designer. This is not always the case for other developers.

Eventually, the smaller your abstract design is, the better it is to minimize code / final product bloat.

B4xCode Conversion / Transpiled to JavaScript: 2 lines of b4xcode can become 6 lines of javascript.

Its important to write optimized code for your b4x lib. When the code is "transpiled" to javascript, the b4x code is converted to javascript. This means 2 lines of b4xcode might become 6 lines of javascript code. Its good to write small functions and also try as much as possible limit the use of strings e.g. string builders.

L6. The User Base & Support

Developers might be actually very quiet, not part of your "telegram", not even sending you or asking anything, however are using your library. This invisible user base is very interesting. Some might just be "watchers" on the momentum. Others are visible and need support.

It's important that whatever bug found is reported so that the software works as expected. This is why I love bug finders because they help stabilize the product as they are using it everyday. As the forum is about helping other developers, the newly added "mark as solution" is one of the best things, it helps others find solutions without having to read the whole thread.

This comes with (a) any question asked in the forum about the library SHOULD BE ANSWERED and also when a person is provided a solution, it will be awesome, if they can mark the answer as a solution & even prefix their title with [SOLVED]. Prefixing questions with [BANanoVuetifyAD3] or [BVAD3] helps in this regard to streamline ambiguous question titles.

This helps other uses with the confidence of visible support for your tool and the commitment. Yes, at times, due to other constraints, we are not always connected.

L7. Testing & Testing & Testing & DEPRECATED content

Finally I have taken a rest from BVAD3 development as it has reached the stage that it was meant for. This however was a very long task, numerous releases, missed testing because releases only to find bugs later on, fixing these etc etc.

There have been DEPRECATED features that were also not serving any purposeful value which had to be changed for more value added services. Whilst the Kitchen Sink WebApp is the best presentation of what BVAD3 is offering, working 110% and being the best Vuetify implementation for BANano in the world, reaching that stage was not an easy feat.

During the development, the testing over and over of the lib has been necessary. At times, one would fix one bug and another bug which didnt exist before would creep up. This has required a lot of patience and a lot of time.

L8. The kindness & understanding & advice

BVAD3 is very unique and is not like any other framework and it stands in its own merits. It continues to receive a lot of humongous support, good advice and this is one of the greatest assets it has, the interested users, the existing users, the others who continue to request features.

There have been things that have been challenging to implement and even do, however through the involvement of the forum community, things have been possible. I humbly thank you for your continued support of this library. Lets continue changing the world.

L9. Finishing what I started

In my drawer there are a few projects that I have not finished yet, a lot has been finished and deployed successfully. Starting and finishing this b4xlib is an achievement I do not take lightly. BANano was never developed to work with anything like Vue, guess what, it was made possible with help from friends. Seeing BANano evolving in the way it has is amazing. Kudos to Alain.

It brings a lot of relief. Seeing the Mashy Teaches Channel succeeding. The full stack web examples for all sorts of back-ends done and released for all to learn is amazing. We have a library, we have all sorts of project templates and everything needed for anyone to create an app in 5 minutes.

To get you started with BVAD3, check these out.









As always, stay blessed!

L10. Chaining can be your best friend, however use it sparingly

When creating your functions, you can add functionality to chain execution. This helps in coding faster, but at times it can be an area of bugs.

De-Chaining your code helps in readability of your code and also helps the BANano compiler. Chaining should not be "overdone"

As an example, I can define my class like this..


And I can call it with.