The Intel XDK application consists of a set of development tools to help you code, debug, test and build mobile web apps and hybrid HTML5 apps for multiple target platforms. This document provides an introduction to the main Intel XDK elements; detailed instructions for each tab can be found by referring to the links in the documentation overview. Tabs in the tool are directed at different stages of the development process. These tabs are presented in the order that you will normally use them; but there is no requirement that you use them in the order presented, you can jump between the tabs as your development requires.
If you are unfamiliar with the concept of using HTML5 to build cross-platform hybrid apps, you can read Building Cross-Platform Apps with HTML5 before you begin using the Intel XDK development system.
Each project in the Intel XDK corresponds to an HTML5 app. You can create an HTML5 project from scratch, by importing existing HTML5 apps or by modifying any of the included sample apps. The Intel XDK requires that a "project" conform to the following two rules:
All files are contained within a hierarchical set of folders emanating from one root folder.
An index.html file is located in that top-most (root) directory of the project's folders.
When a project is created or imported, the Intel XDK creates a special <project-name>.xdk file and locates it in the same directory as the project's index.html file (in the project's root directory). This special <project-name>.xdk file is used by the Intel XDK to manage your project; it does not contain any application code and is not required for your application to execute on a real device. If you delete, relocate or corrupt this file you can recover it by simply importing your project into the Intel XDK and it will create a new <project-name>.xdk file.
Note: The currently active project is always highlighted in the project tab and is the project on which all other tabs operate. The tools in the Intel XDK operate on only one project at a time.
Editing and Designing a User Interface (UI) Layout
App Designer includes an emphasis on responsive layout design through the use of a grid system and media queries, and is especially suited to designing layouts for different screen sizes and orientations. App Designer supports a collection of popular UI framework libraries – one of which you must select when you initially create an App Designer project. App Starter is designed to maximize your use of the App Framework UI library. It is well-suited to rapid prototyping and multi-view layouts.
You can switch between Brackets and whichever UI layout editor your project is configured for at any time during your editing process (but only on those files that are supported by the layout editors – normally the index.html file). The UI layout tools will only be available if you start your project as an App Designer or an App Starter project. If you do not initially create your application in this manner you will only have access to the Brackets editor from within the Develop tab.
App Designer and App Starter are "round-trip" editors; meaning that you can directly modify the HTML layout they create and see your changes in respective UI layout tool. This works only as long as you do not modify the App Designer class="uib*" tag labels ("uib" stands for "user interface builder") or the App Starter class labels. Any elements that these UI layout tools do not recognize will be still be rendered in the layout edit window, but will not be editable within the layout view. Within App Designer and App Starter you can only modify those elements that each layout tool recognizes as editable UI elements.
This round-trip feature is very powerful. Most UI design tools put you on a "one-way" street, where you can mockup a layout, generate code and then are left to finish the work by hand or restart from scratch if you find the layout does not meet your needs. With the UI designer your layout tasks now become part of a more powerful iterative process.
The elements you import into an App Designer layout are built on several popular UI framework libraries. When you first create a layout you choose the UI framework that App Designer will use to build the layout.
Debugging Your Hybrid Mobile App
Apps that only use standard HTML5 APIs and interfaces can be debugged in a standard desktop browser; however, apps that use APIs that go beyond the reach of a standard browser (such as Cordova* device APIs) require something more than a standard browser. Debugging hybrid HTML5 apps is complicated by the fact that hybrid apps have access to device sensors and other features that are typically "off limits" to standard browsers.
The mobile device simulator located in the emulator tab gives you the ability to debug your app's complete functionality, including device APIs, as well as preview your app's layout in virtual mobile devices that span the range from phones to tablets to UltrabookTM devices. Within this tool are panels that allow you to configure the virtual environment seen by the application under test. For example, the GeoLocation panel lets you select the latitude and longitude returned to your app when it calls the Geolocation API.
Selecting a virtual device determines the size of the visual frame rendering your application and helps you see how your app reacts to orientation changes (from portrait to landscape mode). Testing your app this way, with different virtual devices and orientations, lets you quickly determine how well your application will work with a variety of screen sizes and aspect ratios.
Note: The runtime engine that renders your HTML5 code within the mobile device simulator is based on the Chromium open source browser. What you are debugging is a simulation of a mobile device using the Chromium desktop engine that has been augmented with the Cordova and Intel XDK APIs.
Testing on a Real Device
While the device simulator (described above) is a very useful debug tool, ultimately you will want to see how your app looks and performs on real hardware. You can always perform an ad hoc (aka test or debug) build of your app and load it onto a real device, but your ability to debug using this approach is very limited. In addition, the time and effort required to make changes to your app, build your app and then reload your app onto a real device may limit your willingness to take this approach when testing your app. Fortunately, there is an alternative.
From the Test tab you can push your app remotely to a real device, over the Internet, without having to perform a full build. Your app is loaded into a container app on the real device that is representative of the native wrapper included with your app when you build (or package) your app (see next section). Using this process you can evaluate how your app behaves on a real device, and remotely debug your app while it runs on the real device using a tool similar to CDT (above).
Remote debugging means you debug the code running on the real device using a debugger that runs on your development system. Remote debugging allows the debug user interface to not be confined by the display limitations of the mobile device under test. Remote debugging offers many of the same capabilities as debugging in a standard desktop browser or the mobile device simulator (above).
Before you use the remote debug features of the Intel XDK you must first download and install a special container app. This application can be downloaded from the primary store for your device (e.g., Apple Store* and Google Play*). For more information please refer to the detailed instructions for the Test tab found in the documentation overview.
Note: At this time the remote execution and debug features described above are limited to Apple iOS*, Google Android* and Windows* 8 devices.
Packaging Your App for Distribution
By now you are probably aware that HTML5 apps are not limited to execution in a desktop or mobile browser. By packaging your HTML5 web app you can deploy it as a locally installed hybrid mobile app. This enables the use of the same distribution and monetization channels as native mobile apps, as well as the same app installation and launch experience.
In order to deploy your application as a hybrid mobile app you must build it. The build process packages your app into a format that can be submitted to a mobile app store and, ultimately, downloaded and installed on your customer's mobile device. All of the popular mobile platforms (Android, iOS, Windows 8*, Amazon* and Nook*) as well as future mobile platforms (Tizen*) are supported by the Intel XDK. Builds are performed in the cloud, so you do not need to install and configure an SDK or native development system for each target platform on your development system, as you must do if you are building a Cordova (aka PhoneGap*) app.
Like a native app, in order to submit your hybrid app to a store you must obtain the proper developer credentials for that store. The procedures and costs associated with becoming a developer for each store varies and are not facilitated by the Intel XDK NEW. In those cases were you wish to use the Intel XDK NEW to package your app for submission to a store you will have the opportunity to include your developer credentials in the package, minimizing the effort required to go from the build step to the submission step.
Note: Submission of your packaged app to the respective app stores is not a feature of the Intel XDK, it must be performed manually, outside of the Intel XDK NEW development system.
For more information please refer to the detailed instructions for the Test tab found in the documentation overview.
Including Third-Party APIs and Web-Service APIs
Note: The same Cross-Origin Resource Sharing (CORS) restrictions (if any) that apply to server-hosted web based HTML5 apps also apply to packaged hybrid apps.
Within the Services Tab of the Intel XDK you will find third-party web services that either provide direct support for applications built using the Intel XDK or have a relationship with the Intel XDK. You are under no obligation to use any of the services presented in this tab. Likewise, you may use any cloud services that are appropriate for your app, even if they are not presented within the Services tab. Please contact your third-party cloud services provider for information regarding service costs, licensing and technical help.
For more information please refer to the detailed instructions for the Services tab found in the documentation overview.