We can create animations using both android.animation package and android.transition package but I would like to know what is the main difference between these packages since even custom transitions also use animator's from android animation package.
From the documentation of android.animation:
These classes provide functionality for the property animation system,
which allows you to animate object properties of any type.
From the documentation of android.transition:
The classes in this package enable "scenes & transitions" functionality for view hiearchies.
From there a conclusion could be made that android.animation mostly handles individual View animation (a FAB moving left upon click, etc) while android.transition cares mostly about view hierarchy/layout transition animation (Material Design shared elements, etc).
do read about fundamental difference at http://developer.android.com/about/versions/android-4.4.html in 'Animation & Graphics' section. Basically, you can transition between different states of UI by defining Scene objects.
I don't have any code to support as i haven't used this till now, but above link should get you started.
Related
I'm writing a cross-platform app for iOS and Android using MvvmCross.
The Android version makes use of nested Fragments. For example, the home view is a navigation drawer, its various navigation hub views are Fragments which may be split views containing other fragments, and on top of that, each view may show a dialog fragment as well.
Additionally, not all ViewModels are shown via ShowViewModel(), some of them are used more like PropertyChanged event providers as demonstrated in the N=32 video.
This is working fine until a configuration change takes place (typically, rotating the device). When the fragment views get recreated, their View Models aren't and are set to null. This is hinted at in the following MvvmCross issue #636, where Stuart also mentions he'd like the project to come up with some best practice advice.
My question now is what are the best practices for this? What do you do if you have to properly support Android configuration changes in MvvmCross?
I've tried working around the problem as outlined in the issue linked above, i.e. by some form of ViewModel registry in the parent ViewModels, and also by trying to serialize the Fragment's ViewModel when saving its instance state, with limited success. The results felt hackish at best. The problem remains that a Fragment doesn't know how to recreate its View Model in MvvmCross. Oh, and disabling configuration changes on device rotation doesn't count as an answer. ;-)
Obviously this answer is not a direct answer to your question but I feel its related enough to mention here.
In my android apps I have started to inject a Controller (or MVA style Adapter) into a View / Fragment / Activity using the Dagger Dependency Injection library. This has the crucial property of maintaining the instance of the Controller class, so on rotation / config change the same Controller is re-injected.
It seems that Mvx.Resolve() should be able to perform this ideally, or your gonna have a bad time. If it does not introducing a middle layer cache between your view classes and the Mvx class seems the only option to me. But this is my first hour or so reading about Xamarin so I may be off the mark. I have been an Android dev for 5 years now though so just thought I would add my 2 pence :)
We have an Android application made of menu of modules and each module has the same layout as on this picture:
You have a header with module name and two buttons on the bottom. The module itself is behind those three transparent elements. Left button allows the user to move to the previous screen and right button gets him back to the menu with modules. Text in header changes based on current screen action.
My question is how to build the module transparent frame. Is it possible to have one layout in Android on top of the other? Should we design the code as a parent class that would be inherited by all the modules? I am interested in some best practice. I have experience with Java but only theoretical knowledge of Android.
Prepare a separate common layout and use to add that layout to as many layouts you want.
for more details check this
What you are looking for are so called Fragments. These Fragments are sort of like Activities, with their own layouts and lifecycles, but you are able to use multiple Fragments at once. This means you'll be able to use one Fragment for your navigation and header, and one for the module behind it.
'Android Design' site is recommending 'Boundary feedback' for scrollable view.
http://developer.android.com/design/style/touch-feedback.html
http://i.stack.imgur.com/TuBkX.png
is there any API or library for custom view to implement that with ease and consistent?
or should I implement it from the scratch?
Are you "building custom"? If you stick to the UI elements form the API you should be fine. All the scroll views can already be configured to do different things for boundry cases (such as overscroll).
If you are building UI elements from scratch, you might consider simply overriding or subclassing existing UI elements to function the way you want. If not, you can examine the source to see how different boundry cases (again overscrolling) are implemented. But, I get the feeling you're in the first category..
I have an Android app that I would like to convert to an Android library. The app is based around one activity whose entire XML layout contains only a webview that covers the entire screen. The library UI (really, just the webview) must now be integrated into the layout of other apps. For example, one parent app has a tab structure. I would like to have the library webview displayed in one of the tabs, with the tabs always visible at the bottom of the screen. Ordinarily, I'd opt to set the app-library boundary at the activity level but that does not work in this case -- we cannot pop up a new Activity from the library because that would cover all of the screen and the tabs at the bottom.
What is the best way to convert this to a library so that it works within the tab structure of the parent app? Where should the app-library boundary be? Some of my ideas are:
Let the library user create an activity with the custom layout that he prefers (tabs in this case). Make sure that the layout contains a webview. Use findViewById to get the webview object and pass this object into the library for the library to use to display pages. Main disadvantage here is that parts of the library need to hook up some Broadcast receivers onto the parent activity (which is not really part of the library in this scenario), and this coupling seems rather dubious.
Perhaps use fragments which were introduced in Android 3.0. However, these mostly seem geared towards tablets. Would these work in this case?
Is there another option compatible with Android 2.1+ that I am not aware of?
I decided to go with Fragments, using the compatibility library.
http://developer.android.com/guide/topics/fundamentals/fragments.html
http://developer.android.com/sdk/compatibility-library.html
Fragments are really the best choice in this case because:
They have a life cycle similar to that of activities, making conversion easy.
They are a chunk of UI with related functionality, which is exactly what's needed in this case.
I'm getting started with Android development, and I would like to have an interface similar to that of tweetdeck: there are several workspaces (activities) that are laid out left to right, and the user can switch between them with a horizontal gesture. The same way the Android desktops are switched.
In tweetdeck there are also dots in the titlebar, that indicate on which side and how many workspaces there are.
Is it a standard Android interface, or something custom built? How do I do something like this?
How you go about this is going to be partially dependent on the content you want to present. If there are going to be many heavyweight pages you'll want to look into doing something like a custom AdapterView. If there are only a few fixed pages such as in the stock home screen you can treat it like a scrollable view with some custom logic to handle snapping to pages.
Here's a link to the custom view that implements this in the stock Android launcher. The bits you're interested in will mostly be in onTouchEvent, onInterceptTouchEvent, and computeScroll.
https://android.googlesource.com/platform/packages/apps/Launcher2/+/master/src/com/android/launcher2/Workspace.java
Take a look at ViewFlipper: http://developer.android.com/reference/android/widget/ViewFlipper.html
In addition to studying the actual Android code (referenced in another answer), some folks have extracted and isolated the workspace (Launcher2) code into a re-usable view group. You can find the work in github here https://github.com/olibye/AndroViews