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]>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]. > 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.
