I started studying kotlin and came across a lot of questions that I can't find: what is the difference between kotlin multiplatform and compose multiplatform? can they work together in the same project? what is more primary?
All I understood from the official documentation is that kotlin multiplatform is a framework for development on a variety of systems and compose multiplatform is an adaptation of compose from android
Kotlin Multiplatform is a language definition and set of tools that lets you write Kotlin and compile it to a wide range of platforms: JVM/Android, JS, iOS, Macos, Windows, Linux, etc (WASM in progress). It is agnostic about what you do with it. Also, some code can be compiled for all targets (common Kotlin), and some is platform-specific.
Compose UI is a library for writing UI's. The vast majority of effort and the only really "production ready" implementation is for Android. However, compose for Desktop running on the JVM is being used by many teams. Compose UI for web exists, although I'm not sure how much use that gets. Compose for iOS is in the works. We published an app with it recently (https://touchlab.co/droidcon-nyc-ios-app-with-compose/), but I wouldn't use it for a production project yet, but in the not-too-distant future potentially.
All of the non-android platforms use Kotlin Multiplatform to build Compose UI. It's sort of like SwiftUI uses Swift. They're related, but Swift is it's own, much more mature, thing.
Related
We are about to start greenfield development of an Android library and considering using JetPack Compose for UI elements used there.
I know that one restriction to consider is API 21+ (not really a problem).
Are there any other reasons to use or not use Jetpack Compose for library development?
Well I'm not sure if that's a definite "no" for usage (that's rather subjective), but you have to bring the dependency on the compose along with the library. This will affect the library and app size
There are set of related questions here, because I suspect I am asking the wrong question. The related questions may help someone discern what my fundamental misunderstanding is.
I have worked through:
https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html
https://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html
https://www.yoctoproject.org/docs/2.6/sdk-manual/sdk-manual.html
I'm looking for an single build environment from which I can use bitbake, and build a product for different target architectures.
This after all seems to be what the Yocto/OE holy grail is.
It seems like the most functional x86_64 environment is had from:
git clone git://git.yoctoproject.org/poky
It is more capable than the SDK's, but how do I cross-build this environment for another platform?
Is there an SDK that is as functional as this git clone'd environment? Meaning it has a working bitbake and I can cross-build bootable images for different targets?
Questions:
Why can't an SDK build an SDK? (e.g. http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/buildtools/)
Why doesn't an SDK even include bitbake? (The ext SDK does, but doesn't like to add it to the path).
Why does an extensible SDK with properly sourced env (and bitbake added to the path) seem to prefer the distro-installed build tools instead of the ones in the SDK? (when using bitmake directly instead of devtool)
Why is an SDK apparently tied to build for a particular machine or architecture, and apparently unable to cross-build for different architectures? The process for building an SDK even wishes the final architecture to be specified in advance
What I'm used to is a build-sysroot with the cross-toolchain running under some sort of pseudo/proot/chroot with my sources mounted into it.
I realise that Yocto/bitbake does this under the hood, all the recipe caching seems great, the git clone checkout seems powerful, the devtool workflow seems great, but then it all falls down when I try to standardise generation of this environment, or make it cross-compile.
(I’m expecting to source the environment file from a target directory containing some local conf files to specialise the build, and then use bitbake to make the build)
What have I missed? - thanks for reading this far ;-)
SDK is such a generic word that in the context of yocto, it can be miss interpreted and so your question is legit.
Yocto is a wonderful tool to build completely custom images and can be adjusted at all level (bootloader, kernel, applications) based on source fetched online.
The SDK you can generate with yocto is as quoted from the documentation:
The Standard SDK provides a cross-development toolchain and libraries
tailored to the contents of a specific image.
Based on my small experience with Yocto, you use meta layers to create and customize your environment. When your environment is setup, you can generate an SDK to easily cross compile your aplicative programs for your target machine.
Yocto tool is way too powerful, heavy and complicated for developers who just focus on the aplicative part of a project. The SDK on the other side is perfect for that use but you can't change anything in the toolchain with it, you can only use it. If a bug or a patch needs to be applied in runtime libs for example, you need to regenerate the SDK and give this new versions to developers.
With that short explanations:
It is more capable than the SDK's, but how do I cross-build this
environment for another platform?
You need to customize your Yocto meta layers to change from a platform to another.
Is there an SDK that is as functional as this git clone'd environment?
Meaning it has a working bitbake and I can cross-build bootable images
for different targets?
No, i don't think so
Why can't an SDK build an SDK?
Because that's not the philosophy of the SDK, sdk is a generated toolchain for a specific image to cross compile your programs, no more.
Why doesn't an SDK even include bitbake?
Bitbake is a tool to parse yocto recipe (so meta layers) and so, there is no need to have this tool in the SDK
Why is an SDK apparently tied to build for a particular machine or
architecture, and apparently unable to cross-build for different
architectures? The process for building an SDK even wishes the final
architecture to be specified in advance
I think i already gave an answer to this question but, about the second part of your question. It is possible to be a little bit agile and start both the BSP and applications in parallel. Every week, you release a new SDK with BSP new changes an the toolchain is always up-to-date for developers (This is a very idealistic vision i admit)
Reading from https://www.yoctoproject.org/docs/2.6.1/ref-manual/ref-manual.html#cross-development-toolchain
it seems that an SDK and eSDK are examples of a relocatable toolchain;
A relocatable toolchain used outside of BitBake by developers when
developing applications that will run on a targeted device.
This sentence particularly gives the game away:
You can also find more information on using the relocatable toolchain
in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual.
SO I guess the git-clone-poky checkout which builds the SDK and eSDK is:
A toolchain only used by and within BitBake when building an image for a target architecture
No doubt I am interested in:
toolchain concepts as they apply to the Yocto Project
and should:
see the "Cross-Development Toolchain Generation" section in the Yocto
Project Overview and Concepts Manual https://www.yoctoproject.org/docs/2.6.1/overview-manual/overview-manual.html#cross-development-toolchain-generation
Certainly the first image makes it clear that the SDK is for building apps, not the image. I want to build the image (which of course may contain apps).
And so I may wish to make an SDK for other app builders, and incorporate their app into my sources and do the final build for them.
It may also be that the toolchain used for building an image can be run within the SDK so as to use the toolchain of the SDK rather than the host linux distro toolchain no, you can't
I have found so many facility to use javascript, Angular, material design ui with Electron App Framework, I would like to know, is there any possibilities to use ANT UI for my desktop application? At-least some work around.
Yes
The short answer is yes. Electron provides an entire NodeJS environment and allows you to use common Node, Javascript and React toolsets.
In fact, Electron is listed as an officially supported environment on their Github page.
That being said, it's a very diverse library so there might be occurrences where a particular component is not supported or might need tweaking to be compatible with the Electron environment.
Update
The company I work for actually had to do this for a project we're working on so I can officially confirm that it works great.
I am thinking of learning Haxe, after extensive as3 experience and some javascript/nodejs but several people have stated that haxe compiles into a swf and encapsulates it to be run on "insert platform here" making it both incompatible with some native features and with significant overhead.
I am interested in knowing about ipad/iphone specifically. Does this somehow compile into a format compatible with such apple devices? I mean does it translate to x-code then compiles it or what?
I have various clients that want cross platform versions of the same application and Haxe looks like a simple, elegant solution but since my clients are from US, Apple products are a concern to me.
My scope of projects revolves around simple apps with server services and maybe some webcam/microphone action, if this helps for an answer. Cheers.
haxe compiles into a swf and encapsulates it to be run on "insert platform here" making it both incompatible with some native features and with significant overhead.
This is a big misconception. Though as with any cross-platform tech, it's a somewhat nuanced answer.
First, know that Haxe is simply a programming language that compiles to many other language (& bitcode) targets, e.g. JavaScript, C++, PHP, python, SWF, hl, neko and others.
Compiling to C++ is the typical path when building native Android and iOS apps (and Windows and Mac apps, for that matter). Also, Haxe is just the language. Usually a framework is used for building apps, and there are many choices -- OpenFL, or its predecessor Haxe NME, or heaps.io, or HaxeFlixel, or luxe, or Kha.
Each framework is unique in paradigms and workflows, but for example, last time I used OpenFL, it exports an XCode project with C++ code when building for iOS. You are then expected to open and compile the project in XCode and onto your device (or for the app store), just like any other iOS app.
While using a framework is a common way to build apps with Haxe, you can roll your own, if you like, for example:
Compile Haxe to JavaScript, using externs to leverage existing JS libs (e.g. here's a set of Pixi.js externs, or the built-in jQuery externs), and develop mobile web apps with Haxe. Note: many of the above frameworks support a Haxe -> JS workflow.
Compile Haxe to SWF, and then use the Adobe AIR SDK to package your app as a native iOS / Android app. This avoids XCode and is possible from Linux and Windows (where compiling an XCode project is not). Perhaps this flow is what those other people were talking about.
I want to be able to use Scala to code iOS programs. Any tools available for this ?
You can run JavaScript on iOS, so you could compile your Scala to JavaScript using Scala.js. This has obvious huge limitations - I wouldn't want to try to code actual native iOS UI - but might be practical for some cross-platform logic. Combining this with React Native might be interesting.
There's also Scala Native as of a couple months ago; that should probably run on iOS. It's not ready for production use, but keep an eye on it.
Well, now you can use RoboVM - a Java library for native IOS development
See also:
an SBT plugin for RoboVM https://github.com/roboscala/sbt-robovm
A blog post aboute Scala development for IOS http://ajhager.com/
Not today, but it may be close:
http://java.dzone.com/articles/oracle-gets-java-running-ios
http://www.oracle.com/technetwork/developer-tools/adf/overview/adf-mobile-096323.html
But, while Apple directly opposes the use of the JVM on iOS devices, it will make little sense to go that way (it's still early days). You will run into one obstacle after another, and won't have any guarantee that the code you write today, will run on the iOS of tomorrow.
Sit on the sideline with your Android, Ubuntu and popcorn, and let the big guys fight it out.
In the meantime.... you can write a thin front-end in PhoneGap (which works on most modern mobile devices), your services with Spray and have fun with your back-end in Scala.
I recently developed a toolchain based on IKVM and MonoTouch that allows you to develop iOS apps in Scala. I put together a demo of the toolchain here:
https://github.com/samskivert/ios-scala-demo
Currently Codename One doesn't have builtin support for Scala but it supports Kotlin reasonably well. There is a blog post here that covers the process of adapting Codename One to support other JVM languages. By doing that you can instantly get support for other platforms such as iOS, UWP, JavaScript/Web, Android & desktop mac/windows for free.
The core of Codename One which includes the VM's, API's and most of the tools is open source.