iQuit

It appears the Tweetable plugin I was using to push notices to my Twitter followers of new blog posts died on its own over the weekend and made it so every page on the blog was coming up blank. Not cool!

Besides putting out blog fires I’ve just finished Milestone 2 for the Android project and I’m moving on to Milestone 3. Milestone 2 taught lots of GUI creation lessons for Android. The lesson being that it takes a LONG time to make GUIs on the Android compared to the iPhone. The one thing I like better on the Android though is that since you’re coding the GUI by hand with XML you’re already thinking of screen “scalability”, i.e. you’re already factoring in different resolutions and orientations. I’ve had rotating the app working since day one. So far on my iPhone projects multiple orientations have been afterthoughts (even though they shouldn’t be).

I found this handy post to the Android developer’s group, which explained how to get the equivalent behaviour to Apple’s flexible spacer views on toolbars.

The implementation in a layout XML file looks like this:

<LinearLayout android:id="@+id/ToolBar" android:orientation="horizontal" android:layout_width="fill_parent" android:layout_height="wrap_content">
	<View android:layout_width="0px" android:layout_weight="1" android:visibility="invisible"/>
	<Button android:layout_height="wrap_content" android:layout_width="wrap_content" android:background="@drawable/homebuttonselector" android:id="@+id/HomeButton"/>
	<View android:layout_width="0px" android:layout_weight="1" android:visibility="invisible"/>
	<Button android:layout_height="wrap_content" android:layout_width="wrap_content" android:background="@drawable/nextbuttonselector" android:id="@+id/NextButton"/>
	<View android:layout_width="0px" android:layout_weight="1" android:visibility="invisible"/>
</LinearLayout>

Note the use of the layout_weight property for the hidden views.  This tells the layout code to take whatever space is leftover from the non-weighted views (the two buttons) and divide it evenly amongst all the other views set to a weight of 1.  You could play with this to do other goofy layouts as well.  This is much handier than using padding, or even relative layouts to achieve the same effect because it allows you to leave the calculations up to the layout code rather than you figuring out at runtime what the padding should be.  Especially if you’re adding/removing views depending on context.

UPDATE:
After playing with this a little more I actually went with this solution, which makes it even easier to programmatically show/hide the buttons.

<LinearLayout android:id="@+id/ToolBar" android:orientation="horizontal" android:layout_width="fill_parent" android:layout_height="wrap_content">
	<RelativeLayout android:id="@+id/Button1Layout" android:layout_height="wrap_content" android:layout_width="wrap_content" android:layout_weight="1">
		<Button android:layout_height="wrap_content" android:layout_width="wrap_content" android:background="@drawable/button1selector" android:id="@+id/Button1" android:layout_centerHorizontal="true"/>
	</RelativeLayout>
	<RelativeLayout android:id="@+id/Button2Layout" android:layout_height="wrap_content" android:layout_width="wrap_content" android:layout_weight="1">
		<Button android:layout_height="wrap_content" android:layout_width="wrap_content" android:background="@drawable/button2selector" android:id="@+id/Button2" android:layout_centerHorizontal="true"/>
	</RelativeLayout>
</LinearLayout>

With this version to show/hide buttons all you have to do is set the visibility for the layout group the button resides in to Visibility.GONE or Visibility.VISIBLE. You don’t have to worry about having the proper arrangement of empty views to the left and right of the button.

I’ve been working away with major blinders, supremely focused on building the Activity class model properly for the Android port of Prescriber’s Letter.  I’m working on the menu system currently, how the list view of menu items gets filled out from the XML menu structure, how activities are spawned to present the various selected menu items, issues like that.  I’m trying my best to get it right the first time, which takes a lot of googling, book reading and planning to make sure I’m doing things properly the “Android way”.

Some things have been easier to do on Android than they were on the iPhone version, for example the special custom label classes I had to write for the iPhone to display text with mixed normal and italic typefaces.  On Android this is MUCH simpler to do.  You can select spans of text in a text view and apply styles, colors, etc. to the span.  On the iPhone I had to build the custom label class that basically appended labels to each other, each one set to display its particular style.    Being able to rely on the built-in components is nice, it will make all the other follow on things much simpler (supporting different screen dimensions, supporting landscape and portrait orientations, etc.).

iPhone OS 3.2 is a thorn in my side that I’m glad I don’t have to worry about just at the moment.  They snuck in a requirement for Snow Leopard on this version, which I think is plain ridiculous.  There can’t possibly be any good reason for it to require Snow Leopard.  This is flat out just a plain money grab by Apple to force all of us developers to upgrade.  It bothers me to no end, I have no need to upgrade to Snow Leopard.  It doesn’t offer me any features that I place any value in.  All it does is waste my time and money.