jwill · August 29, 2015 14:02
diff --git a/gistfile1.txt b/gistfile1.txt

 That looks pretty sweet -- but what about users who can’t see your shiny new control? Accessibility is a key consideration when building apps, and particularly when creating new Views. 
 You can start by adding a contentDescription[draw] as you would for every other View in your layout.
 But what about Views like our wind speed & direction gauge  -- where the content isn’t static. Knowing you’re looking at a wind gauge isn’t very useful if we don’t know what what the speed and direction it’s displaying is.
 Well within your control, send an accessibility event[draw] whenever the visual content has been modified.
 Then override the dispatchPopulateAccessibilityEvent handler [draw] adding the current control’s visual value to the accessibility event


 onMeasure is called when your View’s parent is laying out it’s children. As you know, when you add a View to a layout, you can specify a specific height or width -- but in most cases you’ll want to match parent or wrap the content.
 When a Views’s onMeasure is called by it’s parent layout, it asks: “How much space will you use?”
 ...And passes in how much space is available, and whether the View will be given exactly that much space, or at most that much space.
 You can decode that like this: [Draw] to obtain the size and mode parameter for the height and width bounds respectively.
 If the returned mode is exactly [draw], the View will be placed into an area of exactly that size. You’ll be passed that value if the layout has specified a specific size, or if the View has been asked to fill the parent. In either case, it’s best practice to simply return the value passed in, unless that value is below your View’s minimum size -- in which case you can return the minimum value and rely on the parent Layout to crop or scroll as necessary.
 The other alternative is AT_MOST, indicating that your view can define it’s own size, up to the size given. This is typically the case for Views set to WRAP_CONTENT -- where the View should be as wide as it needs to be to display it’s content (but no wider!), all provided it still fits within the parent container.
 Once you’ve determined the size of your control, you *must* call setMeasuredDimension -- passing in your values. If you don’t -- your app will crash as soon as your View is laid out.

	That looks pretty sweet -- but what about users who can’t see your shiny new control? Accessibility is a key consideration when building apps, and particularly when creating new Views.
	You can start by adding a contentDescription[draw] as you would for every other View in your layout.
	But what about Views like our wind speed & direction gauge -- where the content isn’t static. Knowing you’re looking at a wind gauge isn’t very useful if we don’t know what what the speed and direction it’s displaying is.
	Well within your control, send an accessibility event[draw] whenever the visual content has been modified.
	Then override the dispatchPopulateAccessibilityEvent handler [draw] adding the current control’s visual value to the accessibility event


	onMeasure is called when your View’s parent is laying out it’s children. As you know, when you add a View to a layout, you can specify a specific height or width -- but in most cases you’ll want to match parent or wrap the content.
	When a Views’s onMeasure is called by it’s parent layout, it asks: “How much space will you use?”
	...And passes in how much space is available, and whether the View will be given exactly that much space, or at most that much space.
	You can decode that like this: [Draw] to obtain the size and mode parameter for the height and width bounds respectively.
	If the returned mode is exactly [draw], the View will be placed into an area of exactly that size. You’ll be passed that value if the layout has specified a specific size, or if the View has been asked to fill the parent. In either case, it’s best practice to simply return the value passed in, unless that value is below your View’s minimum size -- in which case you can return the minimum value and rely on the parent Layout to crop or scroll as necessary.
	The other alternative is AT_MOST, indicating that your view can define it’s own size, up to the size given. This is typically the case for Views set to WRAP_CONTENT -- where the View should be as wide as it needs to be to display it’s content (but no wider!), all provided it still fits within the parent container.
	Once you’ve determined the size of your control, you must call setMeasuredDimension -- passing in your values. If you don’t -- your app will crash as soon as your View is laid out.