Posts by DecSoft

Hello to all,

I think the meta tag is not required at all, at least, I don't use it here in the apps that I develop, who receives push notifications. If you problem is only the icon, I think you must provide an absolute URL for that icon, or, maybe an app's local image path for that icon: that also works.

Below you can see the PHP code (a bit commented) that we use in various apps to send push notifications. The intention of the code is that you can get the whole idea and some useful notes, Paolo: the code is not to be used "as is", but I hope you can get the whole idea. Maybe can be good to copy the below code and paste it in your favorite PHP IDE, so you get the advantage of the syntax highlighting.

If you have any further questions, don't hesitate to post it here in this thread, or just open a new thread without problems. Merry Christmas and Happy New Year to you and for everybody! :-)

Hola Juan,

Acabo de enviarle un correo con ambas cosas: si en un tiempo prudencial no lo recibe... hágamelo saber por aquí y/o contacte conmigo por correo y se lo haré llegar de nuevo: no olvide revisar su carpeta SPAM en el cliente de correo: es posible que haya acabado ahí... :-/

Hola Juan,

La actual versión de la anterior generación de DecSoft App Builder es la 2019.63: voy a escribirle un correo enseguida con un enlace para su descarga, puesto que ya no está disponible públicamente. Respecto de cómo acceder al evento "DeviceReady", en el diseñador de su app, haga doble clic fuera de la vista, es decir, ya sabe que si hace doble clic en el diseñador, dentro de una vista de la app, accederá a los eventos de dicha vista, pues bien, haga doble clic fuera de la vista (por defecto, la vista aparece de color blanco), pero en el mismo diseñador, de modo que accederá a los eventos de la propia app. Si no puede hacerlo hágamelo saber aquí, Juan, y, trataré de ayudarle de otra forma: de hecho voy a mandarle un pequeño vídeo por correo para mostrárselo también mediante ese medio.

P.D. He dicho que voy a mandarle un correo con el enlace para descargar la última versión de la anterior generación de DecSoft App Builder, no obstante, puede también descargarla desde su área de cliente en este sitio web, desde la pestaña "Releases", dentro de la carpeta "App Builder", encontrará una subcarpeta de nombre "Current release", que, enlaza con dicha última versión.

P.D. Si estamos hablando de un nuevo proyecto, y, aunque el anterior DecSoft App Builder sigue soportándose, permítame recomendarle la actual generación de DecSoft App Builder, que, puede descargar desde aquí (puede instalarla sin problemas aunque tenga instalado la anterior generación).

Hola Juan,

Como en este caso estamos hablando de la anterior generación de DecSoft App Builder, puede utilizar el evento "DeviceReady" de la app, y, dentro del mismo, usar las acciones "StartJS" y "EndJS": entre medias de estas acciones puede insertar el código Javascript que necesite.

Si hablásemos de la nueva generación (o sea, la actualmente disponible) de DecSoft App Builder, no tendríamos necesidad de usar las acciones mencionadas, pues, todo el código es Javascript, directamente. El evento "DeviceReady" existe en ambas generaciones del producto.

Hello Paolo,

No problem! I am sure that, with time and work, you can get something useful and working as expected.

Hello Paolo,

Talking about IFrames and Android and iOS apps, I want to say something that may can be useful to you, because you must take it into your consideration. Commonly we must take care when deal with possible links inside our apps. This means that we must control all the links that we can place inside HTML controls, for example, handle it and don't leave the link to be opened "in a normal way". What we must to do, basically, is to handle the link and open it in a new window: it's possible to open it in the system's browser or in the browser provide to us by the Cordova "InAppBrowser" plugin.

Maybe it's not your case, however, we must handle the links because, if we don't handle it, they are opened inside our app's Webview, and, this can cause some problems. Not in all apps this problem appears, but, can appears in some specific apps. For example, supose we maintain an user session inside the app: if we allow the links to be opened in the app's Webview, when the user come back to the Webview, we can loss the app's variables, and, therefore, the user session (saved in that app's variables) is also loss. The solution is always the same: use the Cordova "InAppBrowser" plugin to handle the possible links and never allow the link to be opened in the app's Webview.

I want to mention this "link issues", which is not only related with AB, but, with any Apache Cordova app, because the IFrame usage can put us in a trouble if we need to handle the links... basically we can't do it... because the links which are inside the IFrame cannot be controlled outside the IFrame. So this means we cannot use an IFrame control in our apps? Not at all. We can use IFrames and sometimes they are quite useful, but, the content of the Iframe must be more or less know, and, for example, the links inside the IFrame cannot use a "target=blank" in the links, ni other words, all the links inside an IFrame must be opened in the same IFrame.

Again, maybe this is not a problem in your specific app: maybe the app don't rely in variables, so, maybe we can loss the control with a link who are opened in the app's Webview, and then, we can get back to the app without problems. However, I think that I must refer this possible problem in case you plan to use links to with "target=blank" in your IFrame's content. Because a "target=blank" means "open the link in a new window", and, this new window (for the IFrame) is the app's Webview itself. If your website, then, don't open links in new windows, there is no problem, because your website's links will be opened inside the IFrame, so you don't loss the control at all.

Please, post here if you have any questions or doubt about what I am trying to explain here around the possible link issues inside IFrames. I am not sure about what you are trying to do, so, I don't know if you need to use an IFrame (for example, you no need it if you want to post some information in your website's database, you can use an HTTP control to post it, or just use an XMLHttpRequest to do it). But, if you really want to use an IFrame, then you must take note about the links inside the IFrame's content: the links can be only opened inside the same IFrame / window, and, never have links with "target=blank", since the links will be opened in the app's Webview and this can cause some unexpected (in fact expected, but, anyway a non desired) behaviour.

Hello Paolo,

Glad to know that you got it, sir, and, always thank you for your trust. Have a nice weekend too!

Hello Paolo,

Something that give my attention is when you say "I tried to use the iframe but the login does not finalize the access, it reloads the page." Certainly, I try to put this website (decsoftutils.com) in an IFrame control and then try to login it: to my surprise I get the same result that you refers, however, this is related with the debugger browser used in DecSoft App Builder: maybe I can do something about, however, if you try the app in another browser (Firefox, for example) or compile it with Apache Cordova and run the app in Android (for example), you can see that you can login to this website as expected.

The Login sample app is quite simply, and, it's not intended to login to "any website", to say like that: what the sample try to show is how we can certainly connect to a server script (PHP in the sample) providing a login and a password: only if we provide the correct login and password, we get the right server's response, and in other case we never can see the expected response, but a login error. So we can use this kind or similar login to perform login and password protected operations in our app server, but, not to login to a website.

On the other hand, in my knowledge, the only way in which we can send something to the IFrame source content is by using the URL: certainly we can set the IFrame's source property to an URL like: https://www.mydomain.com/?myvar=myvalue, so, certainly we are sending some information to the website which is intended to be show in the IFrame: what the website do with the data that we send is something that is a duty of the website: if that website is of our property, may we can perform a login with the sended data, for example.

About the possible usage of an IFrame to show controls similar than AB, you can take in consideration that AB uses the Boostrap CSS framework, so certainly it's possible to have something inside an IFrame that looks similar than the AB controls, since we use the Bootstrap CSS framework in our IFrame content, for example, a button in AB is a button of the referred framework, so we can use the right framework's CSS classes in order to get a button similar than the buttons which AB provided:

I hope this information can help you in some way. If I am not wrong, probably the scenario that you are looking for is the ability to login in your website using the provided website's login form, and, what you get is the "reload iframe problem": as I say in my first paragraph, this is apparently a problem with the debugger browser used in DecSoft App Builder: once your app be compiled with Apache Cordova, for example, or just run in an external browser, you can login in your website as expected, and, in fact, the user session is not loss if your app is stopped and started again: I try this in Android with this website and works like a charm.

Please, post here if you have any further related questions, Paolo.

Hello to all,

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

Read the entire product's history

Hello John,

No problem! One thing what I try the local storage, so for that my surprise. But the point is that you got it!

Hello John,

Are you sure that there is not the same local storage? I made some tests and apparently we have the same local storage, John! Can you mention here what exactly method are you using to opened in another tab?

Hello John,

Before I suggest you to use the app's MaxWidth and MaxHeight properties to avoid the possible "scale problem" in your app's view opened in a new tab. This can be certainly a possible way, however, there is another one: it's also possible to use the "app.setAppFixedStyle()" method in the app's view Show event, so, we change to the fixed style, avoiding the possible "scale problem". You can try with all of these possible approaches and take the best for your specific case.

Hello John,

Before I leave you as a task how to create a tab from a content script (in case you need that, that is, if you did not want to use a context menu item created in a background script). Here is a way to create a new tab from content scripts. The point is to send a mesage to the background script in order to create the new tab. Look at the below code:

Hello John,

It's a bit frustrating, because this works like a charm in Firefox:

The point is that "chrome.browserAction.openPopup();" only works in what the documentation named "user action", like a context menu item click, for example. However, the above code don't work as expected in Chrome nor Edge, for example... :-(

However, there is also another possible approach. Take a look at the below code:

The above code can certainly show our app's desired view (note that we can avoid the local storage usage, that is, we can directly open the app's main view) as expected, that is, in another tab, and, that code works in Firefox, Chrome and Edge (and probably other modern browsers like Opera, etc.).

To my surprise, I try to place the "chrome.tabs.create" in a content script, for example, attaching a "dblclick" event to the body and try it, but, this don't work as expected: maybe because to use "chrome.tabs.create" we must use an "user action" like a context menu item click. I leave you as a task to try this (and search a bit around), if you don't want to use a context menu item. Maybe it's another way to create / open a new tab...

Another possible collateral issue can be the size of the popup. Suppose we have a WebExtension that at designtime is 300x300: we expect to have this size for the popup, but, when we open it (as above) in a new tab, the new tab size can be (probably it is) greater than 300x300. Here I propose to you a couple of possible solution: establish the app's MaxWidth and MaxHeight properties to 300 and 300, so the app openned in the new tab respect that size, because that's the maximum width and height.

The other possible solution can be to avoid the usage of AB controls, but use an HTML control, in which you can place the inputs (and other stuff) that you need: since these controls are not AB controlled (to say like that), they are not scaled. You must take a look in your own app, however, and see what of these options can be acceptable for your specific app case, John.

Since we can now open the app in a new tab, I am also thinking that maybe another possible approach is to open a window... a new window (with window.open) and then use the window.document.write() to prepare our HTML stuff: why? Because in this new window we don't have the "problem" related with the content pages, that is, this window do not have the styles, for example, of the content pages, so, maybe can be good for your purposes.

However, probably a new window can be a bit more tricky. I mention it because may you want to try it. I mean in order to control, for example, what the user type in the input controls... how to send that information to our app from the new window... maybe we don't share here the local storage, etc. Maybe this approach can be good, for example, if the new window present a form to the user to be submited to some app's server. Anyway, probably use an app's view... show one of our app's views in the new tab (as described above) can be the best... or better than the new window approach, at least if I am not wrong: I expect that, for example, some local storage saved in the app from the new tab, can be also available from the app shown in the popup...

Please, play a bit with the above code / **instructions**. I hope some of them can be useful for your specific app case, John.

Hello John,

I am not sure if we can go ahead with what you wanted... or it's a wrong approach. Please, let me to explain. The first in that I think is to use some lightbox Javascript library, and, certainly I can see someone that may can help: basiclightbox. This vanilla Javascript lightbox library consists on two files, one CSS and one JS, which we can add to our WebExtensions as content script and content style, respectively.

Additionally, we can add another content CSS file for our WebExtension with the below code:

Once we do the above, we can add this below Javascript code in our app's WebExtContent event, or, maybe in another Javascript file which we include as another content script for our WebExtension:

Note the usage of the "window.myEventDelegationFunction": I include this function to avoid the usage of the jQuery library, that is, to avoid to include it as another content script in our WebExtension. If you do all the above, you can see that, when you double click the content pages body, a modal dialog appear, with some input inside, and a button, which show you what you type in the input, and, additionaly, closes the modal dialog. The double click event can be replaced with the message that you receive from the background script, that is, the above is just a sample: in principle you can show the modal dialog when receive the message from the background script.

So, everything appear fine, right? Not completely. The problem can be, for example, to properly set a style for the input(s) and buttons of the dialog. Why? Because we are inside a content page, and, this content page have his own style... and this style can affect (and in fact do it) to our own style. The same can be said for all the Javascript stuff that we include in the content pages. We must carefully look at what Javascript we include, because the same problem: the content page Javascript can enter in conflicts with our own Javascript.

I start by including the jQuery library (to use event delegation, just to attach an event to the modal close dialog button), and, apparently works fine, even in my website, for example, which already uses jQuery. However, I am not sure about this approach... maybe jQuery don't enter in conflicts with my website, but, maybe can enter in conflicts with some other website. So you can play with the above code / stuff, follow my instructions, John, however, I am not sure if this can be the best approach... modify the content pages in this way... can cause some conflicts, difficult to handler in all the possible situations / content pages.

Maybe I go ahead to quickly to thinking in use some kind of modal dialog. Maybe the HTML form / controls can be appended to the content page's body, in order to appear at the top, for example, and, even in this case, probably we can see some unexpected behaviour in terms of the style that we apply to our inputs, because certainly we can't forget that the content pages have their own CSS style, that we can't control at all. Supose a content page have some CSS style which affects to "inputs", then our inputs become affected with that CSS style... and probably can be difficult to avoid that. Maybe by initialize the input CSS rules... (look for the "initial" values of the CSS rules), maybe we can finally get something working, but, I am not sure if after lot of work we can get something working exactly as we expected in all the content pages.

Please, play a bit with the above code / instructions, and, think maybe in another possible approach. For example, if we have the form / controls / inputs inside our WebExtension popup (in the main view or in other view), then the content page's scripts nor styles can affect to that controls, so, if that is possible, maybe is desirable to take an approach like that, instead to try to modify / append the content pages.