Two ListFragments in One Activity - android-listfragment

Since each ListView is required to have android:id="android:id/list"... how can i make two listviews on two different fragments? .. the OnItemSelectListener seems to listen to events of the other fragment ... plz help

I have the exact same situation... so far, my guess is that this is not possible since the app only takes into account the first ListView created (because android:id="android:id/list" must be unique in app scope) documentation does not state how to have a custom id, therefore my guess is on this case, ListFragment can't be used.

Related

One page, multiple contexts ? Is that possible?

Here is my problem: I have an app that has 2 list view.builders. You can imagine the scenario.
within the Stateful widget, we have:
Widget build(ct)
{
and this returns a column widget that has TWO list views.
The problem I have is that one list view changes (or should change) the items in another list view.
So what are my options? To create two Widget build(ct1) and Widget build(ct2)??
Do we do that? How can I communicate changes to ct1?
Oh my goodness, I've tried a lot, even setState etc... nothing works.. Perhaps could someone tell me how I can invoke the page to be refreshed?? That would work.
I keep on finding the answers myself - but for anyone who has this issue, Flutter apparently has evolved... if you are using the latest version, I really believe that SetState() function should work for you.. you just need to use it in the right place.

A better architecture than passing callback functions to children Widgets

I'm building my first Flutter app, in which I need to refresh a list of data, and every component has some modifiers.
This is the basic architecture.
A big list of data (about 5000 rows) is periodically refreshed from an API inside a RefresherWidget (which is a StatefulWidget that holds the list), and then passed along to the children.
Every RowWidget has a Switch (and Dialogs too) that modifies the data it represents.
Currently, the methods to modify the list are in the RefresherWidget, so I'm passing them as callback functions inside every children until reaching the onChanged callback of the Switch.
But I don't think it's a very clean solution, and I don't know how to implement a better one: I've tried thinking about passing these methods inside an InheritedWidget that stays between RefresherWidget and ListViewWidget, and referencing them using the of function, but I don't know about the perfomance hit I would get if the InheritedWidget gets rebuild.
Also, Streams and BLoCs seem very complicated for what I need to do.
How do you guys usually approach a problem like this?
This is definitely a situation for InheritedWidget or BuildContext in general.
I've tried [...] InheritedWidget [...] but I don't know about the perfomance hit I would get if the InheritedWidget gets rebuild.
You don't have to fear anything. InheritedWidget is built for this exact purpose.
Obtaining the InheritedWidget is very performant (O(1)). And only widgets that depends on the value gets rebuilt – which is optimal too.

Robotium : Is there a way to check for an activity to NOT exist?

I'm automating an app that shows some overlay messages anywhere on the app for several scenarios, such as app installed for the first time etc. (I'm fairly new to Robotium too.)
The overlay displays a text that goes away by swiping or clicking on it. Also, there are different types of these overlays with different unique text on it. (let's call it Activity A)
I wanted to create a robust test case that handles this case gracefully. From the test's perspective we won't know that the activity A will be present all the time. But I want to recover from the scenario if it does, by writing a method that I can call any time. Currently, the tearDown method gets called since my expected activity name doesn't match.
Also, even if the activity A exists, there are other predefined overlay texts too. So, if I use solo.waitForText("abc") to check for text "abc", I may see the overlay 2 with the text "pqr" instead.
So I was looking for a way to automate this, and I can't use solo.assertCurrentActivity() or solo.waitForActivity methods as they just stop the execution after the first failure.
So any guidance is appreciated!
All the waitFor methods return a boolean. So you can use waitForActivity() exactly as you want to. If the Activity doesn't exist it will return false.
You can check which Activity is current:
Activity current = solo.getCurrentActivity();

Order of evaluation with relative layouts, best practices and parsing of relative-layout

I read this
"
It used to be that Android would use a single pass to process
RelativeLayout-defined rules. That meant you could not reference a widget
(e.g., via android:layout_above) until it had been declared in the XML. This
made defining some layouts a bit complicated. Starting in Android 1.6,
Android uses two passes to process the rules, so you can now safely have
forward references to as-yet-undefined widgets.
"
I do not know what is the problem maybe is eclipse problem, but even I use 2.3 I still have problems when I reference some view that is not declared jet so for me it seems like android doesn't uses two passes to process the rules for relative layout.
note: I always use #+id/widget_name when I declare the widget and #id/widget_name when I reference that widget from other widget. I have noticed that I can use #+id/widget_name even when I just want to reference that widget. I guess that is wrong but why sometimes is works without any complaints ? In my opinion one widget should be allowed to be declared only ones...
My questions is is really android uses two passes ? and I need some guidelines (best practices) for working with relative layouts
I am little confused about how this relative layout parings are made, so any explanations are welcomed
Thanks
#+id/name creates a new id, if it doesn't already exist. #id/name references an existing id, and will never create one.
I'm not sure if you can use #id/name before #+id/name in the same file. If not, I can think of two workarounds:
Always use #+id/name.
Define all id's in the ids.xml file, and always use #id/name.
This is general information on how Android draw views.
I think that Android passes twice through all the view, but it doesn't pass through each single view once. So if you have a reference from one xml to another it will always work fine, but if you have references inside a single xml you must be carefull to order the elements in the xml correctly. For example, I have view1 and view2 in my RelativeLayout. If I want to refer to view2 from view1 I must declare view2 before view1.

Creating reusable widgets

I`m using asp.net mvc 2.0 and trying to create reusable web site parts, that can be added at any page dynamically.
The problem I have is how to load a partial view with all related js and data? Ive tried the following ways to do that:
Use partial view and put all the js into it. In main view use render partial. But to initialize partial view I need to add model to current action method model to be able to make RenderPartial("MyPartialView", Model.PartialViewModel).
Also I do not have a place to put additional data I need to fill my form(like drop down lists values, some predefined values etc).
Use RenderAction, but it seems it have same problems as RenderPartial, except for I do not need to add anything to any other model.
Any other oprions are greatly appreciated.
As I understand it, RenderAction performs the full pipeline on the action, then renders the result - so what is rendered is the same as what you'd see if you'd browsed to the action.
I've used RenderAction to render 'widgets' throughout a site, but in my view they should be independent of the page rendering them, otherwise they're not really widgets and should be part of the rendering page's code instead. For instance, if there's a log in form, you will always take the user to a page that can process the information, no matter what page they are currently on, so this makes for a good widget. Other ways I've used it is to show a shopping basket or advertising. Neither of which are dependent on the page being shown.
Hope this helps a little!