f 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.or
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
yea, agreed, tho I think Service Worker will be the spec we track/implement if
necessary
On Wed, Sep 3, 2014
l.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 based apps…unless we implement it as a
> plugin (which we won'
this is of interest 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 a
p
> content - iOS 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: remote
PM
To: dev@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 wrote:
>
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 wrote:
> >
> > I wonder how it solves the problems of serving the
> > correct v
>
> 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-phone
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 cordo
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
wrote:
> Brain I think that's OK at development time everything is fair game :-)
>
> The problem is developer
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 foot
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 wrote:
> That's a good difference to point
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
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"
http://www-01.ibm.com/support/knowledgecenter/api/content/SSZH4A_
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 wrote:
> I think this is a very desired plugin that many end up re-writing, and it's
> far better than setting the content src
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 wrote:
> Make it
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 wrote:
> Marcel, Sorry for the late reply.
>
> For some games that I produce where the entire game is served to the client
> (req
Marcel, Sorry for the late reply.
For some games that I produce where the entire game is served to the client
(requires no .html in the application) we have a tool called "spellcaster".
Spellcaster handles internet connectivity, localisation and Cordova code
injection. It works as follows:
One si
It is great design for development, and netflix.
Sent from my iPhone
> On Aug 1, 2014, at 4:26 PM, Marc Weiner 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:
>
> 3.3.2 An Appli
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 inte
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
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
wrote:
> I don't have the details in hand
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 (HT
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 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
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 sa
I've been getting occasional questions about users trying to use
remotely-loaded (non-local) HTML pages with Cordova (in the webview, not
InAppBrowser), and still expecting to have access to the plugin APIs (camera is
a popular one). My response so far is: "This is an unsupported configuration,
27 matches
Mail list logo
