Well, I am finally forcing myself to make the jump to iOS, but that is taking more time than I anticipated. More on that in the first iOS blog post. I did spend a little time doing some code review, bug fixing and refactoring. In that process I had a great conversation with one of the other Success Engineers at Xamarin, Colby Williams, who gave me some good feedback and reviewed some of my code. I learned one really great nuget that is worth sharing as it is not immediately apparent when getting started with Xamarin from Android.
When using collection views, it is almost always best to subclass BaseAdapter rather than use any of the out of the box adapters provided by Android (ArrayAdapter comes to mind). I was using the default ArrayAdapter for all of my drop down spinner controls and what I learned is most of the default Adapters provided by Android will give a potential performance hit because for each object in the list, an equal java object has to be created and maintained. This is due to how Xamarin and Android communicate with each other. For an in depth review, this document covers it well:
http://developer.xamarin.com/guides/android/under_the_hood/architecture
So what was happening was for every spinner I created using an Array Adapter, a general C# and Java object were being created and maintained, creating overhead. Instead, creating a BaseAdapter, the under the hood creates a single Java object that has a C# implementation within. Much better performance wise, fewer objects to maintain in memory.
My final code for the adapter is actually pretty simple:
public class SpinnerAdapter : BaseAdapter<string>
{
List<string> _items;
Activity _context;
public SpinnerAdapter (Activity context, List<string> items)
{
_items = items;
_context = context;
}
public override long GetItemId (int position)
{
return position;
}
public int GetPosition(string selected)
{
return _items.IndexOf (selected);
}
public override string this[int index] {
get { return _items[index]; }
}
public override Android.Views.View GetView (int position, Android.Views.View convertView, Android.Views.ViewGroup parent)
{
var view = convertView;
if(view == null)
{
view = _context.LayoutInflater.Inflate (Resource.Layout.spinner_item, null);
}
view.FindViewById<TextView> (Resource.Id.text).Text = _items[position];
return view;
}
public override int Count {
get {
return _items.Count;
}
}
}
Once I made that update, I noticed my views loaded much quicker.
Next time I am going to dig into iOS development, and why it can be a challenge. Given that iOS 9 just came out this past week, I am also using this as an "excuse" to learn iOS 9.
Showing posts with label Android. Show all posts
Showing posts with label Android. Show all posts
Monday, September 21, 2015
Monday, August 31, 2015
Android ListViews and Updating the Backend Data
I wanted to spend at least one more post to try to put my app in a finished state so there was a lot of time spent on both backend code and getting my skills list to display properly.
My first thought was to use a ListView to display all of my skills, it seemed logical. It was a of items, numbers and a checkbox. Time to brush off what I learned from custom spinner items. Creating adapters for your ListView is actually pretty standard as a lot of the time the default elements are going to not provide what you need.
The first step was to at least get my ListView organized and all my skills displayed. I already had all the hookups in place thanks to my work last week with implementing ViewPager. The first step was to create a new LayoutView, which housed my ListView. I then used a default ArrayAdapter to just grab a placeholder list of strings.
public override View OnCreateView (LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
{
var root = inflater.Inflate (Resource.Layout.fragment_charsheet_skills, container, false);
ListView view = root.FindViewById<ListView> (Resource.Id.skillsList);
var skills = ((CharacterSheetActivity)this.Activity).CharacterInformation.Skills;
view.Adapter = new ArrayAdapter<string> (this.Activity,Android.Resource.Layout.SimpleListItem1, skills);
return root;
}
Pretty straight forward, and shows at least a starting point:
We have a successful ListView! Now to add the Custom Adapter. In this case, I want to display not only the name, but the ability mod score, whether or not the character is trained, and then the final value. (Mod + Proficiency)
The adapter is set up and in order. The first challenge I ran into was getting my items to not clump together. RelativeLayout was not really an option here, so a little searching I discovered one effective option was to use the "Weight" tag to give each item equal weight within the control.
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="horizontal"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:padding="5dp">
<TextView
android:id="@+id/skillName"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="Placeholder"
android:layout_weight="1" />
<TextView
android:id="@+id/modValue"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_weight="1"
android:text="+3" />
<CheckBox
android:id="@+id/isTrained"
android:layout_width="32.0dp"
android:layout_height="wrap_content"
android:layout_weight="1" />
<TextView
android:id="@+id/totalValue"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_weight="1"
android:text="+5" />
</LinearLayout>
In theory that worked well, but then I realized I had a problem once I got the final result running.
As the weights are row specific, it does not help align each column. Once again, for implementation and times sake I decided to call that "good enough" for now.
The next step was to work on my back end code. As can be seen in the above, I am hard coding all of my values, and no hookup event for the proficiency checkbox. This actually required a lot of back end work, which was good to revisit and clean up the data.
Now, I will preface by saying I do not admit this code will be the best. I'm playing more of the functional over proper card here. As a side project it will regularly be a work in progress.
I created both a Skill and SkillsList class on my back end. The reason for the latter is it gave me a collection that I could house some of the more static concepts like what skills have what ability mods, and a fully populated list of all possible names. Again, not proud of it, but its functional. Then, at launch all possible skills are preloaded based on starting stats. This gives me all my initial conditions that I access as accessor methods. (Loading data I will revisit at a later point).
From an input standpoint the two big changes I needed to make sure happened were
a) update final values as proficiency was enabled
b) update mods when ability scores are changed.
For the first, I did an inline set of code, pretty straight forward.
proficient.CheckedChange += (object sender, CompoundButton.CheckedChangeEventArgs e) =>
{
CharacterSheet sheet = ((CharacterSheetActivity)_context).CharacterInformation;
sheet.Skills[position].IsProficient = e.IsChecked;
skillMod.Text = sheet.Skills [position].TotalValue + "";
}
On the flip side, with all of my Attribute code, I added this line:
character.UpdateSkills (Attributes.AttributeName.STR);
Which is essentially calling an update method within my SkillsList:
public void UpdateSkillMod (Attributes.AttributeName type, int mod)
{
foreach(Skill skill in _skills)
{
if(skill.ModType == type)
{
skill.ModValue = mod;
}
}
}
This is simply an enumeration through all skills that updates the ModValue of the associated type. That gets us to our final version, which we will hold with for now.
On the back end I also did a lot of cleanup for better preparation for when I need to load character data. At this point I am going to call the Android version of the app in a good spot and now move to get an iOS skin running with this.
My first thought was to use a ListView to display all of my skills, it seemed logical. It was a of items, numbers and a checkbox. Time to brush off what I learned from custom spinner items. Creating adapters for your ListView is actually pretty standard as a lot of the time the default elements are going to not provide what you need.
The first step was to at least get my ListView organized and all my skills displayed. I already had all the hookups in place thanks to my work last week with implementing ViewPager. The first step was to create a new LayoutView, which housed my ListView. I then used a default ArrayAdapter to just grab a placeholder list of strings.
public override View OnCreateView (LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
{
var root = inflater.Inflate (Resource.Layout.fragment_charsheet_skills, container, false);
ListView view = root.FindViewById<ListView> (Resource.Id.skillsList);
var skills = ((CharacterSheetActivity)this.Activity).CharacterInformation.Skills;
view.Adapter = new ArrayAdapter<string> (this.Activity,Android.Resource.Layout.SimpleListItem1, skills);
return root;
}
Pretty straight forward, and shows at least a starting point:
We have a successful ListView! Now to add the Custom Adapter. In this case, I want to display not only the name, but the ability mod score, whether or not the character is trained, and then the final value. (Mod + Proficiency)
The adapter is set up and in order. The first challenge I ran into was getting my items to not clump together. RelativeLayout was not really an option here, so a little searching I discovered one effective option was to use the "Weight" tag to give each item equal weight within the control.
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="horizontal"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:padding="5dp">
<TextView
android:id="@+id/skillName"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="Placeholder"
android:layout_weight="1" />
<TextView
android:id="@+id/modValue"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_weight="1"
android:text="+3" />
<CheckBox
android:id="@+id/isTrained"
android:layout_width="32.0dp"
android:layout_height="wrap_content"
android:layout_weight="1" />
<TextView
android:id="@+id/totalValue"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_weight="1"
android:text="+5" />
</LinearLayout>
In theory that worked well, but then I realized I had a problem once I got the final result running.
 |
| Looks Perfect |
 |
| Maybe I need to think this through... |
The next step was to work on my back end code. As can be seen in the above, I am hard coding all of my values, and no hookup event for the proficiency checkbox. This actually required a lot of back end work, which was good to revisit and clean up the data.
Now, I will preface by saying I do not admit this code will be the best. I'm playing more of the functional over proper card here. As a side project it will regularly be a work in progress.
I created both a Skill and SkillsList class on my back end. The reason for the latter is it gave me a collection that I could house some of the more static concepts like what skills have what ability mods, and a fully populated list of all possible names. Again, not proud of it, but its functional. Then, at launch all possible skills are preloaded based on starting stats. This gives me all my initial conditions that I access as accessor methods. (Loading data I will revisit at a later point).
From an input standpoint the two big changes I needed to make sure happened were
a) update final values as proficiency was enabled
b) update mods when ability scores are changed.
For the first, I did an inline set of code, pretty straight forward.
proficient.CheckedChange += (object sender, CompoundButton.CheckedChangeEventArgs e) =>
{
CharacterSheet sheet = ((CharacterSheetActivity)_context).CharacterInformation;
sheet.Skills[position].IsProficient = e.IsChecked;
skillMod.Text = sheet.Skills [position].TotalValue + "";
}
On the flip side, with all of my Attribute code, I added this line:
character.UpdateSkills (Attributes.AttributeName.STR);
Which is essentially calling an update method within my SkillsList:
public void UpdateSkillMod (Attributes.AttributeName type, int mod)
{
foreach(Skill skill in _skills)
{
if(skill.ModType == type)
{
skill.ModValue = mod;
}
}
}
This is simply an enumeration through all skills that updates the ModValue of the associated type. That gets us to our final version, which we will hold with for now.
On the back end I also did a lot of cleanup for better preparation for when I need to load character data. At this point I am going to call the Android version of the app in a good spot and now move to get an iOS skin running with this.
Friday, August 14, 2015
Implementing the Toolbar and Scrolling Tabs
After spending a lot of time working on what was essentially a single page view, I felt like I had enough blocked functionality to really start broadening my horizons. There is too much data on a single character sheet to warrant it all on one view, nor would that make for pretty UI Code.
As a reference, here is what we are basing everything off of, pulled straight from the Dungeons and Dragons Website
First step was the Toolbar. I wanted to try to use all the new latest and greatest and was previously using an ActionBar. Luckily James Montemagno gave a great overview for adding a Toolbar to your app to replace the ActionBar, I suggest starting with a read there:
https://blog.xamarin.com/android-tips-hello-toolbar-goodbye-action-bar/
From a visual side of things everything looked roughly the same, but gives me greater flexibility in the long run. Next step was to add new menu items. I have learned that Android really likes its .xml files and menus are no different. For now, we will start with a new, save and load button. For spacial consideration I am just showing the add button for now, but it gives the app a nice look I think:
The next step was to add a TabLayout to the toolbar. I also wanted to include both tap and swipe navigation as it adds a logical flow to the app. This is where I also had to learn about fragments and ViewPagers. This definitely took a bit of research as there were a number of parts to get a handle on.
From a high level overview, Fragments are a way for Android to both compartmentalize UI into component pieces, to allow you to better support multiple screen sizes, and just break down your UI easier. A good overview that helped me can be found here:
http://developer.xamarin.com/guides/android/platform_features/fragments/
To create my desired setup, this guide on the Android developer docs was highly valuable:
http://developer.android.com/training/implementing-navigation/lateral.html
You break it down by having your TabLayout add 2+ ViewPager objects to represent each tab. Each ViewPager object is going to be a unique Fragment on the back end, or basically a UI view. Really cool stuff.
So the first thing I need to do is set up each of my ViewPager objects, so that they are grouped together and can be "swipable". The following code handles all of that.
var viewPager = FindViewById<ViewPager> (Resource.Id.viewPager);
SetupViewPagers (viewPager);
private void SetupViewPagers(ViewPager viewPager)
{
var adapter = new MyAdapter (SupportFragmentManager);
adapter.AddFragment (new CharSheetOverviewFragment (), "Overview");
adapter.AddFragment(new CharSheetSkillsFragment(), "Skills");
viewPager.Adapter = adapter;
}
This will create my ViewPager object, where the SetupViewPagers method creates each individual Page, and then sets the adapter to group them together. The final result is a ViewPager object, or a number of views that are side by side and have built in scrolling. Pretty neat. SupportFragmentManager is a predefined Adapter provided by the Android Support Package that we need to set all this up. the viewPager resource is simply something that I added to my main .axml file that will house the ViewPager spells.
From there you are following the same process as normal. You create a Fragment .axml file and a correspoding Activity class to load it. The difference being instead of inheriting from "Activity" you are inheriting from Fragment. Your OnCreateView method inflates the fragment UI and returns the view.
public override View OnCreateView (LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
{
var root = inflater.Inflate (Resource.Layout.fragment_charsheet_overview,
container, false);
return root;
}
One of the cool side effects of using Fragments is they also maintain a reference to the parent Activity which loaded them. So in my case, the parent Activity, a CharacterSheetView has a loaded set of character Data. Each of my fragments can pull from that data by using this.Activity.
A view of what we see now can be found below, I have been updating some of the code to modify how my attributes are being displayed, moving from a TableLayout to GridLayout
As a reference, here is what we are basing everything off of, pulled straight from the Dungeons and Dragons Website
This does not include the spells page, that will be its own beast that I will tackle later, but there are some logical groupings of information that we can use. What makes the most sense is to add a Tab Control based layout to scroll through sections of information.
First step was the Toolbar. I wanted to try to use all the new latest and greatest and was previously using an ActionBar. Luckily James Montemagno gave a great overview for adding a Toolbar to your app to replace the ActionBar, I suggest starting with a read there:
https://blog.xamarin.com/android-tips-hello-toolbar-goodbye-action-bar/
From a visual side of things everything looked roughly the same, but gives me greater flexibility in the long run. Next step was to add new menu items. I have learned that Android really likes its .xml files and menus are no different. For now, we will start with a new, save and load button. For spacial consideration I am just showing the add button for now, but it gives the app a nice look I think:
I also am going to remove the floating action button for the time being. I have some ideas for it down the line, but likely will only resurface once I get a more complete product (much later).
The next step was to add a TabLayout to the toolbar. I also wanted to include both tap and swipe navigation as it adds a logical flow to the app. This is where I also had to learn about fragments and ViewPagers. This definitely took a bit of research as there were a number of parts to get a handle on.
From a high level overview, Fragments are a way for Android to both compartmentalize UI into component pieces, to allow you to better support multiple screen sizes, and just break down your UI easier. A good overview that helped me can be found here:
http://developer.xamarin.com/guides/android/platform_features/fragments/
To create my desired setup, this guide on the Android developer docs was highly valuable:
http://developer.android.com/training/implementing-navigation/lateral.html
You break it down by having your TabLayout add 2+ ViewPager objects to represent each tab. Each ViewPager object is going to be a unique Fragment on the back end, or basically a UI view. Really cool stuff.
So the first thing I need to do is set up each of my ViewPager objects, so that they are grouped together and can be "swipable". The following code handles all of that.
var viewPager = FindViewById<ViewPager> (Resource.Id.viewPager);
SetupViewPagers (viewPager);
private void SetupViewPagers(ViewPager viewPager)
{
var adapter = new MyAdapter (SupportFragmentManager);
adapter.AddFragment (new CharSheetOverviewFragment (), "Overview");
adapter.AddFragment(new CharSheetSkillsFragment(), "Skills");
viewPager.Adapter = adapter;
}
This will create my ViewPager object, where the SetupViewPagers method creates each individual Page, and then sets the adapter to group them together. The final result is a ViewPager object, or a number of views that are side by side and have built in scrolling. Pretty neat. SupportFragmentManager is a predefined Adapter provided by the Android Support Package that we need to set all this up. the viewPager resource is simply something that I added to my main .axml file that will house the ViewPager spells.
From there you are following the same process as normal. You create a Fragment .axml file and a correspoding Activity class to load it. The difference being instead of inheriting from "Activity" you are inheriting from Fragment. Your OnCreateView method inflates the fragment UI and returns the view.
public override View OnCreateView (LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
{
var root = inflater.Inflate (Resource.Layout.fragment_charsheet_overview,
container, false);
return root;
}
One of the cool side effects of using Fragments is they also maintain a reference to the parent Activity which loaded them. So in my case, the parent Activity, a CharacterSheetView has a loaded set of character Data. Each of my fragments can pull from that data by using this.Activity.
A view of what we see now can be found below, I have been updating some of the code to modify how my attributes are being displayed, moving from a TableLayout to GridLayout
I
am going to spend a little more time polishing the attribute list and
then actually look to start replicating this in iOS to help broaden my
skillset. I do know that I will likely use a ListView for the skills so I
may just tackle that next. We will see.
Friday, July 31, 2015
Data Validation of Numeric Edit Text in Android
After spending some time to learn Material design, I felt it would be worth my time to take a break and focus on actually getting data onto my app and start progressing, then do a design pass later. I was churning my wheels trying to get all the character attributes set up and decided it was best to just get something on paper. I settled on a TableLayout to organize the labels from the character attributes and modifiers. I also did a bit of playing with design and cleanup and had something at least organized:
Overall this is rather respectable, it has a semi clean look and gives logical organization of the data. Am I in love with it? No, but it is something. The biggest challenge was getting the labels to stretch across the entirety of the view, instead of getting clumped. It took a bit of searching, but I found this attribute:
android:stretchColumns
Which made all the difference. It allowed me to get the desired spread. I likely should revisit the spacing size of the central Numeric EditText but since this is more placeholder I say sufficient for now.
The next big step was setting it so that when the user sets his Attribute value, it would auto update the modifier on the back end. The initial setup was not terrible, you hook up a "TextChanged" event handler, grab the values, update accordingly.
void OnStrengthChanged (object sender, Android.Text.TextChangedEventArgs e)
{
var numField = (EditText)sender;
var value = int.Parse (numField.Text);
characterData.SetSingleAttribute (new Attributes{ Strength = value });
var mod = FindViewById<TextView> (Resource.Id.strengthMod);
mod.Text = testCharacter.FinalAttributes.StrengthModifier.ToString ();
}
Overall, rather straight forward. I currently store Attributes as a single object that contains the individual properties for both Values and modifiers, basically a special array container with some validation inside. "characterData" is my storage for all applicable data. All of that is defined in my shared PCL. I think this is an area that could use a refactor. Currently my SetSingleAttribute is something like this:
public void SetSingleAttribute(Attributes attributes)
{
baseAttributes.Strength = attributes.Strength == 0 ? baseAttributes.Strength : attributes.Strength;
baseAttributes.Dexterity = attributes.Dexterity == 0 ? baseAttributes.Dexterity : attributes.Dexterity;
baseAttributes.Constitution = attributes.Constitution == 0 ? baseAttributes.Constitution : attributes.Constitution;
baseAttributes.Intelligence = attributes.Intelligence == 0 ? baseAttributes.Intelligence : attributes.Intelligence;
baseAttributes.Wisdom = attributes.Wisdom == 0 ? baseAttributes.Wisdom : attributes.Wisdom;
baseAttributes.Charisma = attributes.Charisma == 0 ? baseAttributes.Charisma : attributes.Charisma;
baseAttributes = baseAttributes - Race.BonusAttributes;
}
Basically I find the attribute that has been modified as all the others have been nulled out. I need to spend some more time on this, especially once I implement racial and feat bonuses. For now, it gets things moving forward while I block out all the data.
One challenge that I ran into was editing attribute values. The default behavior when clicking these fields (as they are just text fields) is to allow the user to edit the entry. To handle the scenario where a user deletes the existing values, I was running into an awkward case of trying to convert an empty string to a number, which does not work very well, and left an unintuitive experience. What I did to solve it was set the fields "Hint" parameter:
strValue.Hint = "8";
Then you get a nice greyed out sample field, without disrupting your flow:
This is definitely coming along well. For some preliminary data validation I also set maxLength to 2 to prevent numbers larger than 2 digits. Ideally I should limit to something like 6-20 as per the rules, but it is a start. As a note, a more complete complete implementation would use either a custom class of EditText or InputFilters.
Overall this is rather respectable, it has a semi clean look and gives logical organization of the data. Am I in love with it? No, but it is something. The biggest challenge was getting the labels to stretch across the entirety of the view, instead of getting clumped. It took a bit of searching, but I found this attribute:android:stretchColumns
Which made all the difference. It allowed me to get the desired spread. I likely should revisit the spacing size of the central Numeric EditText but since this is more placeholder I say sufficient for now.
The next big step was setting it so that when the user sets his Attribute value, it would auto update the modifier on the back end. The initial setup was not terrible, you hook up a "TextChanged" event handler, grab the values, update accordingly.
void OnStrengthChanged (object sender, Android.Text.TextChangedEventArgs e)
{
var numField = (EditText)sender;
var value = int.Parse (numField.Text);
characterData.SetSingleAttribute (new Attributes{ Strength = value });
var mod = FindViewById<TextView> (Resource.Id.strengthMod);
mod.Text = testCharacter.FinalAttributes.StrengthModifier.ToString ();
}
Overall, rather straight forward. I currently store Attributes as a single object that contains the individual properties for both Values and modifiers, basically a special array container with some validation inside. "characterData" is my storage for all applicable data. All of that is defined in my shared PCL. I think this is an area that could use a refactor. Currently my SetSingleAttribute is something like this:
public void SetSingleAttribute(Attributes attributes)
{
baseAttributes.Strength = attributes.Strength == 0 ? baseAttributes.Strength : attributes.Strength;
baseAttributes.Dexterity = attributes.Dexterity == 0 ? baseAttributes.Dexterity : attributes.Dexterity;
baseAttributes.Constitution = attributes.Constitution == 0 ? baseAttributes.Constitution : attributes.Constitution;
baseAttributes.Intelligence = attributes.Intelligence == 0 ? baseAttributes.Intelligence : attributes.Intelligence;
baseAttributes.Wisdom = attributes.Wisdom == 0 ? baseAttributes.Wisdom : attributes.Wisdom;
baseAttributes.Charisma = attributes.Charisma == 0 ? baseAttributes.Charisma : attributes.Charisma;
baseAttributes = baseAttributes - Race.BonusAttributes;
}
Basically I find the attribute that has been modified as all the others have been nulled out. I need to spend some more time on this, especially once I implement racial and feat bonuses. For now, it gets things moving forward while I block out all the data.
One challenge that I ran into was editing attribute values. The default behavior when clicking these fields (as they are just text fields) is to allow the user to edit the entry. To handle the scenario where a user deletes the existing values, I was running into an awkward case of trying to convert an empty string to a number, which does not work very well, and left an unintuitive experience. What I did to solve it was set the fields "Hint" parameter:
strValue.Hint = "8";
Then you get a nice greyed out sample field, without disrupting your flow:
 | |
| As you can see, there is a nice greyed entry, more intuitive. |
Friday, July 17, 2015
Creating Custom Views with a Spinner
The next step in my app was making a quick cosmetic change. If you
recall my drop downs for Race and Character classes were left text
aligned. This is due to the default Resource settings I was used at its
creation. Creating spinners, there are two layout settings that I
discovered you can play with.
Spinner races = FindViewById <Spinner> (Resource.Id.charRace);
var adapter = new ArrayAdapter<string> (this, Android.Resource.Layout.SimpleSpinnerItem1, items);
adapter.SetDropDownViewResource (Android.Resource.Layout.SimpleSpinnerDropDownItem );
When you create a Spinner control, you have to set its adapter, which basically determines how it displays the data added, and will tell the Spinner what type of data objects it should expect. The above was my original code.
The first line finds the Spinner in the Android Resources, the second initializes the Adapter to contain/expect an array of type string, and the third sets the display of the individual items when you click the spinner and dropdown. Digging around, I learned it should be as simple as overriding the default Android.Resource.Layout to use a custom layout instead of a default one. Pretty straightforward right? So I created a new android .axml called spinner_item with the following code:
xml version="1.0" encoding="utf-8"?>
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:gravity="right" />
as all I needed was right aligned text. Problem was, when I tried to reference it, I was getting compile errors:
var adapter = new ArrayAdapter<string> (this, Android.Resource.Layout.spinner_item, items);
This was confusing as everything I read said this should work. It was then, digging through Xamarins documentation that I realized I was missing something:
http://developer.xamarin.com/guides/android/application_fundamentals/resources_in_android/part_1_-_android_resource_basics/
When referencing resources programmatically (in code), they can be accessed via the Resources class hierarchy which uses the following syntax:
@[.]Resource..
I noticed I was using Android.Resource.Layout, key word being "ANDROID", or the default resources. Since I was using resources local to my own project, I could just say
Resource.Layout.spinner_item and this would find my new custom layout. Adding that we get this:
var adapter = new ArrayAdapter<string> (this, Resource.Layout.spinner_item, items);
And we get the following:
This looks much better, and a lot cleaner due to how the combo boxes are displaying the data. I am still debating whether or not this falls in line with Material design but for now I am content with it, it looks clean. I have since decided that this is a first pass and so I will likely do a "good enough" approach to get my information visible and then do a full pass pater to get things better organized.
Spinner races = FindViewById <Spinner> (Resource.Id.charRace);
var adapter = new ArrayAdapter<string> (this, Android.Resource.Layout.SimpleSpinnerItem1, items);
adapter.SetDropDownViewResource (Android.Resource.Layout.SimpleSpinnerDropDownItem );
When you create a Spinner control, you have to set its adapter, which basically determines how it displays the data added, and will tell the Spinner what type of data objects it should expect. The above was my original code.
The first line finds the Spinner in the Android Resources, the second initializes the Adapter to contain/expect an array of type string, and the third sets the display of the individual items when you click the spinner and dropdown. Digging around, I learned it should be as simple as overriding the default Android.Resource.Layout to use a custom layout instead of a default one. Pretty straightforward right? So I created a new android .axml called spinner_item with the following code:
xml version="1.0" encoding="utf-8"?>
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:gravity="right" />
as all I needed was right aligned text. Problem was, when I tried to reference it, I was getting compile errors:
var adapter = new ArrayAdapter<string> (this, Android.Resource.Layout.spinner_item, items);
This was confusing as everything I read said this should work. It was then, digging through Xamarins documentation that I realized I was missing something:
http://developer.xamarin.com/guides/android/application_fundamentals/resources_in_android/part_1_-_android_resource_basics/
When referencing resources programmatically (in code), they can be accessed via the Resources class hierarchy which uses the following syntax:
@[
I noticed I was using Android.Resource.Layout, key word being "ANDROID", or the default resources. Since I was using resources local to my own project, I could just say
Resource.Layout.spinner_item and this would find my new custom layout. Adding that we get this:
var adapter = new ArrayAdapter<string> (this, Resource.Layout.spinner_item, items);
And we get the following:
This looks much better, and a lot cleaner due to how the combo boxes are displaying the data. I am still debating whether or not this falls in line with Material design but for now I am content with it, it looks clean. I have since decided that this is a first pass and so I will likely do a "good enough" approach to get my information visible and then do a full pass pater to get things better organized.
Subscribe to:
Posts (Atom)