Re: [swift-users] Build Android GUI apps with Swift 3.0 via a framework/library

[Tony Constantinides via swift-users]

So according to the Swift Community I should adapt Kotlin and not Swift as
my choice for the programming language for a  cross-platform GUI framework?
Is that really going to be easier than building a GUI framework for Android
as listed on this page?
https://github.com/apple/swift/blob/master/docs/Android.md

The main technical issues I can think of when building Android Java API
Access is the following:
a) You can only call static Java methods from the NDK Main Thread in Android
b) If I go the Android NDK(C/C++) approach, it provides access to the C++
API of Android but not the Java API of Android. It bootstraps differently
in that you have access to a NativeActivity class but a lot of Java Android
is deriving from an Activity and adding your overrides. I wonder if that
possible doing that with JNI
c) You would not have access to the XML way of declaring an Android GUI but
will have to do everything in code (I have experience in this in Android).
This is not a problem just extra work
d) Since the Java API of Android bootstraps differently you would need to
add libraries to your module maps in Swift so you can bootstrap the Java VM
literally in Android so you have access to the Java Environment via Java
Native Interface.

Anyone else think of how to call Java API from Swift? I was thinking  a
bootstrap Java Android skeleton app, which receives an API via a 64 bit
encoded number. The number is converted into a string and passed into a
switch statement where the correct API call is made.
Any fresh ideas?
Sincerely yours,
Tony Constantinides







On Mon, Oct 17, 2016 at 9:34 AM, Jens Alfke  wrote:

>
> On Oct 16, 2016, at 1:35 PM, Tony Constantinides via swift-users <
> swift-users@swift.org> wrote:
>
> Kotlin does not run on iOS without some custom VM (Robot VM) which would
> kill performance.
>
>
> If you mean RoboVM, it claims to use ahead-of-time compilation of Java to
> native code, so there shouldn’t be much of a performance penalty.
> (Definitely a *size* penalty, though!) However, RoboVM appears to have
> been discontinued.
>
> —Jens
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Build Android GUI apps with Swift 3.0 via a framework/library

[Jens Alfke via swift-users]

> On Oct 16, 2016, at 1:35 PM, Tony Constantinides via swift-users 
>  wrote:
> 
> Kotlin does not run on iOS without some custom VM (Robot VM) which would kill 
> performance.

If you mean RoboVM, it claims to use ahead-of-time compilation of Java to 
native code, so there shouldn’t be much of a performance penalty. (Definitely a 
size penalty, though!) However, RoboVM appears to have been discontinued.

—Jens___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Build Android GUI apps with Swift 3.0 via a framework/library

[Tony Constantinides via swift-users]

Kotlin does not run on iOS without some custom VM (Robot VM) which would
kill performance. Kotlin  is based on Java byte code compatibility so it
really an Android only solution. JavaScript work across platforms but has
limited functionality based on its programming model. Getting a ListView to
scroll with hundreds of items in it is still almost impossible in
Javascript.  It also (ReactJS) has to call native code to get anything done
expect its bridge is going to be slower than my native JNI calls.  Sure
developers can cop out with Kotlin and JavaScript but both of those
solutions are sub-optimal.

The key is to use a programming language that is support on one platform
(IOS and MacOS) and make it work on another while retaining the ability to
make native calls. Since i can already generate Android ARM code from Swift
on Linux, we just need to ability to call Android 18K API calls to be fully
Android complaint. Since Swift support Clang modules which is basically a C
lib with a module map, I can write JNI calls to the Android Java API via
these modules in C. I would then use the Swift "import xxx" to use these
APIs.

  The key here is to bootstrap Android run time library and not require
developer to relearn 18K API calls. To avoid the Java Native Interface
 calls I could go done the custom compiler approach or code generation
approach. By instead of one co debase I would then have two. Anyone else
have any ideas otherwise I get the impression I posting to the wrong
mailing group.






On Oct 15, 2016 11:07, "Proyb P"  wrote:

> Android N and later may changes a lot, I would use Kotlin which has
> similarity to Swift syntax.
>
> Kotlin Lang
> https://www.toptal.com/software/kotlin-android-language
>
> Javascript for mobile app for best compatibility.
>
>
>
> On Fri, Oct 14, 2016 at 9:34 AM, Tony Constantinides via swift-users <
> swift-users@swift.org> wrote:
>
>> Yeah,
>> I do not disagree with you.
>>   People who have succeeded have gone down the code generation route.
>> a) This require them to build a special Swift compiler that generates
>> Android Java Code from Swift code. They generate a 95% complete Java
>> Android app and finish it in Android Studio. By doing it that way you avoid
>> all the runtime issues and the binding issues. The problem is that you have
>> to mirror the Android SDK on Swift and code Swift like Java. You would have
>> to update the compiler for every new Java Class you would need to generate
>> which is not flexible but doable.
>> b)  Other people have tried to port the entire Swift toolchain to Android
>> but that far too much work and Swift is changing too fast to make that
>> feasible. Observe the dead projects on GitHub.
>> c)  My first thought was to create a shim that routing messages from the
>> Swift app to a Java app which translated them to API calls but this has
>> bootstrapping issues and code maintenance issues.
>> d)  My second thought  is to use JNI, as it already been proven that you
>> can call C code from Swift which in turn can call Android Java code. This
>> approach require lots of bindings and a bootstrap of the Android runtime
>> and god knows how many third party libs. The java app also wants to be in
>> charge and load the JNI bindings as a so file via its LoadLibrary() call.
>> It might be easier to call Swift from Java rather than the other way round
>> if the Swift code could be built as a library. Writing JNI glue code does
>> not excite me.
>>
>>  Since I can already build Swift on Linux and ARM, I do have the ability
>> to generate an Android runnable app from Swift code. The only issue is that
>> I am using the Android NDK way of writing Android which provides access to
>> only the C++ API of Android which is far smaller API surface that the huge
>> Java API surface and its big runtime. This evolves  Swift calling an LVM
>>  module library that contains C code that call the Android NDK API which
>> bootstrap the NativeActivity class in Android (and the android runtime) and
>> from there you can access the Camera and multimedia API just not the GUI
>> widgets.
>>   This is not too soon to think about as Swift language changes are
>> supposed to be minimal until Swift 4.0. Of course Google could do the work
>> for me but I not holding my breath. You can also build Android GUI apps
>> without every referencing the Google Service API but I do notice that the
>> Google Service API is being extended because it does not require an Android
>> OS update to get new features into Android..
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 13, 2016 at 5:20 PM, Hooman Mehr  wrote:
>>
>>> I think it is too soon to tackle this issue.
>>>
>>> I think there is room for making adapters for a lightweight GUI toolkit
>>> for embedded applications. For example, a Swift adapter for EFL
>>>  (of Enlightenment) or
>>> something like that. But when we talk about Android, we are 

Re: [swift-users] Build Android GUI apps with Swift 3.0 via a framework/library

[Proyb P via swift-users]

Android N and later may changes a lot, I would use Kotlin which has
similarity to Swift syntax.

Kotlin Lang
https://www.toptal.com/software/kotlin-android-language

Javascript for mobile app for best compatibility.



On Fri, Oct 14, 2016 at 9:34 AM, Tony Constantinides via swift-users <
swift-users@swift.org> wrote:

> Yeah,
> I do not disagree with you.
>   People who have succeeded have gone down the code generation route.
> a) This require them to build a special Swift compiler that generates
> Android Java Code from Swift code. They generate a 95% complete Java
> Android app and finish it in Android Studio. By doing it that way you avoid
> all the runtime issues and the binding issues. The problem is that you have
> to mirror the Android SDK on Swift and code Swift like Java. You would have
> to update the compiler for every new Java Class you would need to generate
> which is not flexible but doable.
> b)  Other people have tried to port the entire Swift toolchain to Android
> but that far too much work and Swift is changing too fast to make that
> feasible. Observe the dead projects on GitHub.
> c)  My first thought was to create a shim that routing messages from the
> Swift app to a Java app which translated them to API calls but this has
> bootstrapping issues and code maintenance issues.
> d)  My second thought  is to use JNI, as it already been proven that you
> can call C code from Swift which in turn can call Android Java code. This
> approach require lots of bindings and a bootstrap of the Android runtime
> and god knows how many third party libs. The java app also wants to be in
> charge and load the JNI bindings as a so file via its LoadLibrary() call.
> It might be easier to call Swift from Java rather than the other way round
> if the Swift code could be built as a library. Writing JNI glue code does
> not excite me.
>
>  Since I can already build Swift on Linux and ARM, I do have the ability
> to generate an Android runnable app from Swift code. The only issue is that
> I am using the Android NDK way of writing Android which provides access to
> only the C++ API of Android which is far smaller API surface that the huge
> Java API surface and its big runtime. This evolves  Swift calling an LVM
>  module library that contains C code that call the Android NDK API which
> bootstrap the NativeActivity class in Android (and the android runtime) and
> from there you can access the Camera and multimedia API just not the GUI
> widgets.
>   This is not too soon to think about as Swift language changes are
> supposed to be minimal until Swift 4.0. Of course Google could do the work
> for me but I not holding my breath. You can also build Android GUI apps
> without every referencing the Google Service API but I do notice that the
> Google Service API is being extended because it does not require an Android
> OS update to get new features into Android..
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Oct 13, 2016 at 5:20 PM, Hooman Mehr  wrote:
>
>> I think it is too soon to tackle this issue.
>>
>> I think there is room for making adapters for a lightweight GUI toolkit
>> for embedded applications. For example, a Swift adapter for EFL
>>  (of Enlightenment) or
>> something like that. But when we talk about Android, we are usually talking
>> about a real Android app that can be a good citizen in Google ecosystem. I
>> don’t think this is feasible right now.
>>
>> Current Android GUI services is too intertwined with its proprietary
>> runtime and VM and Google is continuing to tie them harder and harder to
>> its Google services API. Unless Google starts treating non-Dalvik-based
>> languages as first class citizens in Android development world, there is no
>> point in trying to make Swift usable as a GUI development language for
>> Android. It is not going to work.
>>
>> Just my opinion.
>>
>> On Oct 13, 2016, at 2:56 PM, Tony Constantinides via swift-users <
>> swift-users@swift.org> wrote:
>>
>> Ok,
>> Can I take the fact that there no feedback yet on
>> a) The community is not interested in writing Android apps in Swift
>> or
>> b) Wrong forum despite the fact the inventor the Swift programming
>> language pointed me here,
>> or
>> c) This has been tried and failed before.
>> I sincerely interested in the Swift community thoughts and ideas. I
>> sincerely want to build this project based on the desires of the Swift
>> developers community. Let me know what you think about the proposal
>> and yes, I can present in much more detail.
>> I took the idea from this page
>> https://github.com/apple/swift/blob/master/docs/Android.md
>> Thank you
>> Sincerely yours,
>> Tony Constantinides
>>
>> On Wed, Oct 12, 2016 at 5:12 PM, Tony Constantinides <
>> constantinnovations...@gmail.com> wrote:
>>
>>> In Swift 3.0 you can build Android apps in Linux but only console apps
>>> as there is no framework to build GUI apps using JNI.
>>> What I propose is to build 

Re: [swift-users] Build Android GUI apps with Swift 3.0 via a framework/library

[Tony Constantinides via swift-users]

Yeah,
I do not disagree with you.
  People who have succeeded have gone down the code generation route.
a) This require them to build a special Swift compiler that generates
Android Java Code from Swift code. They generate a 95% complete Java
Android app and finish it in Android Studio. By doing it that way you avoid
all the runtime issues and the binding issues. The problem is that you have
to mirror the Android SDK on Swift and code Swift like Java. You would have
to update the compiler for every new Java Class you would need to generate
which is not flexible but doable.
b)  Other people have tried to port the entire Swift toolchain to Android
but that far too much work and Swift is changing too fast to make that
feasible. Observe the dead projects on GitHub.
c)  My first thought was to create a shim that routing messages from the
Swift app to a Java app which translated them to API calls but this has
bootstrapping issues and code maintenance issues.
d)  My second thought  is to use JNI, as it already been proven that you
can call C code from Swift which in turn can call Android Java code. This
approach require lots of bindings and a bootstrap of the Android runtime
and god knows how many third party libs. The java app also wants to be in
charge and load the JNI bindings as a so file via its LoadLibrary() call.
It might be easier to call Swift from Java rather than the other way round
if the Swift code could be built as a library. Writing JNI glue code does
not excite me.

 Since I can already build Swift on Linux and ARM, I do have the ability to
generate an Android runnable app from Swift code. The only issue is that I
am using the Android NDK way of writing Android which provides access to
only the C++ API of Android which is far smaller API surface that the huge
Java API surface and its big runtime. This evolves  Swift calling an LVM
 module library that contains C code that call the Android NDK API which
bootstrap the NativeActivity class in Android (and the android runtime) and
from there you can access the Camera and multimedia API just not the GUI
widgets.
  This is not too soon to think about as Swift language changes are
supposed to be minimal until Swift 4.0. Of course Google could do the work
for me but I not holding my breath. You can also build Android GUI apps
without every referencing the Google Service API but I do notice that the
Google Service API is being extended because it does not require an Android
OS update to get new features into Android..















On Thu, Oct 13, 2016 at 5:20 PM, Hooman Mehr  wrote:

> I think it is too soon to tackle this issue.
>
> I think there is room for making adapters for a lightweight GUI toolkit
> for embedded applications. For example, a Swift adapter for EFL
>  (of Enlightenment) or something
> like that. But when we talk about Android, we are usually talking about a
> real Android app that can be a good citizen in Google ecosystem. I don’t
> think this is feasible right now.
>
> Current Android GUI services is too intertwined with its proprietary
> runtime and VM and Google is continuing to tie them harder and harder to
> its Google services API. Unless Google starts treating non-Dalvik-based
> languages as first class citizens in Android development world, there is no
> point in trying to make Swift usable as a GUI development language for
> Android. It is not going to work.
>
> Just my opinion.
>
> On Oct 13, 2016, at 2:56 PM, Tony Constantinides via swift-users <
> swift-users@swift.org> wrote:
>
> Ok,
> Can I take the fact that there no feedback yet on
> a) The community is not interested in writing Android apps in Swift
> or
> b) Wrong forum despite the fact the inventor the Swift programming
> language pointed me here,
> or
> c) This has been tried and failed before.
> I sincerely interested in the Swift community thoughts and ideas. I
> sincerely want to build this project based on the desires of the Swift
> developers community. Let me know what you think about the proposal
> and yes, I can present in much more detail.
> I took the idea from this page
> https://github.com/apple/swift/blob/master/docs/Android.md
> Thank you
> Sincerely yours,
> Tony Constantinides
>
> On Wed, Oct 12, 2016 at 5:12 PM, Tony Constantinides <
> constantinnovations...@gmail.com> wrote:
>
>> In Swift 3.0 you can build Android apps in Linux but only console apps as
>> there is no framework to build GUI apps using JNI.
>> What I propose is to build an initial limited framework coded in C that
>> calls enough of the Java Android API via JNI to bootstrap the android app
>> and to create widgets and layouts.A default Androidmanifest.xml file and
>> some files needed to be generated to make a valid android app.
>>   The Android API java surface is vast, so this framework needs to be
>> build over many releases to be useful. Developing a graphical Android app
>> requires interaction with "Activities" and the 

Re: [swift-users] Build Android GUI apps with Swift 3.0 via a framework/library

[Hooman Mehr via swift-users]

I think it is too soon to tackle this issue.

I think there is room for making adapters for a lightweight GUI toolkit for 
embedded applications. For example, a Swift adapter for EFL 
 (of Enlightenment) or something like 
that. But when we talk about Android, we are usually talking about a real 
Android app that can be a good citizen in Google ecosystem. I don’t think this 
is feasible right now. 

Current Android GUI services is too intertwined with its proprietary runtime 
and VM and Google is continuing to tie them harder and harder to its Google 
services API. Unless Google starts treating non-Dalvik-based languages as first 
class citizens in Android development world, there is no point in trying to 
make Swift usable as a GUI development language for Android. It is not going to 
work.

Just my opinion.

> On Oct 13, 2016, at 2:56 PM, Tony Constantinides via swift-users 
>  wrote:
> 
> Ok,
> Can I take the fact that there no feedback yet on
> a) The community is not interested in writing Android apps in Swift
> or
> b) Wrong forum despite the fact the inventor the Swift programming language 
> pointed me here,
> or
> c) This has been tried and failed before.
> I sincerely interested in the Swift community thoughts and ideas. I sincerely 
> want to build this project based on the desires of the Swift developers 
> community. Let me know what you think about the proposal and yes, I can 
> present in much more detail.
> I took the idea from this page
> https://github.com/apple/swift/blob/master/docs/Android.md 
> 
> Thank you
> Sincerely yours,
> Tony Constantinides
> 
> On Wed, Oct 12, 2016 at 5:12 PM, Tony Constantinides 
> > 
> wrote:
> In Swift 3.0 you can build Android apps in Linux but only console apps as 
> there is no framework to build GUI apps using JNI.
> What I propose is to build an initial limited framework coded in C that calls 
> enough of the Java Android API via JNI to bootstrap the android app and to 
> create widgets and layouts.A default Androidmanifest.xml file and some files 
> needed to be generated to make a valid android app.
>   The Android API java surface is vast, so this framework needs to be build 
> over many releases to be useful. Developing a graphical Android app requires 
> interaction with "Activities" and the package manager and some widgets like 
> Button and some layouts like "RelativeLayout" and "LinearLayout".
>  The result will be the ability to develop GUI Android apps on Linux using 
> Swift 3.0
> Further support for additional APIs will be provided once the basics are 
> solid..
> Who am I: Senior Android mobile developer with more than six years experience 
> on Android.
> Am I able to build Swift 3.0 on Linux: Yes
> Any help, suggestions, or ideas are most welcome
> Warms regards,
> Tony Constantinides
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Build Android GUI apps with Swift 3.0 via a framework/library

[Tony Constantinides via swift-users]

Ok,
Can I take the fact that there no feedback yet on
a) The community is not interested in writing Android apps in Swift
or
b) Wrong forum despite the fact the inventor the Swift programming language
pointed me here,
or
c) This has been tried and failed before.
I sincerely interested in the Swift community thoughts and ideas. I
sincerely want to build this project based on the desires of the Swift
developers community. Let me know what you think about the proposal
and yes, I can present in much more detail.
I took the idea from this page
https://github.com/apple/swift/blob/master/docs/Android.md
Thank you
Sincerely yours,
Tony Constantinides

On Wed, Oct 12, 2016 at 5:12 PM, Tony Constantinides <
constantinnovations...@gmail.com> wrote:

> In Swift 3.0 you can build Android apps in Linux but only console apps as
> there is no framework to build GUI apps using JNI.
> What I propose is to build an initial limited framework coded in C that
> calls enough of the Java Android API via JNI to bootstrap the android app
> and to create widgets and layouts.A default Androidmanifest.xml file and
> some files needed to be generated to make a valid android app.
>   The Android API java surface is vast, so this framework needs to be
> build over many releases to be useful. Developing a graphical Android app
> requires interaction with "Activities" and the package manager and some
> widgets like Button and some layouts like "RelativeLayout" and
> "LinearLayout".
>  The result will be the ability to develop GUI Android apps on Linux using
> Swift 3.0
> Further support for additional APIs will be provided once the basics are
> solid..
> Who am I: Senior Android mobile developer with more than six years
> experience on Android.
> Am I able to build Swift 3.0 on Linux: Yes
> Any help, suggestions, or ideas are most welcome
> Warms regards,
> Tony Constantinides
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users