(particularly if it's part of the packaging
mechanism on the platform).
-Chuck
-Original Message-
From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of
Brian LeRoux
Sent: Wednesday, September 3, 2014 2:59 PM
To: dev@cordova.apache.org
Subject: Re: remotely loaded pages
@cordova.apache.org
Subject: Re: remotely loaded pages
No apologies! It definitely *is* for dev authoring workflow currently …but
given the #'s I think it could be suitable for production runtime. (Sorry I
wasn't clear on that.)
On Thu, Aug 21, 2014 at 11:35 AM, Tim Kim timki...@gmail.com wrote:
I
maxes out at 10mb I think.
-Chuck
-Original Message-
From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of
Brian LeRoux
Sent: Thursday, August 21, 2014 12:15 PM
To: dev@cordova.apache.org
Subject: Re: remotely loaded pages
No apologies! It definitely
in
enterprise scenarios at a minimum.
-Chuck
-Original Message-
From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian
LeRoux
Sent: Wednesday, September 3, 2014 2:35 PM
To: dev@cordova.apache.org
Subject: Re: remotely loaded pages
there is no appcache in webview
...@gmail.com] On Behalf Of
Brian LeRoux
Sent: Wednesday, September 3, 2014 2:35 PM
To: dev@cordova.apache.org
Subject: Re: remotely loaded pages
there is no appcache in webview based apps…unless we implement it as a
plugin (which we won't b/c appcache is a sort of terrible spec)
On Wed, Sep 3
...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian
LeRoux
Sent: Wednesday, September 3, 2014 2:59 PM
To: dev@cordova.apache.org
Subject: Re: remotely loaded pages
yea, agreed, tho I think Service Worker will be the spec we track/implement if
necessary
On Wed, Sep 3, 2014 at 2:49 PM
phonegap-connect serves up remote cordova.js (negotiates the requestor to
send the right file)
no deaths yet!
https://github.com/phonegap/connect-phonegap/blob/master/lib/middleware/cordova/cordova.js#L29
On Wed, Aug 20, 2014 at 8:57 PM, Ally Ogilvie aogil...@wizcorp.jp wrote:
That's a good
Brain I think that's OK at development time everything is fair game :-)
The problem is developers doing stupid things like loading a cordova.js
from a place they don't know for a in production app being used by end
users, that's just kamikaze
That's OK if they want to shoot themselves in the
totally, though connect-phonegap *could* be considered production worthy
(it is being used significantly by the pg downstream community)
On Thu, Aug 21, 2014 at 10:53 AM, Carlos Santana csantan...@gmail.com
wrote:
Brain I think that's OK at development time everything is fair game :-)
The
Sorry Brian, I thought it was a development time tool to allow for fast
development cycle associated with PhoneGap Developer App.
I guess they can use it and run the connect-phonegap in a production
node-js backend system, I wonder how it solves the problems of serving the
correct version of
I wonder how it solves the problems of serving the
correct version of cordova.js and cordova_plugin.js depending on the
version of the native code that is installed on the different versions of
the mobile App in production.
When you connect to the IP that's being served by connect-phonegap,
No apologies! It definitely *is* for dev authoring workflow currently …but
given the #'s I think it could be suitable for production runtime. (Sorry I
wasn't clear on that.)
On Thu, Aug 21, 2014 at 11:35 AM, Tim Kim timki...@gmail.com wrote:
I wonder how it solves the problems of serving
Make it available Ally, of course that sounds interesting!
I'm sure a few of us have suggestions for improvements too.
On Wed, Aug 20, 2014 at 2:38 AM, Ally Ogilvie aogil...@wizcorp.jp wrote:
Marcel, Sorry for the late reply.
For some games that I produce where the entire game is served to
I think this is a very desired plugin that many end up re-writing, and it's
far better than setting the content src directly to a remote URL.
E.g. just stumbled across this yesterday:
http://docs.appmobi.com/index.php/live-update/
On Wed, Aug 20, 2014 at 7:57 AM, Michal Mocny
Very much so. So much so, I think we should even consider such
functionality as 'core'. Could dovetail w/ Serviceworker.
On Wed, Aug 20, 2014 at 7:26 AM, Andrew Grieve agri...@chromium.org wrote:
I think this is a very desired plugin that many end up re-writing, and it's
far better than
I want to make clarification there is a notable difference between loading
a remotely-loaded *(non-local) *HTML pages with Cordova vs. a downloaded
webapp to be loaded from a *local* HTML.
IBM Worklight has a feature Direct update
That's a good difference to point out.
My personal position is that scenarios where developer is in control and
loaded locally (i.e. directupdate, appmobi, spellcaster) is a valid
scenario for Cordova
I agree, because as cordova.js and cordovaLib are version linked, it makes
sense that once an
Hello Marcel.
Interesting scenario here. I'm not an expert on this topic, but loading
remote web artifacts that have native access looks very insecure to me.
Whether it is possible? Yeah, maybe... But is it advisable and, more
important, recommended by the Cordova experts community? I'd like to
I agree that it is not recommended, but it's possible. I delved into
this question here:
https://github.com/shazron/phonegap-questions/issues/37
The PhoneGap Developer App is an example of how this is working at
http://app.phonegap.com but they do some proxying to get around the
CORS limitations
I agree with all your statements Marcel. I use this approach frequently in dev
for fast turnaround.
Ultimately App Store policies decide what can and cannot be done.
Regarding security, there is nothing I can do with a remote page that I can't
already do inside my app. It's an issue of trust.
I don't have the details in hand at the moment, but I remember seeing in
more than one application store last year policies being changed to
disallow remote code to run in an application on-demand. Such rules *could*
as well be applied to Cordova apps that load remote content considered as
code
Adobe PhoneGap Build Hydration is different however -- it downloads an
app payload that is run locally (points to the new www folder
contents), and is only meant for dev purposes, not for App Store
release.
On Fri, Aug 1, 2014 at 2:34 PM, Frederico Galvão
frederico.gal...@pontoget.com.br wrote:
Hi Frederico.
While what you are saying about the policies stores is true, this applies
to public stores only (as far as I can tell). For on-premise app stores
this might be false because each store owner need to set and apply the
governance for the apps. It could end on horrible results due to a
It's technically possible, and even (arguably) legal according to Apple's
documentation, depending on the nature of the code and how it's implemented:
3.3.2 An Application may not download or install executable code.
Interpreted code may only be used in an Application if all scripts, code
and
It is great design for development, and netflix.
Sent from my iPhone
On Aug 1, 2014, at 4:26 PM, Marc Weiner mhweiner...@gmail.com wrote:
It's technically possible, and even (arguably) legal according to Apple's
documentation, depending on the nature of the code and how it's implemented:
25 matches
Mail list logo
