I'd like some advice regarding Android UI (in)efficiency. I'm trying to determine the best way to build a particular layout for my app, however I think my initial idea potentially runs the risk of brutalising performance. Basically I have three very similar and related app components, and to configure them, I need user input. The three components share different parameters within a global set. I want to determine a nice, fluid fashion in which to display this input form on the device.
What I'd like to do is simply allow users to use one form in place of three. All three components are related/similar and they share some of the configuration parameters the user is required to enter.
My initial idea is as follows:
Build an extensive layout of UI elements necessary for initial display for any of the three instances via XML. Unfortunately, given the number of parameters organised in rows, this will amount to approximately 50 view objects in total in this case.
Create activity so that the user enters the screen, and understands
they are required to initially choose one of three values from a
Spinner widget at the top of the screen.
By using bitwise comparison operators, simply show/hide the various
controls related to the chosen Spinner value. (Triggered via
Spinner's onItemSelectedListener() )
Create some minor/lightweight animations and so on so they
understand pieces of the puzzle are being added or removed to
reflect their choice.
Alternatively, a second theory involves using three different activities, and saving state between the three, passing parameters between them... Perhaps I should abandon my initial idea and use something along those lines? A third alternative?
The primary motivation for doing this instead of just breaking it into three separate forms is it should allow for users to experience a consistent UI with minimal frustration if they choose to re-think their initial selection. Using the above, if a user fills out half of the form and decides they'd like to use an alternative option from the Spinner, their information is obviously retained, because they'd be using the same view objects.
I would like to ask you all for a little advice on how I can achieve this without risking too much of a performance decline on typical, mid-range Android devices (by that I mean handsets most users own, from Froyo up, and in particular those from Gingerbread up). I'm concerned because I only have access to one test device and it's a HTC One X handset, and that's obviously an extraordinarily poor choice for getting a handle on how capably most mortal devices can render more complex layouts.
I'd also appreciate any guidance regarding tips for optimising performance... I understand from scouring the community and Android's developer resources that rendering some layout objects is more exhaustive than rendering others, and I should opt for LinearLayout where possible (as opposed to RelativeLayout for example). Is there any definitive resource for comparing the performance of UI options? I'd very much like to spare you the time and effort, and go and acquire the knowledge myself.
Thanks in advance for the time and effort. Cheers.
Edit: I guess I should mention that if necessary, almost none of these views need to be drawn to the screen when the activity is initially loaded (the first time anyway)... If desired, I can initially load only a few views, and the Spinner widget. It'd be like loading 'No option selected' instead of Option 1, by default. The impact on the user may actually be minor if the device is sluggish because their device won't actually have to draw more than a mere handful of view objects when the activity is loaded. At any one point, the device is probably only required to render and subsequently display about 30 view objects at any one time. I guess the critical issue is, "Will the user experience a hang or a delay if their phone is struggling to load a lot of XML, even if it's not displaying it all when the activity is loaded?"
+1 for great effort on the question. My personal suggestion is that you stick with your second theory. Keep your data separate from the views -- store the entered values somewhere such as SharedPreferences or a database -- and have three different layouts (one for each form). On creating your Activity, check each common field for a previously stored value and populate that field if one exists. Trying to do something like the first list, while maybe clever, would hardly be ideal.
I think it would make more sense to just develop layouts for the different device screens. You can do this, and put different layouts in different folders. Here is a great article that talks about some of this. I wouldn't give people the "option" to choose. They may not always know the answer, so it is best to let the phone decide which layout to use.
Here is the article:
http://developer.android.com/guide/practices/screens_support.html
Related
I can't seem to find an answer for that. How many fragments can an app have, or how many xml layouts in general, before it starts getting cluttered and slow? All I found was that with too many nested layouts the activity itself performs worse.
Yes, theoretically it can. But it's not the number of fragments which can make an app slow, it's the way you use them. Even 2 fragments, if badly used, can make an app slow. On the other hand, tens of fragments could be handled fine. If your app instead needs 50, or 100 fragments, unless it's a really complex app and you're on top of it, then it's a good indicator that you're doing something wrong, either in the app flow, or the design. Android Studio provides you very good tools for profiling an app, use them, see where your bottlenecks are, and fix them. Measure the improvements before and after the fix.
No, there is no limit on making any number of fragments in Android app. And it does not harm any app if you make hundreds of fragments. But the way you are using those it DOES MATTER. As far as the matter of nested layout is concerned, yes it all depends upon your hierarchical level. Suitable approach should be used. Obviously not all layouts you will be showing in your activity. On depends or in certain conditions you will be using different nested layout. If this is the case then you can use fragment for dynamically update the UI or the Activity or Secondly you can dynamically add the views in your activity on demand. All at once if you are going to show complex nested layouts and those are in deep as well, this can cause sometimes some jerk or flick to load.To overcome this, You need to first think about weather it is necessary to load all the views else load on demand. Hope that helps you.
I have read the documentation and some other questions' threads about this topic and I don't really feel convinced; I don't see clearly the limits of use of this technique.
Fragments are now seen as a Best Practice; every Activity should be basically a support for one or more Fragments and not call a layout directly.
Fragments are created in order to:
allow the Activity to use many fragments, to change between them, to reuse these units... ==> the Fragment is totally dependent to the Context of an activity , so if I need something generic that I can reuse and handle in many Activities, I can create my own custom layouts or Views ... I will not care about this additional Complexity Developing Layer that fragments would add.
a better handling to different resolution ==> OK for tablets/phones in case of long process that we can show two (or more) fragments in the same Activity in Tablets, and one by one in phones. But why would I use fragments always ?
handling callbacks to navigate between Fragments (i.e: if the user is Logged-in I show a fragment else I show another fragment). ===> Just try to see how many bugs facebook SDK Log-in have because of this, to understand that it is really (?) ...
considering that an Android Application is based on Activities... Adding another life cycles in the Activity would be better to design an Application... I mean the modules, the scenarios, the data management and the connectivity would be better designed, in that way. ===> This is an answer of someone who's used to see the Android SDK and Android Framework with a Fragments vision. I don't think it's wrong, but I am not sure it will give good results... And it is really abstract...
====> Why would I complicate my life, coding more, in using them always? else, why is it a best practice if it's just a tool for some cases? what are these cases?
I am sorry if I wrote too much, and thanks for your time. I hope I will get your attention, because I really need ideas and experiences about this topic.
Best regards, Ahmed
You shouldn't always use fragments. Fragments have their uses, such as when you want to page in and out parts of the screen or when you want to drastically change the UI in different orientations. When they make sense, use them. When they don't, skip them. I find they make sense in maybe about 10-20% of apps- I rarely see the need.
If there's a certain positive aspect apart from the simpler reuse of logic through different layouts, it's the ability of Fragments to be kept alive by the system at orientation change, aka while an Activity is reconstructed from zero, a Fragment can retain its instance, and therefore using them is more stable than an Activity. Also, switching between Fragments is quicker.
Personally, if I don't need to mess around with different orientations and layout sizes, I still prefer using Fragments and a singular container Activity around it, for stability and seamless switching between the different screens.
Its quite a general question and not directly related to a specific programming problem. But in my opinion good software is based on good design and therefore a good understanding and best practices. So your question is a good one for stackoverflow.
So, what about fragments. It took me a while to understand why you could or even should use them. As #pskink said, you can easily live without them. But if you are planning to rollout your software on different devices, you should definately think about fragments.
The screen resolution and density is not the only problem. Think about a smartphone. The screen is much smaller, so you can not present your app the same way as you can on a tablet. For instance a master detail flow. Left side, a list of elements and when you click one element, you will see details of that element on the right side. Easy to do on a tablet. But on a smartphone you would put the master-view into one fragment and the detail-view into another one.
You got two options to realize that scenario. Either programm different activities for smartphone and tablet but because they are actually doing the same logic, it's better practice to put the logic into fragments and reuse those fragments in two layouts (phone/tablet).
Making an application for android i noticed that the layout view on eclipse is different from the application layout view on my phone when i run my application on the phone. Talking about the position of widgets including buttons, image view, custom views. The placement is different in the application layout view on eclipse from that on phone. I was thinking that this means it would variate on different models of the android phones on which the application would be run. How can i make my view generic in order to cater this issue so that the position of the widgets be same no matter where the application is being run? Is it possible to cater this issue?
As Henry suggested in the comment, this Android dev article should be able to make all your dreams come true.
http://developer.android.com/guide/practices/screens_support.html
Literary everything you could ever need to know about formating for different size screens is in that.
I did this to generate UI elements which fit on any phone and have abstraction what elements I want to show and how they will look like:
SimpleUi ( https://github.com/bitstars/SimpleUi )
The generated UI (code below):
The complete code to create this Android UI:
I use it in real applications, not only for fast prototyping or dialogs and its well tested over the years. The concept is based on the model view control principle and for most common scenarios there are ready to use components which automatically look correct on any device. I don't say it should be used for any UI (e.g. listviews should be done by hand) but for most usecases this should be quite handy ;) Oh and feel free to fork it and improve it further if you want
I have android application that is written "regular" way. layouts, java, APK.
Now, depending on some factors I want data to be presented differently to different users with different preferences, etc. Doing it using XML layouts will be very problematic in couple of reasons:
Upgrade issue - we have bunch of users and they not good at upgrading.
Hard to maintain and code.
So, I'm toying with idea of "templates" where we can serve templates from server and just use device to generate those.
Web app won't work because our data available offline in case there is no connection.
There is buttons and stuff that user can press to call regular Activities and do things.
I envision something like:
HTML 5 template with {tags} that I will populate from data. I will receive tempaltes and data separately from server. I will merge that data and display on UI.
Now my question is how do I:
Display HTML5 inside Activity
Intercept button push in HTML in my Java code?
Is this bad idea to write something like this?
It sounds reasonable to me. You can use a WebView for displaying the content. Your app can manage a cache of downloaded templates and other content and display it in the web view either from the web site or from the cache if offline.
I think your objections to layouts are offbase. You really might be better off with layouts. Here's why:
Your app can be set to auto-update by users if you do not change permissions. But pushing updates to your app will remain an issue unless your app is entirely web-based. (not a bad approach by the way) But so long as you have a native app, you will need to push updates from time to time.
And as far as being hard to maintain and code, layouts are specifically designed to make this type of customization manageable. You can break pieces of the layout common to different settings into separate files, and add them with includes.
You can use fragments to adapt to a variety of form factors.
You can serve up different layout based on screen size, language, orientation, or any of a wide variety of variables.
Check out some of the series on layout tricks, and get more familiar with being a layout power user. I think in the long run it will save you a lot of effort, assuming you don't switch to making your app a web app instead.
http://android-developers.blogspot.com/2009/02/android-layout-tricks-2-reusing-layouts.html
http://developer.android.com/resources/articles/layout-tricks-merge.html
http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html
http://www.curious-creature.org/2009/03/16/android-layout-tricks-4-optimize-part-2/
Google: Android Layout Tricks.
Great stuff.
Another benefit: Compiler checking. No broken functionality because a variable or field has the wrong name. Not the case with HTML.
Another benefit: works offline too with no messing around.
And last - you will have a non-trivial amount of work attempting to get this hybrid HTML stuff working the way you want, and then have a very unusual and custom code base that nobody here on Stack Overflow will be able to help you with. Stick with Layouts and there are lots of experts who can help you tackle the stickiest layout puzzles.
I'm working on an app that involves displaying comments from a website. These comments are threaded on the original site, so I'd like to replicate that experience within the app. I know that Android has an ExpandableListView, but it only does two levels and I was hoping for more.
Each top-level content would be aligned to the left. Replies would be indented by x units, replies to the reply would be indented x*2 units, etc.
Additionally, I'd like the ability for the user (or even the application code) to minimize/maximize threads. This would be particularly useful if the first comment has 8724 replies - you could just minimize the original comment instead of scrolling endlessly until you reach the second top-level comment.
What is the best way to present this multi-level list to the user? Are there any native/third-party classes/libraries I can use, or would I be better of coding this list in HTML and displaying that to the user instead?
I don't really think you should use a tree for displaying thread. Device screens are too small for this kind of widget. I would prefer multiple activities for displaying different levels of the thread. But I'm not a UI designer so my opinion may be far from the ideal solution.
EDIT: Here's an open-source tree-view widget: http://code.google.com/p/tree-view-list-android/.