I would like to display a tree without using the tree component, since I don't know how many levels there will be.
I though about a list, that opens another list on item click, and so on...
Is it correct to open a new activity for each level?
Will it not overcharge the system?
Or is it preferable to have only one list that I clear and refill with children?
How the standard back button will behave on both case?
I would have open a new activity for each level. Unless your tree is extremely deep, it will save you time handling back's button correct behavior by hand if you do it with only one activity.
Related
New to Android. Trying to understand the technical downside of a design.
I have an ItemSelectorView which has both an availableItems collection as well as a selectedItem property. The latter is displayed at runtime along with a chevron letting the user know they can change it.
Functionality-wise, it's similar to a spinner except rather than showing a pop-up with the choices, it launches a second activity called ItemSelectorActivity which shows all of the available items from the ItemSelectorView which launched it, as well as helpful information about what each option means as well as the ability to search and filter.
When a user selects one, their choice is then returned back to the originating ItemSelectorView via a trip through MainActivity's onActivityResult override. The override then figures out which ItemSelectorView it's responding to and forwards it along.
However, I really didn't like the way MainActivity had to insert itself into the process just to get the result from ItemSelectorActivity. Plus, if ItemSelectorView was used in a fragment, things become more complex trying to forward the information to the correct view.
Because of this, I instead changed ItemSelectorView to ItemSelectorFragment which can override its own onActivityResult making it, not its owning activity, responsible for updating itself with the selected result. This means it's essentially completely self-contained now.
While this seems to work wonderfully--with this change a user only needs to place the ItemSelectorFragment somewhere in their layout and set the available and selected items--a veteran Android developer here said using a fragment like that was wrong and I should have stayed with a view because of the overhead of fragments.
But going back to a view means I'm back to having to get MainActivity involved again, making this much more complex to actually use.
So what is the technical down-side for using fragments like this? I thought that was the entire point of why they exist. And if I am supposed to use a view, is there an easier way to get a result from ItemSelectorActivity?
If I understand you correctly, your view is starting an activity (ItemSelectorView starts ItemSelectorActivity). But views should be dump in Android. They should display, nothing more.
So a view should never start an activity. A view can contain a list of items maybe, but these items should be views and nothing else. Usually we use an Adapter for that: a middle man between the items to be displayed and the views that are created to represent them on the screen.
You could look into MVP to do this in a proper way. Or maybe MVVM and android architecture, if you like that better.
To answer your question, using a fragment for your use case is a better approach then a view and there is not that much overhead at all.
I have to implement a tree browser in Android. For this particular case, the tree will be a folders hierarchy. So the user will start in a root directory, and will be able to browse the whole hierarchy.
I have experience in iOS development, and this could be done using a UINavigationController, pushing a new controller each time the user taps a folder, but I am not sure if using the same strategy in Android is the right thing to do.
My first idea is to have a FolderViewActivity, create the first one with the root path, and every time the user taps a folder, create a new one with the new path. So you have a stack of activities, and if the user wants to go up, the current activity will be finished and the previous one will be shown.
Is this the right approach? Could be any problems with the back button doing this?
I have seen a few projects in github implementing a file browser, and it seems that everybody tries to reuse a single activity for doing everything, updating an adapter with new data when the user taps a folder. For me this is a poor implementation, unless there is a good reason for doing it (something Android specific?)
In Android you should use as less activities as you can. Activity is quite expensive object and it should be instantiate only if you need specific context with some different settings (orientation, action bar) or if you want to do some new things (for example, editing file content or displaying settings).
When you navigate through file tree you actually do the same action every time: show directory content with some path. For this routine you should use such lightweight and reusable objects as Fragments (http://developer.android.com/guide/components/fragments.html).
The benefits of such approach are: less memory, less expensive calls (create or destroy activity), more fast, more flexible, you can handle back button press as you like.
So you should not create a stack of activities, you should create one activity and then replace fragments for every new folder.
I'm doing the same using a recyclerview. No need for fragments or activities. Firs load the root, after a click you need to update the adapter of the recycler view with the new child objects. You can keep a navigation stack in order to have a navigation back strategie.
I have seen a few questions raised on this topic (for e.g.: https://github.com/jfeinstein10/SlidingMenu/issues/5) but I am still unclear. I hope somebody can clarify this.
Context:
See https://github.com/jfeinstein10/SlidingMenu
I have an android app that organizes screens by activities and fragments (i.e.) each screen is an activity containing one or more fragments.
The new requirement is to add a sliding menu (similar to what this library provides).
Issue:
It appears from the examples and discussion that the right model would be to have just 1 MAIN ACTIVITY that will then switch in/out fragments belonging to the different screens. In fact the author mentions in the above thread: "If you were to launch Activities based upon the list selection, then you would not have the behavior where you swap the views that you're talking about. " and also "You can't put an Activity into the above view. That doesn't really make sense when you think about what an Activity is. ".
Why doesn't it make sense? Obviously, I am missing the point here.
Question:
Given that my project already contains multiple activities (one corresponding to each screen), is my only option then to re-organize the project to have JUST 1 MAIN ACTIVITY, in order to use this library? Or alternatively, is there any way to launch a new activity when a list item in the sliding menu is clicked, and still observe the sliding menu behavior, [EDIT- added the last part to be more clear] or in other words, on how exactly to use this library within my existing app design.
Thanks in advance
First, you can't have an Activity inside another and activities are completely different from views as stated in the docs:
An activity is a single, focused thing that the user can do.
Now, to answer your question, it all depends on how you want your app to behave. You could have your activities with the sliding menu implement the onClosedListener and switch to the selected activity from there. This will give you the animation of closing the menu before switching activities. It will also give you a weird effect since every time you select something from your menu you'll see the animation of a new activity coming to the front.
I think the best approach would be to have a "common purpose" between all your sliding menu options. For example, in one of my projects I have to allow the users to select between lists of different types of data. When the user selects anything from the menu, I load a new list fragment into the right corner where he may choose the item he wants to view or edit. That's the app entry point and also the only place were I have a sliding menu in my app. It is pretty much the same for every app that implements this UI design pattern. Look at google+, currents and youtube where the side menu lets you choose which feed or content to show. Once a user makes a selection, just open a new activity for the selected item (a g+ post, a video, a news article, a tweet or whatever it is).
Your app doesn't have to have lists of different data or anything like that to use the sliding menu, but keep in mind that the activity with the sliding menu should have a clear, focused goal with respect to its functionality and purpose. Having a sliding menu because many other apps have one is a bad choice, you should use it with a specific objective. Also keep in mind that applying the sliding menu everywhere would interfere with the platform's navigation pattern and lead to an overall bad user experience since it wouldn't behave as the other apps.
It doesn't make sense to place an Activity into the above view because the Activity is the main controller for the view of each screen. The Activity also shows views and keeps track of Fragments (which in turn are mini controllers, with or without their own views). So placing an Activity in the above view would mean that you would place an Activity in an Activity... Wich is impossible.
From what I can derive from your text I think it would be wise to read through the Android developer guide on Activities and Fragment again (http://developer.android.com/guide/components/activities.html) to get a better understanding of how the concept of Android works.
Now to your question:
I am not clear on what you are trying to achieve but if you want your app, with menu to behave like, say, the Google+ app then one way of doing it is to implement a base class that extends the Activity class (or what ever base Activity used in your project) and let the base set the SlidingMenu. Then you would simple extend your base Activity in each of the Activities that are supposed to have a menu.
You could also do it the way you describe it, but then you would end up with a classic example of a God object (http://en.wikipedia.org/wiki/God_object). It's a neat way to practice your Fragment juggling skills and switching between Fragments instead of starting new Activities does have it's use cases, but I still wouldn't recommend it for a project with more then a few views.
Here is the answer that came closest to the issue I had - http://www.verious.com/article/polishing-the-sliding-app-menu/. Scroll down to the bottom of the page to see the last section titled "Using the fly-in app menu between Activities". This is one option if you have a lot of activities in your existing app and want to avoid extensive re-factoring. I haven't tried this out yet but its worth being aware of.
I just want to ask what is efficient way of use activity. Mean use one activity for multiple functionality or use multiple activity for every functionality.
In my application working some thing like Category->subcategory->Product listing. In which orientation change design and also need to consume previous functionality state for Back.
Thanks
Per the documentation for Activities, "An activity is a single, focused thing that the user can do". In other words, each different screen of your application should be an activity.
The only time you should have an Activity represent more than one screen is if it's a recursive action like a file browser; i.e. something that just changes the data that is displayed, but is displayed the same way.
It's quite common to create one Activity for every logical "screen" of your application, but to share the same Activity for multiple "states" (eg. dialog boxes, different modes) of that screen.
The back button will automatically go backwards through Activities (by default) and you can override the back button within an activity to revert to a previous state within the same activity (ie. hiding a panel)
Basically, Activity, in case of Android, is not a synonym for functionality. It is synonym for screen UI. Thus, how you implement your functionality is your choice. You just need to consider the following tips:
If you use the same activity for categories and subcategories (using
List elements), then you need time for deleting items for categories
(plus, GC also takes time), populating the list with the values for
subcategories. The weak points here that the user cannot return to
the previous Activity using back button (this violates the default
flow for user interactions), the screens are identical for
categories and subcategories (this can mess the user), it will takes
a long time for deleting unnecessary elements and populating with
new elements. Strong point: you will reduce memory consumption for
your application.
The second option is to use different activities. Weak points: it
also takes time to initialize new activity and to populate the list
with the values of subcategories, it will take more memory to store
two activities. Strong point: clear user understanding, more
responsibility to user's actions (you do not need to run GC to
delete unnecessary objects).
As for me the second approach is better unless you are not restricted with the memory.
I just want to ask what is efficient way of use activity. Mean use one activity for multiple functionality or use multiple activity for every functionality.
In my application working some thing like Category->subcategory->Product listing. In which orientation change design and also need to consume previous functionality state for Back.
Thanks
Per the documentation for Activities, "An activity is a single, focused thing that the user can do". In other words, each different screen of your application should be an activity.
The only time you should have an Activity represent more than one screen is if it's a recursive action like a file browser; i.e. something that just changes the data that is displayed, but is displayed the same way.
It's quite common to create one Activity for every logical "screen" of your application, but to share the same Activity for multiple "states" (eg. dialog boxes, different modes) of that screen.
The back button will automatically go backwards through Activities (by default) and you can override the back button within an activity to revert to a previous state within the same activity (ie. hiding a panel)
Basically, Activity, in case of Android, is not a synonym for functionality. It is synonym for screen UI. Thus, how you implement your functionality is your choice. You just need to consider the following tips:
If you use the same activity for categories and subcategories (using
List elements), then you need time for deleting items for categories
(plus, GC also takes time), populating the list with the values for
subcategories. The weak points here that the user cannot return to
the previous Activity using back button (this violates the default
flow for user interactions), the screens are identical for
categories and subcategories (this can mess the user), it will takes
a long time for deleting unnecessary elements and populating with
new elements. Strong point: you will reduce memory consumption for
your application.
The second option is to use different activities. Weak points: it
also takes time to initialize new activity and to populate the list
with the values of subcategories, it will take more memory to store
two activities. Strong point: clear user understanding, more
responsibility to user's actions (you do not need to run GC to
delete unnecessary objects).
As for me the second approach is better unless you are not restricted with the memory.