xmnboy's Forum Posts

  • 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 sucks 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 sucks.. i have a pre android 5 phone so i know it will suck 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".

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Chigabooga -- the XDK builds standard Cordova (aka PhoneGap) apps. It has no bearing on the way your apps are initialized, how they run or how the various Cordova plugins work. Thus, there is no "fix" that the XDK can provide to deal with the audio delay issue you are experiencing. I recommend you search Stack Overflow for issues related to Cordova or PhoneGap apps and audio delays, and include keywords in your search regarding the plugin or HTML5 technique you are using to play your audio. Any solutions you find for Cordova/PhoneGap apps can be applied to an app built with the XDK, since it simply builds a Cordova app.

  • Ashley and — -- I've tried to summarize how best to update an existing Intel XDK project using the "new" Construct2 export option, here > https://software.intel.com/en-us/forums ... pic/607195 <

    Ashley -- I'm not clear on how to refer to your "new" export process. Please read over what I have written to confirm that I have not left anything out and there is no confusion.

  • — -- you could use links to do what you are trying to do.

    For example:

    • export initial project (first time export)
    • open initial project in the XDK
    • export second time to a new location (preserving state of first export)
    • replace www in first project (the active XDK project) with a link to the second project's www folder
    • make subsequent exports to the second project

    Now all subsequent updates from C2 go to the second location and only the www folder in your initial XDK project will be updated, leaving the <project-name>.xdk unchanged each time you export to the second project.

    In this case your first project is the master XDK project, meaning it contains the plugins folder, the <project-name>.xdk file, etc. The second project is the master source code project, because it contains the www folder with all resources. This will work best with hard links, not soft links, which require that both projects exist on the same filesystem. Hard links are supported on Mac, Linux and Windows machines, so this solution applies regardless of the OS on your development system.

  • xmnboy - if the problem is the .xdk file being overwritten, perhaps a simpler workaround is to export to a separate folder, then copy all the files over apart from the .xdk file? i.e. just update all the asset files and leave the same project file.

    Ashley -- that is the approach that should be taken: 1) export new project once then 2) export to a new location and copy updated files to the original project. This is a bit cumbersome and might be difficult for some developers to use or understand.

    I'm thinking an approach that allows one to export only the www folder (call it an "update export") for delta updates. Perhaps if you detected an existing <project-name>.xdk file you automatically just update the www folder in the destination? I can show you how to detect if that <project-name>.xdk file has been processed and is now in use by the XDK.

  • — -- The pathnames in your video are blurry, so I cannot be sure, but I believe you exported the Construct2 project a second time, on top of an existing project that had previously been imported by the XDK. Is that correct?

    If my assumption is correct, then I believe what is happening is you are confusing the XDK by changing the contents of a "known good" project file (the <project-name>.xdk file) with a project file that was exported by Construct2.

    Try this process, instead, when you intend to export a new copy of your project from Construct2:

      * "remove" the old project from the XDK project list * exit the XDK * delete (or rename) the old project's folder * export your Construct2 project * "open" the newly exported Contruct2 project

    The <project-name>.xdk file that is exported by Construct2 is a "partial" project file, it gets "completed" by the XDK on the very first open. Once it has been added to the list of projects in the project file list it is expected to be in this "completed" state the next time it is opened -- but if that <project-name>.xdk file has been over written, the project is no longer in that "completed" state. This is likely the cause of the error message you are seeing in the video.

    Let me know if the process described above works.

    In essence, if you are going to export the same project, multiple times, onto the same location on your development system, you need to first remove the old project from the XDK project list AND remove it from your system (or rename the project folder so it is effectively gone).

  • Xam CDogs1964 PixelPower frazermerrick — -- please see the second half of the top post for a possible solution to the black screen problem on iOS 10 > https://software.intel.com/en-us/forums ... pic/685395 <