I need to develop a desktop app for Windows and Mac OS with Jetbrains Compose Multiplatform
I will use the Kotlin language to design the UI.
But I need guidance on following points:
Which languages will be required for the core logic / calculations / network client, etc. in the desktop app ?
Can we write the entire Microsoft desktop app in Kotlin (Compose for Desktop)
Can we use Android classes like Fragment, ViewModels, Room in Compose for Desktop ?
If we cannot use Android classes in desktop app then, where do we write the code which we write in ViewModel classes in Android ? How to structure the code and packages
What is the best architecture for Desktop app which are being built with Compose or Desktop. ?
I could not find any architecture diagram for Desktop Compose App
Can we use Jnuit and Espresso for writing UI and Instrumented tests in Compose for Desktop ?
Note:
I have gone through the official documentation of compose desktop.
I also went though the code of samples and multiple blogs, but the above queries are not answered clearly.
Hence I need your guidance
1,2 — I guess that any JVM-compatible language would be fine.
3,4 — https://github.com/JetBrains/compose-jb/discussions/1587
You should abstract from androidx ViewModel creating a pure Kotlin ViewModel delegate that can be injected into android ViewModel.
So in this case androidx ViewModel will play the role of wrapper over multiplatform implementation.
But keep in mind that there is no component's lifecycle or navigation ecosystem like in Android world. For this purpose, you can use Decompose library.
I am not an expert in Compose for Desktop, so I would prefer not to answer the last two questions. Also, I would recommend you to search for answers in the #compose-desktop channel of the Kotlin official Slack workspace(get an invite here).
Related
What is the difference between React-native and Flutter technically?
Both technologies seem to do relatively the same thing, and Flutter even admits that it takes inspiration from React: faq
This is even more obvious when they list the same features and have almost the same syntax (StatefulWidget vs Component class).
Similarly to AngularDart being a Dart implementation of Angular; is it right to assume that Flutter is a Dart implementation of React?
Architecturally, React Native (RN) and Flutter are very similar.
What Flutter calls a "Widget" is the strict equivalent to React's "Component". That's what Flutter means when it says its inspired from React.
The difference between them lies in the other aspects of the frameworks:
Interpreted Javascript VS Compiled Dart
Flutter uses Dart, a typed language that offers both "Just in time" (JIT) and "Ahead of time" (AOT) compilation (with tree-shaking included)
In development, Flutter uses JIT compilation to empower hot-reload. And for production builds, it uses AOT compilation for better performances.
React-Native uses Javascript enhanced by some syntax sugar called JSX.
JSX being a different language, it compiles to JS, then evaluated at runtime.
Bridge to native VS Complete rewrite
React native is built on the top of native.
When using a button or a text in React Native, you are manipulating the official object used for native Android/iOS apps.
We can consider React as a common language between Android/iOS to declare layouts – but fundamentally the applications are different with potential inconsistencies.
It's is not true cross-platform. But at the same time, it allows better interoperability with native elements.
Flutter is the opposite. The goal of Flutter is to use as few native elements as possible.
Flutter requests to the OS a window, and then entirely manage its content using Dart and Skia (it's c++ graphics engine).
It has a few implications:
All the UI logic had to be reimplemented by Flutter. Be it scroll, touch events, animations, ...
The application is written entirely in Dart, even deep into the lower layers. It means that whatever the platform is, it's always the same code that is executed.
Potentially anything that can run Dart code and create a window can run Flutter and apps should work with little to no change. As such, web is in progress ( Hummingbird) and basic support of desktops is available.
To some extent, we can compare Flutter to a webview/game engine, but optimized for casual applications.
Remi already has a couple good points. I have one more.
Interpreted with bridges - vs. native and no bridges
Despite what the name might imply, React Native apps are not compiled to native code. React Native apps interpret Javascript code during runtime, and component updates in a React Native app go through a bridge to the native view counterpart. This might slow things down a little bit and be a bottleneck.
On the contrary, Flutter apps (on release mode) are compiled to native code and don't require a bridge for manipulating the UI. This in turn, at least in theory, will be more performant - there's no need to do roundtrips to the native land to make simple UI changes. Not to mention that release Flutter code is natively compiled and there are no interpreters involved.
Dance monkey, dance
Now that we know that release mode Flutter apps don't have an interpreter or the need for bridges for UI manipulations, let's see what those two things actually are in the first place.
We'll do this with a highly hypothetical example app. Our React Native app has a button that makes a monkey dance on the screen. In React Native, our button and the dancing monkey components are written in Javascript and React.
Interpreters
Since Javascript is not a first class language on Android or iOS, your React Native app includes a Javascript interpreter that interprets your Javascript code in runtime. Without the interpreter, you wouldn't be able to write apps with Javascript at all - even a simple console.log('Hello World!') wouldn't work.
According to the React Native docs, in "most cases", the Javascript code will be interpreted with JavascriptCore.
Bridges
Under the hood, React Native uses the native Android Views and iOS UIViews for displaying UI components (such as dancing monkeys) on the screen. But since the UI parts of the Android and iOS SDKs don't use Javascript, you can't make the monkey dance by using Javascript alone.
This is where a bridge comes into play. On the other side of the bridge are your React Native components and logic, written in Javascript. On the opposite side, we have the host Android/iOS app that renders native views into the screen.
From now on, let's call the two sides of the bridge as the Javascript land and the native land.
So, what happens when the user clicks on our "dance, monkey, dance!" button?
The native Android/iOS view dispatches an onclick event, which goes over the bridge to the Javascript land.
Our onclick listener written in Javascript gets invoked. It is a simple call that toggles a boolean inside the component. Something along the lines of setState(() {isMonkeyDancing = true}) or similar.
React sees that something has changed. It comes up with an updated representation of UI elements that has a dancing monkey. The representation is just a tree of plain Javascript objects that describes the updated state of the UI.
The Javascript object tree gets serialized and sent over the bridge to the native land.
The host app receives the serialized object tree and deserializes it. Now it can update the native Android/iOS view to match the deserialized UI representation. Our monkey is now dancing and our user is eternally happy.
So in this example, one button click required going over the bridge two times.
Actually, it's three - just simply rendering a button initially is a call across the bridge itself.
In an app that is more than just one button and a dancing monkey, you're likely to go over the bridge a lot more. And every time you do, it requires serializing data and sending it over from one side to the another.
This is slower than just coming up with the UI representation and updating the UI with that directly. Additionally, there's a cost of interpreting Javascript in runtime compared to having the code compiled ahead of time.
The bottom line
Since Flutter is essentially a portable rendering engine, Flutter doesn't need a bridge to do an UI update. And because of that, UI updates, at least in theory, are faster. That's one reason why building apps with complex animations or things like Flare, SpriteWidget, or even games would be more lucrative with Flutter compared to React Native.
And because Flutter on release mode is AOT compiled, Flutter doesn't need an interpreter either. That's the difference between Flutter and React Native.
Flutter vs React Native: A Developer’s Perspective
React Native by Facebook and Flutter by Google – two hot cross-platform app development technologies creating a buzz. In this post, we will compare both of them in detail from a developer’s perspective.
What’s Flutter and React Native?
React Native is a project started by Facebook internally that they open-sourced in 2015. On the other side is Flutter, a project started by Google which they have been heavily promoting since I/O 2017. Both of these technologies help app developers build cross-platform apps faster by using a single programming language. React Native is already a mature tool and has a huge community, but Flutter also started seeing huge adoption rates since 2017. In this post, we will compare each of them using ten criteria:
Programming language
Technical architecture
Installation
Setup and project configuration
UI components and development API
Developer productivity
Community support
Testing support
Build & release automation support
DevOps and CI/CD support
Programming Language
The key benefit of using a cross-platform mobile app development technology is the ability to use a single programming language to develop apps for both iOS and Android.
React Native — JavaScript
Flutter — Dart
Installation
The installation method should be straightforward without having too many complicated steps so that it could be easily learned by developers that are just starting with it.
React Native - NPM
Flutter - Binary Download from Source
UI Components and Development API
React Native - Less Components
Flutter - Rich in Components
Conclusion
React Native and Flutter both have their pros and cons. Some of the industry experts have predicted that Flutter is the future of mobile app development. Considering the comparison above, it’s clear that Flutter has entered the cross-platform mobile development race very strongly. Let’s not predict the future but wait and watch!
If you learn both technology in deep. So, you will find big differences:
Programming language- Java Script and Dart
Technical architecture- Flex and Skia.
UI components and development API: Widget in flutter but views in React native.
Developer productivity: Debugging is very easy in Flutter.
Community: Big Community support in React Native.
Documentation & Toolkit: Flutter team have created simple duc for all widgets.
Testing support: Flutter providing testing libs.
DevOps and CI/CD: Flutter Providing CI/CD supports.
There are more difference between React Native and Flutter that you can read her.
I'm trying to decide which language to learn so I can program an mobile app that revolves around NFC and your location. I heard Flutter and Reactive Native are two relatively new languages that allows you to write code for both iOS and Android and there's courses for them on Udemy. However when I Google searched "NFC Flutter" there wasn't any relevant articles on how to incorporate NFC. Is it worth learning either of the two languages or should I write my app separately in Swift and Java?
You can use either React Native or Flutter and still have NFC capabilities.
For Flutter there is this plugin you could try (haven't tested it myself)
For React Native you could use this plugin which is tested and works great
At the time of writing this answer there is no full solution for NFC in flutter.
That said, you can implement NFC functionality using PlatformChannels. Or, better, encapsulate in in a plugin.
That way, you can write a code for your app in dart for both platforms, but NFC functionality will call Native Swift or Java code to handle platform specifics.
Here is one plugin that is still Work in progress, that does the exact same thing for Android only. You could, for example, fork the plugin and add iOS code and there you would have full solution.
i want to get location (use gps) at xamarin.form - that is, in cross platform.
but i can't find. only platform-dependent (at android, at ios, etc.)
if you know, please share to me !
(i found xamarin.mobile - geolocation, but it is also platform-dependent T^T)
This is going to be device specific. Probably the best approach is to create an Interface in your portable class library and then implement the interface in your Android and iOS -specific projects. The PCL will connect to the implementation through the Xamarin Forms DependencyService. Please have a look at the following link Accessing Native Features via the DependencyService
It is likely that you will be able to use the other examples on the Xamarin site to write your platform-specific code. For example here is a link to the Android LocationService
Checkout Forms Labs. It should be pretty simple to reuse it even without Xamarin.Forms (if that's the case).
This one is a quick question regarding the possibility of having the same LnF (same look) on Android and iOS, is there an API that can provide something like this? SImilar to MAUI in MoSync or IwUI in marmaladeSDK?
Basically what I would like to do is to create my UI once for both iOS and Android using monodeveloper.
Note: Before anyone downvotes anymore, please take into account that this is a real requirement for a real project. The question is not without reason, since after looking at the documentation, I can see that Xamarin does not provide such solution, but other multi-platform SDKs do provide such solution, and since the mono ecosystem is vast, perhaps there is a third party library that can provide such functionality.
Unfortunately most of your code portability will be on the backend (non UI) when leveraging Monotouch. There are far too many inconsistencies with how an Android UI vs iOS UI are implemented respectively to their OS's.
Have you checked out http://ifactr.com/overview ? It is a paid product so I haven't tried it, but it might be at least work looking into. Other than this, no there is no cross-platform UI if you go the Mono route.
Taken directly from their page:
"But we learned that even with as much code sharing that MonoCross provides, for applications with significant UI layers, the burden of creating platform-specific UIs can be overbearing. So we created the iFactr UI abstraction layer, which allows developers to code to an abstract UI interface, and then reference our iFactr concrete implementations of that interface for all the mobile platforms, both as native UI implementations and HTML5 UI implementations.
While not a silver bullet for all mobile development, it is designed and optimized for rapidly creating data-driven UIs that enterprise users tend to demand. And because it’s integrated with MonoCross, you can mix-and-match your iFactr UI screens that are shared across platforms with screens that you can code to target specific platforms using the entire set of native APIs available on each mobile OS."
The problem is Android and iOS have different UI / UX metaphors.
Take this for example: http://kintek.com.au/blog/portkit-ux-metaphor-equivalents-for-ios-6-and-android-4/
The differences are fairly significant. If you use a development wrapper then you'll have to 100% rely on their tools. We've had experience with Titanium in the past and it wasn't good at all.
I've been looking over Sproutcore, Ember and Blossom and other competitive framework efforts (e.g. Sencha) to select for a HTML5 client side application project. The state, information, and documentation from these projects is a bit fragmented and in need of clarity, so I am presenting this to the community.
My project is to be a native-like HTML5 application with desktop level complexity in need of a complete application framework, that will work well on desktops and run with good speed on mobile devices with touch awareness. The widgets should be native-like (not web-like), but customizable so to be unique to the application.
Questions/framework Requirement:
Native vs. Web style Applications. Framework should make it easy to
build native-like user experiences with the ability to make a custom
native feel (not just wholly imitating mac/win/iOS). Some of the text
surrounding Ember indicates it is really meant for web-style apps - which given no
UI layer maybe goes without saying. Frameworks like Sencha, can it easily accommodate custom widgets?
Mobile Appropreatness. Framework should be appropreate for mobile devices and have facilities for touch input and
gestures.Several notes I've seen in my research indicate that Sproutcore and
Blossom aren't very appropreate for mobile, and that Ember is better
geared towards mobile (size?). It isn't clear whether the
touch/mobile libraries are very developed in Sproutcore/Blossom and if they will be supported it the
current state going forward. (and blossom compile to native is not acceptable). On the otherhand, Frameworks like Sencha, do they have the facility to work well on desktop as well as mobile?
Framework Completeness. The framework should be a fairly complete application framework, with desktop-like OO expectations and management for automatically and efficiently syncing, managing, and serializing the data model with the server. Not sure if there is much difference between Ember and Sproutcore, how do other efforts like Sencha stack up?
Your question covers a lot of ground. I will pick some quotes and answer them directly.
My project is to be a native-like HTML5 application with desktop level
complexity in need of a complete application framework
Ember.js specifically bills itself as a "web-style" framework, not a an RIA framework. That said, you can build anything you want, but you would be trailblazing.
Sproutcore bills itself as an RIA framework. You have complete control over the DOM, so if you can do it in the browser, you can do it in Sproutcore.
Ext-Js is also a good application framework for desktops (Sencha Touch is for Mobile). If you like the way its examples look, then its a good choice. You can of course customize the dom and write your own widgets.
Blossom is basically Sproutcore with a canvas based view layer. It just went into beta, so you would definitely be trailblazing if you went with it.
So, you can basically use any of the frameworks you mentioned for the RIA part of your enterprise. I would eliminate Ember.js simply because the framework itself purposes itself for web-style (e.g. twitter) as opposed to RIA (e.g. iCloud) apps, which is not what you want.
The widgets should be native-like (not web-like), but customizable so
to be unique to the application.
All three of your remaining options can do this. If you like Senchas widgets, its a good choice. I don't know if they are native enough for you. That said, with any of the remaining frameworks you can customize the DOM to your heart's content.
Mobile Appropreatness. Framework should be appropreate for mobile devices
This is a tough one. Sencha Touch (which is separate but similar to Ext-Js) is very popular and gets the job done. It is performant too; a non-trivial app ran fine on my original Droid (which surprised me).
Sproutcore is very heavy weight. It has mobile support (i.e. for touch events) but you need to very careful about the dom you create, so as not to overwhelm the browser. I wouldn't choose Sproutcore for mobile, although you could if you are very careful.
and blossom compile to native is not acceptable
That does not seem reasonable to me. To be clear, NONE of these frameworks run natively on mobile devices; they ALL run in the browser. Blossom comes closes as the canvas API is mapped directly to the native API, giving you a truly native app. The only way you could get closer would be to use objective-c/java for iOs and Android.
So basically, at this point your left with Sencha(Ext-Js) and Blossom. Blossom is still in Beta, you would be trailblazing if you tried it. Sencha is established, has great support (Blossom support is good on irc), and a large developer base.
So Sencha is the choice, unless you really want to be cutting edge, and take a little risk.
Troy. Indeed, ember can run with another view layer framework such as jQuery Mobile which can provide a "app-like" look and feel.There is a github project: https://github.com/LuisSala/emberjs-jqm. In my view, if you need very cool animation you can use blossom.If you want to build a app, SC or ember should be OK. I'll choose ember because it 's loosely coupled.