I have not tested, but supposedly you can point to a local html error file. Whenever a navigation error occurs, it should navigate to that local page.
<preference name="ErrorUrl" value="myErrorPage.html"/> Anyway, I see no point in limiting the content tag, people can still navigate to remote sites by using javascript as long as the remote url is whitelisted with the appropriate allow-navigation tag. They just need a window.location = 'https://remoteurl.com'; El mar., 22 oct. 2019 a las 18:56, Norman Breau (<nor...@normanbreau.com>) escribió: > There are some things I definitely disagree with in your list of > responses. I do think > the enterprise setup is enough of a reason to not add any kind of > deprecation notice as I originally proposed. So I concede on the idea of > deprecating this usage of the feature. > > I however do still think, a note on this should be documented in the > config.xml docs as I think many users are not building enterprise apps, > but still use remote urls for production apps. > > #1 is definitely TOS breaking. Code from a remote source must not be a > requirement for the app, read: "Apps may contain or run code that is not > embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as > code distribution isn’t the main purpose of the app" > > Code that isn't bundled with the app can only use capabilities available > in the standard webkit view. Read "(2) only uses capabilities available > in a standard WebKit view (e.g. it must open and run natively in Safari > without modifications or additional software)". Google Play also has > similar text in their policies. > > I also fail to understand how a developer can use a remote html page for > their app index page and still avoid a blank page due to the device not > having a data connection. > > So for these reasons, I think it still should be documented as bad > practice for production apps at the very least. Of course, it can made > clear that this note only applies to apps intended to be distributed to > the app stores. > > On 2019-10-22 1:24 p.m., Jesse wrote: > > Also, please keep in mind that there are other ways to distribute apps. > > A company/developer with an enterprise license can build apps for > > company/employee use and distribute them as they see fit. > > > > > > On Tue, Oct 22, 2019 at 9:20 AM Jesse <purplecabb...@gmail.com> wrote: > > > >> This is a crucial feature for development tools, and a valid production > >> use case. > >> > >> 1. This is NOT breaking TOS with Apple, unless the developer decides to > >> significantly change their app, which is bad practice anyway. > >> 2. Care should be taken in what you deliver to your app, this is not > >> cordova's concern. > >> 3. Apps should provide 'some' offline experience, and not show a 404 of > >> course, but that is up to the developer. > >> 4. Yes, developers should be aware of this. > >> 5. This is not 'repacking a website' you are missing the point, this is: > >> 'making a purpose built web-app that you can make minor tweaks to > without > >> having to submit to app stores repeatedly, and to do some heavy lifting > on > >> the server.' Some notable apps that are examples of this: Amazon, > Walmart, > >> Apple Music, Apple App Store, ... > >> > >> > >> > >> > >> On Tue, Oct 22, 2019 at 9:05 AM julio cesar sanchez < > >> jcesarmob...@gmail.com> wrote: > >> > >>> The content tag is also used for pointing to local development servers > and > >>> benefit from live reloading, so how do you plan to deprecate it only > for > >>> remote urls? > >>> > >>> El mar., 22 oct. 2019 a las 17:46, Norman Breau (< > nor...@normanbreau.com > >>>> ) > >>> escribió: > >>> > >>>> This is an extension of the issue I raised for adding warnings to the > >>>> documentation which can be found at > >>>> https://github.com/apache/cordova-docs/issues/1022 > >>>> > >>>> In my opinion there are several reasons why using a remote url (such > as > >>>> https://myserver.com/) to host a cordova app is bad practice. > >>>> > >>>> 1. If your app uses native APIs, you're breaking the terms of service > of > >>>> the Apple and Google Play app stores. See Section 2.5.2 Software > >>>> Requirements of apples guidelines.[1] > >>>> > >>>> 2. Extending onto #1, it makes the app must more easier to become > >>>> vulnerable to exploits, because any other > >>>> third party code loaded onto the website may have access to the > cordova > >>>> APIs. > >>>> > >>>> 3. Apple & Google expects your app to be able to launch and "work" > >>>> without a data connection. If your index file is > >>>> remote, then your app cannot load to provide the user proper feedback > >>>> that they require an internet connection. (See section 2.1 App > >>>> Completeness & 4.2 Minimum Functionality apple guidelines)[1]. > >>>> > >>>> 4. Using a remote URL generally causes a lot of CORs related issues > when > >>>> using non-standard protocols such as cdvfile:// (see > >>>> https://github.com/apache/cordova-plugin-file/issues/352) > >>>> > >>>> 5. Even if your app does not use native APIs, and it's just > repackaging > >>>> a website, this goes against section 4.2 on apples policy[1]. > >>>> > >>>> I don't exactly know how popular using <content src="remoteurl" /> is, > >>>> but I do see it frequent enough on reported issues. This is kind of > >>>> frightening. > >>>> > >>>> So given the reasons I listed above, I think allowing remote sources > in > >>>> the <content> tag should be deprecated, and eventually removed in the > >>>> future, of course allowing time for developers to refactor their app > to > >>>> bundle their code within the app. > >>>> > >>>> Sources: > >>>> [1] https://developer.apple.com/app-store/review/guidelines/#design > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >>>> For additional commands, e-mail: dev-h...@cordova.apache.org > >>>> > >>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
