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

Sun Oct 16 15:35:09 CDT 2016

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" <proyb6 at gmail.com> 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 at 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 <hooman at mac.com> 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
>>> <https://www.enlightenment.org/about-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 at 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 <
>>> constantinnovationsinc at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>
>>>
>>>
>>
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20161016/e2757904/attachment.html>