IFrame and Bootstrap question


Peter Groll
Hello David, first of all, I hope you are well and healthy in this times!

a) I noticed a little problem with the IFrame url. If I change the url and rebuild the app the old url stays. When I close the app and open it again then in most cases the new url is taken.

b) Is it possible to use the Bootstrap grid system in AppBuilder, and how to to this? (What I mean is that in Bootstrap the elements may be placed in a grid, and if the screen is big enough all elements are side by side in a row, if the screen is small (smartphone) the elements are placed among each other and you can scroll down.

kind regards, Peter
Peter Groll

DecSoft

Hello Peter,

Thanks for your kindly words: I hope you and yours are also good, Peter. About your first question, I need to take a look. Maybe it's certain problem that must be fixed. About your second question, it's possible to use the Bootstrap Grid system by using the HTML control. In fact, you can copy the below code and then paste it in an app view designer: the result is that a new HTML control is placed in the view with that HTML markup inside:

You can place in an HTML control almost any HTML markup, including buttons, rows and cols for the Bootstrap Grid system, etc. Just post here if you have an further question around this.



Peter Groll
Hello David, thanks for your reply. But if I place my elements inside the HTML control I loose the visual design advantage of AppBuilder. So my idea was to use containers and frame them with HTML control, but this does not work. Here is my example:

So I would like to have the containers as Bootstrap row elements, but maybe there is another way to do this? Do you have an idea?

kind regards Peter
Peter Groll

DecSoft

Hello Peter,

You can't place different grid columns in different HTML controls. At least, that don't work as expected, since a "col" must be placed inside a "row". Depend on the target of your app, the grid system can be interesting or not. In my opinion, only if you want the app running in more or less larger screen, you can consider to use the grid system. In other case maybe that is not needed: even for larger screen, sometimes the grid system can be good, and, sometimes not necessary.

You did not loss the AB functionallity by using the HTML control: this control is one of the available ones, and, in fact one of the most powerfull, basically, because we can place in that control almost any HTML markup, for example, using the Bootstrap Grid system. Doing that requires a bit extra work, for example, to control the possible "buttons" (or other controls) placed inside the HTML control, however, this is perfectly possible.



Peter Groll
Hello David, yes, I see your point, I tried to modify the view1.html and frame the containers in a row and "col-md-4" columns. This works in principle, but bootstrap does not know how to handle the container, so it is of no use.

The reason, why I like to use the bootstrap grid is that my app uses a lot of buttons, slider and labels, which should be placed in a special order together. When you use a smartphone in portrait mode with bootstrap grid, you can define how this happens and scroll down to see the other buttons etc. On the other hand with AppBuilder it is very easy to place my buttons labels and images on different places for a smartphone portrait version. Unfortunately this produces another problem:

When I change the apps size to be larger than the browser (eg. to 320 x 960 px for my portrait version) then you can scroll down the app but the upper 10%-15% is unreachable, you can not see it and you can not scroll up to it. Do you have an idea, how to change this?

kind regards, Peter
Peter Groll

DecSoft

Hello Peter,

Hello David, yes, I see your point, I tried to modify the view1.html and frame the containers in a row and "col-md-4" columns. This works in principle, but bootstrap does not know how to handle the container, so it is of no use.

I am not sure if can understand. You can try the below codes, and, certainly, see how Bootstrap deal as expected with the "container" and the "container-fluid", you can see how this containers are dealing in a different way, as expected.

When I change the apps size to be larger than the browser (eg. to 320 x 960 px for my portrait version) then you can scroll down the app but the upper 10%-15% is unreachable, you can not see it and you can not scroll up to it. Do you have an idea, how to change this?

I need a sample app to see what you refer, Peter. Send to my E-Mail a sample app, so I can take a look. On the other hand, take a look at the "Inputs" sample app: it's possible to place controls beyond the app view, allowing the user to scroll the view in order to see all the controls. Maybe this sample app can give you some alternative ideas.



DecSoft

Hello Peter,

Here are my comments around the sample app that you sent to me. Please, take note about the changes that I made in the modified sample app which I send to you when publish this post:

  1. You are using the app's Scale option set to "False": consider or just (in order to follow these advises, since I think you can get what you wanted) set the Scale option to "True".
  2. Instead of use a 960px pixels height, use a 480px pixels height: the idea is that we can go beyond the app view, but, not necessarily by increasing the view's height: just place controls below the view bottom.

That's all. As you can see in my modified sample, we can now reach the bottom controls using the scroll (note the container which I place at the very bottom: it's to get some space between the latest bottom and the end of the view).

Try the app in a browser with a size of 320x480 pixels (which is the design size), and you can see how we can scroll the view to see all the controls. You can also try to increase the size of the browser, and see that the app scales reasonably too.

That's is in fact the way to get an app that can work from a small screen size to a more or less greater screen, in other words, from mobile to tablets. For more larger screens may can be a good idea to use the app's "MaxWidth" property, in order to avoid the controls to scale "too much".

You can try it by set the "MaxWidth" property to 1024, for example, and then run the app in a larger (desktop) screen to see the result. Take a look and tell me that do you think about, Peter.



Peter Groll
Hello David,

no, that is not what I want. I do not want Autoscale and I would prefer to use larger sizes than the normal browser has and let the user scroll down. This is no problem with eg. a bootstrap site. I do not understand, why the browser can not show the upper part of the AppBuilder site. If you scale down the page you can reach the the whole site, but not at 100% or more. Is it possible, that I have to set a special "scrollable" attribute for the whole site??

kind regards,

Peter


Peter Groll

DecSoft

Hello Peter,

I am now busy, but, want to think about. However, the Fixed (not scaled) style has that behaviour: since it's a fixed size, the screen must be at least the same than the fixed size, in order to see everything as expected. Said that, if what you wanted is an app working from smaller to larger screens, then probably the Scaled option is for you, as I shown you in the modified sample: you can see all the controls, from small to larger screens.



Peter Groll
Hello David,

shure, take your time. If there is no such scroll solution, I have to find another way .....

take care,

Peter


Peter Groll

DecSoft

Hello Peter,

I say I am busy this morning? The same than now! :-/ But the point is more or less clear, Peter. :-( If we set the app's Scale option to False, then we need a screen size at least equal than the design size: in other case it's normal that some unexpected behaviour occur, because the designed size is greater than the screen size. Or I am wrong... or you need to set the Scale option to True, designing in a more or less smaller size (320x480, for example), so the app can view properly in that size, but also scales in more larger screen sizes. Please, take a look at this help topic.



DecSoft

Hello again, Peter,

I think that may I can't explain it as well as I wanted... let me to try it again...

If we use the Scale option set to False, we need a screen size at least as greater than the app's design size. If you have a smaller screen size, then the app cannot be show as expected, because the design size (which is established when Scale is set to False) just cannot fit in the smaller screen size. What you see is one of the possible unexpected results.

On the other hand, since apparently you want to see the app in an smaller screen... then you must take the path that I shown you in the modified sample app. The app's design size can be 320x480, for example (can be greater if you wanted, but, remember that this is the minimum screen size required when the app run), and then use the Scale option set to True.

Doing that you can see what I shown you in the modified app sample: your app can run in screens, at least, with a 320x360 size, and, also more larger screens, since the app automatically scales. Not all the time we need that, but, it's perfectly possible (I do in various apps) to place controls beyond the app view (but remember, beyond mean that the app view continue to be 320x480, just that we can place controls beyond that design size), so the controls can be reached by using the scroll.



Peter Groll
Hello David,

I found the solution. In the shared.css you have to replace .app-view { position: absolute ..} with .app-view { position: relative ..} and add "overflow-y: auto" after "overflow-x: auto". Then the app behaves exactly as I want. This is independent of scaled or not scaled. Best way to do this seems to overwrite the standard setting in the custom style css.

If you are not to busy or have a quick solution, please, I have another question. When I use the file tool to open an image (with image/* accept) on smartphones is allways the camera selected, not the file browser. Is there a way to change this?

kind regards,

Peter


Peter Groll

DecSoft

Hello Peter,

I found the solution. In the shared.css you have to replace .app-view { position: absolute ..} with .app-view { position: relative ..} and add "overflow-y: auto" after "overflow-x: auto". Then the app behaves exactly as I want. This is independent of scaled or not scaled. Best way to do this seems to overwrite the standard setting in the custom style css.

Yes; that's what I am thinking about: maybe we can apply some CSS style in order to get what you wanted. However, I am not sure,... I think you must think about the proposed solution with the Scale option set to True. Of course, if you prefer it, you can use the app's Style option in order to apply or overwrite the CSS style that you wanted.

If you are not to busy or have a quick solution, please, I have another question. When I use the file tool to open an image (with image/* accept) on smartphones is allways the camera selected, not the file browser. Is there a way to change this?

I think this depend on the phone / choosed option... I just place an Input File control with the "Accept" set to "image/*", compile an APK, and, in my phone, I can choose an image file from the file system or the gallery. Honestly I don't know how to change this preselected option in the phone. May you are using the "Capture" property of the Input File control? If so, leave it empty, since I do it and works like I refer. On the other hand, if your app is target to Cordova platforms (not the browser), may you can try the "CordovaMediaCapture" sample app. Maybe it's also possible to use an Input File control or the device stuff, depending if the app run in a Cordova platform or not.

P.S. Please, Peter, the next time, place new questions in different forum's threads. Thanks!



Peter Groll
Hi David,

thanks for the reply. Regarding the accept "image/*" option for loading an image file, I have replaced this option with ".jpg,.png" and this works fine on Android!


Peter Groll

DecSoft

Hello Peter,

It's possible... however I think that there is some previous system configuration set, so "image/*" don't work as you expected... due to this possible system configuration. In my case "image/*" works as expected, so I think there is some possible system configuration related. Sometimes Android ask the user for an option and allow the user to set that option "for always" usage... I think that something similar can happen here. Anyway, it's possible that ".jpg,.png" do the job too, so, it's possible to use like that.



DecSoft

Hello again, Peter,

Maybe a way to test this can be to use a "non configured" device, maybe a "reset to default" or "reset to fabric settings" device. May you can use a device like that in order to try with "image/*".


Todo el mundo puede leer el foro de soporte de DecSoft para aprender del mismo, sin embargo, sólo los clientes de DecSoft pueden abrir nuevos hilos. Compre una o más licencias de productos de DecSoft y obtendrá este y otros beneficios.

Este sitio utiliza "cookies" útiles para almacenar sus preferencias.

Bien. Ocultar esta nota. Obtener más información.