The fact that Flutter heavily uses the word widget makes it difficult to find documentation on this topic.
On Android (I believe this isn't possible on iOS), we can add widgets on our home dashboard, allowing us to see app-related information or to trigger one-click actions without needing to open the app in question.
Is it possible to build such "widgets" in Dart & Flutter? Or should I do that in java and somehow plug it with my flutter app?
Can you share an example of a resource containing one?
EDIT: I have no android development experience, but it sounds like using a drawable canvas might do the trick.
I could find some canvas flutter code, but I can't connect the dots yet.
EDIT 2: From this Github issue, it looks like writing android home widgets in flutter is a no go since Flutter has its own rendering engine. I'm keen on learning kotlin to get this done, but if someone knew of nice tutorials to help me with that, that would be immensely helpful.
As the OP mentioned in an edit, this isn't currently possible because Flutter uses a custom rendering engine.
Widgets are quite limited in what they can render; the documentation explains that only certain layouts may be used. You could theoretically use Flutter's software renderer to render to an image in a seperate instance from the main one and display that, but that would be very technical, likely not very performant, and not straightforward at all!
Here is a quite detailed tutorial for widgets that guides you through creating a few examples although in Java. The same logic applies with just a few syntactical changes for Kotlin as the classes are pretty much interchangeable. However, realistically, most of the work is in the layout with some wiring in android; if you're already familiar with Android & Java, keep in mind that Kotlin does add a bit to your app size (The Kotlin runtime adds about 7,000 methods and ~1MB to your debug APK from the kotlin on android FAQ) and since most of your logic should be in flutter you probably won't have all that much Kotlin/Java code if this is all you're using it for (although if you're new to both Java & Kotlin, Kotlin is arguably more friendly in some ways).
Also, to be able to communicate between your flutter app and the java/kotlin backend, you'll need to use platform channels as described in the flutter documentation.
Related
I'm fairly new to Flutter but have found that it fits most of my design needs for iOS and Android. But, I've been unable to find a way to dynamically change the app icon.
In Swift, you were able to change the app icon from inside the actual app allowing for some pretty neat customization. A Medium article discussed this back when it first came out for iOS 10.3.
Does anybody know of any way to do this in Flutter, or will I need to make a custom package to do this?
https://medium.com/flutter-community/programatically-change-ios-app-icon-in-flutter-c9e84bc541a2
Maybe this would help. Here's a plugin too.
https://pub.dev/packages/flutter_dynamic_icon
I don't believe this is currently supported, and probably won't be by the flutter team although someone could theoretically write a plugin to do it. However, most of the configuration needs to be done natively anyways, so I don't know how much value the plugin would provide other than doing the call to setAlternateIconName.
What you should do is write the code directly in iOS as you would for a native iOS app, but expose a MethodChannel to the dart side which would allow you to control it from flutter.
Are there any advancements in this area? I want to be able to write purely functional code on Android in Haskell or similar languages. I've tried some examples with Scala but it seems to be a pain to get started. Are there any other functional JVM languages which I can use to write Android applications?
Edit: functional languages that write native android applications. My mistake about the JVM.
I doubt that you can find anything mature for writing Haskell-like code for Android. You do need to implement Java abstractions which are required by Android API (implement activity, etc.).
But if you really want to write for Android in a purely functional style you can try to implement your business logic in a pure functional language that compiles to JVM and call it from your Java classes. That approach would be much simpler than trying to implement it entirely in pure functional style.
As your language choice, you can try
Frege, it even has a library for android - froid
Eta lang, it is very new and probably nobody has tried to use it for Android yet
I you want a painless solution in terms of Gradle builds etc., you have only two options: Java and Kotlin, of which of course you should choose Kotlin ;)
Kotlin has most of the things you need to write in functional style:
functions as first class citizen
higher-order functions
immutable collections
var and val like in Scala
if-else as a statement
elements of pattern matching (where statement)
tail recursion
and more...
If you also include funKTionale and kotlinx.collections.immutable, you'll have all the functional goodies like: Option, Try, currying, memoization, persistent data structures and so on...
To start with Kotlin just install the latest Android Studio 3 Preview, which already has built-in Kotlin support.
BTW, don't be so polarized into "pure" functional ;) After all, being 100% "pure" means no side-effects, which means your app can't interact with the user ;)
Hope this helps :)
I've never tried it personally, but you can do F# programming using Xamarin.Android (and, I believe, with Xamarin Forms too). You can see the guide here. (It also includes sample code).
As some background, F# is the .NET Framework's functional language. It is derived from ML; in fact, many ML scripts can be compiled almost "directly" as F# (with the caveat that you may have to do some renaming because F# has some additional keywords that ML doesn't have in order to support several .NET-specific extensions).
Xamarin allows for native development for Android, iOS, and Windows phone. Xamarin Forms allows for a single code-base for all three platforms (it's a competitor to Ionic).
One more quick point: Android does not use the JVM, even if you're writing apps in Java. (In fact, Android does not even support all Java 8 features yet). Through Android 4.4 it used Dalvik; after that, it started using Android Runtime.
You could also try using a JVM language like Scala to create a JAR file and create a bindings library for it.
Please also note that you'll end up using at least somewhat of a mixed paradigm - for example, things like Activities are objects, and the XML files used to define an Android screen is, for all practical purposes, declarative. Edit: This last point is slightly debatable - see the comments.
One final possibility: I haven't checked this out too closely, but try also this link for a site claiming you can do Scala in Android.
Between Pure functional and Java, there is a way which is IMO Pragmatic functional. For instance Redux achieves that in the React arena.
My goal is to write an app (Activity) having an immutable state that advanced as a result of interactions is functional.
In the browser you can see that done with elm (Haskel like language which is also web platform)
Since we want an Android app, I opened the Android Studio used the wizard to create and app with Navigaton Drawer Action bar (with Drawer, FloatingActionBar),
Then converted it to use Elm concepts of immutable model functional approach into a working POC based on a small ElmBase class and idioms.
The code is written in Kotlin (JetBrains tool of choice for the JVM).
You can find the app at my GitHub https://github.com/saffih/ElmDroid The sweet spot of that approach is that it leverages Kotlin being strongly typed and the editor does code completions very well,
making lot's of the code completed for me in a way I have never seen before - amazing experience (But it require using idioms like the sealed class and when properly).
Does anyone have experience with NativeScript and can compare it to developing native apps, especially for Android?
I have read all these articles:
FIRST THOUGHTS ON NATIVESCRIPT
SECOND THOUGHTS ON NATIVESCRIPT
Introduction to Native Script – Is It Worth Your Time?
My Experience Developing with Telerik NativeScript
I know especially three of them may be outdated. But I want to ask all of you developers:
How is your experience with NativeScript?
Are there any Android-Components you cannot use? Which are these ones?
Is styling really so limited?
Do apps really look so different at runtime as in the mockup as in the pictures of the first article referenced above?
Does loading of native Android objects into JavaScript Code always work correctly?
Does NativeScript generate Java-Code for Android-Platform out of the NativeScript code I write?
Is it possible to modifiy this code if I want to use some native-only features? What if I want to make UI changes then? Do I have to regenerate the code and do I miss my native extensions then?
Very glad to see that you are evaluating NativeScript to eventually use it in present and future projects.
I'll try to condense answers to a few of the questions into one, as they really are mostly related.
Skipped.*
That depends on what has already been exposed through a custom view/plugin or module. The core-modules that every NativeScript app comes with contains the most basic of wrappers for both Android and iOS under a common API. There are plugins (nativescript npm modules) that provide additional wrappers on native android views (nativescript-telerik-ui for one, nativescript-carousel), most of which are created by the NS community.
As RexSplode mentioned before me - it's mostly the platform that imposes certain limitations. NS uses CSS to declare style, but you can also access the native components and manage their style and appearance programatically if what you need isn't readily available out of the box.
First I'd like to note that the first 3 articles you've linked are over a year old now, and trust me, NativeScript has evolved a lot since then. With all the available components (remember the npm modules I mentioned earlier?) there's a good chance that you will get a close to 1:1 similarity to a well-styled native Android mockup.
At build time metadata is generated for the Android/Java public API used in the project. When the JavaScript Engine (V8) fires up, that metadata is loaded into memory, prototype chains are constructed, and callbacks are attached, so that when you call new android.widget.Button(); in your JavaScript code, the proper virtual machine instructions will be called, and a native button will be created. Static methods are accessed similarly, check out the official docs to get a better understanding of how it all works.https://docs.nativescript.org/runtimes/android/advanced-topics/execution-flow
and 7., and a cont. of 2. Java code, or rather compiled Java code is generated whenever you wish to extend a native Android class that isn't available already in a module or in the native Framework. Extending classes is very similar to how you would do it in Java - you extend a class, and create new implementations of interfaces. That means that you won't have to open Android Studio to create a new class, build it into a native plugin and then add it to your project, since you can do it all in your NativeScript code using JavaScript/TypeScript. https://docs.nativescript.org/runtimes/android/generator/extend-class-interface
Disclaimer: I am on the NativeScript Engineering team
I investigated the Native Script a little and my colleague at work writes an app with it, so I can offer you a bit of information that I have.
1. skipped
There are limited amount of components you can use with native script out of the box. However, if you have a native-java developer who can write a wrapper for you - you can use everything.
It is limited to the platform you are using. Android itself has a lot of style limitations which cannot be easily overwhelmed.
don't know
It works a little different. Your JS object, or rather widgets are translated to java code. So with the items from the box - yes, they are okey. If you write a wrapper for your custom component, then all is up to you.
Yes it does.
No, the code is generated, how are you going to modify it? Changes will be undone on the next build. However, you can write a native module for your application and use any features you want. It is like defining an interface, which you can use in JS code afterwards.
I'm contemplating on using React Native for a new web app. Is it possible to ship both iOS and Android apps using it?
I know that it's on the roadmap, but it's unclear to me whether it's going to be a separate open-source project (e.g., React Android vs React Native), or just one (e.g., React Native).
TLDR: Most likely you can. But it depends on your use cases.
You can aim for about 80~99+% code reuse (depending on how much Android/iOS native views/modules you use eg. Do you have custom graphics code or low-level TCP networking code; Those can only be done in native code; And expose as API to your JS code. The amount of the platform-specific JS code is actually minimal. Plus you can also use platform check like if (Platform.OS === 'android'){} to solve that) of code reuse, which is pretty nice. Dropbox and other companies have done similar projects: using c++ to build a 'shared' component between iOS and Android project, while implementing most of the UI code in native iOS(Objective-c or swift) and Android(java). But now you are doing C++ with Java and Objective-C or Swift, more language to master, more complexity and more brain juice went down the drain. And it probably took some super tough gymnastic move to make different native code work in both iOS and Android, plus debugging...
React Native just makes it a lot easier to write almost everything in JavaScript. But there is a catch, only about 80% of the JS code could be shared. In the foreseeable future, you still need to write 'platform-specific' JS code for Android and iOS versions.
That's why FB said they aim for 'Learn once, code anywhere' instead of 'run' everywhere.
But it's still very nice other than code reuse(80+% code reuse is still a big improvement comparing to maintaining 2 entirely different versions: Android and iOS ya?)
Cmd +R to refresh the app is a GREAT boost for development speed. Waiting for a big project to compile just makes you felt you were dying inside.
Declarative UI you get for free, because of using React. This is another great plus! As you don't need to 'dig' into your specific UI code that often anymore. Data changed? Just 'flush' it and UI just update accordingly. No brain juice wasted.
I just ported my not so complicated Android React Native App to iOS. And it took me 3 days. The request for and iOS version for the App came as a rather abrupt and unplanned move. So could definitely be even faster had I built the Android with a plan for iOS too. Huge win:)
Another great benefit is able to do hot code push without going through the hellish 1 week app store review process. So no more, "YAY, our app is approved. Let's release. Oh Shiiit. Critical bug and our app keeps crashing(that's gonna keep happening for at least a week before your fix is live). And you have to beg Apple to speed up the process". This is possible because the major part of the code base would be written in JS and with tools like AppHub or CodePush, you could almost instantly deploy code to your users. This is conditionally allowed by Apple.
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code, and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
Lastly, as an open-source project, project longevity tends to be a concern. Not an issue for React Native. Internally used by(FB Ads Manager) and backed by FB(a dozen FB Engineers?) by Facebook, with close to 500 contributors and 25k Stars, React Native is full of life. Seeing is believing :) (https://github.com/facebook/react-native)
EDIT 1
I realized that I am apparently a bit biased and only talked about the good stuff about React Native. So do checkout https://productpains.com/product/react-native/ and Github issues to have a full picture. It's definitely not silver bullet. That being said, it satisfies most of my use case and I couldn't see me use native iOS or Android anytime soon.
EDIT 2
The Facebook F8 conference app released by Facebook (duh..) is 100% open source and they have a really nice tutorial to show you how you could have both iOS and Android native experience(90% as good as native ?), and at the same time, achieved 85% code re-use. check it out --> https://makeitopen.com
EDIT 3
You may also want to checkout Flutter and its pros & cons :)
It doesn't make sense to have a single codebase if you want a truly native experience. At the moment we have things like NavigatorIOS in React Native which provides an iOS-style UI for navigating between app screens, but if we were to just start using that on Android it wouldn't feel like a true Android app.
Therefore I'd expect to see a NavigatorAndroid component or similar when the time comes, and the same for various other components that behave differently between the platforms.
One benefit that you would get is that any application logic - maybe a store, or your backend interactions - could be written in a JavaScript file and then included by both iOS and Android.
So while you won't get that write-once run-everywhere developer experience from React Native I would expect to see a solution that gives first-class UI on both platforms while encouraging as much reuse as possible. I personally also hope to see strong build tools to help develop and ship on multiple platforms.
React Native for Android has just been released, Android folder will be creating along side with iOS folder upon creating a new project.
Just another tip as NavigatorIOS was mentioned. Facebook are not really maintaining the code for NavigatorIOS. Instead they are focusing on Navigator.
Yes. We're running it in production with about 5m registered users.
Some things are a little behind iOS but catching up quickly. It's a good wagon to be on.
React Native is designed so that you can deploy to both iOS and Android. There is a caveat, of course.
React Native has supported iOS for much longer, coming to Android only recently. So, there are some differences in terms of what is supported on each platform.
For example, if you place borders on Text, they will show up on iOS, but not on Android. In order to overcome this, you need to place a View around the Text, and apply a border to that. Luckily, React Native makes it easy to integrate separate stylesheets for each platform (or even platform-specific styling on a single stylesheet).
Support for Android is continuously evolving, so it will only be a matter of time before React Native for Android is on par with iOS. Nevertheless, this shouldn't deter you. In my experience, it's a great way to quickly develop for both platforms, and it does save some headaches.
you don't need to maintenance separate code base for android & ios. Actually you can use same code base for build android & ios. I recommend to read the react-native documentation(according to react-native version you are using) before using any inbuilt component in your code.
Eg:- TextInput component onKeyPress function supports for ios only.
if ur are using external lib check these lib support for both ios and android.
Anyway you have to configure external lib separately(install) both android and ios.
hope this will helpful.
I created an Android app. While creating one specific app was an interesting challenge, I'm now looking into creating a group of similar apps.
I'd like to create a group of similar Android apps and then move on to creating the same on tablets and iOS... (anything mobile).
I've considered doing so with a product called PhoneGap or doing a web based mobile app. Both of these options seem less than ideal. Doing the Android app I've been frustrated by Java's lack of control and low level constructs. Moving to something like a web based app seems like the exact wrong direction.
C++ is my language of choice. It has the ability to work at a low level, is highly portable across platforms, and has significant support for generic coding which would be useful for generating a group of similar apps. However, the Android documentation suggests to not use C++ unless your goal is porting existing code or dealing with computationally heavy tasks.
I'm leaning towards using C++ anyway, but are there other options I've not considered?
Thanks
You could in theory write your logic in C++ and then have UI layers on top that make use of it. If you are really comfortable with C++ that might be the way to go.
Almost any other parts (networking, UI, animation, etc) are better off being done in the native language of the platform. Use of cross platform solutions always limits you in some way, and usually leads to an application that is not as good as it could be for any platform.
Well, Google's recommendation to not use C++ is based on the following, I believe. C++ is low level, so you can get extra performance out of it if you know what you are doing. Google makes the reasonable assumption that many programmers do not. It is easier for an inexperienced programmer to do harm in C++ then to get a performance boost.
But, if you know what you are doing, it can help you. UI elements on both iOS and Android are implemented in their main language (obj-c, and Java respectively) so there is not a great way around that, but you can write core logic and other functions in C++ and it will be portable between them (iOS can use C++ directly and Android can use it via the Native Development Kit).
There are a few other options available. The one I ended up using is Appcelerator Titanium but please stay away from it. If your project gets complicated or large at all you will hate yourself for choosing it, as I did. Another interesting one that uses C++ instead of Javascript is Marmalade. I haven't used it though, so I can't comment on it.
A non-free solution that I hear good things about is Xamarin, who have ported both environments to C# and a .NET using Mono. However, you still have to write two versions of your code for the UI as far as I can tell.