I am developing the Android version of my Xamarin.iOS application, so I want to share as much code as possible between both platforms.
I am using MonoTouch.Dialog for iOS screens and the MvvmCross Android.Dialog for Android screens.
How would be the best approach to develop the right side (Android) screen?
I am targeting Android 4.0.3+ and using the Support Library v13 (Rev 18) to work with child fragments.
The DialogListFragment is a custom Android ListFragment.
I have been reading lots of questions about ListViews embedded inside a ScrollView but I could not figure it out yet what is the best practice to follow. Is there some official documentation?
When trying to implement the right (Android) screen I could see two behaviours:
By using the internal ScrollView, all child fragments' ListViews are displaying just their first content row;
By eliminating the internal ScrollView, fragments get correctly displayed. But in some cases, their height may be higher then the screen height and so they will not completely appear.
Related
I'm trying to port an iOS app to Android. I'm an Android noob, but I'm quite experienced in iOS. Here is a screenshot of my app.
The UITableView has custom cell types: Switch cells, tap to toggle the switch on and off. Multi-value cells: tap to expand a UIPickerView. My iOS app also has a tab bar for more screens.
So I started with the default TabLayout template in Android Studio, and made it to show three different fragments.
I then moved on to making the main interface. That was when the PreferenceFragment popped up in my searches, and seemed like a very good idea – my iOS app has a relatively complicated architecture to keep track of the state, and the PreferenceFragment promised to take care of that transparently, so I was in.
However, the TabLayout does not seem to like PreferenceFragments because they are not the same as compat fragments (did I get that right?). Anyway, the linked question suggests a couple of solutions that I'd rather not follow (re-invent the wheel? Seriously?).
Reading around, people suggest I might get away with a PreferenceActivity instead, but I really liked the idea of fragments, mostly because I want my app to scale to tablet and have a "different" UI, with the two different lists of parameters showing up side by side – a job for fragments, right?
Now, the best I can figure is to go back to RecyclerViews, so my question is: is that it? And if so, do RecyclerViews support simultaneous different types of cells like UITableViews do? I should also say that I don't particularly care for Android <5.0, if that helps…
Any other hints or pointers for me to follow when porting iOS apps to Android?
The reason TabLayout does not seem to like a PreferenceFragment is because PreferenceFragment extends android.app.Fragment not android.support.v4.app.Fragment (you did get that right), which the TabLayout (in reality, the FragmentPagerAdapter) expects.
If you want the functionality of a PreferenceFragment to be paired with other app-compat widgets, import the v7 Preference Support Library:
compile 'com.android.support:preference-v7:24.2.1'
Then you can extend android.support.v7.preference.PreferenceFragmentCompat, which itself extends from android.support.v4.app.Fragment.
Please have a look at this screenshot from Google Maps for Android. What layout is Google using for this particular screen?
Using multiple ListView controls here would be an overkill in terms of performance (or so I think). Also, because one can scroll on this screen, I don't think Google is using ListView controls here as ListView controls don't work along with ScrollView controls. Is Google using multiple instances of the all new CardView control on top of a ScrollView control here?
Can someone help with the best possible layout (from a performance perspective) for rendering this particular screen? I need to make sure my app supports lower end Android handsets so rendering performance is the number one priority but nothing like achieving it with clean, simple & reusable code + layouts (if possible in this scenario).
Thanks in advance!
I'm having serious problems getting three layers of nested tabs to work in an app that runs from Android 2.1 up and looks like Android 4 (uses support library fragments).
The goal
App should have an ActionBar (works, currenly uses ActionBarSherlock)
3 fixed tabs on the main screen, that don't move into the ActionBar even if the screen is large enough. The second of these tabs contains...
About 4 tabs that were loaded from a server when the user logged in the first time. Each of these contains
About 10 swipable tabs (like in the Play Store) that were loaded from a server when the user logged in the first time. My idea here is to use ViewPagerIndicator, since that library is written by the same guy who ActionBarSherlock which should keep problems down to a minimum. But I'm open to ideas here). Each of these swipable tabs contains something that is currently a Fragment, but could be changed.
The Problem
When this was an Android 2 app, it simply used nested TabActivities, but these don't work with all the Android 4 stuff. I don't understand how to do this probably, especially the "you can't nest fragments" restriction is causing me headaches. Also, it seems that you can only use one FragmentManager per Activity, so my idea to have one in each of the second row tabs didn't work (All except for the first tab remained empty).
How to do this the right way?
(Please understand that "Use a different GUI design" is not an option since this is what the customer asked for and he won't reconsider)
PagerAdapter does not require Fragments as children. You can inflate/manage your own custom views in there. So you could continue to use nested TabActivities. Or, you could put Fragments at the top-level, and manage your own Views in the bottom-level ViewPager.
You could also, theoretically, use ViewFlipper if you want to keep the Fragments in the ViewPager. You'll have to write your own LinearLayout with Buttons as tabs, but this is easy. If you're looking for the Holo look, simply set the style to the ones found in ABS.
Another option is to use TabHost without using the TabActivity. You can even use it with Fragments. See the example here.
Also note: If you're looking for the Google Play style of ViewPagerIndicator, thats now inlcuded in the Support package: PagerTitleStrip.
I'd imagine that your best option is to use Fragments as the top-level, as this will help with memory consumption.
That said,
I must say that this sounds like a terrible UI pattern. Even worse, we are talking about a lot of inflated views in one Activity. You may run into memory issues here, depending on whats being shown. I suggest heavy usage of ViewStubs and recycling if you keep the ViewPager at the bottom.
Keep trying to push the client toward using the ActionBar spinner pattern for top-level (main 3 tabs), or even consider the fancy sliding drawer pattern. Perhaps that smooth animation could be enough to sway their opinion.
Refer them to the official design website, and show examples of popular navigation patterns like the ones found in Gmail, YouTube, Google+, Evernote, etc. I recently dealt with a client requesting the exact-same pattern you describe, and after weeks of pushing was able to convince them that more-than` 2 layers of tabs is unacceptable.
You can also show them my Wall of Shame Google+ page, highlighting bad design patterns used in popular Android apps: Android UI Anti-Patterns. :-)
The new Youtube app, and the newer version of JuiceDefender, contains a sliding tabbed layout similar to those seen in Windows 7 Phone. This is a UI feature I would like to include in an app I'm am designing but I cannot find any information or tutorials online. Has anyone seen a tutorial on this?
I believe it's implemented as a HorizontalScrollView containing a TabWidget with custom, fixed-width, tab indicator views.
Now, getting the tab content views to be paged horizontally is less easy, and that requires something like adapting Workspace.java in the Launcher.git project in AOSP.
I have found the answer to this question. The Sliding layout I described is a ViewPager, available from the Android Compatibility Package v4, which is available from the SDK installer.
A tutorial for this can be found here :http://mobile.tutsplus.com/tutorials/android/android-user-interface-design-horizontal-view-paging/
Edit
An improvement over the Android Compatibility package is the http://actionbarsherlock.com/ an improvement over the support package that adds more Jelly bean style stuff.
I haven't seen a tutorial like this, but you won't be able to do something like this with just the native widgets as they are. You're really looking at implementing your own custom widgets and views, or at the very least wrapping the included widgets with your own code. Maybe a future api will have such features built in, but at this point you're forced to do everything yourself if you want such an interface.
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.