OFFLINE BUILD

[ENEMALI_J_]

I just started using intel xdk and discovered you can only get the .apk version of the app if you are online, is there any way to build to apk offline?

thanks in advance

[SithLord]

You cant build xdk offline but you can setup a local cordova build environment.

http://cordova.apache.org/docs/en/4.0.0/guide_cli_index.md.html#The%20Command-Line%20Interface

[PaulF_IntelCorp]

For best bet when working with CLI locally, is to use the Early Access version. In particular, see this doc page: https://software.intel.com/en-us/xdk/docs/early-access-project-plugin-selection

[ENEMALI_J_]

Thanks SithLord  and  Paul Fischer (Intel) i will give both suggestions a trial and see what i can come up with . But i will happy if intel will come up with a single package where you just install , code your app then build without the need of an online buildserver ( i'm just a beginner thats why i speak like this)   .

thanks again

[John_H_Intel2]

That would require much much much more work/install size/work/work for the developers. The builds make use of the Cordova builds (in the cloud) that we (Intel) can control which version(s) you are building against.  If we allowed for Android, others would want it for iOS, however iOS builds must happen on a Mac, which not all users have.

Dont look for local builds to happen with the XDK anytime soon. :)

You will need to install the CLI outside of the XDK to make this work.

[SithLord]

I started using xdk years ago when it was a much less polished product under appmobi. Despite various issues over the years I've never considered stopping because with xdk i don't have to deal with the build environments issue.  I could have dealt with the android side but I find most development tasks that involves apple ends up being rather distasteful. 

I wish visual studio tools for cordova had something similar but i expect Microsoft will come out with their own cross platform cloud build environment around the same time Intel rolls out their 'local build' environment.

[Michael_O_2]

Intel XDK is still the best open source cross platform environment.

It has evolved from just a Google Chrome plugin to a full SDK.

[Thepjday_A_]

With the advent of XDK 3649, there is a prominent warning that the XDK will stop supporting mobile targets in the future and focus on IoT.

Understandable that this would be your new area of focus, but despite comments that there are mature HTML5 and hybrid build solutions to be used "natively", for those of us that have built our ecosystem around the XDK build pipeline, this is problematic. In order to use these "native" solutions, we need to migrate our code and build systems to the new toolset without having a clear understanding of which piece came from where. Also, many of these Mature HTML5 environments are specific to certain environments (Mac, Windows) and very few exist that allow us access to the cross-platform access of XDK. (Linux)

We do not expect you to support us indefinitely. However, because there is much magic happening under the hood on the cloud build servers, and we have no clear process by which XDK takes the information that is sitting in the config files and then creates the corresponding build configs for Cordova, we do not have a migration path. And there is a certain expectation for those of us that have jumped on the XDK bandwagon for the last 2+ years to have some clear mechanism to exit with our time-investment intact. Granted, there may be some heavy lifting on our part to create scripts to translate from XDK configs to others, but there is currently no guidance on this.

Is there any hope of a tutorial on migration or exporting the build configuration one final time before retiring mobile targets so that we can switch to locally maintained and built mobile targets from our legacy ecosystems? Such that we could install open source packages like Cordova and be able to use our heavily invested builds and mobile apps from the XDK ecosystem in a local environment which would take place of our then-defunct ability to build mobile targets in the cloud? This exit strategy would allow us to continue to focus on use of the XDK for IoT and advocate its continued use. But to remove our build targets and simply tell us to "go elsewhere" would make it seem like when IoT is no longer the craze that rebuilt Rome, it too will go the way of the Dodo.

Perhaps when the mobile build targets are deprecated, the cloud build process can be clearly documented and open-sourced for those same mobile targets? The documentation alone would be a big assist.

While the XDK platform has been spectacular at hiding some of the complexities of the Cordova environment, it has at the same time made it hard for those of us learned to use the XDK GUI build pipeline to go back to the CLI since we have not seen how the GUI pieces fit in the CLI pipeline. Even if many of us are CLI experts or even linux certified developers and admins - we do not know how to migrate back to the non-cloud reliant build process. And now I and I'm sure many others are feeling the impending crushing force of the walls of the Imperial Trash Compactor closing in with no R2D2 or C3PO in sight.

Thanks.

[Hamilton_Tenório_da_]

The words of Thepjday A.  are mine too. I created all my ecosystem around the XDK. My startup (only me) is based in some apps created and operated using XDK (since XDK New).

I passed for some update versions. I recreated, changed and rebuild to follow new requirements and spent a lot of time considering this excelent tool as a great companion. 

Those days, since the last release, I am wondering about a solution for me. I do not know anything about CLI, Cordova and others components. I am worried about XDK future and how I can migrate to other plataform, if necessary. 

For me, at this moment, this situation is a nightmare.

[Diego_Calp]

Hi all,

+1 for Thepjday and Hamilton comments.

I'm not so worried about the toolchain to build an hybrid app because I'm sure that with some effort looking cordova cli documentation and googling it is feasible to set up. I recognize that XDK toolchain is great, it will be a big loss not to having it. But there are alternatives, some online and cli resources ready like Phonegap and others.

My point is that a haven't find yet an opensource wysiwyg GUI builder like XDK. It was fantastic also the initial support of several frameworks, but I understand that keepeing all up to date for XDK Designer must be very complicated. Seeing the deprecations, my hope was that one or two most popular will be mantainted, like Bootstrap and Ionic.

With XDK I can draft a mobile app in minutes. That, added to the integrated simulation and debug options make it a developer's dream tool.

I also read Intel's staff comments about the mature staus of tools to develop mobile apps, but couldn't find any like XDK designer for the GUI. Anybody has a suggestion?

Thanks,

Diego

[PaulF_IntelCorp]

Note that an "IoT Companion App" is a mobile Cordova app that's been optimized for use with IoT devices and IoT cloud services.

If you do need to move off our build system to a local Cordova CLI build system see this forum post > https://software.intel.com/en-us/forums/intel-xdk/topic/685326#comment-1885369 < which contains a short list of how to convert your project to Cordova CLI.

Fortunately, since our build system is standard Cordova CLI and our intelxdk.*.config.xml files are about 90% standard Cordova config.xml files, there's really not that much "magic" under the hood. Note, also, that PhoneGap CLI is a "convenience" shim on top of Cordova CLI, so you could also migrate your projects to PhoneGap CLI or to PhoneGap Build (which is an offline extension to PhoneGap CLI).

The UI frameworks change so frequently, that any graphical UI design tool requires a lot of work to just maintain "lock step" with updates to the various libraries. Probably one of the reasons it is so difficult to find a good open source or free UI layout tool. For using the Ionic UI framework, I recommend you checkout Ionic Creator (http://ionic.io/products/creator); it's only free for a single project, but it may suit your needs, if that is your UI framework of choice.

[Thepjday_A_]

Here's a real question and a real thought.

I'm re-asking here because it may not have been the proper place in the other thread. There is much talk of "lots of heavy lifting to maintain against new versions of libraries". But for starters, not a lot of us are losing sleep over the newest versions of libraries and some libraries are mature and the new versions are slow to come.

Having said that - XDK is a NodeJS Client-server app that runs JavaScript with a few fancy libraries to provide additional capabilities.

While I agree it is not feasible for Intel to support XDK perpetually, there may be other routes to take. When Intel decides to deprecate features, it could be useful to open-source or unburden the license for the removed features so that they are still copyright Intel but are perhaps a more permissive license like LGPL or Apache or the like.

I asked once before if we could maintain the UI builder and was told it was not possible. Having read through the support code for the UI builder, I would like to posit that we can definitely maintain the UI builder even after specific libraries are removed. However, the thing PREVENTING us is the license which clearly states that we cannot use any of the JS code without express consent and permission.

And on top of that, as the XDK forces us to login, even if we are not using the online builder, we are STUCK not being able to do things when the XDK version we want to use no longer works.

Is there any recourse to either relax the licensing of the removed features so that Intel still owns the copyright but derivative works can be created? Is there any way to allow older versions of the XDK to continue to function without requiring a login if we are not using the cloud build features? I was once informed I could continue to use 1912 to use the app designer until I realized I couldn't because 1912 insisted I had to log in.

I think the real cost to us is not the vendor-lock-in but rather the vendor-controlled-obsolescence. It's akin to the loss of Optima++ by Watcom which was then acquired by Sybase and then killed off. No such feature-rich C++ UI environment ever returned to the fore nor do any of the current crop of UI designers provide the level of language versatility that was present in Optima++ - we lost closures and the ability to code in snippets or the larger window area - we lost the ability to create custom classes dynamically and have the system recognize them. Not even the Embarcadero or visual studio product comes close to the ability of Optima++. Visual Age for C++ was close once but it had too many graphical symbols and not enough literals - the arrows were just too much - scratch is a better visual. As we lose features in the XDK, we have no ability to recreate or maintain those features because Intel says we cannot reuse the discarded parts even if it is not for profit.

Perhaps the improvement we need in the XDK is not more Intel staff but expansion of the XDK community allowed to contribute to the product.

Running the XDK JS through a beautifier shows things that are not obvious such as: live-view can be enabled if your app doesn't use the special features, but XDK has forced it to be turned off for hybrid apps; update-checks can be disabled but XDK does not allow this feature. The list goes on.

We do have the expertise to assist and provide additional benefits to the XDK ecosystem. Perhaps Intel would be better served by allowing the different libraries or featuers to have its own set of maintainers and commiters and perhaps provide or allow us to create a plugin mechanism for the UI so that we lessen the burden on Intel but still allow the tool to flourish. In addition, but extending to the community, it becomes possible to maintain the build targets long term for those of us that rely on them for our future growth.

Please feel free to weigh in with comments and suggestions. I really think this needs to go beyond just Intel maintaining it - especially for the parts that are no longer profitable or areas of focus for Intel but are very valuable to us.

Otherwise, per license, we are NOT ALLOWED to use any of the content in any way not allowed expressly by Intel in the currently working version.

P.S. I still have multiple correction patches I have to apply to run this on Fedora and patches to the sidebar plugin in JQM in order for it to react to events correctly. On another note, the JQM patch for the select has been fixed in the most recent XDK.

/*
 * @license Copyright(C) 2013 - 2014 Intel Corporation All Rights Reserved.
 *
 * The source code, information and material ("Material") contained herein is
 * owned by Intel Corporation or its suppliers or licensors, and title to such
 * Material remains with Intel Corporation or its suppliers or licensors. The
 * Material contains proprietary information of Intel or its suppliers and
 * licensors. The Material is protected by worldwide copyright laws and treaty
 * provisions. No part of the Material may be used, copied, reproduced,
 * modified, published, uploaded, posted, transmitted, distributed or disclosed
 * in any way without Intel's prior express written permission. No license under
 * any patent, copyright or other intellectual property rights in the Material
 * is granted to or conferred upon you, either expressly, by implication,
 * inducement, estoppel or otherwise. Any license under such intellectual
 * property rights must be express and approved by Intel in writing.
 *
 * Unless otherwise agreed by Intel in writing, you may not remove or alter this
 * notice or any other notice embedded in Materials by Intel or Intel's
 * suppliers or licensors in any way.
 */

[PaulF_IntelCorp]

Thepjday -- I'm assuming you meant to write "Intel" and not "IBM" in your message. Intel does have open source projects, and many engineers working to support them. From the beginning of this project we decided not to make it an open source project, for a variety of reasons that aren't really important to the discussion.

I can certainly let management know that some developers are interested in converting the deprecated features into open source. Reading between the lines, it sounds like you are specifically interested in an open source version of App Designer? It's not that clear.

Thanks for your feedback.

[Thepjday_A_]

Good catch - I replaced "Intel" for "IBM".

So there's the use cases I'm looking at:

1. Intel deprecates a feature but I want to keep using it so I need to be able to use the older version of the XDK but I cannot because Intel says I have to login - I can't disable the login

2. Intel doesn't support the library I want to use, but I want to add the library as a possible toolkit for use.

3. Intel removes certain features from the build in JavaScript, but I want to add it back.

I can get to the JavaScript today to do these things. I am not allowed to per the license in the JavaScript file.

So I can CORRECT behavior, but I cannot add behavior nor can I re-use the existing to support a new target library.

Granted, I do not expect any copyrights to the prior code. But Intel would have to decide if they wanted to go the way of the GPL and require that my code be assigned free source level use, or if it would be LGPL and that it would stay copyrighted to me while the mods required to make use of it would be owned by Intel. I'm envisioning an ecosystem of devs who create and maintain app designer plugins and maybe part of the agreement is to sign up with Intel and for each copy of a plugin sold, Intel gets a piece of the pie. Or Intel could make it required that the plugin if made free could be bundled with the XDK with the dev's claim to fame. There are so many ways to slice this.

What I'm reacting to is "we can't maintain all the features so we choose what is active" and changing that to "we can't maintain all the features so we're allowing others to help us maintain things that are important to them."

If you leverage the community, it is possible to keep providing existing targets (because it becomes someone else's headache), or add new libraries (because it's someone else's itch to scratch). It doesn't have to become a "we can't support it with personnel but we do have the servers so due to limited bandwidth of our staff, we are reducing the featureset".

Isolation in silos in the face of limited resources is what eventually kills a project and a product.

[Diego_Calp]

Hi all,

Count me among the developers interested to opensource deprecated functions.

Thanks,

Diego

[PaulF_IntelCorp]

I have forwarded your requests to management.

[Thepjday_A_]

P.S. An open-source app-designer would certainly help a LOT - it's where the meat of the rubber meeting the road happens to be since that's the most time-consuming part of creating the interface is.

But even a plugin-system for the app-designer would allow us to continue to use the libraries that we think we need to continue to use or to add new ones that Intel hasn't got to. Make sure you put in the caveat that failure of code in the plugin is the responsibility of the respective developer. And please make sure we have a test suite that allows us to know that the plugin meets the interface requirements of the app-designer :).

We would be happy to edit the rest of the code in the existing Brackets ecosystem.

The other thing that we would want to assist in maintaining is the deprecated build targets - remember - "mobile targets will be deprecated in a future version of XDK as the focus of Intel is IoT".

Thanks.

[PaulF_IntelCorp]

Thepjday A. wrote:

The other thing that we would want to assist in maintaining is the deprecated build targets - remember - "mobile targets will be deprecated in a future version of XDK as the focus of Intel is IoT".

Not sure where you found that quote. Mobile companion apps are one of our targets; which are mobile Cordova apps and web apps optimized for use with IoT apps. For example, a mobile app that can be used to interrogate or configure an IoT device and it's cloud-based data would be considered a mobile companion app.

[Thepjday_A_]

Found the reference here:

https://software.intel.com/en-us/xdk/docs/release-notes-information-intel-xdk

We are "All-In" on the Internet of Things (IoT)

With respect to IoT, you should expect us to add more functionality for IoT app development over time. As a result, we will be deprecating and eventually removing some mobile app development features that are not well used, or out of date and not worth updating. We will announce such deprecations in Joe's blog, in these Release Notes and in the Intel XDK forum.

I read this as: if intel decides a mobile target is not well-used or out-of-date or not-worth-updating, it falls into this category. E.g. Amazon targets have disappeared. As have facebook apps.

Oh - one more thing - the "login required" should really be "login optional". For logins into deprecated versions for whatever reason, the "build" and "publish" tabs should be disabled but the login should still be allowed (if you require a login). This "forced upgrade" in order to use the editor and emulator and app-designer is getting really old really fast. There is no real reason to force someone to use the newest version of your editor universe if that universe isn't going to support them fully going forward. E.g. Deprecating Framework7, Ionic, JQM etc etc etc. I get why the upgrade is there and the feature may be deprecated, but forcing someone to login and then forcing them to upgrade because the old version can't build instead of using the old version that understands the platform doesn't seem very logical. I get that we can't build with the older versions - why bother having us login?

FYI - this happened right around 2833 or around there. I was using 1912 for the longest time - I was told I could continue to use it as I was in a production rollout - and I still had to login. And then all of a sudden I couldn't login on 1912 and had to upgrade - even if I was attempting to  bypass the cloud build system. So my upgrade to 2833 happened not because of the improvements in XDK but because XDK would no longer let me edit my project.

If you DO force us to login, please do so on the tabs where they are required - the build and publish tab and whichever other ones use Intel cloud systems.

The rest of the tabs should not require a login (optional) or the login should be allowed on deprecated versions/plugins and just and if it's for an un-supporterd platform, let it be on the head of the dev responsible to make it work - Intel should allow the dev to indemnify them for the use of the non-supported plugin.

My two cents.

Thanks.

P.S. For the record, app-designer is the BEST editor out there bar none - EXCEPT the defunct Optima++ editor which allowed me to tie events directly to specific snippets of code and allowed me to edit that snipped in isolation if I wanted to or edit it as part of the complete page if I wanted to. I just wish there was another way to demarcate what an event handler connection looked like because I've had to create quite a few delegates that marshall common arguments in order to create the connection and having to repeat the same arguments falls short of DRY.

[Thepjday_A_]

That was weird - I submitted a comment - and it got flagged for approval. I hope I did not say anything offensive or rude. Apologies if I did but I was only pointing out where I found the mobile target reference and the need to perhaps make the logins optional. Feel free to sanitize my post for any offensive words if there are any - I promise they would have been unintentional. As I've stated before, I've stuck with XDK because it is the best cross-platform UI editor and the best environment for putting all the parts together. I just want to do my part to make sure that it stays viable.

[PaulF_IntelCorp]

Thanks for the additional feedback.

Regarding the "flagged for approval," there are times when our web sites and forums are getting hit heavily by spam and other "bad actors" which results in a "dialing up" of the monitoring systems that filter that stuff. I suspect IT just turned up the dial and it caused your post to get caught in the "flagged for approval" queue. It's not something I can control, this forum is just one of many maintained by our IT group.