Download Kony Studio For Mac

1. Download Kony Studio For Mac Osx
2. Download Kony Studio For Mac Download
3. Download Kony Studio For Mac Windows 10

Kony Service Level Agreement

Kony Studio support for Mac OS X Install and run Kony Studio natively on Macs. Selecting platform-specific content Choose the target OS platforms to show only selected platform content such as, widgets, properties, context options, skins, resources, and emulators, i.e. If Android is selected as the target platform, one will see only Android. Kony Fabric is the mobile app counterpart for the Kony Fabric console available in Kony Cloud (manage.kony.com). The app lets users view their application's usage and analytics using a set of standard and custom reports. Report data can be filtered.

1. Definitions.

1.1. 'Hosted Software' means the hosting service performed by Kony for Customer.

DBX Retail Banking 4.1 Learning Path covers the following modules. Functional Walkthrough of Online Banking (OLB), Mobile Banking (MB) and Customer 360 Model Driven Architecture – Business Delegator Pattern Digital Banking Platform Services for OLB, MB and Customer 360 OLB, MB Code Walkthrough for Login, Accounts, Locate Us, Payments and Transfers flow Customer 360 Code Walkthrough for Login. Kony Version 70.

1.2. 'Customer Application' means a Kony Platform-enabled mobile application developed by or for Customer or the pre-configured mobile application included in the Kony Pre-Packaged Application that is configured for its use.

1.3. 'Program' has the meaning assigned to it in the Subscription License Agreement.

1.4. The Kony cloud is comprised of the Kony platform software stack and the Kony cloud foundation that contains the required APIs, automation, security, scalability and monitoring to run the Kony Platform. The infrastructure for the Kony cloud is provided by Amazon's AWS cloud. Kony is an official partner and reseller of AWS services.

1.5. The Kony Server product is provided on the Kony cloud as 'App Services' and is deployed as a dedicated single-tenant environment.

1.6. The Kony Sync product is provided on the Kony cloud as 'Sync Services' and is deployed as a dedicated single-tenant environment.

1.7. The Kony Messaging product is provided on the Kony cloud as 'Messaging Services' and is a multi-tenant shared environment

1.8. The Kony Enterprise Mobility Management (EMM) product is provided on the Kony cloud as 'Management Services' and is a multi-tenant shared environment

1.9. The terms and service levels under this agreement are between the Customer and Kony. No additional contract, agreement or terms are granted or required between the Customer and Amazon.

1.10. Each Kony Cloud environment includes Redundancy and Failover capabilities. Redundancy provides at least two instances of every system component required for the operation of the system. Failover provides the ability to automatically route request or workloads to the second instance of a system component if one of the components becomes unavailable. Redundancy and Failover are achieved through a combination of the software deployment architecture and the Redundancy built-in to the infrastructure hosted by Amazon AWS. The Kony application cluster is deployed behind a load balancer within the same Amazon AWS Region, but across at least two Amazon AWS Availability Zones in two separate physical datacenters. The application cluster deployed will consist of a minimum of two server instances to provide Redundancy, and additional instances added or removed based on server resource usage. The allowed max scale out capacity limit is dynamically adjusted based on the app session consumption rate or number of concurrent licensed user interacting with the system using a ratio determined by Kony to easily meet the resource needs of a typical application and will include the ability to scale up to an increased number of concurrent license users at no cost to Customer. Database layer redundancy is provided through the use of the Amazon AWS RDS Multi-AZ deployment model offering redundant database servers in two separate availability zones. For more information about Amazon Availability zone, please visit: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html.

2. Hosting Support Services Overview

2.1. HostingSupport Services will include:

· Email and Web Portal support for hosting incidents on a 24x7x365 basis

· Telephone support for Severity 1 incidents on a 24x7x365 basis

· Error resolution and escalation support

· 24x7x365 access to Kony's Support Portal

· Access to technical support bulletins related to Hosted Software

Customer may contact Kony through the following means:

Web: https://basecamp.kony.com

Phone: Telephone: 1 (888) 323- 9630 (Press 5 for Severity 1 Incidents)

2.2. Definition of Support Severity and Response Times: Kony will provide support services based on Errors logged by Customers in Kony's Support Portal (following Customer's initial investigation and confirmation that the Error is related to the Hosted Service). Errors will be logged by Customer in accordance with the severity level definitions below. Kony and Customer will work together to achieve consensus should there be any disagreement in assigned severities. Severities assigned to an Error may change with time if mutually agreed to by both parties. For example, an issue may be initially categorized as Severity Low and upon further investigation or after a certain period of time, it may be mutually concluded by Kony and Customer that the issue should be reclassified as Severity Medium. Response and Target Resolution times for Errors will be measured from the time the Errors logged by Customer into Kony's Support Portal. Error activity will subsequently be managed and tracked through the Support Portal. The Customer will have access to audit or review response and resolution times of Errors logged through the Support Portal.

'Error' means a hardware infrastructure or server software issue which renders the operation and use of the Hosted Software in non-conformance with its documentation or the specified SLA's.

A 'Critical' or 'Severity 1' Error renders the Hosted Software completely unusable or nearly unusable or introduces a high degree of operational risk. No Workaround is available that would effectively enable the Error to meet the classification of a Severity 2 or lower. Until this Error is resolved, the Hosted Software usage is essentially halted. A large number of users and/or the Hosted Software performance is severely impacted.

A 'High' or 'Severity 2' Error renders the Hosted Software consistently unavailable or obstructed, and causes a moderate level of hindrance or risk. Workarounds may be available, but use of the Hosted Software or performance is acutely degraded and causes continuing operational risk. A moderate number of users are significantly impacted, but overall the Hosted Software is operational and functional.

A 'Medium' or 'Severity 3' Error is an inconvenience or causes inconsistent behavior, which does not impede the normal functioning of the Hosted Software. It could be an Error that occurs inconsistently and affects small number of users. It may also contain visual errors where the graphical display of the Program is not ideal, but still functioning correctly.

A 'Low' or 'Severity 4' Error has a small degree of significance, or is a minor operational or configuration issue, or is a 'one off' case. A 'one off' case occurs when the Error occurs infrequently and cannot be replicated easily. These are Errors that do not impact the daily use of the Hosted Software. A Low Error is something does not affect normal use, and can be accepted for a period of time, but user would eventually want to be fixed.

2.3. Error Investigation & Reporting Procedures

In order to correct an Error, an initial phase of investigation is necessary. When an Error is reported by a user of the Hosted Software, Customer's support personnel shall first perform an initial investigation to ensure that the Error is not caused by improper usage of the Hosting Service; Customer developed / provided software, any dependency on Customer back-end systems, or due to third party applications/software being used by Customer. Once this process is completed and Customer's support team has investigated the issue and reasonably determined it is Hosting Service related, the Error will be reported to Kony via Kony's Support Portal.

Customer must report Error(s) in sufficient detail to enable Kony to identify and reproduce the Error. Delays in supplying such information by Customer may impact the Response/ Target Resolution timelines.

An initial report should include (but not limited to) the following, as applicable based on the nature of the Error:

· A general description of the Error and its characteristics

· The number of occurrences or frequency of the Error

Download Kony Studio For Mac Osx

· Steps to reproduce the Error

· The exact text of any error messages reported by the Hosting Service

· Screenshots if applicable

· The mobile device type and carrier

· Time of occurrence of the issue(s) (with time zone)

On receipt of the Error and initial investigation details from Customer, Kony will begin diagnosing the Error and will assist Customer until: (i) the Error is resolved or a workaround is provided; (ii) is assigned back to Customer as a 'Customer issue' if the Error is deemed to be Customers responsibility; or (iii) assigned to a Third-Party (e.g. Oracle for a Java Virtual Machine runtime issue) if the Error is deemed to be a Third Party's responsibility except in the case that the Third-Party is Amazon AWS where the Error will remain assigned to Kony. Kony and Customer will work jointly during the investigation such that the current status is visible to both parties. All Errors reported in the Kony support portal will be responded to in accordance with the Severity level as described below.

2.4. Support Response and Resolution Table

Production Infrastructure Errors

Non-Production Infrastructure or Software related Errors

· * Kony will make every effort to achieve the Target Resolution times, however, the time needed to provide a correction may vary depending on the specific nature of the Error requiring correction. In the case of a resolution that includes a software update, additional time may be required to deploy the update to the production environment due to maintenance windows, coordination with customer app rebuild, customer system updates, customer maintenance windows, customer testing, or other deployment activities that must occur after the Error has been resolved within the software.

· Customer will ensure that a resource is assigned to work with Kony to provide information or verification on an ongoing basis, until the issue is resolved.

· In the event of multiple reported Errors being worked concurrently, unless otherwise requested by Customer, Kony will prioritize based on Severity starting with Critical (S1) and then on the time the Error was reported starting with the oldest. The SLA will apply to the top two Errors being worked based on this priority.

· In the event Kony's response time to an Error is negatively impacted due to Customer's delayed response to Kony's request for additional information to correct an Error, the response times provided above will be extended by an amount of time proportionate to such delay.

· Both parties may agree that due to technical dependencies and other factors, certain Errors classified as Medium and Low may be resolved in the an appropriate scheduled maintenance window. Customer acknowledges that Kony does not and cannot guarantee that all Errors can or will be corrected.

· System changes for upgrades or patches will be applied during Scheduled Maintenance unless the change is required to restore system availability.

· Business Days are Monday through Friday excluding US national Holidays.

Service Level Reporting

Each month Kony will provide Customer with a report detailing its adherence to the Service Levels for reported Errors for the prior month.

2.5. Escalation Table

Kony provides an escalation mechanism to ensure that Critical and High issues are addressed in a timely manner. Escalation is triggered when an issue is not resolved within the defined Target Resolution Time Table set forth in section 2.4 above.

The escalation time windows for resolution, and contact matrix are as follows;

Production Infrastructure Errors

Non-Production Infrastructure and Software Errors

3. Service Level Description

Kony provides Hosted Software within a single Amazon AWS region across at least two Amazon AWS Availability Zones. All systems are managed through the Kony Network Operations Center (NOC) in India, which is staffed 24 hours per day, 365 days per year.

3.1. In addition to the service level 'Support Response and Resolution' set forth in Section 2 above, Kony provides Service Level Agreements (SLA) on System Availability, Sync Time and Response Time as set forth below.

'Downtime' is defined as a periodof time when the Hosted Software and Kony Platform is unavailable or not accessible to Customer and its Users. Downtime does not include performance impacts during a customer initiated app deployment at which time the associated servers may recycle to update their runtime code. Downtime also excludes Scheduled Maintenance Windows where Kony performs upgrades or maintenance to the Hosted Software, during which time the system may not be available, or may not perform at the committed SLA levels. Downtime also excludes any performance impacts due to failures in the Customer's website, Customer provided software or Customer back-end data sources which cause the Hosted Software functionality to be rendered unavailable or operating with degraded performance.

'Scheduled Maintenance Windows' means periods during which the Hosted Software may be unavailable due to scheduled maintenance windows. Kony will use commercially reasonable efforts to avoid impacting the System Availability or Average Response Time of the system and any other adverse impact on use of the Kony Cloud and Hosted Software during Scheduled Maintenance and to schedule the maintenance windows during off-peak times. The total Scheduled Maintenance time will not exceed 6 hours per calendar month for each cloud service. Customers will be notified via email of Schedule Maintenance Windows at least one (1) month in advance.

'System Availability' is defined as: Total number of minutes in a given calendar month MINUS Total number of minutes of Downtime in a given calendar month, DIVIDED BY Total number of minutes in a given calendar month.

'App ServicesResponse Time' is defined as the time taken to process a request received from the device to the Kony cloud app services component of the Hosted Software, to the time it responds to the mobile device barring custom application code execution time. Response Time also excludes any delays due to the mobile wireless network and the time required to retrieve and process data from the Customer owned or other external back end systems. This time can be measured through the reporting capabilities of the Kony Cloud using the internal service duration metric available in the service detail report. The Response Time SLA shall not apply to the additional processing time required as a result of custom logic within the Customer Application including, but not limited to preprocessors, java connectors, response parsing, and post processors.

'Sync Services Response Time' is defined as the time taken to process a request received from the device to the Kony cloud sync services component of the Hosted Software, to the time taken to return with a response to establish the data transfer session. The Sync Service ResponseTime excludes any custom code execution time or delays delivering the response due to the mobile wireless network. The Sync Services Response Time also excludes the time to connect to the backend datastore and transfer the data required to sync the device to the backend datastore as this is dependent on the size of the data and the network speed of the device. The Sync Services Response Time can be measured using the performance reports available in the Kony cloud sync services admin console. In the event that the data transfer time is limited due to the network bandwidth between the Amazon AWS network and the enterprise datacenter, the Customer may request Kony will work with Amazon AWS Support and the customer's enterprise datacenter network team to establish a dedicated network connection using the AWS DirectConnect service as defined at http://aws.amazon.com/directconnect.The additional network costs will be passed through from Amazon as-is to the Customer.

'Messaging ServicesResponse Time' is defined as the time taken to process a request received from the device to subscribe or unsubscribe for push notifications to the Kony cloud messaging services component of the Hosted Software, to the time it responds to the mobile device barring the time taken to transmit data over the mobile wireless network. This time cannot currently be measured through the reporting capabilities of the Kony Cloud, but customers can open a support ticket to have the Kony cloud hosting support team verify the response time if they suspect it is not performing within the defined SLA. The Kony cloud messaging services administration console will provide a performance report in a future release to display the average service response time.

'Management ServicesResponse Time' is defined as the time taken to process a request received from the device to the service endpoints provided by the Kony cloud management services component of the Hosted Software, to the time it responds to the mobile device barring the time taken communicate with an external system or transmit data over the mobile wireless network. This time cannot currently be measured through the reporting capabilities of the Kony Cloud, but customers can open a support ticket to have the Kony cloud hosting support team verify the response time if they suspect it is not performing within the defined SLA. The Kony cloud management services administration console will provide a performance report in a future release to display the average service response time.

System Availability & Response Time SLA Commitment

Program Support Services

A. Kony will use all commercially reasonable efforts to provide updates of the Programs to function with new releases of currently supported mobile device manufacturer's Operating Systems 'OS' as per the timelines below:

(i) New releases of currently supported manufacturer's OS or SDK - within 30 business days 'from General Availability (GA) release by the manufacturer to the developer community or the next GA' release of Programs, whichever is later. Customer must update new GA plugins made available by Kony to: a) take advantage of the new features or enhancements in the Programs current feature set; and b) overcome any backward compatibility issues with the newer versions (major, minor) of currently supported OS's or SDK's. New GA plug-in's may require testing to ensure the Customer mobile application is optimized on/for the new OS's and SDK. In case there are any backward compatibility issues identified by Kony on the new platform GA version, they will be communicated through release notes and necessary build scripts will be provided with the platform plug-in, where applicable.

(ii) New versions of currently supported mobile browsers or new form factors for devices using the currently supported OS and Mobile Browser - within 30 business days from GA release by the manufacturer to the developer community or next GA release of Programs, whichever is later. Customer must implement new GA plug-in's to take advantage of the new releases of currently supported Browsers or new form factors. New GA plugins may require testing to ensure the Customer mobile application is optimized on/for the new Browser. In case there are any backward compatibility issues identified by Kony on a new platform GA version, they will be communicated through release notes and necessary build scripts would be provided with the platform plug-in, where applicable.

B. Kony will use all commercially reasonable efforts to provide updates to the Program in a new GA release, to function with net new OS within 90 business days from GA release of the new OS to the developer community, subject to Kony's determination that the net new OS is commercially viable to support. Net new OS GA releases will ensure forward compatibility, in the sense that mobile applications developed on previous versions of OS are fully compatible with the new OS and not necessarily supporting the new features released with the new OS. Customer's must implement new GA plugins to overcome any backward compatibility issues with the new OS versions or take advantage of the new OS features. New GA plugins may require testing to ensure the Customer mobile application is optimized on/for the new OS. In case there are any backward compatibility issues identified by Kony with the new platform GA version, they will be communicated through release notes and necessary build scripts will be provided with the platform plug-in, where applicable. Kony reserves the right to support to a new OS's / browsers / devices at its sole discretion.

C. Kony will provide Support Services for the version of Programs licensed hereunder to Customer as of the effective date ('Current Version') for a period of time equal to twelve months from the date of the next immediate release of a new version of the Program ('New Version'). Support for the prior version, during the time period referenced above, after the release of the New Version will consist of limited support (hotfixes and patches only, no enhancement or re-releases). If Customer upgrades to New Versions of the Programs, the upgraded versions of Programs will be considered the Current Version for purposes of this Section.

D. The list of Kony supported versions of 3rd party software is listed in the Kony Studio and server installation guides and can be viewed at https://basecamp.kony.com/.

E. Subject to Kony's obligations under Section (C) above, Kony will upon request and on a time and material basis at rates currently in effect, provide services to ensure either versions of Programs remain compatible with older or new publically supported versions of 3rd party software, not supported by the Programs (as evidenced by such 3rd party's notice generally made available to the public).

F. Kony will revise the Programs documentation to reflect any corrections, enhancements or updates no later than the time of official releases of Programs to customers.

G. General releases schedule for the Programs will be published on Kony Base Camp (http://basecamp.kony.com) site for on-premise enterprise customers and also published on the standard Kony Studio Eclipse update site that enables the Customer to download and install the updates from within Kony Studio. Hot fix / defect fix releases, if any, are also published on both sites. Patches or fixes will be provided based on priority, either as a Program update or as part of the next scheduled Program release. Customers will be provided credentials to access this abovementioned Kony Base Camp site for on-premise server installation software if required.

H. Kony will post notices (new releases dates for Programs, new supported devices & OS's etc.) on Kony Base Camp for on-premise customers, along with regular announcements/ newsletters.

I. A list of supported devices, OS and browsers is published as part of the standard Kony documentation. Devices, browsers and OS versions not published on the 'supported' list may or may not operate with current version of the Programs. For non-supported or older versions of devices, browsers and OS versions, hotline support is available on a time and material basis.

Exclusions: Kony will have no obligation of any kind to provide Support Services of any kind for problems in the operation or performance of Programs to the extent caused by any of the following: (a) non-Kony supported software or hardware products or use of the Programs in conjunction therewith; (b) modifications to Programs made by any party other than Kony; (c) Customer's or its users' use of Programs other than as authorized in the License Agreement or as provided in the documentation; or (d) Customer's or its users' use of other than the version of Programs identified in C above or any error corrections or updates thereto provided by Kony (each an 'Excluded Error'). If Kony determines that it is necessary to perform Support Services for a problem in the operation or performance of Programs that is caused by an Excluded Error, then Kony will notify Customer thereof as soon as Kony is aware of such Excluded Error and Kony will have the right to invoice Customer at Kony's then-current published time and materials rates for all such Support Services performed by Kony.

Software Updates, Maintenance and Support

A. Kony releases a new major version of its software about every 12-18 months and follows a ‘Service Pack', ‘Fix Pack', and ‘Hot Fix' approach to providing software updates, maintenance and support. A ‘Hot Fix' is created in response to a specific customer support request where a product update is required to resolve the issue. The goal of a hot fix is to release a fix as quickly as possible for a specific customer. The details of hot fixes are not published publicly because they are customer specific at first. Hot Fixes are bundled together in a later Fix Pack and then published publicly for any customer to consume. Fix Packs are released about every 6 weeks, but that schedule may vary depending on how many fixes are pending and the complexity of testing, packaging and releasing the Fix Pack. In some cases, small feature additions or enhancements will be included in a Fix Pack. A ‘Service Pack' adds new functionality to a major version with the goal of complete backward compatibility. A Service Pack are released about every 3-4 months and will also include all Fix Packs since the previous Service Pack.

B. Kony strongly recommends that customers stay current with each Fix Pack and Service Pack by applying them as quickly as possible. Staying current helps customers maintain the highest level of security, stability, and performance. Each Fix Pack and Service Pack is designed to be backward compatible to minimize any disruption to customers when applying these updates. When customer specific Hot Fixes are required, it is Kony's policy to add that hotfix to the most recent Fix Pack for the Customer's current Service Pack level. For example, if a Customer is on V8, Service Pack 1, and Fix Pack 2 then their Hot Fix will be on Service Pack 1 but may be applied to a later Fix Pack such as Fix Pack 4 if that is the most recent available Fix Pack for Service Pack 1. Fix pack 4 would have updates from fix pack 1, fix pack 2, fix pack 3 and some more. Following this approach has proven to be the most effective in delivering the best results for customers.

This appendix explains a few Frequently Asked Questions (FAQs) related to various topics.

Build issue after installing Android SDK Build-tools Rev 19?

It is an Android defect with SDK build-tools Rev 19. An issue is logged with the Android support team.

If you have installed Android Rev 19, we recommend you to uninstall and install 18.x.x version of Android SDK Build-tools.

What is the difference between pre-show and onclick event of a Button?

Pre-show gets executed on the main thread of the mobile device whereas the onclick event of a button runs on another thread.

The main thread performs the following:

• Renders and lays out the forms.
• Executes all the form events except for post-show event. Post show event runs asynchronously (not on the main thread) after displaying the form to the user.
• Handles all system events such as background, foreground, idletime, pre-appinit, and post-appinit events.
• Responds to different user gestures like touches and delegates the actual execution to another thread.

What are the intricacies to be aware while writing long running activities such as network calls?

The onhide event of a form gets executed on the main thread. The onhide event of the previous form triggers after displaying the current form. If you include a long running activity like network call in the onhide event of a form, the user interface of the current form becomes un-operational during the execution of onhide.

Do not include any long running activities like network calls in the pre-show and onhide events of a form. These events of the form have no way of indicating to the user visually that some action is in progress in the background. Including network calls in these events blocks the execution of the main thread and leads to a bad user experience.

What is the best place to accommodate long running activities like network calls?

As per user interface guidelines, any application must visually indicate to the user that a long running activity like network call is in progress in the background.

We recommend the following to accommodate long running activities like network calls:

• as part of closures attached to the widgets placed on the form (like buttons, segmented UI, and so on). You can visually indicate to the user about the network calls in the closures of these widgets.
• as part of postshow for network calls that belong to the current form.

Can I call form.show of another form or the same form in the preshow event?

No. Technically, a form enters into the shown state only after executing preshow and displaying the form. Hence, invoking form.show in the preshow will lead to undefined behavior.

Can I make a network call or perform time taking activities in postshow?

Yes. The postshow event gets fired after displaying the form to the user. So, while the user sees the form, postshow gets executed in the background. While postshow is in progress, the platforms suspend any operations on the form till its execution is complete. Hence, you can make network calls in the postshow event.

During the execution of postshow, platforms can be configured for visual indication to the user for long running tasks. For example, iPhone has the properties transparencyDuringPostShow and needsProgressIndicatorDuringPostShow. Alternatively, use window.showloadingscreen API. For more information, see Kony Widget User Guide and Kony API Reference Guide.

How can I show interstitial forms (an intermediate form before the actual form appears)?

You can use the postshow event of an intermediate form to move to the desired form. You can invoke form.show in postshow of the intermediate form because, technically the intermediate form is already shown to the user.

Which is the right place to prepare a form by making some widgets visible or invisible and clear the old data based on the application needs?

preshow is the perfect place. Every form is responsible for preparing itself (in the preshow event). This way encourages the modularity and allows execution of code only when needed.

For example, lets take a banking scenario. In a banking application, when the user switches over from cards to bank, forms may end up turning off/on different widgets on different forms. If this turning on/off is done as part of single function and attached to a widget on the form, it will lead to performance issues because when a property or widget is accessed on a form for the first time, the entire lifecycle of the form is triggered.

Can I change the visibility of the widgets of the form which I am trying to show in the postshow event?

Yes. But it may lead to bad user experience. A form is shown to the user while postshow is getting executed, and if you the change the visibility of some widgets that the user has already seen, it leads to a bad user experience.

What is the value I get when I access getcurrentform API in preshow of a form?

getcurrentform API returns a handle to the form which is already shown but not the destination form. When you invoke getcurrentform API in the preshow event, it does not reflect the form that you are trying to show, as technically the form is not yet shown.

When I call form.show of a form which is currently shown, are preshow and postshow events triggered?

Yes, they are triggered. Also the form transitions in platforms like iPhone and Android are also applicable.

Are preshow and postshow events triggered when the user uses device Back button or the default Back button provided by the platform?

No. preshow and postshow events are not triggered. However, the developers can overwrite the default Back button or the device Back button behavior by attaching the a closure to it.

How can I clear the data for each form?

Currently, there is no support from the platform to clear the form's data easily. You should access each of the widgets on every form and set the data to empty or nil.

Important: Writing a single function that clears all the data of all the forms is not recommended.

When you access the widgets on the form or properties of the form for the first time, the lifecycle of the form is executed. Writing a generic function which touches all the widgets on all forms and clears the data may trigger life cycle of forms unnecessarily and can lead to performance problems.

The best way to clear a form's data is to use the form.destroy API as it clears the data along with the state of the form.

Do the callbacks of form lifecycle events receive the form on which the lifecycle is initiated as the first argument?

Yes. All the form lifecycle event callbacks receive the form on which the lifecycle is initiated as the first argument. If you need to know deterministically what is the form on which the lifecycle events are initiated, you can rely on the first parameter instead of relying on getcurrentform API.

Why is Opera Mini not a recommended browser for banking applications?

Opera Mini browser has potential security issues as there is no full end-to-end SSL between Opera Mini Browser and Enterprise Server. This is because opera Mini Server is present between the Opera Mini Browser and the Enterprise Server. Actual SSL handshake will happen between the Opera Mini Server and Enterprise Server and data is transmitted securely between Opera Mini Server and Enterprise Server only.

For more information, see http://www.opera.com/mobile/help/faq/.

Does Kony Platform support Arabic and Hebrew languages?

The following are the locale codes:

• Hebrew: iw_IL
• Arabic (Egypt): ar_EG.

Kony Platform does not support right-to-left data entry and hence these languages and locales are not supported.

If the application is already running in the background and if the user tries to launch it again from a third party application - Will the application be brought to foreground or will kill the previous instance and launch fresh?

Application will be brought to foreground, and the application will be notified with delegate method about invocation. For more information on delegate methods, refer http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/
iPhoneOSProgrammingGuide/AdvancedAppTricks/AdvancedAppTricks.html

If you register 2 applications with the same URL scheme or pattern - what is the user experience when you try to launch the application?

1) will the OS launch both the apps

2) will it provide a choice

3) registering the same URL scheme/ pattern multiple times is not possible?

• You cannot overwrite a URL Scheme if it has already been registered for an application. No compile time/ Installation time/ runtime error is thrown but the URL Scheme binding will not occur for the new application trying to overwrite the URL scheme.
• Only the first application which is registered with a particular URL Scheme is invoked from any application.

Why does the blocked UI page remains on the screen in promotional video after selecting 'Done' button and the user has to enter the url again to get back to the application?

Video will open in device native player and native player is not in our control. Hence do not use blocked UI for video widget.

How do I call an ondone() event, when the user taps 'Previous/Next' button on top of iPhone keyboard?

Currently we do not have an option to hide the Previous/Next buttons in our platform. The Done button which is beside Previous/Next button provides the option to dismiss the keypad after entering the text in the widget and not to call an event. The Done button which is in the Keypad signifies the ondone event of the textbox.

How do I retain the Data Mapping which is done through mapping editor in the application which is developed in Kony studio 3.x and imported to Kony studio 4.x?

After importing the application to Kony studio 4.x, right-click project, navigate to Utilities and click 'Upgrade Project to Current Version' option.

Is the middleware's 'convert to JSON' process applied on the response of a JSON service (as it is already in JSON format)?

Yes, the JSON conversion process is still done. Though the result is a JSON, the device is interested in part of JSON response. Hence based on the XPath's specified as service output params for the service, we parse the JSON response and build the Result object. The Result object is again run through the common JSON conversion process to send it to the device.

Whenever we select Focus skin for a segment, is it mandatory to select the Behavior property as either single select or multi select.

Yes. If the Behavior property of Appearance is default, the focus skin will not work.

How to achieve different keypad's in Thinclient advanced versions?

Select the combinations of Mode property and keyboard type as shown below to achieve the different keypads in Thinclient. These keypads are available from CGEN-GA-3.0.07, CGEN-GA-3.1.06 and CGEN-GA-3.5 plugins.

Why is the ongestureclosure not invoked when swipe gestures are applied for boxes?

This is a limitation on android platform as the touch events are not propagated to box as they are consumed by the form's scroll container.

If I am unable to connect to SAP/Siebel server what to do?

Check whether all the required jars are present under the java ext folder used by eclipse. To know the version used by eclipse, navigate to Help > About Eclipse> Installation Details > Configurations and check the -vm parameter.

For example:

-vm

C:/Program Files (x86)/Java/jdk1.6.0_27/jre/bin/client/jvm.dll

If I see an issue with loading NTLM wsdl which is not working with soapui tool-4.5 jars(used internally in com.pat.soapui plugin) and it has been working with soapui tool-4.0.1 jars (used in com.pat.soapui.preversion) what do I do?

To support both the versions (4.5 and 4.0.1) the preversion plugin has been added.

To load a wsdl using preversion plugin:

add -Dkony.soapversion=4.0 below vmargs in eclipse.ini file.

Snippet from eclipse.ini file

-vmargs

-Dkony.soapversion=4.0

-Xms40m

-Xmx384m

Restart the eclipse after adding the parameter and when wsdl is loaded the line below should be printed in the console.

'------------------Using soapui version 4 for loading wsdl-------------------'

If the plugin is not installed then below line should be printed.

---------There is no plugin registered supporting soapui version 4. Using soapui version 4.5-------

If nothing is printed on the console:

Change following option

-vm

D:/jdk1.6.0_30/bin/javaw.exe

-vm

D:/jdk1.6.0_30/bin/java.exe

How can we achieve the following using Kony:

1. Download a PDF file onto the mobile device (Given the pdf file's url).

2. Then view this PDF offline.

For ThinClient applications, use the API - window.openurl(url_having_pdf_file), then that pdf gets downloaded to the device (Android - in download section) memory and you can also open it off line. Browser should have the capability to open PDFs.

Whereas, in case of Rich Client Apps, the device should rely on third party tool (like- quick office for Android) or some FFI based (PDF reader)code that is required to be integrateds .

How do I control the exact height of a segment in a Segmented UI widget?

We do not have explicit control over the height of the widgets.

As a general principle and per our layout model, height of the widgets is always determined by the content of the widget.

When it comes to the segmented UI, you can make it as a Screen Level widget the height of the segment UI widget then is the form height excluding headers, footers.

While using iOS build automation, the connect fails and no error messages appear.

This is caused when SSH is not enabled on your Mac machine. Please configure and test the connection on Kony Studio.

SPA-related FAQs

Where do you cache SPA pages (Local Storage or browser cache)?

Application Cache is used to store the necessary resources as specified in the manifest.

When does the cache expire?

Cache expiry settings are specific to deployment.

How to clear SPA pages, cache, from the browser side?

To clear the Application Cache, depending on the device either there is an option to clear data or cache.

How often do we interact with the Kony Middleware for pages?

We interact with the Kony Middleware from SPA only when the network calls are made to the services. Other wise we do not interact with the Kony Middleware. In SPA architecture, the forms are constructed on the fly based on the logic provided . In such cases, we never interact with the Kony Middleware to fetch a page.

Where is the doc root, images and resources saved on the Kony Middleware?

SPA applications are bundled as a war file, which can be deployed on any J2EE compliant web server. All the images resources and CSS are stored with in the war file. The images are relative to the application's root.

How to update and push new or modified pages from Kony Middleware to the device?

SPA applications use HTML5 manifest file and when it is changed (touched),it indicates the browser:

Download Kony Studio For Mac Download

• to reload the application or
• that the necessary manifest files are changed.

So, if the application is modified and only app.js needs to be changed, then the manifest file can be changed to reflect this. When the application is relaunched the next time, it will recognize this change and download it. This is a feature provided by the HTML5 compliant browsers.

Please confirm that the pages get cleared after a session is expired. That means that every time a user logs in, they get a new set of pages.

The session invalidation is handled by the application / developer.

Please provide details about the life cycle of a SPA page

In SPA, the client fetches required libraries and resources at once and the application logic runs on the client side. It interacts with the server only to fetch the data and not the pages. The pages or forms are rendered using JavaScript and that session is valid until the user closes or refresh the browser.

Please also note that for SPA to work perfectly on a mobile browser below are the settings that needs to be done and verified by the user.

1. Enable JavaScript
2. Accept Cookies
3. Private browsing should be OFF

Since Kony Desktop Web channel is also based out of the SPA platform, most of the above will apply to a Desktop Web application running on the desktop browser as well.

Download Kony Studio For Mac Windows 10

-Xms40m

-Xmx384m

Restart the eclipse after adding the parameter and when wsdl is loaded the line below should be printed in the console.

'------------------Using soapui version 4 for loading wsdl-------------------'

If the plugin is not installed then below line should be printed.

---------There is no plugin registered supporting soapui version 4. Using soapui version 4.5-------

If nothing is printed on the console:

Change following option

-vm

D:/jdk1.6.0_30/bin/javaw.exe

-vm

D:/jdk1.6.0_30/bin/java.exe

How can we achieve the following using Kony:

1. Download a PDF file onto the mobile device (Given the pdf file's url).

2. Then view this PDF offline.

For ThinClient applications, use the API - window.openurl(url_having_pdf_file), then that pdf gets downloaded to the device (Android - in download section) memory and you can also open it off line. Browser should have the capability to open PDFs.

Whereas, in case of Rich Client Apps, the device should rely on third party tool (like- quick office for Android) or some FFI based (PDF reader)code that is required to be integrateds .

How do I control the exact height of a segment in a Segmented UI widget?

We do not have explicit control over the height of the widgets.

As a general principle and per our layout model, height of the widgets is always determined by the content of the widget.

When it comes to the segmented UI, you can make it as a Screen Level widget the height of the segment UI widget then is the form height excluding headers, footers.

While using iOS build automation, the connect fails and no error messages appear.

This is caused when SSH is not enabled on your Mac machine. Please configure and test the connection on Kony Studio.

SPA-related FAQs

Where do you cache SPA pages (Local Storage or browser cache)?

Application Cache is used to store the necessary resources as specified in the manifest.

When does the cache expire?

Cache expiry settings are specific to deployment.

How to clear SPA pages, cache, from the browser side?

To clear the Application Cache, depending on the device either there is an option to clear data or cache.

How often do we interact with the Kony Middleware for pages?

We interact with the Kony Middleware from SPA only when the network calls are made to the services. Other wise we do not interact with the Kony Middleware. In SPA architecture, the forms are constructed on the fly based on the logic provided . In such cases, we never interact with the Kony Middleware to fetch a page.

Where is the doc root, images and resources saved on the Kony Middleware?

SPA applications are bundled as a war file, which can be deployed on any J2EE compliant web server. All the images resources and CSS are stored with in the war file. The images are relative to the application's root.

How to update and push new or modified pages from Kony Middleware to the device?

SPA applications use HTML5 manifest file and when it is changed (touched),it indicates the browser:

Download Kony Studio For Mac Download

• to reload the application or
• that the necessary manifest files are changed.

So, if the application is modified and only app.js needs to be changed, then the manifest file can be changed to reflect this. When the application is relaunched the next time, it will recognize this change and download it. This is a feature provided by the HTML5 compliant browsers.

Please confirm that the pages get cleared after a session is expired. That means that every time a user logs in, they get a new set of pages.

The session invalidation is handled by the application / developer.

Please provide details about the life cycle of a SPA page

In SPA, the client fetches required libraries and resources at once and the application logic runs on the client side. It interacts with the server only to fetch the data and not the pages. The pages or forms are rendered using JavaScript and that session is valid until the user closes or refresh the browser.

Please also note that for SPA to work perfectly on a mobile browser below are the settings that needs to be done and verified by the user.

1. Enable JavaScript
2. Accept Cookies
3. Private browsing should be OFF

Since Kony Desktop Web channel is also based out of the SPA platform, most of the above will apply to a Desktop Web application running on the desktop browser as well.

Download Kony Studio For Mac Windows 10