<div dir="ltr"><p dir="ltr">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.</p><p>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.</p><p> 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.</p><p><br></p><p><br></p><p dir="ltr"><br></p><p><br></p>
<div class="gmail_extra"><br><div class="gmail_quote">On Oct 15, 2016 11:07, "Proyb P" <<a href="mailto:proyb6@gmail.com" target="_blank">proyb6@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Android N and later may changes a lot, I would use Kotlin which has similarity to Swift syntax.</div><div><br></div><div>Kotlin Lang</div><div><a href="https://www.toptal.com/software/kotlin-android-language" target="_blank">https://www.toptal.com/softwar<wbr>e/kotlin-android-language</a><br></div><div><br></div><div>Javascript for mobile app for best compatibility.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 14, 2016 at 9:34 AM, Tony Constantinides via swift-users <span dir="ltr"><<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Yeah, </div><div>I do not disagree with you.</div><div> People who have succeeded have gone down the code generation route.</div><div>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.</div><div>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.</div><div>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.</div><div><div>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.</div><div><br></div><div> 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.</div><div> 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..</div><div> </div><div><br></div><div> </div></div><div> </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="m_5469687862851257577m_-6342204857032130312m_3279262500799652655HOEnZb"><div class="m_5469687862851257577m_-6342204857032130312m_3279262500799652655h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 13, 2016 at 5:20 PM, Hooman Mehr <span dir="ltr"><<a href="mailto:hooman@mac.com" target="_blank">hooman@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I think it is too soon to tackle this issue.<div><br></div><div>I think there is room for making adapters for a lightweight GUI toolkit for embedded applications. For example, a Swift adapter for <a href="https://www.enlightenment.org/about-efl" target="_blank">EFL</a> (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. </div><div><br></div><div>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.</div><div><br></div><div>Just my opinion.</div><div><br><div><blockquote type="cite"><div><div class="m_5469687862851257577m_-6342204857032130312m_3279262500799652655m_2271974245254762303h5"><div>On Oct 13, 2016, at 2:56 PM, Tony Constantinides via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>> wrote:</div><br class="m_5469687862851257577m_-6342204857032130312m_3279262500799652655m_2271974245254762303m_-1026354346181404520Apple-interchange-newline"></div></div><div><div><div class="m_5469687862851257577m_-6342204857032130312m_3279262500799652655m_2271974245254762303h5"><div dir="ltr"><div>Ok,</div><div>Can I take the fact that there no feedback yet on </div><div>a) The community is not interested in writing Android apps in Swift</div><div>or</div><div>b) Wrong forum despite the fact the inventor the Swift programming language pointed me here,</div><div>or</div><div>c) This has been tried and failed before.</div><div>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.</div><div>I took the idea from this page</div><div><a href="https://github.com/apple/swift/blob/master/docs/Android.md" target="_blank">https://github.com/apple/swift<wbr>/blob/master/docs/Android.md</a></div><div>Thank you</div><div>Sincerely yours,</div><div>Tony Constantinides<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 5:12 PM, Tony Constantinides <span dir="ltr"><<a href="mailto:constantinnovationsinc@gmail.com" target="_blank">constantinnovationsinc@gmail.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.8px">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.</div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"> 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".</div><div style="font-size:12.8px"> The result will be the ability to develop GUI Android apps on Linux using Swift 3.0</div><div style="font-size:12.8px">Further support for additional APIs will be provided once the basics are solid..</div><div style="font-size:12.8px">Who am I: Senior Android mobile developer with more than six years experience on Android.</div><div style="font-size:12.8px">Am I able to build Swift 3.0 on Linux: Yes</div><div style="font-size:12.8px">Any help, suggestions, or ideas are most welcome</div><div style="font-size:12.8px">Warms regards,</div><div style="font-size:12.8px">Tony Constantinides</div></div>
</blockquote></div><br></div></div></div>
______________________________<wbr>_________________<br>swift-users mailing list<br><a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-users" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-users</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div>
</div>