Populating Listview....

by furby » Tue, 08 Sep 2009 09:45:25 GMT


Sponsored Links
 I am probably being stupid here because I am a beginner in Android
development... But could somebody explain the step by step process of
dynamically populating a listview? I have found a few pages that do it
by reams and reams of code, but that seems kind of silly to me - I
think I must be missing the use of that since I am just looking for a
method that essentially says "Append an element to the list"....

--~--~---------~--~----~------------~-------~--~----~



Populating Listview....

by Mark Murphy » Tue, 08 Sep 2009 10:03:29 GMT


 


If you are using an ArrayAdapter on an ArrayList, call add() on the
ArrayAdapter.

-- 
Mark Murphy (a Commons Guy)
 http://commonsware.com  |  http://twitter.com/commonsguy 

Android Development Wiki:  http://wiki.andmob.org 

--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


Other Threads

1. No surfaceCreated() callback after phone wakes up

This sounds very similar to a problem I saw previously also regarding
SurfaceHolder callbacks not arriving properly. My experience was the
opposite where I wasn't getting the callback upon the press of the
END_CALL button. I filed a bug about 2 months ago that is here give a
star and perhaps add your observations as while different than mine
they are related and the only trouble spot I have regarding providing
a seamless GL experience on Android.

http://code.google.com/p/android/issues/detail?id=4125

Regards,
--Mike




-- 

2. Android unnecessarily hard to unit test?

Hi guys,

First: thanks for a great platform in Android. Being able to write
Android apps in regular Java is a huge win.

However, I am confused about unit testing Android apps. Many of the
'best practices' seem to boil down to 'split your business logic off,
and test it separately using JUnit'. This is great as far as it goes.
And I understand that truly testing the UI will require firing up the
emulator.

But it seems there is a category of UI tests that I should be able to
run without the emulator. The various Mockxxx classes seem to be going
a long way towards this. But why (oh why oh why!) do they all...

    throw new RuntimeException( "Stub!" );

...in their constructors? I can understand them doing this in their
METHODS (then I could subclass them as needed) but why their
constructors? I cannot stop this functionality so I cannot do (limited
but useful) UI tests such as...

public TextView createTextView( Context context )
{
   return new TextView( context );
}

public void testCreateTextView()
{
   MockContext context = new MockContext();
   assertTrue( createTextView( mockContext ) instanceof TextView );
}

...which I would dearly love to be able to do!

Regards,

Richard.



--~--~---------~--~----~------------~-------~--~----~

3. Reg: PHone panics on mentioning X and Y value in Bitmap.createBitmap method

4. Rom2 android

5. Multiple Choice ListView with icons

6. Error in function driver configuration

7. line discipline for connectivity combo chips