When adding a "settings" screen to my app I seem to have come up with two choices:
use the PreferenceActivity that is given by Android
create a standard Activity that saves all the user's choices
Assuming I don't mind writing the code that saves the preferences (a relatively trivial task), what other advantages are there to using a PreferenceActivity? If anything, using a standard Activity provides much more flexibility with regards to UI design.
You are right, given the desired view complexity (which sometimes is not more usable - remember preferences should be easy to set), it might not make sense to implement a PreferenceActivity. The idea is to present a uniform configuration screen & visual style to the user. As such, a user will always know when he entered a preference screen.
From the docs:
Furthermore, the preferences shown will follow the visual style of system
preferences. It is easy to create a hierarchy of preferences (that can be
shown on multiple screens) via XML. For these reasons, it is recommended
to use this activity (as a superclass) to deal with preferences in applications.
The docs say something about inflated views, maybe you could investigate whether complex layouts or custom views can be integrated.
Related
I'm currently working on an Android app, and looking at the PreferenceActivity class and the corresponding layout elements (PreferenceScreen, etc.), it appears that it provides much of the functionality that I desire for a major component of the app. However, that component is not a Settings activity per se, and I'm not sure if using Preference stuff for things that aren't technically preferences is a good way to do things. On the other hand, I'd prefer not having to implement all the features that PreferenceActivity/etc. provides, so would it be fine to use that framework and just change the layout theme so it doesn't seem like a Settings menu?
You can definitely load/set up the preference layout using the android framework and then save the data using your own implementation of SharedPreferences. This class is a good example. Not sure why you would not make it look like a preference screen though. What's wrong with that look?
I'm relatively new to Android, and I'm trying to port an app from iOS, which does something slightly unconventional.
My app has an in-house xml language for representing GUI (kind of our own nib/xib in iOS or res/layout/whatever.xml in android, believe me, we had no choice), and an inflation mechanism that inflates this xml and builds a view controller and view instances.
As a result, in iOS, my app had several live UIViewController instances of the same class (added and removed from the navigation stack as necessary) which were all inflated once (from different XMLs) and remained alive as long as the app was.
Now, I'm a bit unsure about the correct way to do this in Android. Ideally, I would like to be able to create instances of an Activity class, each with its views inflated from our xml language, and do the navigation between then. However, to my understanding this is not possible in Android (since activities are started by intents, and created by class).
Is it true that I would not be able to keep activities alive and at the same time - not on stack (i.e. "back" always kills activities)?
If so, does this mean I need to inflate the activities and all their views from xml, every time I navigate "forward" (serious performance issue), or is there an alternative?
Is it reasonable to at least save the parsed xml structure in an Application subclass, so the inflation will be faster?
Would it make sense to only send (on creation) and save (for persistency) an activity identifier to the new activity instance, and have it go to my Application subclass, and inflate itself / get its state by identifier?
In general, assuming having the GUI inflated from XML is a must, and I would like to minimize the need to re-inflate the GUI, what would you suggest as the cleanest solution?
Any other tips will be greatly appreciated… Thanks!
I am not 100% sure I understand your situation - I think what you are saying is that you've got custom XML that defines your layouts and controllers. I am going to answer based on that, correct me if I'm wrong.
First, your questions show an understanding of the problems you face if you go down your current path. I'm not going to answer them individually because I think there's a better solution - use Fragments via the compatibility package.
The way Fragments work is that you have a single Activity, then a series of Fragments inside of it that define the UI. For phones, this ends up looking the same as an Activity-based application. But in your case, it will provide a few bonuses:
Fragments can be created dynamically in code.
Fragments can be popped off the stack, but kept in memory so you can re-add them later.
You can store all of your pre-parsed XML in a retained, invisible Fragment instance (instead of the global Application subclass).
This isn't to say there are no problems with Fragments - there may be limitations there as well (I've only recently started working with them). But I would give them a look to see if they might solve your problem.
Another alternative would be to write a transformation (pre-processed) between your in-house XML and Android's XML. Android's XML View creation is pretty fast because it's optimized for it.
I am starting to develop an application for Android and was wondering what the common application design/structure looks like.
In iOS, I would generally start with a RootController which contains a UITabBarController and fill this with 4-5 UINavigationControllers. Each UINavigationController would contain its stack with UIViewControllers.
What would a similar application look like for Android?
Start reading here. The basic building block is an Activity, you setup your UI, display data and respond to events in your Activity classes. Screen navigation is handled by starting other activities using intents.
I lay out my activities and my activity xml files. Then I code in the components that are needed in the activity classes. Then I set up preferences and my submenu etc. From there I do my support classes and glue it all together.
Egil.. The Android way is significantly different from the iOS way in that it is more like a web interface.
First: "Activities" or UIs can be killed at any time. In fact, rotating the phone can kill an activity. So that each Activity needs to be able to save its state in onSaveInstanceState and restore state in onResume. Furthermore, "shared document like data" is written in onPause() and restored in onResume(). The closest analogy in iOS is saving state on low memory warning.
Second: Activities are relatively independent of each other so that state needs to be passed between Activities (UIs) using intents or saved globally using say Application state.
It is possible to quickly move an iOS TabBar to Android using Androids Options menu, but there is no built in hierarchy of views like UINavigationController.
I have a table comparing and contrasting iOS and Android here.
Take a look at Android Design in Action, they have great video lessons on how to design Android apps!
Most apps have some kind of preferences or user settings that can be stored via the SharedPreferences. My first implementation of an activity for the user to edit his settings was pretty straight forward: a couple of input fields and a 'Save' Button. This is neither pretty nor easily extensible.
The android system settings and many apps that I have seen tend to layout their preference editing in ListViews.
My second approach tries to imitate this: a ListActivity and every item has to supply it's own layout, since I want to store different types of values (some are numbers, some are boolean radio buttons).
I am finding it rather cumbersome to implement this and now I am wondering if I am missing some obvious design pattern here?
Just use PreferenceActivity, it will build the UI and handle the preferences persistence for you. Here you have more documentation:
http://developer.android.com/reference/android/preference/PreferenceScreen.html
http://jetpad.org/2011/01/creating-a-preference-activity-in-android/
http://www.kaloer.com/android-preferences
I am creating an android application that has a lot of different screens where the user can navigate to those screens using the buttons or list provided in those screens. What would be the best way to design the entire app's navigation flow? Should I map each screen to be View or an Activity? Can an design an entire android app with just one activity and many views, where each view represents one screen with many other UI elements (buttons, lists, images etc)
I suggest you use for every "screen" that is significantly different from another screen (in both look and data that it is related to) a new activity. This gives you easier control and you don't have to mess up your code with plenty of variables to define different states. Using different activites you usually shouldn't have to worry about running in a undesirable or even undefined state.
To exchange data between activities you can use putExtra() to add "simple" data to an INTENT or for more complex data you can extend Application and use that instance as a singleton, which you then can access via (MyApplication)getApplication();
You really want to stay away from the single activity idea. That's actually an anti-pattern from the java model 1 web application days called "The magic servlet". I guess here it would be called "The magic activity". Each logical "screen" that the user interacts with should be an instance of the Activity class.
Modifying individual user interface elements based on user interaction is fine as long as it's just one or two elements, or just a portion of the screen, but for the most part you should be looking for reasons to split things out into their own activities, not looking for reasons to keep things together. In the long run it will make your code easier to maintain and understand.