RE: Properties of Custom Layout

>> A note, though: I didn't see in the proposed desired properties the
>> ability to rely on an existing layout mode. Maybe the customized grid
>> layout may (after some precomputations and adjustements) actually want
>> to rely on the normal grid for the last steps of the layout. I don't know how
>> feasible this is. If this is not feasible, it's ok, we just need to think about it.
> 
> This is a good suggestion; however, I would really like our first stab at this to
> focus solely on getting it up and running:
> 
> 1. Access the fragment tree
> 2. Create a box
> 3. Do it's layout (and any of its children) 
> 4. Add it to the necessary trees via the API when done 
> 5. Call for paint invalidation on next avaialable frame via
> custom paint (although this is should not be a dependency)
> 
> I would prefer to get just basic layout working before we try to get too much
> communication happening between native layouts and dependency by
> those from custom layouts. Additionally, it feels like we're trying (to some
> extent) to move more of this to the author, so we _may_ not want the
> author to depend on native since we're trying to give them more of the
> control.

I guess everyone agrees that we should adopt an agile process with all "Custom Things" where we start with a minimally working implementation and start adding features as they become asked by authors using the initial technology. 

Desirable properties is not about v1, though. The fact we want to start small doesn't prevent us from thinking about use cases in advance and see how the model we choose looks "evolve-to-fit"-able to those use cases, without a need to find out about the exact details of said possible evolutions. That has been my reasoning until now, at least; after all we're still only in the brainstorming phase at this point.

Received on Wednesday, 3 June 2015 20:41:18 UTC