Im just starting out diving into PWAs.
Where should a PWA being published?
Can it be published like any other javascript app on the web (as a simple URL)?
A PWA is like any other website. You can host it anywhere you can host a "regular" site, as long as it is served via HTTPS.
A PWA is made up of service workers, which can run in the background. To avoid tampering with service workers the specification of PWA requires it to be hosted over HTTPS.
So any hosts supporting HTTPS would be good enough for them.
Related
We are building an Ionic App with Capacitor. As far as I understand the architecture this starts a webserver in the app to serve the web resources (Angular) so they can be loaded in the webview.
My question is: How does isolation work, when running multiple Ionic Apps? Is the webserver only accessible for the app? Why are there no port conflicts?
Is there any detailed documentation for such topics?
I received the following answer on the github page of capacitor: https://github.com/ionic-team/capacitor/discussions/5880
It’s not a real web server, so there is no conflict with other apps. In the past iOS had a real web server and it had conflicts, so we removed it.
It uses WKURLScheme handler instead that intercepts requests to custom schemes
https://developer.apple.com/documentation/webkit/wkurlschemehandler
I have been working on a NativeScript project that uses an API. The API project is on my MacBook and haven't deployed to anywhere yet. It's based on Laravel and I use Laravel Valet as development environment.
I can't test the mobile app on iPhone because the app can't connect to local API URL. I know Valet has "share" command, but because the API consumes another API -which has IP restrictions-, it doesn't work for me. Sharing a local domain via Valet's share command is something like a proxy as I understand, so the consumed API doesn't work on that proxy.
I also checked articles about how to share Macbook's network with iPhone, but it only shares the same network. I can't access the local API still.
Is there any other way that can resolve my issue? Maybe a Docker based solution? I am not that good at Docker, but I can give a try if it is possible with it.
https://ngrok.com/ will happily expose your local Laravel Valet server.
Looks like there's a bit of a walk through on that here too https://mannyisles.com/using-laravel-valet-and-ngrok/ which may help?
Can a GWT web application be deployed on Github?
For example, a GWT web application is created, and it works on a server intalled with Tomcat. It's known that a web page can be created on Github, like http://help.github.com/articles/creating-pages-with-the-automatic-generator/ Can a GWT web application also be deployed on Github? If it's possible, how to deploy it?
On Github Pages you can only use/host client-side technology like JavaScript, CSS and HTML. So your app would not have an back-end which can handle your RPCs. But it's possible on GitHub Pages to make Ajax calls (http://blog.teamtreehouse.com/code-a-simple-github-api-webapp-using-jquery-ajax ) , which are also the base for GWT-RPCs.
When the fron-end is running, you need a server for your backend. Afaik there are libraries to use php as an back-end (I guess most are not maintained anymore), or you could use the JsonpRequestBuilder to make HTTP-calls to a server of your choice. JSONP would be necessary to overcome the cross-domain restrictions imposed by browsers same-origin policy, because your backend would be on a different server.
So all in all this is not the way to go. As I mentioned in the comments you can try the GAE (Google App Engine) to host your application without recreating your back-end, because the other solution would require to rewrite your back-end (eg. PHP) and to host it somewhere
One last tip: Before you move definitely to GAE, check that you have all necessary libraries for you backed.
If you are using servlets and stuff : certainly no
If you are only using client stuff, my guess is also no. I don't think github even allows javascript, or even html ?
I'm creating an application (with the Desktop Browser web page environment) using Worklight 6.0. My problem is this: my application only works in either HTTP or HTTPS but not in both.
When I tried to run my app, it returns:
The application failed connecting to the service
How can i build my app for both, and deploy it? because I want to put this app on the Facebook canvas, but it only works on HTTP or HTTPS.
It's not the application or the environment you've added to your application, but the server. Requests from the Worklight Server are either HTTP or HTTPS, they cannot be both.
But IMO this is irrelevant. I think the correct approach is to put Apache or alike in-front of Worklight (or WebSphere, in your case, which hosts Worklight Server since you've deployed it there), and its job is to handle incoming and outgoing connections - be it HTTPS or HTTP.
That said, AFAIK in Facebook only HTTPS should be used.
Is it possible to develop facebook apps locally on my system so that the callback URL need not be a public URL like http://abc.com and instead can be an internal IP address like localhost http://127.0.0.1?
It is now possible to develop Facebook apps locally.
I believe this is true especially if you're developing in an iframe, which is now the standard way of developing facebook apps (FBML is deprecated).
In case this does not work, there are still some ways to make working more convenient.
Take a look at this answer:
Testing FB apps is still a rather primitive process.
I generally setup a test application that is a complete copy of the production settings inside the FB development environment that uses an SSH tunnel to point to my development server. You can setup as many applications as you need inside FB - I generally have a development application, a staging app and production. Staging and Production are both on "live" servers rather than an SSH tunnel.
The rest of the answers to this question detail different workflows that people have utilized to make it more convenient to develop on a remote host.
you can use http://127.0.0.1/ProjectName as the callback url, or your ip address itself