Cornerstone in CyanogenMod

[Steve Kondik]

We (the CM team) have been experimenting with Cornerstone on our
tablet builds. There are a few things to iron out, but for the most
part it's working pretty well. What is causing me some concern, is a
response to a re-share on Google+ by Dianne Hackborn, an engineer at
Google working on the Android platform. She raises some pretty valid
concerns (probably threatening to ban us from the Market if we include
it was a bit far over the line, though). I was wondering if someone
from Onskreen would care to comment?

https://plus.google.com/u/0/100275307499530023476/posts/ViCME1bb8F6

[onhsnm]

Steve,

Thanks for reaching out. We have heard variations on this theme for
some time, so it appears that it is time for us to respond.

We very much appreciate the amount of work that the Android team has
done to address the complexity of supporting applications on the
variety of screen sizes that "real" Android runs on. The Onskreen team
has spent an immense amount of time to continue that effort while
creating the Cornerstone experience.

As far as responding to Diane's comments directly, it’s a bit
difficult because there are no specific concerns mentioned. Her
contention appears to be that changes were made to the Android
Framework at all, not with anything specific with Cornerstone. We'd be
happy to have a conversation with them about anything specifically
they feel negatively impacts apps. We have more work to do on the
product so there are definitely items on our todo list to continue to
improve, but the first release clearly stays within the realm of an
Android optimization (most definitely not a fork) and outside of bugs,
does not break Android apps.

One of our goals was to support Android applications unchanged without
introducing Cornerstone specific APIs or modifications that
applications must conform to. As Diane said, there are some great
things we could have done by introducing multi-tasking specific
interfaces and manifest declarations, but we did not so Cornerstone
did not fragment from Android as it exists today. After all that is
what the app developers have targeted for their apps. Throughout the
code, you will find a number of architectural decisions to ensure apps
run without fragmentation (Ex: setting correct Configurations, not
running multiple instances, etc...); as well as feature decisions to
ensure the same (Ex: ability to turn Cornerstone off, removing the
ability to swap so that apps weren't forced to deal with changing
screen size, etc...)

Threats to rescind Market access are a bit much, we prefer to stick to
specifics and open a dialogue. We are happy to discuss specific
concerns and we expect that once the Google team has had a chance to
dig into the code, we will hear some. We also expect that dialogue to
make Cornerstone better for everyone, one of the reasons we open
sourced the code to start with.

hansmeet.

[ciwrl]

Bumping this with further comments from Dianne. I have asked her to
provide tangible concerns (so they can potentially be addressed 1 to
1)

Original Source here: http://goo.gl/qT1xL

"I have plenty of foresight, because we had been thinking about this
kind of thing since early in the tablet work. (If you look at the HC/
ICS code, you'll find a new ActivityStack class in the activity
manager which is the start of some refactoring to support just this
kind of thing.) Ultimately this was punted from HC because doing it
actually correctly is a significant amount of work, with requirements
on applications for them to behave correctly with it. To just start to
see the scope of the issue, try at runtime changing your screen from
1280x800 dp to say 640x400 dp and see how applications like that. You
can pick out many that will be fine, but plenty will break, and it is
not appropriate to inflict that on developers. Or consider that when
this UI has the right-hand panes up, the configuration of the main
area has switch from landscape to portrait, and is in an aspect ratio
that isn't compatible as per the CDD." - Dianne Hackborn

[ciwrl]

Response received: http://goo.gl/8Zah9

"You can look at the original post this one links to for my comments.
(And to be clear: nobody can give you a full list up-front of
problems, ultimately the problems are whatever is causing apps to
break, and to find that out you need to do extensive third party app
compatibility testing. You really should do this for any changes you
make to the platform, because developers can make surprising
assumptions about how the platform behaves that you don't expect.)"

"The dual screen devices were done by those manufacturers in a careful
way to not break apps -- existing applications are only run on one
screen, so they don't break. This kind of thing is done closely with
the manufacturer in order for them to be able to ship Market in a way
that won't impact existing applications.

As far as what issues there are, there are two obvious things I can
tell you right off that make this not compatible as per the CDD: when
the side panel is displayed, the resulting aspect ratio of the main
app area is outside the limits allowed by the CDD, and changes to
screen size available to apps is not compatible per the CDD. These
limitations are in place for very real reasons: for example, consider
apps that are using Market's multi-apk feature to have different .apks
for tablet vs. phone screen sizes, and what happens with them when
they switch between these two states? (Handling this probably means
first of all aggressively deprecating the use of multi-apk for this
stuff, which is why it needs to be done as part of the core platform
and the developer relationship with the platform.) Even ignoring multi-
apk, I can guarantee you there are apps that will break if switched
between these sizes.

Here's a basic rule of thumb when working on the platform: if you need
to make changes in any of the platform apps as a result of changes you
are doing in the platform, you almost certainly have introduced
compatibility issues that are going to impact our third party apps.
For example, what do you think the standard platform launcher is going
to do when its screen size is changing like that? It isn't going to be
happy, and nor will many of the third party launcher apps. With the
change you are looking at here, these kinds of issues are going to
come up all over the place, and solving many of them will require
introducing new contracts with applications and the platform (a.k.a.
APIs) for them to work with it. Plus a lot of careful compatibility
code to make sure existing apps don't get into situations they don't
expect."