> AFAIK, PhoneGap Build has identical support to the XDK. So you can just use PhoneGap Build now. They are both based on Cordova.

>

> The main reason we postponed our own build system is the XDK did the job for free. It's a shame they are retracting a free service, but since nobody ever paid for it, it's not really that surprising.

>

Hi Ashley,

I think they are not identical.

For example with xdk I can use the GPS and the camera with android. With PhoneGap not working.

Is there any way to fix this?

Thanks

IceVANPS -- I cannot speak for Ashley, but the PhoneGap Build system is, practically speaking, the same as the XDK build system (with more CLI version options and some additional config options). How you interact with PhoneGap Build is different than how you interact with the XDK build system, but both generate the same packages and both rely on Cordova CLI (in the cloud) to perform the build. Both use the identical Cordova plugins to provide access to native device features and APIs. These are the very same plugins that Cordova CLI uses, there are absolutely no differences regarding plugins and APIs when comparing PhoneGap Build to the Intel XDK to Cordova CLI.

If you are having trouble with the GPS and camera on PhoneGap Build I suspect you are experiencing a configuration issue. Have you tried using the Cordova Build Package export option in the XDK to create a package that you can submit to PhoneGap Build?

xmnboy -- Thanks for the details. Its really really sad XDK publish is going away!

I heard Visual Studio allows you to compile APKs using Cordova projects. Is that true? Can same be used for iOS compile as well?

Yes, Visual Studio has an add-on for creating Cordova apps. They have been very active in the Cordova project. However, they do not provide a "build in the cloud" option, like the XDK or PhoneGap Build. You need access to a Mac to build for iOS; however, they support the use of a "remote" Mac on your local network.

Importing a Construct2 app into a Visual Studio project probably requires quite a bit of effort. I recommend you use PhoneGap Build (which does not require access to a Mac) or build with Cordova CLI directly (which does require access to a Mac, like Visual Studio).

Has anyone tried the newest version of XDK, 3922, that just came out?

We highly recommend that you use 3922 and not 3900. The 3922 release is a hotfix of 3900 -- meaning that it fixes a bunch of issues that were introduced with the 3900 release. Also, the Cordova export package has several improvements for better compatibility with PhoneGap Build. See the release notes for details > https://software.intel.com/en-us/xdk/do ... -intel-xdk <

xmnboy I am getting an error in Phonegap build that I did not get in Intel XDK. I think it has to do with the official In-App-Purchase plugin by Scirra. When you import your project, the plugin comes up with 2 errors in intel XDK, but you can dismiss those and add your own custom plugin to make it work. But with the phonegap build within XDK it doesn't let me build at all with the official IAP plugin included. Not sure how to fix this...

STARTECHSTUDIOS -- the only way to employ your custom plugins with PhoneGap Build is to pay for an account that allows private plugins. Otherwise, you can use Cordova CLI to build with custom plugins.

yea but the game must be under 50MB. So nothing fancy.

But okay. I can manage. What about AdMob/IAPs support?

Like the Intel XDK cloud-based build system, the PhoneGap Build system also does not allow the use of Cordova CLI "hooks scripts." These "hooks scripts" are special scripts included with plugins that allow the plugin to perform extra tasks before and after the build process. In the case of the Intel XDK build system they were disallowed, primarily for security reasons, because there are no limitations on the actions those scripts can take.

Given that limitation, if you have successfully incorporated and used a plugin with the Intel XDK build system you should be able to use that same plugin with the PhoneGap Build system. Our plugin restrictions have generally been stricter than the PhoneGap Build restrictions, and many plugin writers have alternate versions of their plugins that are specifically directed at and tested on PhoneGap Build, so I do not see any plugin compatibility issues for users of the Intel XDK build system that migrate to PhoneGap Build.

Also, given that Adobe maintains a faster and more complete adoption rate for their PhoneGap Build system, I would expect more flexibility and better results with their build system than with ours.

PhoneGap is paid and limited. Are you telling me to spend even more money...?!?

PhoneGap Build offers one free "private" slot. You can use that private slot to build as many apps as you want. The private slot doesn't remember the name of the app you've built with it, so if you have three apps you can build all three with that free private slot. After you build "appA" just upload a ZIP of "appB" into the private slot and build that, etc.

They do limit the size of the ZIP you can upload into the private slot, but for most users I don't think the size limit is an issue.

Of course, the Cordova CLI option is completely free, which is exactly what PhoneGap Build and the Intel XDK build tools are based on. Both create Cordova CLI apps.

Does this mean we will lose access to our apps that were published with XDK using Cordova since the KeyStore we used is on XDK? If we export them from XDK are we able to import them elsewhere or is the export for XDK only?

The keystore you've been using with the XDK has always been available to you. Use the Certificate Management tool under the Account Settings section of the XDK (upper right corner "person" icon). From there you can download your keystore (see the docs for the PhoneGap Build/Cordova CLI export tool).

Even when the XDK build server has been retired, you'll still be able to download the keystore file, which you will need if you use either PhoneGap Build or Cordova CLI to build your app.

NOTE: retrieving the keystore only makes sense if you ALREADY have an app in a store. If you have never published your app, there is no need to retrieve that keystore from the XDK.

>

>

> >

> > ugh...XDK is what I use as well... I wonder why they nixed it?

> >

> >

> Probably because they've provided their services for free and never charged.

>

>

Actually it's because Android Nougat does not require the webview engine anymore.

It kinda ***** for us because the projects that run on webview will face some issues on devices running latest version of Android Nougat.

Android has not needed Crosswalk acceleration since 5.0 (Lollipop) was released. If your only interest in Crosswalk was a good performance webview (which is true for most Construct2 users), then you can limit distribution of apps built with Crosswalk to Android 4.x devices, because Android 5+ devices have a webview that is updated regularly by Google (no guarantee of how often it is updated for non-Google stores).

If you have imported your app into the Intel XDK, and Crosswalk is enabled for that project, the config.xml file we provide using the PhoneGap Build/Cordova CLI export tool will result in including the Crosswalk library when built with either PhoneGap Build or Cordova CLI. The APK you get using that config.xml will be a "multi-architecture" APK, because the PhoneGap Build interface will only return a single APK file to you. That APK will be larger than the one you normally get from the XDK because it contains both a 32-bit x86 Crosswalk lib and a 32-bit ARM Crosswalk lib, but only one APK needs to be submitted to your Android store.

If you have a project in the XDK, I recommend you do the export so you can get the config.xml file it generates for reference, especially if you are going to permanently move away from the XDK and move to using either Cordova CLI directly or PhoneGap Build. There are a few bugs we are working on, but by and large what it generates now will work.

PS -- if you remove the spec="#.#.#" part of the Crosswalk plugin tag in the config.xml file you'll get a build that will use the most recent version of Crosswalk, which is version 23. Likewise, if you remove the <preference name="phonegap-version" value="cli-6.2.0" /> tag you'll get the latest CLI build from PhoneGap Build (what you get with Cordova CLI depends on the version you installed).

no i havne't tried webview, it sounds like it ******* i have a pre android 5 phone so i know it will **** for my test device.. i'm ok with crosswalk and cocoon.io regardless of bloat.. i don't really care if a game is 30mb.. few people are going to not play my game because it's 22+ mb

Some clarification for those reading this thread regarding "webviews" and build systems:

* All Cordova apps (PhoneGap, XDK, Cordova and other HTML5 hybrid apps packaged for distribution in a mobile store) run in a "webview" (aka, the HTML5 runtime engine).

* The "webview" is built into the device OS/firmware, so performance varies as a function of the specific device hardware (CPU, RAM speed, Flash speed, etc.) and the version of the OS running on that device.

* iOS 9+ devices allow you to select between the "standard" webview and the "wk" webview. The "wk" webview has better performance than the "standard" webview.

* Android 5, 6, 7+ devices have a "replaceable" webview, which is equivalent in features and performance to the mobile Chrome browser runtime engine. That webview is automatically updated, from time-to-time, via the mobile app store.

* Android 4.x devices have fixed webviews, with substantially lower performance and features compared to the mobile Chrome browser runtime engine.

* Crosswalk is a replacement webview that can be installed on Android 4.x devices (as well as Android 5+ devices). It is based on the Chromium project, so generally has similar features and performance to the Android 5+ replaceable webview, but is usually several releases behind.

* Only Android allows for replacement of the webview. Windows and iOS devices do not allow the webview to be replaced, they are fixed in the device (in the case of iOS you can select between the two stated above).

* The Crosswalk webview is actually enabled via a Cordova plugin (as is the iOS "wk" webview). Checking the "Optimize with Crosswalk" option in the XDK simply enables including that plugin during the build phase.

Cordova CLI and PhoneGap Build and the Intel XDK are all standard Cordova build systems. Those systems, and any other build systems that depend on Cordova CLI (under the hood), will always build to the "standard webview" that is built into the device, unless the Crosswalk plugin is added to the mix for Android orthe "wk" webview plugin is added for your iOS projects. Windows devices have no such options, you get what you get.

Thus, the performance you get from your game will be the same whether you build with PhoneGap, Cordova or the XDK, assuming you build with the same set of plugins and the same HTML5 code. The reason you see performance that is usually worse with PhoneGap Build or Cordova CLI is because you have to take some extra steps to add the Crosswalk plugin to your project (which the XDK does automatically for you if you check that "optimize with Crosswalk" box). But if you include the Crosswalk plugin with PhoneGap or Cordova CLI you'll get similar performance to the XDK.

Cocoon and Canvas+ are doing some other tricks that provide specific optimizations for specific types of operations, so performance comparisons with those systems against standard Cordova builds will vary depending on how your app works. I do not have insight into precisely what they are doing, so I cannot comment on where to expect those performance advantages, but you should understand that YMMV when using those tools.

"ulysses 31" -- As — indicates, the plugins you include in your app determine the permissions that are shown when the app is installed. The standard Cordova build will usually include the "network" permission, and a few older versions of Crosswalk included two or three others.

If you are building with CLI 6.2.0 and a recent version of Crosswalk and are seeing a lot of permissions, this is due to the Cordova plugins you've included with your app.

Attempting to remove the permissions from your app, without removing the plugins that require them, will result in problems when your app runs. Those plugins require those permissions because they use Android APIs that require those permissions. If you remove the permissions those API calls will fail when your app runs.

The best way to control the permissions is to evaluate the plugins you are using and determine which are adding permissions you do not want in your app and see if there is an alternative that might require fewer permissions. For example, if you are using a plugin that implements multiple functions, but you only need one of those functions, you might be able to find a plugin that implements only that single function, in exchange for fewer permission requirements.

TheRealDannyyy -- sorry for taking so long to reply, I don't check the Construct2 site that frequently. Providing a mechanism to support APK expansion files is outside the scope of the XDK and the types of apps we are supporting. It is not something that will be added to the product. For that sort of a feature I recommend you go directly to using Cordova CLI, where you have much more control over the construction of your APK files.

There is at least one APK expansion file Cordova plugin available (perhaps more) that you might want to experiment with. It likely will not work with our build system, because there appears to be a lot of fixups to your project that will likely fail with our build system, thus Cordova CLI is your best bet.

aquadijoib -- I think the problem is due to a space in you path or, possibly, due to a bad TMP environment variable. See this piece from the beginning of the error message:

[quote:3ashpemd]

File not found: C:/Users/user/Desktop/SmartWebRadio (mobile)/www/C/Users/user/Desktop/SmartWebRadio (mobile)/package-assets/app_icon_96x96.png.png

Note the odd filename "C:/Users/.../SmartWebRadio (mobile)/.../C/Users/..." the path is "starting over" within the file reference ("C/Users/" is equivalent to "C:/Users/"), which may be due to a space in your path or something else (not quite sure what that 'something else' would be).

Could be due to some weird specification of the location of that image file? If you check the various intelxdk.*.config.xml files that are generated in your project folder, you can inspect the paths that are specified for the icons. They should start with "package-assets" not with "C:/" or "/C".