I want to port my application on all Android devices, and I want to have the right/left animation on the activities transition on all Android platform versions. I know that this feature is implemented in the 2.0 version. How can I implement this feature for the lower versions?
You can simulate it on lower versions by using ViewFlipper for example, but I would not suggest it if you have a lot of View elements on your UI because this requires all the Activities' code to be merged into a single Activity. With a lot of Views you'll max-out the CPU/GPU limits pretty easily. All you get is messy code and bloated XML files.
This is the effect - http://www.youtube.com/watch?v=SZTiJmclaRc
My suggestion - just stick to what the platform API version offers by default and don't rape the hardware.
Related
I don't understand why google decided to not implement support for custom views or even support for the ones bundled in the support library when designing widgets, and instead it decided to rely on RemoteViews
Widgets are such a big part of users interaction with the app, I'm sure many developers found themselves forced to change plans due to this limitation
Is there a specific reason why this was made, maybe related to performances or?
For example, now i would like to implement a recycler view in one widget but I can't, and I don't understand why it has to be so hard to design one and with so much boilerplate code
Widgets are such a big part of users interaction with the app
Few apps implement app widgets.
Is there a specific reason why this was made
Both the host of the app widget (e.g., home screen/launcher) and the publisher of the app widget need to agree on what UI elements can be used and how they can be configured.
For example, you seem to want to use a RecyclerView. That's fine, however, your app does not render the app widget. The host is the one that needs to render the UI of the app widget. So, if you were to use a RecyclerView, your app widget would fail on all hosts that lack RecyclerView support for app widgets. This includes:
All hosts that have not been updated since before RecyclerView was introduced (e.g., home screens on older devices)
All hosts that did not bother to bundle in RecyclerView in their apps
All hosts that did not bother to bundle in whatever the code would be that would cause app widget rendering to support RecyclerView
This coordination gets very complex with hundreds or thousands of hosts and tens or hundreds of thousands of app widgets.
Plus, where does it stop? You think that using RecyclerView is reasonable, and the next person will think that using Facebook's Litho is reasonable, and the person after that will think that using some obscure custom View found on the Android Arsenal is reasonable.
The simple approach for ensuring this agreement is to use a common definition in the framework classes, like RemoteViews, so there is a guaranteed-consistent definition between host and app widget provider. However, RemoteViews is difficult to change in a backwards-compatible fashion, which is why Google has only done it once to date (API Level 11, with the introduction of AdapterView-based options, such as ListView). And framework classes know nothing about libraries, such as those providing RecyclerView or Litho.
I am trying to develop custom launcher app (with unlimited number of home pages)and i need to implement Drag and Drop as done in Launcher2(android 4.2).
So i found two approaches
1) Drag and Drop framework
2) Use the android launcher2 way like implementation DragController, DragSource as explained here.
But i am struggling to understand why didn't Android guys didn't use the Drag and Drop framework developed by them in their own application. Can anyone brief regarding possible rationale behind their approach?( i mean in terms of memory/performance)
Thanks in advance.
The Android drag and drop framework is very basic as compared to the one used in the Launcher app.
The Launcher app has a myriad of "layers" and the drag and drop occurs accross these layers, namely the DragLayer, Workspace and the All Apps view etc. It uses window flags and dynamically adds/removes views to the DragLayer when a drag is in progress and a multitude of activities monitor the drag. For more details look at the DragLayer.java and Workspace.java files particularly.
Drag and Drop in Android Launcher is done as Overlay drawing within the same ViewGroup and in same window . But android drag and drop approach creates a separate window with a separate window type altogether .
Resource and memory wise standard android drag and drop approach is costlier.
If performance is very critical my suggestion is go as per Android launcher way else prefer standard android approach its easy and simple.
Drag and Drop framework is sice api 11.
My guess is, lot of code for launcher was written before that, and noone had time to refactor it yet. But api works similar like second approach.
http://javapapers.com/android/android-drag-and-drop/. This is the best drag and drop example since i have implemented the same in my application. Note: It will support versions only above 11. The drag and drop feature will not support for version 10. Instead u have to move the fields in a absolute layout by settin X and Y positons. But Absolute layout is completely deprecated...
You should use WindowManaager to control Drag And Drop if in case your Application is not so much complex. This is easy to implement and work on Position changed. get the code Here
I noticed that with every iteration of the Android platform, the buttons and UI components keep looking slicker and slicker.
Besides API changes I want to be able to adopt the latest buttons (such as spinners with the bottom-right corner as an arrow), or Jelly bean icons, across all versions of Android where my application is used. How is this usually accomplished?
I want to be able to adopt the latest buttons across all versions of Android where my application is used.
The Holo Everywhere library is a popular choice to do this.
I am developing a mobile app using Titanium. I came across the Google Plus, Tweetdeck, Market Apps for Android. To switch between the tabs they use the slide gesture. Its like the next view simply slides in based on your swipe/drag. I would also like to add the same kind to behavior for my app I would like to have it work on both Android and iOS platforms. How can I have it?
I have tried Ti.UI.scrollableView. The problems I faced were
The sliding was not as responsive as seen in the above apps.
The view does not move along with the finger drag. It moves after the finger drag is finished.
It seems to take more memory as the application response slows drastically and animations dont appear to be smooth.
Kindly let me know if there is any other alternative to implement this kind of experience in the app.
Thanks!!
What you basically need is a Ti.UI.ScrollableView which implements the native Android ViewPager. Those other Apps are binding their Tabs to the ViewPager. You can't do this with a Ti.UI.TabGroup but you can either use your own Tab views or some other module that provides this functionality like this. You could also have a look at my Alloy widget here - it provides a custom tab-indicator for Ti.UI.ScrollableView (without another module).
For Android you should consider using a third-party library to implement such functionality.
Personally I use PagerSlidingTabStrip which I have found that works really well.
Need to implement a View which contains 5 Images placed in stack order. When user move finger up or down at this View picture replace each other.
This approach looks like StackView in Android 3.0, but standard StackView displays applications and it works from API 11 level and I develop for Eclair.
Would like to know if you know some sources where this kind of view has already implemented for Android 2.X, or may be you'll give me an advice to try another one approach to implement this stylization kind.
One option may be to pull the StackView source from a recent Android source base and place it in your application. If I were to do this I would certainly change the package name, and in order to maintain forward compatibility I would see if the original class exists on the platform and use that instead.
If I were to implement what you describe without consideration for having StackView, I would think this could be done easily enough by overriding ImageView and giving my class an array of images to have the source cycle through.