Android Jetpack is a set of components, tools and guidance to make great Android apps. In addition, your app can run on various versions of the platform because Android Jetpack components are built to provide their functionality independent of any specific version, providing backwards 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.Jetpack should help limit your reliance on boilerplate copypasta, with an eye towards rapid development and unit testing. It's even optimized for Kotlin, if you've started moving over into the new language. Google has also increased how quickly the Android Studio emulator launches, thanks to new snapshots which store the full state of the emulator while it isn't in use. All this combines together to let you develop apps faster.
Android Jetpack comes with five new components:
- WorkManager alpha release
- Navigation alpha release
- Paging stable release
- Slices alpha release
- Android KTX (Kotlin Extensions) alpha release
WorkManager:
WorkManager is intended for tasks that require a guarantee that the system will run them even if the app exits, like uploading app data to a server. It is not intended for in-process background work that can safely be terminated if the app process goes away; for situations like that, its recommend using ThreadPools.
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. For example, an app might need to download new resources from the network from time to time. Using these classes, you can set up a task, choose appropriate circumstances for it to run (like "only while device is charging and online"), and hand it off to WorkManager to run when the conditions are met. The task is still guaranteed to run, even if your app is force-quit or the device is rebooted.
The WorkMananager component is a powerful new library that provides a one-stop solution for constraint-based background jobs that need guaranteed execution, replacing the need to use things like jobs or SyncAdapters. WorkManager provides a simplified, modern API, the ability to work on devices with or without Google Play Services, the ability to create graphs of work, and the ability to query the state of your work. Early feedback is very encouraging but we love to make sure that your use cases are covered, too.WorkManager might use JobScheduler, Firebase JobDispatcher, or AlarmManager. You don't need to write device logic to figure out what capabilities the device has and choose an appropriate API; instead, you can just hand your task off to WorkManager and let it choose the best option.
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. For example, an app might need to download new resources from the network from time to time. Using these classes, you can set up a task, choose appropriate circumstances for it to run (like "only while device is charging and online"), and hand it off to WorkManager to run when the conditions are met. The task is still guaranteed to run, even if your app is force-quit or the device is rebooted.
The WorkMananager component is a powerful new library that provides a one-stop solution for constraint-based background jobs that need guaranteed execution, replacing the need to use things like jobs or SyncAdapters. WorkManager provides a simplified, modern API, the ability to work on devices with or without Google Play Services, the ability to create graphs of work, and the ability to query the state of your work. Early feedback is very encouraging but we love to make sure that your use cases are covered, too.WorkManager might use JobScheduler, Firebase JobDispatcher, or AlarmManager. You don't need to write device logic to figure out what capabilities the device has and choose an appropriate API; instead, you can just hand your task off to WorkManager and let it choose the best option.
Navigation:
The goal of any in-app navigation should be to provide a consistent and predictable experience to users. To meet this goal, the Navigation Architecture Component helps you build an app that adheres to each of the navigation principles below.
The app should have a fixed starting destinationApps have a fixed destination which is the screen the user sees when they launch your app from the launcher. This destination should also be the last screen the user sees when they return to the launcher after pressing the back button.
A stack is used to represent the "navigation state" of an appThe navigation state of your app should be represented with a last in, first out structure. This "navigation stack" should have the start destination of the app at the bottom of the stack and the current destination as the top of the stack.Operations that change the navigation stack should always operate on the top of the navigation stack, either by "pushing" a new destination onto the top of the stack or "popping" the top-most destination off the stack.
The Up button never exits your appIf a user is at the start destination, the Up button should not be shown. When your app is launched using a deep link on another app's task, Up should take users to the hierarchical parent destination and not back to the other app.
Up and Back are equivalent within your app's taskWhen the system Back button would not exit your app, such as when you are on your own task and not on the start destination, the Up button should function identically to the system Back button.
Deep linking to a destination or navigating to the same destination should yield the same stackA user can enter an app at the start destination and navigate to a destination. A user can also use a deep link, if available, to navigate to the same destination. In both of these cases, the navigation stack should have the same stack of destinations. Specifically, the user should be able to use the Back or Up button, regardless of how they got to a destination, to navigate through destinations back to the start destination. Any existing navigation stack is removed and replaced with the deep link’s navigation stack.
The app should have a fixed starting destinationApps have a fixed destination which is the screen the user sees when they launch your app from the launcher. This destination should also be the last screen the user sees when they return to the launcher after pressing the back button.
A stack is used to represent the "navigation state" of an appThe navigation state of your app should be represented with a last in, first out structure. This "navigation stack" should have the start destination of the app at the bottom of the stack and the current destination as the top of the stack.Operations that change the navigation stack should always operate on the top of the navigation stack, either by "pushing" a new destination onto the top of the stack or "popping" the top-most destination off the stack.
The Up button never exits your appIf a user is at the start destination, the Up button should not be shown. When your app is launched using a deep link on another app's task, Up should take users to the hierarchical parent destination and not back to the other app.
Up and Back are equivalent within your app's taskWhen the system Back button would not exit your app, such as when you are on your own task and not on the start destination, the Up button should function identically to the system Back button.
Deep linking to a destination or navigating to the same destination should yield the same stackA user can enter an app at the start destination and navigate to a destination. A user can also use a deep link, if available, to navigate to the same destination. In both of these cases, the navigation stack should have the same stack of destinations. Specifically, the user should be able to use the Back or Up button, regardless of how they got to a destination, to navigate through destinations back to the start destination. Any existing navigation stack is removed and replaced with the deep link’s navigation stack.
Paging:
Data presented in an app can be large and costly to load, so it's important to avoid downloading, creating, or presenting too much at once. The Paging component version 1.0.0 makes it easy to load and present large data sets with fast, infinite scrolling in your RecyclerView. It can load paged data from local storage, the network, or both, and lets you define how your content gets loaded. It works out of the box with Room, LiveData, and RxJava.
Slices:
And finally, to round out the set of new features making their debut in Android Jetpack is the Slices component. A "slice" is a way to surface your app's UI inside of the Google Assistant as a result of a search:
Android KTX
And last but not least, one goal of Android Jetpack takes advantage of Kotlin language features that make you more productive. Android KTX lets you transform Kotlin code like this:To start using Android KTX, add the following to your project's build.gradle file:
repositories {
google()
}
When you use a module, include a dependency for each Android KTX artifact in your app's build.gradle file. Remember to append the version to the artifact. For example
dependencies {
implementation 'androidx.core:core-ktx:1.0.0-alpha1'
}
repositories {
google()
}
When you use a module, include a dependency for each Android KTX artifact in your app's build.gradle file. Remember to append the version to the artifact. For example
dependencies {
implementation 'androidx.core:core-ktx:1.0.0-alpha1'
}
Modules
Android KTX is composed of the following Maven artifacts. For API reference documentation, click on the specific package name and see the Extension functions summary.
Reference:https://android-developers.googleblog.com/2018/05/use-android-jetpack-to-accelerate-your.html
Comments
Post a Comment