I've seen the developer keynote of Google I/O 2018, and I've read the jetpack homepage on Android developer website, but I cannot make sense of what it actually is. To me it seems like just a new name for a bunch of APIs we already use. Is there going to be something that the IDE does for us or something that's helpful while coding? All the components in Jetpack point to their original Android documentation, and don't actually showcase any difference than before. Can someone explain in simple terms what Jetpack actually does for me as a developer, apart from clubbing documentation on a web page?
On its official site, it says:
Android Jetpack is a set of libraries, tools and architectural guidance to help make it quick and easy to build great Android apps. It provides common infrastructure code so you can focus on what makes your app unique
Technically, it is the support library, android-ktx and the Android Architecture Components re-branded as a single modular "entity".
This is why all non-Android extension libraries like support, etc. are re-packaged to androidx.**.
Quote from Alan Viverette (from Android Framework Team):
Jetpack is a larger-scoped effort to improve developer experience, but AndroidX forms the technical foundation. From a technical perspective, it's still the same libraries you'd have seen under Support Library and Architecture Components.
As best practices change, you may also see libraries in the androidx.* package that are not included in Jetpack.
See https://developer.android.com/topic/libraries/support-library/refactor for more info.
Basically it is just set of useful things combined and sorted under 4 categories
Foundation
Architecture
Behavior
UI
Some of the core things like AppCompat library, Architecture components, Fragments, Animation and transitions and many more were added now in relative categories and these 5 things were newly added.
Android Ktx
The purpose of Android KTX is to make Android development with Kotlin more
concise, pleasant, and idiomatic by leveraging Kotlin language features such
as extension functions/properties, lambdas, named parameters, and parameter
default values
Navigation
The Navigation Architecture Component simplifies the implementation of
navigation in an Android app.This is related to implementing a clear flow in
your app. Here in this video you can find a very nice explanation about
this topic.
Paging
The Paging Library makes it easier for you to load data gradually and
gracefully within your app's RecyclerView. Here is the I/O talk from Yigit
Boyar, It's very well explained by him.
Slices
Slices are UI templates that can display rich, dynamic, and interactive content
from your app from within the Google Search app and later in other places like
the Google Assistant. Slices can help users perform tasks faster by enabling
engagement outside of the full screen app experience. You can build Slices as
enhancements to App Actions. Learn more from this talk
WorkManager [ I personally recommend you to check this thing out ]
You can gracefully schedule tasks with WorkManager.The WorkManager API makes it
easy to specify deferrable, asynchronous tasks and when they should run. These
APIs let you create a task and hand it off to WorkManager to run immediately or
at an appropriate time. This Video explains it in depth.
I have created a playlist Here. It consists all best videos related to
Jetpack, Hope this helps.
Android Jetpack is a collection of Android software components which helps us in building great Android apps.
These software components help in:
Following the best practices and writing the boilerplate code.
Making complex things very simple.
Earlier there were many challenges which are as follows:
Managing activity lifecycles.
Surviving configuration changes.
Preventing memory leaks.
All these major problems have been solved by the Android Jetpack's software components.
So, the solution for all the problems is Andriod Jetpack.
Another most important thing about the Jetpack is that it gets updated more frequently than the Android platform so that we always get the latest version.
Jetpack comprises the androidx.* package libraries, unbundled from the platform APIs. This means that it offers backward compatibility.
Android Jetpack Components
Android Jetpack components are a collection of libraries that are individually adoptable and built to work together while taking advantage of Kotlin language features that make us more productive.
These software components have been arranged in 4 categories which are as follows:
Foundation Components
Architecture Components
Behavior Components
UI Components
Let's see one by one.
Foundation Components
The foundation components provide the following:
Backward compatibility
Testing
Kotlin language support.
All the foundation components are as follows:
App Compat
Android KTX
Multidex
Test
Architecture Components
The architecture components help us in building:
Robust Apps
Testable Apps
Maintainable Apps
All the architecture components are as follows:
Data Binding
Lifecycles
LiveData
Navigation
Paging
Room
ViewModel
WorkManager
Behavior Components
The behavior components help in the integration with standard Android services like
Notifications
Permissions
Sharing
Assistant
All the behavior components are as follows:
Download Manager
Media & playback
Notifications
Permissions
Preferences
Sharing
Slices
UI Components
The UI components provide widgets and helpers to make your app not only easy, but delightful to use.
All the UI components are as follows:
Animation and transitions
Auto
Emoji
Fragment
Layout
Palette
TV
Wear
Reference article
From the blog:
Android Jetpack is the next generation of Android components, bringing together the benefits of the Support Library -- backwards compatibility and immediate updates -- to a larger set of components, making it quick and easy to build robust, high quality apps. Android Jetpack manages activities like background tasks, navigation, and lifecycle management, so you can eliminate boilerplate code and focus on what makes your app great. Android Jetpack is designed to work well with Kotlin, saving you even more code with Android KTX. The new Android Jetpack components released today include WorkManager, Paging, Navigation, and Slices.
From official doc:
Android Jetpack is a set of libraries, developer tools and architectural guidance to help make it quick and easy to build great Android apps. It provides common infrastructure code so you can focus on what makes your app unique.
As we all are quoting the official site and it says,
Android Jetpack provides a series of unbundled libraries not tied to any particular version of Android, giving developers a way to support newer features on older versions of the Android operating system. In addition to backward compatibility, Jetpack promises to help you get more done, with less code, by providing the boilerplate to handle repetitive tasks like managing the application lifecycle.
So now let's break this into bits and pieces, it simply says 2 things
So, all the libraries that come under Jetpack are independent of each other. You can update any particular library without updating others at the same time. You remember those warning,
Those frustrating “All com.android.support libraries must use the exact same version specification” messages should become a thing of the past now.
But that is when you use Androidx libraries and not Support ones.
Now all these libraries that come under Jetpack do a lot of boilerplate code at their side, so you don't need to write a lot of code and just worry about the logic. Ex - Remember handling Screen Rotation? (ViewModel takes care of it), Handling infinite scrolling by pagination? (now you have Paging library for that), handling back buttons (Navigation library is there for you), handling dependency injection manually or using Dagger (Hilt is your friend here), handling different use-cases of Camera and still fixing bugs in production ( CameraX is an easy way going) (just a few of those)
There are other reasons too to put out JetPack separately, let's discuss those too..
Initially, the name of each package indicated the minimum API level supported by that package, for example, support-v4. However, version 26.0.0 of the Support Library increased the minimum API to 14, so today many of the package names have nothing to do with the minimum supported API level. When support-v4 and the support-v7 packages both have a minimum API of 14, it’s easy to see why people get confused!. So now with AndroidX, this confusion disappears.
With the current naming convention (support ones), it also isn’t clear which packages are bundled with the Android operating system, and which are packaged with your application’s APK (Android Package Kit). To clear up this confusion, all the unbundled libraries will be moved to AndroidX’s androidx.* namespace, while the android.* package hierarchy will be reserved for packages that ship with the Android operating system. Simply saying, now on, android.* will be reserved for android operating system related packages, so these packages will anyway start with android.* package name WHILE androidx.* will now be reserved for app development related stuff.
Apart from this, you have:
Architectural Component
Foundational Component
UI component
Behaviour Component
So now, Jetpack is nothing but a name given to the superset of these components, androidx and other tools.
Android Jetpack Components
Android Jetpack components are a collection of libraries that are individually adoptable and built to work together while taking advantage of Kotlin language features that make us more productive.
These software components have been arranged in 4 categories which are as follows:
Foundation Components
Architecture Components
Behavior Components
UI Components
Architecture Components
All the architecture components are as follows:
Data Binding: Declaratively bind UI elements to in our layout to data sources of our app.
Lifecycles: Manages activity and fragment lifecycles of our app.
LiveData: Notify views of any database changes.
Navigation: Handle everything needed for in-app navigation.
Paging: Gradually load information on demand from your data source.
Room: Fluent SQLite database access.
ViewModel: Manage UI-related data in a lifecycle-conscious way.
WorkManager: Manage every background jobs in Android with the circumstances we choose.
For more details use below link:-
https://blog.mindorks.com/what-is-android-jetpack-and-why-should-we-use-it
Android Jetpack is a collection of Android software components which helps us in building great Android apps. Android Jetpack Components are a collection of libraries ,tools that help in developing robust android applications. Jetpack comprises the androidx.* package libraries, unbundled from the platform APIs. This means that it offers backward compatibility. The software components have been divided into 4 categories:
Foundation Components
Architecture Components
Behaviour Components
UI Components
Foundation Components - Foundation Components provide Backward compatibility, Testing, Kotlin support.
Foundation Components are:
App Compat: The AppCompat library in Jetpack foundation includes all of the components from the v7 library.
This includes AppCompat, Cardview, GridLayout, MediaRouter, Palette, RecyclerView, Renderscript, Preferences, Leanback, Vector Drawable, Design, Custom tabs, etc.
Moreover, this library provides implementation support to the material design user interface which makes AppCompat very useful for the developers.
Android KTX: KTX stands for Kotlin Extensions ,Android KTX consists of a set of Kotlin extensions that are designed to facilitate developers to remove boilerplate code
as well as to write concise code while developing android applications with Kotlin language.
Multidex: Dex is the format of the executable file which runs on the Android virtual machine(known as Dalvik). Multidex component also provides support to the collective dex files of an application.
Test: includes the Espresso UI testing framework for the runtime UI test and AndroidJUnitRunner for the purpose of unit testing of Android applications.
Architecture Componets helps in building robust apps.It does not support any particular architecture pattern but suggests clear separation of concerns and controlling of UI from Model by which developers can avoid problems related to activity lifecycle.
Architecture components are:
Room-The Room component acts as an SQLite Object Mapping Library which overcomes challenges from using SQLite like checking the queries at compile-time, writing boiler plate code.
Room converts queries directly into objects, check errors in queries at the compile-time, and is also capable of persisting the Java POJOs. Sub components are:
1.Entity
2.Data Access Object
3.Database
WorkManager-manage the background tasks in Android which are deferrable(can be run later and is still useful) as well as guaranteed(runs even if the device restarts).
It Provides backward compatibility,Scheduling and chaining of tasks is possible ,Users can keep track of/status of the tasks.
LifeCycles-The androidx.lifecycle package components perform actions in response to a change in the lifecycle status of another component, such as activities and fragments. These components help you produce better-organized, and often lighter-weight code, that is easier to maintain.This helps in creating organized application components, ease in testing and maintenance of components, less code requirement to executes tasks.
ViewModel-Manage UI-related data in a lifecycle-conscious way. It helps in data management during configuration changes ,Reduce UI bugs and crashes.
LiveData- Livedata notify the UI of any appropriate change in the data. If the observer’s lifecycle state is destroyed, LiveData is capable to remove it, and thus it avoids memory leaks.
It removes the stopped or destroyed activities which reduce the chance of app crash.
Navigation Component-Navigation Component get all the benefits of other Architecture components as well like Lifecycle and ViewModel. It helps in implementing basic navigation styles like simple button clicks to complex navigation patterns like app bar and navigation drawer.Further, it also supports deep links and helpers which enables the connection of this component with the navigation drawer and bottom navigation. It
ease the transition through animated visualization,s upports deep linking, handle fragment transactions, support common as well as a complex navigation pattern
Paging- This library provides the facility to load the application data slowly and in a cautious manner. Easy to integrate with Recycler View in order to display a large data set, compatible with LiveData and RxJava for updating the UI data, loads data gradually with caution.
Data Binding- Data Binding library is a support library that provides the feature of binding UI components in an activity/fragment to the data sources of the application.
Make code simpler and easy to maintain by removing UI frameworks called in the activity.It also Allows classes and methods to observe changes in data and allows to make objects and filled which works as collection observable.
Behaviour Components- Behavior components help in the integration with standard Android services like Notifications,Permissions,Sharing,Assistant.
Behaviour Components are:
Download Manager : The DownloadManager is a system service in Android that helps in downloading bulky files in the background thread.It Schedule and manage large downloads in background with auto retry support.
Media & playback:Jetpack provides a backward-compatible API for the Android multimedia framework.
The included Media libraries facilitate developers to integrate audio, video, and image files into an application Backwards compatible APIs for media playback and routing (including Google Cast).
Notifications: Provides a backwards-compatible notification API with Wear and Auto support.
Permissions: Compatibility APIs for checking and requesting permissions in app.
Preferences: Create interactive settings screens for users to configure.
Sharing: Provides a share action suitable for an app’s action bar.The ShareActionProvider class is used to carry out the task of sharing contents and information.
Slices: Create flexible UI elements that can display app data outside the app and can be extended all the way back to Android 4.4.
UI Components-The UI components provide widgets and helpers that aim
to improve the interactions that users have with Android applications.
UI Components are:
Animation and transitions: Jetpack offers APIs to set up different kinds of animations available for Android apps.This framework imparts
the ability to move widgets as well as switching between screens with
animation and transition in an application.
Auto: Components to develop Android Auto apps.The following category of applications can be built, test, and distributed on
Android Auto: Navigation apps,Messaging apps,Media apps.
Emoji: Enable updated emoji font on older platforms. Google has released new library called EmojiCompat in order to handle emoji
characters and to use downloadable font support.The backward
compatibility of this library is up to Android 4.4(API level 19).
Fragment: Represents a behaviour or portion of the user interface, used for dynamic and flexible UI designs (and to reduce boilerplate
layouts and code).
Layout: Are used for creating and designing the structure of the user interface.
Palette: Used for designing layout themes and to apply custom colors to the elements of the app.
TV: Components to develop Android TV apps.
Wear: Components created to help develop apps for Wear.
Android Jetpack is a set of libraries that helps you to deal with the challenges you eventually face as a Android Developer — writing boilerplate code, managing activity lifecycles, surviving configuration changes or preventing memory leaks.
Jetpack libraries may be used alone or in combination to address different needs in your apps.
WorkManager for your background scheduling needs.
Room for data storage persistence.
Navigation to manage your application navigation flow.
CameraX for your camera app needs.
Android Jetpack is a set of libraries which makes life of android developers easy. Android development can be done without jetpack also, but it gives your applications more modular, application life-cycle aware and more testable.
For instance, Work manager is a Jetpack component which is used for scheduling tasks for may get triggered when suitable conditions meet (like device is plugged in). Applications can be developed without using Workmanager also (Using Jobschedular), but developer will not have more options.
Android Jetpack is a set of libraries which makes life of android developers easy. Android development can be done without jetpack also, but it gives your applications more modular, application life-cycle aware and more testable.
For instance, Work manager is a Jetpack component which is used for scheduling tasks for may get triggered when suitable conditions meet (like device is plugged in). Applications can be developed without using Workmanager also (Using Jobschedular), but developer will not have more options.
Related
As per my knowledge Androidx is itself a library, and android jetpack is a set of libraries. Does androidx is a library in Android jetpack ? Iam little bit confused about androidx and android jetpack. Can anyone explain me clearly
As per the AndroidX FAQ doc:
How are androidx and AndroidX related to Jetpack?
They are all the same thing! In a sentence, androidx is the packaging and AndroidX is the development workflow for all components in Jetpack. Jetpack is the external branding for libraries within androidx.
In more detail, Jetpack is the external branding for the set of components, tools, and guidance that improve the developer experience on Android. AndroidX is the open-source development project that defines the workflow, versioning, and release policies for ALL libraries included in Jetpack. All libraries within the androidx Java package follow a consistent set of API design guidelines, conform to SemVer and alpha/beta revision cycles, and use the Android issue tracker for bugs and feature requests.
androidx.* has been replacing the old android.support.* and android.arch.* set of libraries.
It also includes support to all the older libraries (except for the deprecated one, of course).
Android Jetpack is a suite of tools developed by Google to write applications that follow certain standards as well as ease the job of developers like us.
Part of the Android Jetpack "universe" is Room (a library that facilitates the writing of an SQL database), DataStore (currently still in beta, but soon it will replace SharedPreference for the persistence of settings when for example we set Dark mode in the app, we close it, and we expect to still have Dark mode ON when we open it back), LiveData (for asynchronous data stream), ......and others.
All this goes hand in hand with the continuous development of the Kotlin language and the never-ending usefulness of COROUTINES, just to mention one.
I hope this overview was of use to the readers.
I can't seem to find a clear answer to this in Google, and all the documentation and samples I've seen for Jetpack seem to refer to and use Kotlin.
But do you HAVE to use Kotlin in order to use Jetpack? Or can Jetpack be used with traditional Java programs?
I was looking at Kotlin but it adds almost a MB to your app size. And seeing as my entire app is only about 200KB currently, I don't think Kotlin is worth increasing the size of my app by 500%!
Jetpack is a collection of libraries plus guidance on how Google recommends building Android applications. These libraries all have Java APIs, so you don't need to move to Kotlin to use any of them. Both languages are still completely supported for Android development.
As for the APK size consideration, it's true that Kotlin will definitely increase it. It's hard to tell how much larger it'll be, but Proguard should strip out a lot of the standard library that you end up not using, so it could be much less than an entire MB. Here's an article that compared Java and Kotlin APK sizes of an essentially empty Hello world app that found the increase to be just 11 KBs, for example. So unless you're in a market where this is extremely important, you could probably get away with using Kotlin.
More importantly though, switching to Kotlin is more than just pulling in a library - it's a new language to learn, which means you have to put some effort into it, and it can change a lot about how you write your applications. You should look into the language more and see if you like what it offers.
You just get more syntactic sugar when you use kotlin instead of java, but they have same functionality and you can even use them hybird.
Also android Jetpack is great, it shouldn't be limited by language. Although android-sunflower - the official demonstrate app of Android Jetpack wrote in Kotlin, it can still implement by java. In order to support Android Jetpack, I translated all kotlin implementations to Java, and added [app-java] module as the Java version of android-sunflower app, please check out android-sunflower-java.
Quoting Android documentation
Jetpack is a collection of Android software components to make it easier for you to develop great Android apps. These components help you follow best practices, free you from writing boilerplate code, and simplify complex tasks, so you can focus on the code you care about.
Jetpack comprises the androidx.* package libraries, unbundled from the platform APIs. This means that it offers backward compatibility and is updated more frequently than the Android platform, making sure you always have access to the latest and greatest versions of the Jetpack components.
Nowhere in the docs you'll find something saying that using Kotlin is required for Jetpack development. Also, if you open Android Studio 3.2 (Currently beta 5), in the New Project Dialog, you'll see the option to add Kotlin support just like the previous version of Android Studio, so you'll be completely fine going with Java without checking this box.
I'm a little confused about the advantages and disadvantages of using Android KTX vs Anko. Because both libraries are trying to achieve the same end goal, and the line between them it's getting a little bit blurry to the point, in some cases, the same functionality is available in both libraries.
I will be very thankful if you help me to clarify the mission of each one, and their use cases.
Thanks in advance!
Anko is a project JetBrains started while developing Kotlin and making it relevant for Android. I'd qualify it as an early production-ready showcase of Kotlin possibilities.
Anko is well known for Anko layouts, but also has some extensions for Android development in Anko Commons, and also a few other modules like SQLite.
However, Anko libraries have accumulated a significant number of methods updates after updates, which today make the library relatively heavyweight when you are limited to 65K methods per dex file (I prefer staying with a single one, for apk size and performance reasons).
Anko commons provides extensions for Android, so it's similar to Android KTX in a way, but it's not as well integrated and organized (packages and artifacts wise) as Android KTX which is now part of AndroidX, which is part of Android Jetpack. Making the libraries smaller, and more loosely coupled is part of the Android Jetpack / Android X philosophy BTW.
So Android KTX, is clearly the future, and I see no reason to not jump in the ship, or rather, not letting it jump in your Android projects.
Also, as you yourself pointed out, future Anko versions will deprecate (and probably finally remove) overlap with Android KTX, to provide only features that are not in AndroidX.
Includes a shameless plug:
Since you're talking about Anko, if Anko layouts got your attention, but you experienced struggles with them (especially when interacting with custom or third-party views), I'd recommend you to check out Views DSL in Splitties, which is more flexible than Anko layouts, and very lightweight. The other modules may also interest you. I started this project to leverage Kotlin features in my Android projects at work and at home.
You've not asked about it, but here's my take on Anko coroutines:
I find the bg { … } extension confusing. I prefer to use kotlinx.coroutines with the Android artifact, using launch, withContext, etc, along with Dispatchers.IO.
However, the Anko coroutines listeners (e.g. onClick that can suspend) are not a bad idea IMO.
Anko is a Kotlin library from JetBrains. It shares the goals with Android KTX of making your life as an Android developer easier and making your code more readable and pleasant to use. Android KTX and are Anko are similar but not quite the same.
Differences Between Anko and Android KTX
They have common goals but with different scopes in mind. The mission of KTX is to bring idiomatic APIs to Kotlin users. KTX does not intend to add new functionality to the existing Android APIs.
Anko has a wider scope, and this gives it the flexibility to innovate and create new features
Deciding When to Use Anko or Android KTX
Generally speaking, Anko and Android KTX cover different parts of the Android API, and there’s no reason you can’t use both in your project. Investigate each one individually and use either as much as you want in your projects!
There is a core ERP mobile application for Android. A customer has requested additional features that will require more screens (and Activities) and extra functionality.
Is there a way I can add sort of an extension to the core mobile application in order to intergrate the extra features or should I code on top of the code of the core application?
I am interested in finding a neat solution focused on extendability since different clients might ask for different additional features. How would you deal with such an issue? Any tips on the structure of such a project would also be welcome.
Would it make a difference if the extra features need to use the same db as the core application?
Thank you in advance for your help.
The answer to your question lies in the Open/Closed principle introduced by Bertrand Meyer. Open/Closed Principle is a very simple Object Oriented Design principle which states that
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"
From your question its clear that you have identified the core functionalities in your application. So rather than Modifying this core functionalities and making it more specific, I would recommend, on the basis of the Open/Closed principle, that you should freeze your code features and write your customer specific functionalities over it without corrupting the core.
Now to answer your question on what kind of structure you may follow. I would recommend that you create a library project of your core functionalities and make different client specific projects that would include your core functionalities as a library project.
It won't make a difference if your application is using the same db as your core application provided all your applications uses it, else it should not be in your core application in the first place.
Hope this explanation help you.
Update:
My friend pointed out that I may not have understood the question right. So rather than correcting my old post(...which may be useful for others) I am updating it.
So if I understand it right, you have an ERP project which you may not have coded. The right approach, according to me,still would be that you build over this existing code. Rather than making changes on this project, include it as a library because if the project is downloaded from a reliable source, you will have the benefit of getting the updated version as and when it is available.
This is kind of a design philosophy question. Here are a couple choices that might give you ideas:
You could look into making your core application code/features into a custom library. Then your new core application is just a simple wrapper that includes the custom library. Your additional features for a specific customer could then be a different app that also references the core library but will include additional features. There are lots of tutorials on how to turn your app into a custom library. You would end up with different apps that target different a customers. (A tip that took a while for me to uncover is that if you have a resource name in your custom library you can "override" it by using the same name in the app that includes the library. Another tip is that you need to essentially duplicate the manifest of the library in the app by listing all the activities in the library that would be used by the app.) I haven't tried this but it might be that your additional features are each libraries that are included in different apps.
You could have an key the user inputs that will unlock certain features. You could save this as a shared preference so that they don't need to keep entering the key. This approach has the benefit that you can "reuse" features for other clients without any more implementation other than determining which client gets what feature. The majority of users just wouldn't have a key to unlock anything.
Both these solutions should use the same db since they would be calling the same core classes, etc.
Another possible solution is to create a Library Project. Put your core ERP app code inside the library Project, and then create different project for different customers. Each one of these projects will also use the same library project.
Your core library project could expose an api to dynamically register new features (Such as a menu that can expose new menu items).
I'm working on an Android project and I would like to know any recommendations about what's a good architecture to build an android application.
I want to use dependency injection using Roboguice and I've been reading about MVVM pattern or MVC pattern (Android MVVM Design Pattern Examples).
Also I know that roboguice have a pretty cool Context-Based Event's raising and handling feature that could be very testable as the code is decoupled.
Any recommendations on a working design pattern? a testable and scalable architecture you have worked with or developed?
The Android platform provides a common set of design patterns, and with the limited hardware resources you get compared to Web-apps it is still often best to stick with using these directly in production code. There are other frameworks that sort of "wrap" the base platform; these are worth looking into if you have a specific purpose (or perhaps for prototyping/experimenting), but for the best level of support you are generally best sticking with the standard components.
This is a great resource when working on UI solutions: http://www.androidpatterns.com/
Specifically for DI: There is a Spring framework for Android, I've had a play with it and it looks quite promising. You've already mentioned Roboguice as another alternative to this. However, to avoid performance and library overhead, I still find the easiest approach is to write a simple reflection-based class that registers and injects dependencies within my own code. Similar to this approach, except I usually move the injection code into a separate singleton and reference it from there.
In my experience most of the third-party offerings are not yet mature enough to rely on right now, and don't really give you much on top of what the base platform provides. They are constantly progressing, however, so be sure to experiment with the big names from time-to-time.