Frametagmedia

apps

How to Export Test Apps from OpenFL on non-iOS platforms

Posted on August 30, 2020 by Developers tagged with , , , , , , , under How To

Testing apps with OpenFL is a generally a straightforward process, but to streamline this, you can follow our step-by-step guide here to test on all platforms except iOS (for which we’ve made a separate guide, here).

Development environment:

Haxe 4.1.2
Lime 7.8.0
OpenFL 8.9.7-Lpv3od
  1. Install Haxe via:

https://haxe.org/download/

Then, run the below in Terminal using the default settings:

     haxelib setup

Then install OpenFL and Lime via Terminal (default settings in setup are fine) with:

     haxelib install lime
     haxelib run lime setup
     haxelib install openfl
     haxelib run openfl setup
  1. Test OpenFL is working with:
     openfl
  1. Create a sample project/navigate to a project directory in command line:
     openfl create DisplayingABitmap
     cd DisplayingABitmap
  1. Ensure the project works normally:
     openfl test neko

Windows

Development environment:

     Windows 10 Home 2004
     Visual Studio Community 2019 16.6.4
  1. Setup Windows export/testing with the following command:
     lime setup windows
  1. After installing a C++ compiler (ideally Microsoft Visual Studio as linked in the setup) you can finish by running the following command:
     lime test windows

Android

Development environment:

     Windows 10 Home 2004
     Samsung Galaxy S10+ on Android 10
     Android 10.0 (Q) Rev. 4 SDK
     Android 21.3.6528147 NDK
     Java 14.0.1 JDK
     Android SDK Platform-Tools 30.0.3
  1. Setup Android export/testing with the following command:
     lime setup android

And provide your Android SDK location, Android NDK location, and Java JDK location (default install locations below, replace {USER_PROFILE} with user folder name):

     C:\Users\{USER_PROFILE}\AppData\Local\Android\Sdk
     C:\Users\{USER_PROFILE}\AppData\Local\Android\Sdk\ndk\21.3.6528147
     C:\Users\{USER_PROFILE}\Java\jdk-14.0.1
  1. Ensure an Android device is plugged in via USB with USB debugging enabled in Developer options, then run the following command:
     lime test android
  1. If the build fails with “Could not initialize class org.codehaus.groovy.reflection.ReflectionCache”, one solution may be to change/append the gradle version to the project.xml file with this line, then run the test command again:
     <config:android gradle-version="6.3" />

macOS

Environment:

     mac OS Catalina 10.15.5
  1. Run the following command:
     lime test macos

Linux

Environment:

     Ubuntu 18.04.4 LTS
  1. Setup Linux export/testing with the following command:
     lime setup linux
  1. Run the following command:
     lime test linux

And there you have it. You are now able to test your OpenFL apps on all non-iOS platforms.


How to Export Test Apps to iOS with OpenFL

Posted on July 30, 2020 by Developers tagged with , , , , , under How To

Creating test apps for most platforms is generally quite straightforward with OpenFL, but iOS requires a little more setup. As such, in this blog we will go through the process step-by-step, so you too can test your OpenFL-based iOS apps.

Environment:

macOS Catalina 10.15.5
iPhone 6s on iOS 13.5.1
Xcode 11.5
Haxe 4.1.2
Lime 7.8.0
OpenFL 8.9.7-Lpv3od
  1. Install Haxe via:

https://haxe.org/download/

Then, run the below in Terminal using the default settings:

      haxelib setup

Then install OpenFL and Lime via Terminal (default settings in setup are fine) with:

      haxelib install lime
      haxelib run lime setup
      haxelib install openfl
      haxelib run openfl setup
  1. Test OpenFL is working with:
      openfl
  1. Create a sample project/navigate to a project directory in Terminal:
      openfl create DisplayingABitmap
      cd DisplayingABitmap
  1. Ensure the project works normally:
      openfl test neko
  1. Open the project into Xcode:
      lime update ios -xcode
  1. Navigate to Signing & Capabilities via the project, underneath TARGETS:
  1. Click “Add (an) Account…” next to Team/in the team dropdown and login to an Apple ID:
  1. Shortly, the status will update and may include the errors below:

To fix these, simply change the Bundle Identifier to something unique (note that the same Bundle Identifier should be used per-project), then click “Try Again”.

  1. Select the testing device (assuming a physical device for this example) from the [Project name] > [Testing device] dropdown in the toolbar:
  1. Click the Run button in the left of the toolbar and unlock the device:
  1. An error will likely appear.

To fix this, on your connected device, navigate Settings>General>Device Management>Apple Development: [Apple ID] and select “Trust ‘Apple Development: [Apple ID]’”, then “Trust”. The app should be listed as “Verified” (otherwise there should be a “Verify” button):

  1. The app should now be able to launch from the homescreen and by running through Xcode (don’t uninstall the app from the device when running through Xcode, otherwise it may have to be trusted again as per 11 – it should just update automatically). However, this error may also appear in Xcode, with a blank screen on the device:

The solution here is to navigate to Project (the folder icon in the left window)>Resources>[Project name]/[Project name]-Info.plist where you can click the plus icon next to “Information Property List” and enter “NSBluetoothAlwaysUsageDescription”, then press <Enter>:

The string entered in the Value column for the Key you just added (now titled “Privacy – Bluetooth Always Usage Description”) is what will appear when the app asks for Bluetooth permissions, so enter something appropriate.

Note: It is unclear why the app requires Bluetooth permissions, so this should be investigated before a release build.

  1. Run the app via Xcode again (again, be sure not to uninstall the app from the device, or you may need to repeat 11), and the app should now work correctly.

Note, that utilising other parts of iOS that require permissions will also likely require editing the Info.plist file again, and possibly also editing Capabilities in the Signing & Capabilities page.


Generating a signing key for Android apps

Posted on February 7, 2018 by Rodney Gedda tagged with , , , , , , , under Technology

Before you publish a mobile app on the Google Play store the app package file (.apk) must be built with a key that is signed by Google. This helps prevent “fake” apps from popping up in the store.

On Linux and Mac OS X you can use the “keytool” command to generate a a keystore file. If you’re using Ubuntu Linux the keystore command should be installed by default. Here is an example of how to use the keytool command to generate a key for an Android app:

# keytool -genkey -v -keystore ftm-fishorsink.keystore -alias ftm-fishorsink-apk -keyalg RSA -keysize 2048 -validity 10000

That will generate a keystore file with 2048-bit RSA encryption. You will asked a bit about your organisation before the keys are generated. The validity in this case its 10000 days.

Now you can build your Android app to be published on Google Play.

It’s also possible to use openssl to generate a certificate signing request file that can be used for signing iOS apps. More about that in another post.