summaryrefslogtreecommitdiffstats
path: root/src/java/jogamp/android/launcher/ActivityLauncher.java
Commit message (Collapse)AuthorAgeFilesLines
* Android: Cleanup ClassLoaderUtil/LauncherUtil - Using cached parent ↵Sven Gothel2013-01-311-2/+12
| | | | | | | | | | | | | | | | | | | | | ClassLoader for SYS-Packages w/ native libs, and non cached child ClassLoader for USR-Packages Android's Dalvik VM, like a JVM, cannot load a native library from one location by multiple ClassLoader. Since we don't like to hardcode the system-packages, as it was before, i.e. "com.jogamp.common", "javax.media.opengl", we need to either copy the libs or use parenting of cached ClassLoader. The latter is chosen, since it's faster and uses less resources. - System-packages are passed through from the user 'List<String> LauncherUtil.BaseActivityLauncher::getSysPackages()' to the ActivityLauncher, which instantiates the ClassLoader. - No more hard-reference the system-packages in ClassLoaderUtil ("com.jogamp.common", "javax.media.opengl"), just use the new user provided system-packages. - The system-packages denominate a hash-key for caching, a new ClassLoader is created and mapped if it does not yet exist. - A non-chached user-packages ClassLoader is created using the cached system-packages ClassLoader as it's parent.
* Fix ActivityLauncher/MainLauncher .. and make adb-launch-main more suitableSven Gothel2013-01-191-1/+0
| | | | | | | | | | | | | | - ActivityLauncher - no finish() from onDestroy() - MainLauncher - finish activity after returning 'main()' returns - no finish() from onDestroy() - adb-launch-main: - Clear logcat - Wait until activity is stopped - Dump logcat to local logfile
* Android Completion for launching main() class via MainLauncher; Fix ↵Sven Gothel2013-01-181-3/+3
| | | | | | | | | | | | | | ActivityLauncher order of delegation/super activity callbacks. - StaticContext: - Add ViewGroup for standalone tests w/ UI - MainLauncher/LauncherUtil: - Complete launching a main() class from our activity launcher - adding main-cmdline-args - ActivityLauncher - Fix order of delegation/super activity callbacks.
* AndroidLauncher: Add 'MainLauncher'; ClassLoaderUtil adds list of direct ↵Sven Gothel2012-05-031-7/+7
| | | | | | | | | | APKs to add to classpath MainLauncher is capable of launching a traditional static main method from a activity. TODO: - parametrize the APK list (junit, ..) - pass-through the activity instance to be used w/ NEWT AndroidWindow
* StringBuffer -> StringBuilder (Local objects, no concurrency)Sven Gothel2012-04-161-1/+1
|
* ActivityLauncher/LauncherUtil: Clear properties 'onDestroy()'Sven Gothel2012-04-091-2/+7
|
* Add 'asset' URLConnection; IOUtil uses URLConnection / incr. effeciency; ↵Sven Gothel2012-03-171-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Android ClassLoaderUtil cleanup; - Add 'asset' URLConnection - Please read API doc 'PiggybackURLConnection' and 'AssetURLConnection' - Solves generic resource handling where platform locations may differ, ie ClassLoader lookup on Android in the 'assets/' subfolder. - New Android 'AssetDexClassLoader' uses 'assets/' folder for findResource(..) - aapt.signed (our APK ant task) - uses 'assets/' folder - adds the 'assetsdir' attribute allowing to copy other assets into the APK - IOUtil uses URLConnection / incr. effeciency - using URLConnection on all getResource(..) since URL is connected anyways for validation and URLConnection can be used by caller right away - String getRelativeOf(URL, String) -> URL getRelativeOf(URL, String) - preserves scheme, authority, etc - simple parentOf handling, more efficient - reusing new 'asset' protocol impl. - Android ClassLoaderUtil cleanup; - Use createClassLoader(..) impl for build-in static jogamp and user APKs, which removes code redundancy Tests: New code path, especially 'assets' are covered by new unit tests, no regressions on Linux.
* Android: New ActivityLauncher (jogamp.android-launcher.apk)Sven Gothel2012-03-141-0/+231
ActivityLauncher provides delegating Activities, allowing the user to: - daisy chain custom APK classes and native libraries to the classpath - name one custom activity which gets delegated to, the downstream activity Overview: [User:a1] -- (usr-data) --> [Launcher] -> [User:a2] + using [other packages..] [User APK] - The user provided APK [JogAmp APK] - JogAmp APKs [User:a1] - The initial user activity, which starts the [Launcher]. Providing data to [Launcher]: [User:a2], [User APK] Resides in [User APK] [User:a2] - The actual downstream 'real' activity, spoiled w/ full fledged ClassLoader having access to all packages as requested, ie. [User APK], .. Resides in [User APK] [Launcher] - The launcher activity. Gets called by [User:a1]. Creates a new ClassLoader, daisy chainging all requested APKs. Instantiates [User:a2] w/ new ClassLoader. Delegates all calls to [User:a2]. Resides in [JogAmp APK].