James,
I would say these custom layouts could come in extra packages, since
Macroid mostly provides UI language and operators, not concrete widgets
(although there are some helpers in org.macroid.contrib package, like a
better ListAdapter).
That said, it’s not very complex to come up with what you outlined:
1) write a ResizingButton class, inheriting from Button, an add text size
adapting functionality
2) something like this will stretch a couple of buttons horizontally:
l[HorizontalLinearLayout](
w[ResizingButton] ~> text("...") ~> lp(WRAP_CONTENT, WRAP_CONTENT, 1.0f),
// layout params with weight 1.0
w[ResizingButton] ~> text("...") ~> lp(WRAP_CONTENT, WRAP_CONTENT, 1.0f)
)
You can also make a function for buttons like this inside linear layouts:
def stretchableButton(caption: String) = w[ResizingButton] ~>
lpOf[LinearLayout](WRAP_CONTENT, WRAP_CONTENT, 1.0f)
And use it like this:
w[LinearLayout](stretchableButton("1"), stretchableButton("2")) ~>
horizontal
Nick
On Monday, December 30, 2013 10:52:13 PM UTC, JamesJ wrote:
>
> Nick,
>
> Thanks for the pointer. Looks interesting.
>
> Here is my 2 cents for future consideration.
>
> What about offering some nice utilities to make implementing custom
> layouts easier?
>
> I personally have a very strong dislike of the android suggested way of
> doing layouts. It is like trying to build consumer electronics enclosures
> using Legos. Yes it is possible, but you only get to use pieces that
> others have given you, in the way they want you to use them, and in the end
> it never looks polished.
>
> Back in my Java days, I was annoyed with it's layout environment too,
> until one day I just wrote my own layout manager. It was not a universal
> reusable manager, just the specific manager that put things where I wanted,
> the size I wanted and with the correct relationships to other things.
> Since then, I haven't looked back. The canned layouts are OK for fast
> prototypes, but i developed a taste for designing things the way I wanted
> instead of trying to fit the design into "their" system.
>
> In android, as it turns out, implementing a custom layout by overriding a
> few methods in ViewGroup is not very hard, once you figure it out the first
> time. (As long as you are willing to do some math, and make some mistakes
> along the way.)
>
> Pros:
> - No XML !
> - No attributes,
> - Can be dynamic and change or tweak layout based on data
> - More Design Freedom
> - Easy to do things like intentionally overlap or have multiple
> co-existing z-layers in the design. (e.g. buttons over other content)
> - If desired, support multiple size, orientation, etc in one
> implementation in Scala instead of lots of separate xml files.
> - Can introduce less computational load. Instead of a deep tree of
> layouts, each doing layout, collapse into one "smart" level
>
> Cons:
> - Very few good examples or tutorials on line.
> - Easy to make dumb mistake the first few times.
> - Help is hard to find, as most people don't do it this way.
> - Incorporating Theme elements is a bit more difficult. ( Another great
> tool: simple accessors for current theme, with nice override mechanism)
> - Some easy layouts are slower to create. (So use the standard way for
> those if you like)
>
> I don't think that it is necessary to choose one way or the other, but it
> is nice to be familiar with both ways. Custom layouts are not for
> everyone, especially if you don't like working through the nuts and bolts
> of algorithms.
>
> So, my suggestion, is to give it some thought and try out some tools that
> would make custom layouts easier.
>
>
> For example,
>
> In landscape, I wanted 4 buttons that were spaced evenly across a
> horizontal row that used 25% of the vertical screen space, with the text
> using all available space. For the android way, I would have needed two
> layout managers, lots of redundant XML in a second file, and the text
> wouldn't resize.
>
> Instead, using functional program:
>
> First:
> Write missing functionality for button sizing. Write a function that runs
> once when screen config changes. It uses a temporary button to "measure"
> text size to button height. It sets text size a few times and uses
> interpolation to "guess" the right text size to meet size requirement.
> (Note, this is the kind of "tool" that would be very handy in a toolkit)
>
> Second:
> Write a function to config buttons and add view to container and to local
> list.
> call function 4 times
> using list, in onMeasure iterate and set measures (Handling MeasureSpec is
> also a great opportunity for tools)
> using list, in onLayout, set layout location
>
>
> Thanks for the work that you have done on Macroid so far.
>
> James Jensen
>
>
>
> On Sun, Dec 29, 2013 at 8:11 PM, Nick Stanchenko
> <[email protected]<javascript:>
> > wrote:
>
>> For offloading the UI thread you could use Macroid, which packs a couple
>> orders of magnitude less methods ;)
>> See here: http://macroid.herokuapp.com/whynot.html#threading and here:
>> http://macroid.herokuapp.com/#threading.
>>
>>
>> On Sunday, December 29, 2013 11:43:57 PM UTC, JamesJ wrote:
>>
>>> Thanks for all the good info.
>>>
>>> I had to bail on Scaloid, as it caused the dex to fail with too many
>>> methods (~49000) I know it's probably some config problem, but I didn't
>>> have much time to track it down. With Scala, it is pretty easy to build to
>>> do quite a bit of utility building on your own as needed.
>>>
>>> I also bailed on AKKA, as it seemed way too much headache for what I
>>> needed. I am just using a Handler and HandlerThread for a background
>>> thread, then using post and runOnUiThread to msg back and forth.
>>> (Note: there are lots of opinions on how best to do backgrounding.
>>> About half of them suggest using AsyncTask, but the Big Nerd Ranch book on
>>> Android warns that AsyncTask are run all on one thread in the latest
>>> versions of android. I.e. if you do too much, you can make other apps
>>> behave poorly.) For me, using immutable data and posting provides some
>>> some pretty simple solutions.
>>>
>>>
>>> On Sun, Dec 29, 2013 at 1:48 PM, Perry Nguyen <[email protected]> wrote:
>>>
>>>> That's actually a very good suggestion, my proguard cache behaves in
>>>> the same way (as it is based off of what you did conceptually)
>>>>
>>>>
>>>> On Sun, Dec 29, 2013 at 11:46 AM, James Moore <[email protected]>wrote:
>>>>
>>>>> On Thu, Dec 26, 2013 at 10:45 PM, Nick Stanchenko
>>>>> <[email protected]>wrote:
>>>>>
>>>>>> P.S. If you use Props[A] or the like for creating actors, you’ll need
>>>>>> to add -keep lines for the actor classes as well. I suggest to just use
>>>>>> Props(new A) instead.
>>>>>>
>>>>>
>>>>> One other trick is to create a dummy class that contains calls to
>>>>> things that you want to keep, and then just tell proguard to keep that
>>>>> one
>>>>> class. Sometimes that's easier than mucking around with the Proguard
>>>>> config. Put a call to new A in a class that's never instantiated, and
>>>>> you
>>>>> don't have to change the way you normally create Akka objects.
>>>>>
>>>>>
>>>>> If you're using my Eclipse plugin, doing it this way will improve your
>>>>> cache hits too, since the plugin doesn't know anything about things
>>>>> you've
>>>>> kept via proguard config files.
>>>>>
>>>>> --
>>>>> James Moore
>>>>> [email protected]
>>>>> http://blog.restphone.com/
>>>>> http://www.linkedin.com/in/jamesmmooreiv
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "scala-on-android" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>>
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "scala-on-android" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>>
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "scala-on-android" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"scala-on-android" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
