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 simply adds an application URL to Cordova's config.xml in <content
src=YOUR_URL_HERE>
- Spellcaster will check for an active internet connection. If one is not
found Spellcaster will continue retrying at a set interval.
- Spellcaster downloads the content of the provided application URL and
stores to application cache (overriding any existing loader).
- Spellcaster injects Cordova script tags just after the <head> tag.
- Spellcaster loads the new *loader into the WebView
*loader is your html to load.
Are people still in need of such a solution? I could have this code made
public it just needs a public sanitise check. Spellcaster supports iOS and
Android.
For iOS it requires 1 line of code to be added to
didFinishLaunchingWithOptions.
For Android it requires these overrides in onCreate:
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
super.init();
@Override
public void init() {
Spellcaster spellcaster = new Spellcaster();
spellcaster.init(this, Config.getStartUrl(), appView);
...
@Override
public void init(org.apache.cordova.CordovaWebView webView,
org.apache.cordova.CordovaWebViewClient webViewClient,
org.apache.cordova.CordovaChromeClient webChromeClient) {
super.init(webView, webViewClient, webChromeClient);
Spellcaster spellcaster = new Spellcaster();
spellcaster.init(this, Config.getStartUrl(), webView);
...
On Sat, Aug 2, 2014 at 2:17 PM, purplecabbage <purplecabb...@gmail.com>
wrote:
> 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:
> >
> > 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 interpreters are packaged in the Application and not downloaded. The
> > only exception to the foregoing is scripts and code downloaded and run by
> > Apple's built-in WebKit framework, provided that such scripts and code do
> > not change the primary purpose of the Application by providing features
> or
> > functionality that are inconsistent with the intended and advertised
> > purpose of the Application as submitted to the App Store.
> >
> > However, I would only do so if the code is coming from a server that you
> > control, and if you are able to control what code is getting executed.
> > Loading in 3rd party, unverified scripts into your Cordova view is a big
> > "no-no" for security reasons, and could get your app delisted (or
> rejected).
> >
> > If anyone else has more information on the topic, I'd be interested in
> > hearing it.
> >
> > Marc
> >
> >
> >> On Fri, Aug 1, 2014 at 7:01 PM, Victor Sosa <sosah.vic...@gmail.com>
> 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 bad
> >> implementation.
> >>
> >> I concur with everyone, it is possible but awful design
> >> On Aug 1, 2014 4:35 PM, "Frederico Galvão" <
> >> frederico.gal...@pontoget.com.br>
> >> wrote:
> >>
> >>> 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 (HTML isn't, but JS is). It's not only a security concern per se,
> >> but
> >>> also an imposed limitation on the stores (which were obviously created
> >> for
> >>> security concerns in the first place).
> >>>
> >>> Not even mentioning the issues with providing the right cordova.js
> >> version
> >>> from the remote server not really knowing where the request came from.
> >>> However, it's good to note too that aside Phonegap Developer App, there
> >> is
> >>> also Adobe Hydration that does the exact same thing as a side service
> to
> >>> Phonegap Build. I don't know if they've come into any of the issues
> >>> mentioned, and I haven't even heard of it being used in production.
> >>>
> >>>
> >>> 2014-08-01 17:36 GMT-03:00 purplecabbage <purplecabb...@gmail.com>:
> >>>
> >>>> 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.
> >>>>
> >>>>
> >>>> Sent from my iPhone
> >>>>
> >>>>> On Aug 1, 2014, at 10:35 AM, Shazron <shaz...@gmail.com> wrote:
> >>>>>
> >>>>> 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 believe.
> >>>>>
> >>>>>> On Fri, Aug 1, 2014 at 10:23 AM, Marcel Kinard <cmarc...@gmail.com>
> >>>> wrote:
> >>>>>> 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, because Cordova was not designed for this and the
> >>> community
> >>>> does no testing of this configuration. While it can work in some
> >>>> circumstances, it is not recommended nor supported."
> >>>>>>
> >>>>>> My definition of "unsupported" is not that it is incapable, but that
> >>> we
> >>>> don't claim that it is supposed to work, and more importantly, we
> won't
> >>>> actively fix user-submitted defects on this topic.
> >>>>>>
> >>>>>> The main concern I have on this is same origin policy, and matching
> >>> the
> >>>> remotely-served cordova.js with the locally-installed native Cordova
> >>>> platform to avoid version mismatch.
> >>>>>>
> >>>>>> Do you think I'm out in-the-weeds on this, or do you agree?
> >>>>>>
> >>>>>> If you agree, what would you think of a blurb in cordova-docs
> >>> somewhere
> >>>> that captures this gist?
> >>>>>>
> >>>>>> Thanks for your feedback!
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> *Frederico Galvão*
> >>>
> >>> Diretor de Tecnologia
> >>>
> >>> PontoGet Inovação Web
> >>>
> >>>
> >>> ( +55(62) 8131-5720
> >>>
> >>> * www.pontoget.com.br <http://www.pontoget.com/>
> >>
>
--
<http://www.wizcorp.jp/>Ally Ogilvie
Lead Developer - MobDev. | Wizcorp Inc. <http://www.wizcorp.jp/>
------------------------------
TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 | Website
<http://www.wizcorp.jp/> | Twitter <https://twitter.com/Wizcorp> | Facebook
<http://www.facebook.com/Wizcorp> | LinkedIn
<http://www.linkedin.com/company/wizcorp>
