Adapting to Data. Before we get to the fun stuff... Initial setup

Transcription

1 Adapting to Data So far, we've mostly been sticking with a recurring theme: visual elements are tied to XML-defined resources, not programmatic creation or management. But that won't always be the case. See, thus far, what's also been true is that we've already had everything we needed clearly identified, and ready in advance. However, that won't always be the case. Whether the data we want is available on the other end of some network resource; or in an unmanaged assets folder that could be updated; or on an SD card; or even something ostensibly readily available, but too bulky to immediately load in; we will sometimes need to deal with things from the programmatic side. Some of this, we'll be addressing later. But we can cover the general cases now. Before we get to the fun stuff... Let's first address a basic issue that we've already hinted at: needing to retrieve or process a resource that can't be immediately loaded. There are two (closely-related) aspects to this: 1. Simply retrieving the data could cause a delay 2. When users aren't permitted to operate their applications/devices, you should probably let them know it's normal, and not indefinite Properly addressing the former issue comes later, but we can at least look at the latter right away. Basically, we need some sort of widget that can indicate that progress is being made. Initial setup Before we get any further, let's create a project with an empty activity, and just put down a progress bar. We won't worry about attaching it to anything yet. <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android=" android:layout_height="match_parent" android:orientation="vertical" > <ProgressBar android:id="@+id/progressive" style="@android:style/widget.progressbar.horizontal" android:progress="0" android:max="100" </LinearLayout>

2 There are a few things worth noting here: Setting the current progress to 0, and the max to 100, did absolutely nothing. Those are the defaults There are other progress bar styles. For example, try temporarily switching over to Large. We'll be sticking with Horizontal for this example, though There are two possible natures of progress bars: determinate (what we're using), and indeterminate Setting the android:indeterminate option to true makes it less about showing absolute progress, and more as an indication of activity. Personally, I'm partial to progress bars showing progress, so I'll stick to determinate For our initial test, add three buttons, and give them all the same onclick handler. I'll call mine buttona, buttonb, and buttonc. Let's switch over to the code to see how they can work. Since we're using a single method to handle all three, I'll just use a switch statement on their ID's: public void clickit(view v) { ProgressBar pb=(progressbar)findviewbyid(r.id.progressive); switch (v.getid()) { case R.id.buttonA: pb.setprogress(33); break; case R.id.buttonB: pb.setprogress(66); break; case R.id.buttonC: pb.incrementprogressby(1); break; Note that you can either set absolute progress values, or simply state the change. If we were using API 24 or higher, we could also specify whether or not we wanted the progress bar to animate when changing. Interjection: Here's a thought, suppose we added an extra line to the third button: pb.incrementsecondaryprogressby(2); What would we expect as the outcome? What the heck is a secondary progress? (For those following along via this script, instead of in-lecture, I'll include the answer on the next page. Just pause to think about it for a moment, though, k?)

3 Secondary progress simply allows you to show the progress of a second value, along the same scale as the original. The most common place you've seen one is for videos on the web (wherein you have your primary progress: where you are in the video, and a secondary progress: how much more of the video is already buffered). You can read more here: So, why aren't we using this for real yet? Let's explore that! Let's say we had a source of data: package ca.brocku.efoxwell.a2017_fourthstage; //your package name here! public class DataSource { static int counter=0; static byte[] getbytes() { int qty=(int)(math.random()*(100-counter)/2.0+1); byte[] datas=new byte[qty]; for (int i=0;i<qty;i++) datas[i]=(byte)(++counter); //try {Thread.sleep(1000); catch (InterruptedException ie) { return datas; And let's rewrite the third button thusly: case R.id.buttonC: int count=100; while (count>0) for (byte b:datasource.getbytes()) pb.setprogress(100-count--); break; Aaand... it probably works just fine, right? Oh, silly me, I forgot to uncomment that delay (to simulate latency in receiving or processing data). This time, it may or may not have reported an ANR error, but it certainly didn't work correctly, right? There are ways it can be made to work, but the best approach is to create an Asynchronous Task to handle the heavy lifting in the background, possibly provide status updates as it makes progress, and report back in once it's done. (And that comes later) So, next, let's look at something that doesn't require using generics with triple-parametrized types, yes?

4 ListViews Last lecture, we looked at how we can include data in arrays. We could very easily access that data from our code. If desired, we can also access that directly in our XML layouts. Let's make a new activity (LVA), and rewrite the first button to start it. Or add another button; I'm not the boss of you. First, we need an array resource: <string-array name="mayneverdie"> <item>tinfoil</item> <item>airhorns</item> <item>every chicken</item> <item>in this</item> <item>room</item> <item>hype</item> <item>100% confirmed</item> </string-array> and then we need a layout: <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android=" xmlns:app=" xmlns:tools=" android:layout_height="match_parent" tools:context="ca.brocku.efoxwell.a2017_fourthstage.lva" android:orientation="vertical"> <ListView android:id="@+id/bowl" android:entries="@array/mayneverdie" android:drawselectorontop="false" <TextView android:id="@+id/selectedb" </LinearLayout>

5 So far, so good. We don't need much code to support this: protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_lva); final String[] bowlarray=getresources().getstringarray(r.array.mayneverdie); final TextView selectedb=(textview)findviewbyid(r.id.selectedb); ListView cbowl=(listview)findviewbyid(r.id.bowl); cbowl.setonitemclicklistener(new AdapterView.OnItemClickListener() { public void onitemclick(adapterview<?> parent, View v, int position, long id) { selectedb.settext(":> "+bowlarray[position]); ); Try it out, and you'll see that it works pretty much as you'd expect. In case it isn't clear, even though the usage isn't really any harder, what it's doing is a bit more complicated. Basically, our list of text entries is a container View, holding several individual Views. We use an adapter to help us with the autogeneration of those Views. Do we want to chat about the 'drawselectorontop' stuff? Let me know if we do. This isn't what you promised This is true. I promised we'd look at data that isn't already within the resources. But switching over to some other form of array-based data will be a very tiny hop. This time, we'll be explicitly invoking an ArrayAdapter to generate our Views for us. I'll make another activity (LVAB), and set the second button on the first screen to start it. The layout isn't terribly remarkable: <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android=" xmlns:app=" xmlns:tools=" android:layout_height="match_parent" tools:context="ca.brocku.efoxwell.a2017_fourthstage.lvab" android:orientation="vertical"> <ListView android:id="@+id/fruits" android:drawselectorontop="false" <TextView

6 </LinearLayout> The Java code also hasn't changed much: protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_lvab); final String[] fruits={"spinach","aubergine","a rock","tomato","kale"; final TextView selectedf=(textview)findviewbyid(r.id.selectedf); ListView flist=(listview)findviewbyid(r.id.fruits); final ArrayAdapter<String> adapter=new ArrayAdapter<>( this, android.r.layout.simple_list_item_1, fruits ); flist.setadapter(adapter); flist.setonitemclicklistener(new AdapterView.OnItemClickListener() { public void onitemclick(adapterview<?> adapterview, View view, int i, long l) { selectedf.settext(":> "+fruits[i]); ); Most of this is fairly straightforward, but there's one thing that might be confusing: android.r.layout.simple_list_item_1. Remember the two points we've already learned: Our ListView is effectively a container of individual Views Our ArrayAdapter is creating those Views for us Basically, that's how we're identifying the type of View with which to populate the ListView. For example, if we'd gone with android.r.layout.simple_list_item_single_choice instead, it would look like radio buttons. However, it still wouldn't act like radio buttons. For something like that, we'd simply add: flist.setchoicemode(listview.choice_mode_single); Similarly, CHOICE_MODE_MULTIPLE is good for checkboxes (in which case, you'd probably want to switch the item Views to simple_list_item_multiple_choice. As a final thought, if the primary purpose for an Activity were solely to display a ListView, there's actually a ListActivity we can extend. You might feel it makes the process slightly simpler. Basically, there's a lot to play with here.

7 Interjection Presumably, you've noticed that this is not how one typically creates radio buttons. You've likely already stumbled upon the RadioButton and RadioGroup classes when working on the assignment, and that's how you'd normally handle trivial, well-defined selections. What we've looked at today is more for when dealing with arbitrary data. Something's missing... Very astute observation! What we've looked at so far might be suitable for any number of specific Use Cases. For example, filling out surveys, selecting extras for restaurant menu items, etc. Basically, it's fine for cases where you might want the group of selections to figure prominently into the overall view. But is that the only common usage for a group of multiple selections? Is that how one would normally, for example, wish to choose one's country? (Okay, so sometimes that is how it's done, but that doesn't make it good) In that case, how do we normally offer such a selection? Via a drop-down, right? Then let's talk about the Spinner. Twirling towards freedom First, I'll make another Activity (HelpMe), and repurpose that third button to start it. The layout is easy: <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android=" android:layout_height="match_parent" android:orientation="vertical" > <Spinner android:id="@+id/spinny" <TextView android:id="@+id/spun" </LinearLayout> Note that, if we wanted to, we could have specified the android:entries here.

8 Since the difference between a Spinner and a ListView is primarily presentation, the code is comparably easy: public class HelpMe extends AppCompatActivity implements AdapterView.OnItemSelectedListener { String[] cbowl; protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_help_me); cbowl=getresources().getstringarray(r.array.mayneverdie); Spinner spinny=(spinner)findviewbyid(r.id.spinny); ArrayAdapter<String> adapter=new ArrayAdapter<>( this,android.r.layout.simple_spinner_item,cbowl ); spinny.setadapter(adapter); spinny.setonitemselectedlistener(this); public void onitemselected(adapterview<?> parent, View v, int position, long id) { ((TextView)findViewById(R.id.spun)).setText(":> "+cbowl[position]); public void onnothingselected(adapterview<?> parent) { ((TextView)findViewById(R.id.spun)).setText("This likely isn't relevant"); That's neat, but that isn't how I make most selections This is true. Oftentimes, rather than needing to scroll through a lengthy list, you can simply type part of what you want, and have it fill in the rest. Let's add one more view to the same layout: <AutoCompleteTextView android:id="@+id/finishmythought" Of course, we could add more here, but we'll do it in the code section: ArrayAdapter<String> completion=new ArrayAdapter<>(this,android.R.layout.simple_dropdown_item_1line,cbowl); AutoCompleteTextView actv=(autocompletetextview)findviewbyid(r.id.finishmythought); actv.setthreshold(1); actv.setadapter(completion); Again, pretty straightforward, but let's still take a quick look.

9 Okay, so that's it! Sort of... That's everything we needed to cover this evening, but I imagine we have time for one more example, right? If we do have time, the book actually had an interesting example of another type of adapter, and I thought it might be worth taking a quick look at. I'll just include the whole thing here, and then talk about it afterwards. I'll be using an Activity name of Imagine for this one. I'll also put some images into the drawable folder. First, the layout: <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android=" xmlns:tools=" android:layout_height="match_parent" android:orientation="vertical" > <TextView android:text="browsing" android:gravity="center" android:textstyle="bold" android:id="@+id/kwyjibo" <android.support.v4.view.viewpager android:layout_height="400dip" android:layout_margintop="25dip" android:id="@+id/pager" </LinearLayout> And now (deep breath), the Java code: public class Imagine extends AppCompatActivity { public TextView kwyjibo; protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_imagine); kwyjibo=(textview)findviewbyid(r.id.kwyjibo); ViewPager pager=(viewpager)findviewbyid(r.id.pager); pager.setadapter(new ImageAdapter()); //pager.setonpagechangelistener(new PageListener()); //deprecated pager.addonpagechangelistener(new PageListener()); class ImageAdapter extends PagerAdapter { Integer[] images={ R.drawable.urgh1, R.drawable.urgh2,

10 ; R.drawable.urgh3, R.drawable.urgh4, R.drawable.urgh5 /*public Object instantiateitem(view container, int position) { ImageView view=new ImageView(Imagine.this); view.setimageresource(images[position]); ((ViewPager) container).addview(view,0); return view; */ //deprecated public Object instantiateitem(android.view.viewgroup container, int position) { ImageView view=new ImageView(Imagine.this); view.setimageresource(images[position]); container.addview(view,0); return view; public int getcount() { return images.length; public void destroyitem(view arg0, int arg1, Object arg2) { ((ViewPager)arg0).removeView((View) arg2); public boolean isviewfromobject(view arg0, Object arg1) { return arg0==((view)arg1); class PageListener extends ViewPager.SimpleOnPageChangeListener { public void onpageselected(int position) { kwyjibo.settext(":> "+position); Okay, so what does all of that do? Well, remember how I said the Adapter creates Views to be added to the UI? Here, we can actually see that being done. (Note that I included the 'old way' of doing a couple things, that are now deprecated) Let's try it out and see what we've done! On a side note: this is certainly not the only (nor the normal) way to scroll. If you've simply run out of space for what you want to include, just use a ScrollView. If we still have any time, I can even show that off really quickly. Just remember that a ScrollView only holds a single View (so make that View be a Layout/container if you want to hold multiple things).