When loaded a PWA (Progressive Web App) inside a iframe, it will work normal (saving Web Workers, offline availability, etc) or some features will be blocked?
I have a PWA that uses an iframe. It uses some pretty advanced features, including a web-worker (in addition to the service worker) that I implemented long before recently porting it over to a PWA. All of those features work the same, with the additional benefit of controlled caching of specified resources. I haven't seen anything in the documentation to suggest otherwise, and can honestly say it works amazing! So fast to load now, it's in the app drawer, etc., even installs and looks like a normal app on desktop. My only issue is the soft-keyboard overlaps in fullscreen, but there is a solution, I've seen it work.
My suggestion-- try it. It's pretty easy to set up. Test your features. I am sure you will be impressed.
Related
We have set up our application as a custom Microsoft Teams app. The application is working just fine in the browser but fails to load in the Desktop APP. The application uses Azure Active Directory to perform the login through the saml2.0 implementation and is embedded through an iFrame.
Can't find a good way to debug what the issue might be. The AAD logs are always empty and the DevTools do not show what's happening in the embedded iFrame.
Has anyone encountered this issue before or might know of a way to try and debug it?
This is actually quite common, that it works fine in browser but not in desktop, and there are probably several reasons for that, not least of which that the popup experience is easier to control in browser versus the actual Teams desktop sandbox. It's also common, I think, that people try to launch their own popup to handle the login, which you can't actually do in the Teams desktop. It's a bit wierd, but basically Teams desktop launches a popup for you, which loads your login page, which in turn then needs to do a -redirect- because you're now in a new browser page.
In any case, in my experience, it's always because I've done something wrong, that's why desktop doesn't work correctly. My suggestion is to follow the docs -exactly- and it should work fine.
The most important doc is this one, which really does give some quite straightforward step-by-step. You can also check out this video which helps as well.
I'm using Python and QT (PySide) in a local application (which connect to a database on cloud Azure).
Now, my objective is moving this app on the web, in particular on Azure (I have an Azure subscription), simply transfering it on Azure, it's possible in some manner? I have not found examples on the web.
The important question is: is Python QT (app web) compatible with Azure?
Thanks
UPDATED ANSWER!
Yes, now you can. Well sort of. The mad mads at Digia have created something called "QT for Web Assembly" that can compile your whole app into something that runs embedded into a web page.
https://doc.qt.io/qtcreator/creator-setup-webassembly.html
You might have to rethink connecting directly to the database however, as thats simply not gonna fly with web-sockets (And honestly direct app to remote RDBMS has never been a smart move. Theres a LOT of things that can go wrong letting the internet connnect to your databaes). But you could at least keep the UI and rewrite the databaes layer to interogate something like a GraphQL (or whatever) front end to the data.
OLD ANSWER
I'm afraid your up for a nearly complete rewrite. QT is a desktop/mobile platform. It doesn't go anywhere near HTML/CSS except perhaps for displaying them in a webview component. Azure or AWS won't magically make it into a web application for you.
Your code as it stands needd to be rewritten in a web-first transactional manner. That is it takes a request, processes it, produces a result. To some extent websockets has changed this dynamic for a limited subset of use cases where interaction needs to be non transactional, and modern web app design hides much of the transactionality behind a web-services model, but 90% of web work is still very much transactional.
Database <---> Web server/Web app stack <--- Internet! --> Web browser
My suggestion is to pick up Django (or one of the other systems. If its just simple, Flask is another good alternative. Flask for simple apps, Django for the big stuff. Or use something else, you have choices here!, and start from scratch. Analyse your products function and start mapping out how to make this work as a database driven transactional system.
Theres no shortcuts here, I'm afraid.
I was reading about advantages of PWAs, but I really can't understand why we have to use this technology. Is this similar to SPA? Or this is completely something else?
A Single Page Application (SPA) can be a Progressive Web App (PWA) but a PWA doesn't need to be a SPA. They are two different things. A PWA as defined by Google is:
Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.
Fast - Respond quickly to user interactions with silky smooth animations and no janky scrolling.
Engaging - Feel like a natural app on the device, with an immersive user experience.
The Google PWA site is a good place to start learning about PWA and why and how you would build one.
https://developers.google.com/web/progressive-web-apps/
A SPA is simply a web app where a single page is loaded in the browser and all subsequent routing and page view rendering is handled on the client (browser) using JavaScript.
Properly combining the principles of PWA and SPA can result in a much improved user experience especially on mobile phones with unreliable internet connections.
Probably the best example today of a well implemented PWA is Twitter Lite. Check it out here:
https://mobile.twitter.com/home
...and read about it here:
https://blog.twitter.com/en_us/topics/product/2017/introducing-twitter-lite.html
A SPA is something different than a PWA. You can view PWA as an enhancement of your website. By adding a service worker and a manifest you can bring your website (SPA or not) out of the browser, work like a mobile app and make it perform better.
I we have been working for some years in a flex (cairgorn)+spring+blazeDataservice application using blazeDataservice to connect to the back end, now its getting kind of big and takes too much time too load, and people who use it, normally need it to use it regulary.
My country's internet bandwith is not getting better, actually it´s getting worse, so the app gets bigger and bandwith gets worse so loading it it's getting slower by the day.
I was wondering how could I get the client to be installed on peoples computers, I would be turning a flex online app into a desktop app WITHOUT REWRITING IT. I only need someone to point me in the right direction, i was thinking about 2 options:
1.- Can it be turned into adobe air ? is in´t adobe air desktop ?
2.- Maybe a flash that runs in peoples desktop ?
I need everything to work against the host spring backend just like it does today
Thank you very much!
Just to be clear:
If it is the size of the app (SWF) itself, rather than the queries being performed, an another alternative to speed things up, without building a Desktop (AIR) version, would be to use what Flex calls Modules.
Basically you would be breaking your app into smaller pieces that get loaded only as necessary.
If you do go the Desktop (AIR) route, you may also want to explore a local SQLite database that Syncs with your server only as needed, thus further reducing the internet connectivity issues.
This would of course add to your development time, but it seems like it might be a good bet given the situation you describe.
As for where to start, switching from a Web to a Desktop (AIR) app can be as simple as changing the main MXML tag from (in Flex 3) mx:Application to mx:WindowedApplication and launching your app.
UPDATE in response to follow up question:
Hard to say how much rewriting would be involved without knowing how your code is currently structured, but doubtful it would be a major rewrite.
As an experiment, I would suggest the following:
Create a new Flex application.
Create a new Module.
Add some simple MXML and Actionscript to the Module.
Add an instance of the Module to your Main view.
Run/Compile.
What you should see is that you might as well have not wrapped it in a Module at all, from a functionality or coding perspective, but the Module will have been compiled into a separate SWF, and Flex will handle loading it as needed.
If that all works and makes sense, I would start breaking up pieces of your code into Modules and see if that begins to solve your problem.
Adobe AIR is the right way to go. It is essentially #2, and often you can pretty much just publish exactly what you have straight to AIR instead of the web, and it just works. Fancy!
I am considering creating a website with the complexity of Facebook that should be able to scale into the millions of users. My question is: Is there any reason not to use Adobe Flex for such large project apart from the obvious point of requiring everyone to have Flash installed and not having to rely on Adobe? In my view Adobe Flex would reduce the server load for Facebook, because more of the work could me done on the client side. Do you agree?
Of course Facebook could have been implemented in Flash. But then the question is would it have succeeded? There are reasons big web companies like Google, Facebook and Yahoo only use Flash as sparingly as possible.
The thing I would fear most is alienating users. The Flash plugin isn't the best piece of software out there. It is slow and likely to crash once in a while. If your app gets bigger you might get some loading times that might not be acceptable to your users. Also in my opinion full Flash sites just don't feel right because they behave differently from HTML websites. All great websites like Google, Flickr, Stackoverflow or Facebook feel very light and slick which is very elegant makes up for great usability.
And then HTML and JavaScript are a lot more flexible. Do you want your website to be available on smartphonse? The iPhone has no Flash and even with phones that do you have the problem that users will very likely hate a full Flash site since those phones don't necessarily scale Flash as nicely as they scale HTML and Flash draws battery like crazy. If someone comes up with another revolution like smartphones you can be sure it supports HTML and JavaScript but you can't be so sure about Flash.
Then the question is how would you gain any efficiency? Of course you can write your UI with Flex and just call very lightweight webservices like you would use them for AJAX and you can even cache some of the content of the site locally so that you don't transmit more data as necessary for user interaction (the UI is transmitted only once). But you can also do that with JavaScript. You can write your UI in HTML and JavaScript, load it once and then just pull the naked JSON data from the servers and render it using JavaScript. You can also fetch lots of this data in advance to get the number of requests down. But still such an approach has its cons. Did you ever notice that when you type an answer on stackoverflow and someone else submits an answer you get notified while typing your answer. Such real time features are very cool and you might want this at some point in time which means more server interaction.
But whatever you do your servers still have to scale if your site grows. Even if you minimize the number of GET requests that hit your servers they will still grow a lot when your site gets popular and you will need a lot of servers to handle you will just improve your users/servers ratio.
The most interesting point though is that Flex is much easier to program than AJAX (think about browser incompatibilities for instance) and still AJAX was not only invented but the whole world messes with all those problems that come with it instead of using Flex. I think this tells a lot about of the value of the result you get when creating a full website in Flash.
Go to facebook and do view source...do you see all that JavaScript? That all runs client side
Johannes is right to point out the difference for server vs. client. The server side stuff is what needs to scale.
As an example, the Microsoft Silverlight team has assembled a facebook client app in silverlight (using the Facebook public API). My point is, using todays technologies, it is entirely possible to write a web application targeting many different kinds of client technologies: classic web browsers (HTML/javascript), 'rich internet applications' (flex, silverlight), ...
See also the myriad of Twitter clients out there.
The company I work for has a large app in Flash that is used by Governments. It is very hard to maintain and does fail sometimes. The problem is all of the .fla and .as files that have to be altered just to make a small change. Yes, the app could have been built better but even so, it is still harder to maintain than an HTML/JavaScript front end.
While I love writing Flash/Flex apps, I believe they should complement a site and not be the site.
Using a good JavaScript framework like jQuery takes the Browser compatibility question out of the picture (for the most part) and allows a lot of functionality.
Flex is the GUI for the client. You still need server-side storage and that's what has to scale. The user interface could be in Flex, while most of your users won't like such interfaces.
You will have to do a custom version of your site for the iPad/iPhone.
There are other ways of moving load to the client side. Javascript will give you porting headaches, but less than moving away from the entire architecture like Flex.
OTOH when you get a million users you'll have the resources to reimplement your site.
I don't think you would see a performance advantage with a site like Facebook, because the content is highly dynamic, comes from many different places, and is created by many independent entities. Flash (and therefore Flex) is better for monolithic apps from a single source that don't need to change very often.
The default in Flash is to build everything into a single .swf file that holds everything. It is possible to break out of this default behavior, of course. You can make web service calls, pull in external components via the SWC mechanism, load static content via HTTP, etc. Nevertheless, it's not the default pattern, which affects how Flash development libraries and tools work. Besides, the more of this you do, the less of the "run everything we possibly can on the client side" benefit you get. It gets soaked up in HTTP connection overhead.
The default on the plain old standards-based web is to store all assets separately and assemble them dynamically at the client. This is one reason the web is slow -- again, all that HTTP connection overhead -- but also why it is flexible and dynamic. It mates well with a site like Facebook which requires constant evolution by a lot of independent developers.
I say this having developed a Flex app, which I am happy with. Only one person -- me -- has to maintain it, and it's naturally a monolithic app. It plays right into Flex's strengths.