Posts by DecSoft

Hello Tin,

Then I can't understand what can happen, since I can't reproduce the problem here. One thing is clear... apparently your app is not using the Status bar plugin, and they must do it... Are you try to change the color of the "Status Bar"? But we are on the same thing... the Calculator sample already set a color for the "Status Bar"! Can you see this, Tin? Can you take a look at the app's options -> Cordova -> Configuration -> Statusbar and confirm that you can see a silver color for the "Status Bar"?

Hello Tin,

Are you try with a new compilation of the app? Remove the "Compiled" directory, compile the app again. Remove the Cordova stuff of the app and compile the app again from the scratch. I can't reproduce that problem here, Tin, my above screenshots are from an iPhone X emulator, and, I also try with certain other app (a real app which I am developing) in the emulators of all the new iPhones and works as expected.

Hello Tin,

This is quite rare. I check rigth now the latest Calculator sample and they include the Cordova "Status Bar" plugin, but your Calculator sample apparently don't use it... maybe you need to start with a new Cordova compilation? Can you check if the app is using the Cordova "Status Bar" plugin?

Hello to all,

More information about this. I start to add a new "OpenWindowEx" action to AB when I fall into another question... yes; the "OpenWindow" action do not really use the "cordova.InAppBrowser.open", but the "window.open" method, in order to do their work.

I remember that in the past, the "InAppBrowser" plugin, automatically replace the "window.open" for their method, but, apparently this changes from sometime ago, and now we must do that explicitily by code, as we can see in the plugin's documentation.

This suprise me, because I can see that we are using "window.open", but this work like expected in certain Android app that I am developing! My doubt now is if I must change this... because maybe is not a good idea.

Let me to explain. The OpenWindow action, right now, relies on "window.open", works as expected, not only in Android, but also in all other platforms, including the web browser, because they no need to use any Cordova plugin.

So maybe it's a good idea to leave the "OpenWindow" action working like now. And, on the other hand, I am not to quite sure about the possible "OpenWindowEx" action, because this action must rely on the refered Cordova plugin.

Yes; some other actions relies on Cordova plugins, so, why not the "OpenWindowEx" one? Because I am not sure if this can be good, looking for the future. And more important... because we already can use the "cordova.InAppBrowser.open" without any problem, if we really wanted it!

Please, Tin, go ahead if you have any further question!

Hello Tin,

I am investingating this issue and here what I found. First of all, we certainly can use the "viewport=cover" instead of the "viewport=contain". In fact, I upload right now a new AB release who already use the "viewport=cover". However, what we can't apply is the CSS code that you shown above.

We can't use that CSS in the body nor in the ".appView", better said, we can use it... but that code don't work as expected. This is due to the way in which AB places our controls in the app's view: AB place the controls in an absolute way, then, the view's padding can't do nothing here.

But not all is loss! We can take at least two possible ways in order to view our apps working in the new iPhone devices. The first way is to use the Cordova's Status Bar plugin, that is, just check the "Status Bar" Cordova plugin in the app's Cordova options.

A good idea is also to set a color for the status bar and we can do this from the app's options -> Cordova -> Configuration -> Statusbar.

By using a status bar in our apps, what we can see is the Calculator sample (for example) like the below one, in an iPhone X simulator:

As we can see in the images (and you can see if try with the new AB release and the modified Calculator app sample), by using the Status Bar our "top" input control are placed as expected, and, the same can be said for the bottom of the views, since we are now using the "viewport=cover" now too.

So this means that we need to use the Apache Cordova Status Bar plugin in any case? Not always, or, better said, just if we need that... let me to explain. If we prefer to do not use the Status Bar plugin, then we leave the appropriate space at the top of the views.

So we can continue placing controls at the top, but, maybe it's not a good idea to place input controls at the top, except if we leave a little more space between the top view and the control's top. Remember, this preventions are not needed if we use the Status Bar plugin.

So the point is that, if we do not want to use the Apache Cordova Status Bar plugin, we must leave a little more space for the controls at the top of the app's views. Yes; a more or less similar space that what you try to do using your proposed CSS code.

Instead of use that CSS code, and, since we really can't use it, what we must to do is to leave that space in the controls at the top of the views. We must take this solution... or use the Status bar plugin, which produces the expected result without this preventions.

Go ahead if you have any further question, Tin!

Hello to all,

Here is a new DecSoft App Builder release, with the below changes, fixes and enhancements:

Read the entire product's history

Hello Tin,

Thanks for the link. Yes; certainly there is a lot (a lot) of options for non specific platforms. I think this is why I choose only to include the "Show location bar" option: because this is the only one that works in all the platforms.

You can continue using the Javascript "as is". My idea (when possible) is to add a new action to AB, that allows to use all the possible options, without change the way in which the current "OpenWindow" action works, so we don't break the backward compatibility.

Hello Amin,

I am not an expert in SQL, so, I am not sure if can help you in the best way, but at least I can always try it. :-)

Hello Amin,

Then I am not sure if can understand. First of all, probably you want to create the view over and over again: once you create the view (for example with a database manager like PhpMyAdmin), what you must to do is to execute the appropriate SQL query. You talk about errors, Amin, but can you please refer that errors here?

Hello Amin,

If I am not wrong, to create the VIEW you must use the "Database::exec()" method. So the only thing that I see rare is that if you use "Database::beginTransaction"()", after execute the query, you must execute "Database::commit()". Maybe you no need to use the "begin transaction" at all?

Can this help you in some manner?

Hello Tin,

It's the very first time that know the "hideurlbar" option. Let me to take a look, Tin, and I will back to you here. In the meanwhile, of course, you can continue the Javascript code "as is" like now.

Hello to all,

Here is a new DecSoft App Builder release, with the below changes, fixes and enhancements:

Read the entire product's history

Hello Amin,

Honestly I think than the server is the best to do this things. But, anyway, we can't use SQL in Javascript "as is". We can use the "IndexedDB" database, which offer SQL queries, but, outside that context, we can't use SQL to deal with data. But even if possible, I insist that the server can be better for this. Maybe the "IndexedDB" can be an option, that is, you can feed the database, and then query it in order to conform a Report's Data variable. But I am not sure that this is a good idea... if the server can do that.

Hello Amin,

But, unfortuantelly, something like that is not possible. The Report control nor the Data variable (which is only an array) support something like SQL, Amin. In my honest opinion, I think you no need to worry about the server SQL complexity... except if you find some unexpected result, in which you must try to optimize the queries. Personally, I am developing certain app which have amazing SQL queries (to me, since I am not an expert in SQL) in the server side, and everything works fine.

Hello Amin,

I am not sure if can understand. First of all, probably it's better than the server take care about the data processing, and feed the app in the right way. On the other hand, in what context do you want to use SQL queries in the client side? That is, are you talking about to use something like the IndexedDB technology?