Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -480,7 +480,7 @@ rim.nativeBrowser true/false defaults to false. Enables the native blackberry br
|The JVM that should be bundled in the Windows desktop build. Windows desktop builds only. Supported values: zulu8, zuluFx8, zulu8-32bit, zuluFx8-32bit, zulu11, zuluFx11, zulu11-32bit, zuluFx11-32bit

|windows.extensions
|Content to be embedded into the `<Extensions>` section of the Package.appxmanifest file for windows (UWP) builds.
|Historical build hint for the discontinued UWP target. It is retained here only for legacy reference and is not used by current supported build targets.

|win.vm32bit
|true/false (defaults to false). Forces windows desktop builds to use the Win32 JVM instead of the 64 bit VM making them compatible with older Windows Machines. This is off by default at the moment because of a bug in JDK 8 update 112 that might cause this to fail for some cases
Expand Down
14 changes: 5 additions & 9 deletions docs/developer-guide/Index.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ This effectively means bringing that old "Write Once Run Anywhere" (WORA) Java m
The things that make Codename One stand out from other tools in this field are:

* Write Once Run Anywhere support with no special hardware requirements and 100% code reuse (((Reuse)))
* Compiles Java/Kotlin into native code for iOS, UWP (Universal Windows Platform), Android and even JavaScript/PWA
* Compiles Java/Kotlin into native code for iOS, Android and even JavaScript/PWA
* Open Source and Free with commercial backing/support
* Easy to use with 100% portable Drag and Drop GUI builder
* Full access to underlying native OS capabilities using the native OS programming language (e.g. Objective-C) without compromising portability
Expand Down Expand Up @@ -59,7 +59,7 @@ On iOS, Codename One built and open sourced ParparVM, which is a very conservati

NOTE: Codename One translates the bytecode to C which is faster than Swift/Objective-C. The port code that invokes iOS API's is hand coded in Objective-C

For Windows 10 desktop and Mobile support, Codename One uses iKVM to target UWP (Universal Windows Platform) and has open sourced the changes to the original iKVM code.
Codename One previously offered a UWP (Universal Windows Platform) target based on iKVM. That target was discontinued in release 7.0.229 and is preserved only as historical context in older documentation and blog posts.

JavaScript build targets use TeaVM to do the translation statically. TeaVM provides support for threading using JavaScript by breaking the app down in a rather elaborate way. To support the complex UI Codename One uses the HTML5 Canvas API which allows absolute flexibility for building applications.

Expand Down Expand Up @@ -94,15 +94,11 @@ The key advantages of ParparVM over other approaches are:

- *Simple and Extensible* -- to work with ParparVM you need a basic understanding of C. This is crucial for the fast moving world of mobile development, as Apple changes things left and right we need a more agile VM.

===== Windows Phone/UWP
===== Historical Windows Ports

In the past Codename One had 2 major Windows VM port rewrites and 3 or 4 rendering pipelines within those ports (depends on how you would define a "rewrite").
Codename One experimented with multiple Windows ports over the years, including the legacy Windows Phone target and a later UWP (Universal Windows Platform) target based on iKVM.

NOTE: The old Windows Phone port was deprecated and is no longer supported, the UWP port is the only supported Windows mobile target

Codename One now targets UWP by leveraging a https://github.com/shannah/cn1-ikvm-uwp[modified version of iKVM] to build native Windows Universal Applications.

iKVM uses a bytecode to CLR translation process that effectively converts Java bytecode directly to the .net equivalent. This is paired with a port of the Codename One API's that was built for the UWP environment. The UWP port generates native Windows 10 applications that can support ARM Windows devices natively as well as desktops etc. These binaries can be uploaded directly to Microsofts online store without special processing.
NOTE: The UWP target was discontinued in release 7.0.229 and is no longer part of the supported build targets. Older references to it in historical material are retained only for archival context.

===== JavaScript Port

Expand Down
8 changes: 0 additions & 8 deletions docs/developer-guide/Maven-Creating-CN1Libs.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -223,14 +223,6 @@ If we do a file listing on the project directory, it shows the following:
----
Steves-Mac-Pro:MyFirstLibrary shannah$ find .
.
./win
./win/pom.xml
./win/src
./win/src/main
./win/src/main/csharp
./win/src/main/csharp/com
./win/src/main/csharp/com/example
./win/src/main/csharp/com/example/myfirstlib
./tests
./tests/pom.xml
./tests/javase
Expand Down
61 changes: 5 additions & 56 deletions docs/developer-guide/Push-Notifications.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ Let's take minute to go over the three callbacks in our application.

==== Registration

When your application first opens, it needs to register with the platform's central cloud messaging infrastructure. On Android this involves a call to their GCM/FCM server; on iOS, the call will be to the APNS server, on Windows (UWP) the call will be to the WNS server. And so on. That server will return a unique device ID that can be used to send push notifications to the device. This device ID will then be passed to your `registeredForPush()` method as the `deviceId` parameter so that you can save it somewhere. Typically you would send this value to your own web service so that you can use it to send notifications to the device later on. The device ID will generally not change unless you uninstall and reinstall the app, but you will receive the callback every time the app starts.
When your application first opens, it needs to register with the platform's central cloud messaging infrastructure. On Android this involves a call to their GCM/FCM server; on iOS, the call will be to the APNS server. And so on. That server will return a unique device ID that can be used to send push notifications to the device. This device ID will then be passed to your `registeredForPush()` method as the `deviceId` parameter so that you can save it somewhere. Typically you would send this value to your own web service so that you can use it to send notifications to the device later on. The device ID will generally not change unless you uninstall and reinstall the app, but you will receive the callback every time the app starts.

IMPORTANT: The `deviceId` parameter cannot be used directly when sending push messages via the Codename One push service. It needs to be prefixed with a platform identifier so the that push server knows which messaging service to route the message through. You can obtain the complete device ID, including the platform prefix, by calling `Push.getPushKey()`

Expand Down Expand Up @@ -318,7 +318,7 @@ Rich push notifications refer to push notifications that include functionality a

==== Image Attachment Support

When you attach an image to a push notification, it will appear as a large image in the push notification on the user's device if that device supports it. iOS supports image attachments in iOS 10, Android supports them in API 26. The Javascript port, and Windows (UWP) port do not currently support image attachments. If a platform that doesn't support image attachments receives a push notification with an image attachment, it will just ignore it.
When you attach an image to a push notification, it will appear as a large image in the push notification on the user's device if that device supports it. iOS supports image attachments in iOS 10, Android supports them in API 26. The Javascript port does not currently support image attachments. If a platform that doesn't support image attachments receives a push notification with an image attachment, it will just ignore it.

Push type "99" is used to send rich push notifications. It is sort of a "meta" push type, or a "container", as it can be used to send any of the other push types, but to attach additional content, such as image attachments.

Expand Down Expand Up @@ -590,53 +590,9 @@ You can read more about the certificate wizard in the https://www.codenameone.co
You can read more about the certificate wizard in the <<signing-section-top-heading,signing section>>
////

[[push-bureaucracy-uwp-section]]
==== The Push Bureaucracy - UWP (Windows 10)
==== Historical Note About UWP Push

Push on UWP requires only that you register your app in the Windows Store Dashboard. You will then be provided with credentials (Package Security Identifier (SID) and a secret key) that you can use to send push notifications to your app. To begin this process, go to the https://developer.microsoft.com/en-us/windows[Windows Dev Center] and select "Dashboard".

// HTML_ONLY_START
You can read more about the registering your app in the Windows store https://www.codenameone.com/manual/appendix-uwp.html#building-for-the-windows-store[here].
// HTML_ONLY_END
////
//PDF_ONLY
You can read more about the registering your app in the Windows store <<building-for-the-windows-store,here>>
////

Once you have registered your app in the Windows Store, and completed the corresponding setup in Codename One settings (e.g. generated a certificate), you should proceed to configure your app for push notifications.

Navigate to the App overview page for your app inside the Windows store dashboard. Under the "Services" menu (left side), select "Push notifications".

.Push notifications menu item in Windows Store dashboard
image::img/windows-store-push-notications-menu.png[Push notifications menu item in Windows Store dashboard,scaledwidth=10%]

Then, select the "WNS/MPNS" option that appears in the left menu under "Push notifications"

.WNS menu item in Windows Store dashboard
image::img/windows-store-wns-menu-item.png[WNS menu item in Windows Store dashboard,scaledwidth=10%]

This will bring you to a page with information about WNS push notifications. You'll be interested in the paragraph shown here:

.Live services link
image::img/wns-live-services-link.png[Live services link,scaledwidth=20%]

Click on the "Live Services Site" link.

You'll be prompted to log in using your Windows Store account. Then you'll be taken to a page that contains the push credentials that you can use for sending push messages to your app. You'll be interested in two values:

Package SID. (It will be of the form "ms-app://XXXXXXXXXXX...")

.WNS Package SID
image::img/wns-package-id.png[WNS Package SID,scaledwidth=20%]

Client Secret. This will be listed in a section called "Application Secrets"

.WNS Client secret
image::img/wns-client-secret.png[WNS Client secret,scaledwidth=20%]

You will use these two values for sending push notifications to your app.

Microsoft provides full instructions on setting up WNS notifications https://msdn.microsoft.com/library/windows/apps/hh465407[here] but much of this is not relevant for Codename One apps. For Codename One apps, one need only obtain Package Security ID and client secret values for the app.
The Codename One UWP target was discontinued in release 7.0.229. Older references to WNS setup, Package SID values, and client secrets are preserved only in archived material for teams maintaining legacy code outside the current supported build flow.

[[push-bureaucracy-javascript-section]]
==== The Push Bureaucracy - Javascript
Expand Down Expand Up @@ -686,13 +642,8 @@ The instructions for extracting the API key for Google are <<push-bureaucracy-an
private static final String FCM_SERVER_API_KEY = "******************-********************";
-----

The instructions for extracting the SID and Client Secret for Windows are <<push-bureaucracy-uwp-section,listed above>>.
Historical UWP push credentials (SID/client secret) were used only by the discontinued UWP target, which was removed in release 7.0.229.

[source,java]
-----
private static final String WNS_SID = "ms-app://**************************************";
private static final String WNS_CLIENT_SECRET = "*************************";
-----

When sending push to iOS devices we have two modes:
- Production
Expand Down Expand Up @@ -775,8 +726,6 @@ We can send a push message as an HTTP `POST` request to https://push.codenameone
- *production* - `true`/`false` whether to push to production or sandbox environment in iOS - `ITUNES_PRODUCTION_PUSH`
- *certPassword* - password for the push certificate in iOS push - `ITUNES_DEVELOPMENT_PUSH_CERT_PASSWORD` or `ITUNES_PRODUCTION_PUSH_CERT_PASSWORD`
- *cert* - http or https URL containing the push certificate for an iOS push - `ITUNES_DEVELOPMENT_PUSH_CERT` or `ITUNES_PRODUCTION_PUSH_CERT`
- *sid* - The package security ID (SID) for UWP apps.
- *client_secret* - The client secret for UWP apps.

We can thus send a push from Java EE using code like this:

Expand Down
1 change: 0 additions & 1 deletion docs/developer-guide/Video-Capture-Constraints.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -109,7 +109,6 @@ if (cnst.isSizeSupported()) {
| iOS | Limited | Yes | Yes | No
| Android | No* | Yes | Yes | Yes
| Simulator/JavaSE | No | No | No | No
| UWP | No* | Yes | Yes | No
| Javascript (Desktop) | Yes | Yes | Yes | No
| Javascript (Android) | Yes | Yes | Yes | No
| Javascript (iOS) | Yes | Yes | Yes | No
Expand Down
Loading
Loading