Remove support for Android 2.1, api level android-7 #182

Closed
donv opened this Issue May 16, 2012 · 16 comments

Comments

Projects
None yet
2 participants
@donv
Member

donv commented May 16, 2012

http://developer.android.com/resources/dashboard/platform-versions.html

Android 2.1 devices are as of 2012-05-01 5.5% of the connected devices. If we cleanup our code and remove special support for Android 2.1 (api level android-7) , we still support 93.5% of the connected devices, and in my opinion all devices that can comfortably run Ruboto.

@ruboto any other opinions?

@rscottm

This comment has been minimized.

Show comment
Hide comment
@rscottm

rscottm May 17, 2012

Member

Can you say a little more about what code this impacts on our end?

I'm leaning towards supporting it a little longer, but I'm not clear on the
impact. One android-7 device I'm still using is the WIMM One, but that is a
special case.

On Wed, May 16, 2012 at 1:04 PM, Uwe Kubosch <
reply@reply.github.com

wrote:

http://developer.android.com/resources/dashboard/platform-versions.html

Android 2.1 devices are as of 2012-05-01 5.5% of the connected devices.
If we cleanup our code and remove special support for Android 2.1 (api
level android-7) , we still support 93.5% of the connected devices, and in
my opinion all devices that can comfortably run Ruboto.

@ruboto any other opinions?


Reply to this email directly or view it on GitHub:
#182

Member

rscottm commented May 17, 2012

Can you say a little more about what code this impacts on our end?

I'm leaning towards supporting it a little longer, but I'm not clear on the
impact. One android-7 device I'm still using is the WIMM One, but that is a
special case.

On Wed, May 16, 2012 at 1:04 PM, Uwe Kubosch <
reply@reply.github.com

wrote:

http://developer.android.com/resources/dashboard/platform-versions.html

Android 2.1 devices are as of 2012-05-01 5.5% of the connected devices.
If we cleanup our code and remove special support for Android 2.1 (api
level android-7) , we still support 93.5% of the connected devices, and in
my opinion all devices that can comfortably run Ruboto.

@ruboto any other opinions?


Reply to this email directly or view it on GitHub:
#182

@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv May 18, 2012

Member

On 2012-05-17, at 20:35, Scott Moyer wrote:

Can you say a little more about what code this impacts on our end?

Certainly! I am airing deprecation wishes regularly so we can keep a culture of dropping old code and do regular cleanups.

In this process I try to mark every workaround for old code with TODO/FIXME markers. Each marker should be accompanied by a developer name. This developer is not alone responsible for the bit of code, we all are, right :) However, if nobody can remember why the TODO/FIXME is there, not even the mentioned developer, then the code should be removed. This is a practice that has served me well on other projects.

The bits of code that are only for android-7 support should be marked with android-7. The ones I know of are:

  • test/rake_test.rb
    Test for skipping on-device tests.
    No real impact since the tests aren't run for android-7 anyway.
  • assets/src/org/ruboto/Script.java
    Logic around getExternalFilesDir that is missing from android-7 => use of Ruby code to get external files dir. Requires that the JRuby runtime is initialized earlier than necessary, leading to more complicated startup.

I'm leaning towards supporting it a little longer, but I'm not clear on the
impact.

The impact is perhaps small on the code, and not THAT big a deal. One thing nagging me is that the code is not tested and not testable, and that we don't know of ANY actual users. I hate having code around that we don't know for sure is actually used by anyone.

I am with you on keeping android-7 support for a while longer, as long as you like, but I would like some kind of condition for when to remove it.

One android-7 device I'm still using is the WIMM One, but that is a
special case.

Yes, a special case, but a concrete one. Does it work? It's been a while since I heard anything about it. If it works, and is usable, we should make a showcase of it.

I see new Android devices almost every week now. Does the WIMM One have any competitors, yet?

Uwe Kubosch
http://ruboto.org/

Member

donv commented May 18, 2012

On 2012-05-17, at 20:35, Scott Moyer wrote:

Can you say a little more about what code this impacts on our end?

Certainly! I am airing deprecation wishes regularly so we can keep a culture of dropping old code and do regular cleanups.

In this process I try to mark every workaround for old code with TODO/FIXME markers. Each marker should be accompanied by a developer name. This developer is not alone responsible for the bit of code, we all are, right :) However, if nobody can remember why the TODO/FIXME is there, not even the mentioned developer, then the code should be removed. This is a practice that has served me well on other projects.

The bits of code that are only for android-7 support should be marked with android-7. The ones I know of are:

  • test/rake_test.rb
    Test for skipping on-device tests.
    No real impact since the tests aren't run for android-7 anyway.
  • assets/src/org/ruboto/Script.java
    Logic around getExternalFilesDir that is missing from android-7 => use of Ruby code to get external files dir. Requires that the JRuby runtime is initialized earlier than necessary, leading to more complicated startup.

I'm leaning towards supporting it a little longer, but I'm not clear on the
impact.

The impact is perhaps small on the code, and not THAT big a deal. One thing nagging me is that the code is not tested and not testable, and that we don't know of ANY actual users. I hate having code around that we don't know for sure is actually used by anyone.

I am with you on keeping android-7 support for a while longer, as long as you like, but I would like some kind of condition for when to remove it.

One android-7 device I'm still using is the WIMM One, but that is a
special case.

Yes, a special case, but a concrete one. Does it work? It's been a while since I heard anything about it. If it works, and is usable, we should make a showcase of it.

I see new Android devices almost every week now. Does the WIMM One have any competitors, yet?

Uwe Kubosch
http://ruboto.org/

@rscottm

This comment has been minimized.

Show comment
Hide comment
@rscottm

rscottm May 21, 2012

Member

On Fri, May 18, 2012 at 1:31 AM, Uwe Kubosch <
reply@reply.github.com

wrote:

On 2012-05-17, at 20:35, Scott Moyer wrote:

Can you say a little more about what code this impacts on our end?

Certainly! I am airing deprecation wishes regularly so we can keep a
culture of dropping old code and do regular cleanups.

In this process I try to mark every workaround for old code with
TODO/FIXME markers. Each marker should be accompanied by a developer name.
This developer is not alone responsible for the bit of code, we all are,
right :) However, if nobody can remember why the TODO/FIXME is there, not
even the mentioned developer, then the code should be removed. This is a
practice that has served me well on other projects.

Sounds good to me.

The bits of code that are only for android-7 support should be marked with
android-7. The ones I know of are:

  • test/rake_test.rb
    Test for skipping on-device tests.
    No real impact since the tests aren't run for android-7 anyway.
  • assets/src/org/ruboto/Script.java
    Logic around getExternalFilesDir that is missing from android-7 => use of
    Ruby code to get external files dir. Requires that the JRuby runtime is
    initialized earlier than necessary, leading to more complicated startup.

We could definitely modify this last to use reflection instead of going
through the runtime. Not sure it strikes me as a big enough issues to make
any changes since it seems to be working.

I'm leaning towards supporting it a little longer, but I'm not clear on
the
impact.

The impact is perhaps small on the code, and not THAT big a deal. One
thing nagging me is that the code is not tested and not testable, and that
we don't know of ANY actual users. I hate having code around that we don't
know for sure is actually used by anyone.

I am with you on keeping android-7 support for a while longer, as long as
you like, but I would like some kind of condition for when to remove it.

One android-7 device I'm still using is the WIMM One, but that is a
special case.

Yes, a special case, but a concrete one. Does it work? It's been a while
since I heard anything about it. If it works, and is usable, we should
make a showcase of it.

It works. It could use a little TLC to polish it up.

I see new Android devices almost every week now. Does the WIMM One have
any competitors, yet?

There seem to be a bunch of smart watches coming out. Each one takes a
different approach. The Sony one seems to simply be a bluetooth-based
remote display. WIMM seems to have a good approach (make a platform and
then try to license it to other providers). I like that it's a pretty
complete device (sensors, connectivity, etc.). It's still just a developer
preview. I haven't seen any partners announced.

Member

rscottm commented May 21, 2012

On Fri, May 18, 2012 at 1:31 AM, Uwe Kubosch <
reply@reply.github.com

wrote:

On 2012-05-17, at 20:35, Scott Moyer wrote:

Can you say a little more about what code this impacts on our end?

Certainly! I am airing deprecation wishes regularly so we can keep a
culture of dropping old code and do regular cleanups.

In this process I try to mark every workaround for old code with
TODO/FIXME markers. Each marker should be accompanied by a developer name.
This developer is not alone responsible for the bit of code, we all are,
right :) However, if nobody can remember why the TODO/FIXME is there, not
even the mentioned developer, then the code should be removed. This is a
practice that has served me well on other projects.

Sounds good to me.

The bits of code that are only for android-7 support should be marked with
android-7. The ones I know of are:

  • test/rake_test.rb
    Test for skipping on-device tests.
    No real impact since the tests aren't run for android-7 anyway.
  • assets/src/org/ruboto/Script.java
    Logic around getExternalFilesDir that is missing from android-7 => use of
    Ruby code to get external files dir. Requires that the JRuby runtime is
    initialized earlier than necessary, leading to more complicated startup.

We could definitely modify this last to use reflection instead of going
through the runtime. Not sure it strikes me as a big enough issues to make
any changes since it seems to be working.

I'm leaning towards supporting it a little longer, but I'm not clear on
the
impact.

The impact is perhaps small on the code, and not THAT big a deal. One
thing nagging me is that the code is not tested and not testable, and that
we don't know of ANY actual users. I hate having code around that we don't
know for sure is actually used by anyone.

I am with you on keeping android-7 support for a while longer, as long as
you like, but I would like some kind of condition for when to remove it.

One android-7 device I'm still using is the WIMM One, but that is a
special case.

Yes, a special case, but a concrete one. Does it work? It's been a while
since I heard anything about it. If it works, and is usable, we should
make a showcase of it.

It works. It could use a little TLC to polish it up.

I see new Android devices almost every week now. Does the WIMM One have
any competitors, yet?

There seem to be a bunch of smart watches coming out. Each one takes a
different approach. The Sony one seems to simply be a bluetooth-based
remote display. WIMM seems to have a good approach (make a platform and
then try to license it to other providers). I like that it's a pretty
complete device (sensors, connectivity, etc.). It's still just a developer
preview. I haven't seen any partners announced.

@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv May 24, 2012

Member

On 2012-05-21, at 06:40, Scott Moyer wrote:

  • assets/src/org/ruboto/Script.java
    Logic around getExternalFilesDir that is missing from android-7 => use of
    Ruby code to get external files dir. Requires that the JRuby runtime is
    initialized earlier than necessary, leading to more complicated startup.

We could definitely modify this last to use reflection instead of going
through the runtime. Not sure it strikes me as a big enough issues to make
any changes since it seems to be working.

I'll change it to use reflection and see if it has any impact on startup time. If there is no real difference, we can keep it.

I am with you on keeping android-7 support for a while longer, as long as
you like, but I would like some kind of condition for when to remove it.

One android-7 device I'm still using is the WIMM One, but that is a
special case.

Yes, a special case, but a concrete one. Does it work? It's been a while
since I heard anything about it. If it works, and is usable, we should
make a showcase of it.

It works. It could use a little TLC to polish it up.

Does it use a standard Ruboto project, or is special customization required?

Do you use it?

Uwe Kubosch
http://ruboto.org/

Member

donv commented May 24, 2012

On 2012-05-21, at 06:40, Scott Moyer wrote:

  • assets/src/org/ruboto/Script.java
    Logic around getExternalFilesDir that is missing from android-7 => use of
    Ruby code to get external files dir. Requires that the JRuby runtime is
    initialized earlier than necessary, leading to more complicated startup.

We could definitely modify this last to use reflection instead of going
through the runtime. Not sure it strikes me as a big enough issues to make
any changes since it seems to be working.

I'll change it to use reflection and see if it has any impact on startup time. If there is no real difference, we can keep it.

I am with you on keeping android-7 support for a while longer, as long as
you like, but I would like some kind of condition for when to remove it.

One android-7 device I'm still using is the WIMM One, but that is a
special case.

Yes, a special case, but a concrete one. Does it work? It's been a while
since I heard anything about it. If it works, and is usable, we should
make a showcase of it.

It works. It could use a little TLC to polish it up.

Does it use a standard Ruboto project, or is special customization required?

Do you use it?

Uwe Kubosch
http://ruboto.org/

@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv May 24, 2012

Member

So, I have changed the getExternalFiles call to use Java reflection instead of Ruby code, and I am satisfied for now. Postponing dropping android-7 support.

Maybe reconsider when android-7 devices are less than 1% of connected devices?

Member

donv commented May 24, 2012

So, I have changed the getExternalFiles call to use Java reflection instead of Ruby code, and I am satisfied for now. Postponing dropping android-7 support.

Maybe reconsider when android-7 devices are less than 1% of connected devices?

@rscottm

This comment has been minimized.

Show comment
Hide comment
@rscottm

rscottm May 24, 2012

Member

On Thu, May 24, 2012 at 3:58 AM, Uwe Kubosch <
reply@reply.github.com

wrote:

On 2012-05-21, at 06:40, Scott Moyer wrote:

I am with you on keeping android-7 support for a while longer, as long
as
you like, but I would like some kind of condition for when to remove it.

One android-7 device I'm still using is the WIMM One, but that is a
special case.

Yes, a special case, but a concrete one. Does it work? It's been a
while
since I heard anything about it. If it works, and is usable, we should
make a showcase of it.

It works. It could use a little TLC to polish it up.

Does it use a standard Ruboto project, or is special customization
required?

I think it was a snapshot of of ruboto (maybe January), but it's not the
latest. I had to do a few things to get around the heap issue: 1) Drop back
to an older JRuby (1.5.6), 2) trim out most of the Joda timezone files, and
3) add the stdlib as zip to be unpacked into the filesystem.

Do you use it?

No, I haven't been working any on any projects for the WIMM One.

Member

rscottm commented May 24, 2012

On Thu, May 24, 2012 at 3:58 AM, Uwe Kubosch <
reply@reply.github.com

wrote:

On 2012-05-21, at 06:40, Scott Moyer wrote:

I am with you on keeping android-7 support for a while longer, as long
as
you like, but I would like some kind of condition for when to remove it.

One android-7 device I'm still using is the WIMM One, but that is a
special case.

Yes, a special case, but a concrete one. Does it work? It's been a
while
since I heard anything about it. If it works, and is usable, we should
make a showcase of it.

It works. It could use a little TLC to polish it up.

Does it use a standard Ruboto project, or is special customization
required?

I think it was a snapshot of of ruboto (maybe January), but it's not the
latest. I had to do a few things to get around the heap issue: 1) Drop back
to an older JRuby (1.5.6), 2) trim out most of the Joda timezone files, and
3) add the stdlib as zip to be unpacked into the filesystem.

Do you use it?

No, I haven't been working any on any projects for the WIMM One.

@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv Jun 16, 2012

Member

Android 2.1: 5.2% as of 2012-06-01

Member

donv commented Jun 16, 2012

Android 2.1: 5.2% as of 2012-06-01

@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv Jul 6, 2012

Member

Android 2.1: 4.7% as of 2012-07-02

Member

donv commented Jul 6, 2012

Android 2.1: 4.7% as of 2012-07-02

@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv Aug 10, 2012

Member

Android 2.1: 4.2% as of 2012-08-01

Member

donv commented Aug 10, 2012

Android 2.1: 4.2% as of 2012-08-01

@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv Sep 8, 2012

Member

Android 2.1: 3.7% as of 2012-09-04

Member

donv commented Sep 8, 2012

Android 2.1: 3.7% as of 2012-09-04

@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv Oct 2, 2012

Member

Android 2.1: 3.4% as of 2012-10-01

Member

donv commented Oct 2, 2012

Android 2.1: 3.4% as of 2012-10-01

@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv Nov 5, 2012

Member

Android 2.1: 3.1% as of 2012-11-01

Member

donv commented Nov 5, 2012

Android 2.1: 3.1% as of 2012-11-01

@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv Dec 4, 2012

Member

Android 2.1: 2.7% as of 2012-12-03

Member

donv commented Dec 4, 2012

Android 2.1: 2.7% as of 2012-12-03

@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv Jan 6, 2013

Member

Starting to track all the versions, for history. Google does not display values older than 6 months.

Data collected during a 14-day period ending on January 3, 2013:

VersionCodenameAPIDistribution
1.6Donut40.2%
2.1Eclair72.4%
2.2Froyo89.0%
2.3 - 2.3.2Gingerbread90.2%
2.3.3 - 2.3.71047.4%
3.1Honeycomb120.4%
3.2131.1%
4.0.3-4.0.4Ice Cream Sandwich1529.1%
4.1Jelly Bean169.0%
4.2171.2%
Member

donv commented Jan 6, 2013

Starting to track all the versions, for history. Google does not display values older than 6 months.

Data collected during a 14-day period ending on January 3, 2013:

VersionCodenameAPIDistribution
1.6Donut40.2%
2.1Eclair72.4%
2.2Froyo89.0%
2.3 - 2.3.2Gingerbread90.2%
2.3.3 - 2.3.71047.4%
3.1Honeycomb120.4%
3.2131.1%
4.0.3-4.0.4Ice Cream Sandwich1529.1%
4.1Jelly Bean169.0%
4.2171.2%
@donv

This comment has been minimized.

Show comment
Hide comment
@donv

donv Feb 12, 2013

Member

1.6 Donut 4 0.2%
2.1 Eclair 7 2.2%
2.2 Froyo 8 8.1%
2.3 - 2.3.2 Gingerbread 9 0.2%
2.3.3 - 2.3.7 10 45.4%
3.1 Honeycomb 12 0.3%
3.2 13 1.0%
4.0.3 - 4.0.4 Ice Cream Sandwich 15 29.0%
4.1 Jelly Bean 16 12.2%
4.2 17 1.4%

Data collected during a 14-day period ending on February 4, 2013

Member

donv commented Feb 12, 2013

1.6 Donut 4 0.2%
2.1 Eclair 7 2.2%
2.2 Froyo 8 8.1%
2.3 - 2.3.2 Gingerbread 9 0.2%
2.3.3 - 2.3.7 10 45.4%
3.1 Honeycomb 12 0.3%
3.2 13 1.0%
4.0.3 - 4.0.4 Ice Cream Sandwich 15 29.0%
4.1 Jelly Bean 16 12.2%
4.2 17 1.4%

Data collected during a 14-day period ending on February 4, 2013

@rscottm

This comment has been minimized.

Show comment
Hide comment
@rscottm

rscottm Feb 12, 2013

Member

I say it's time.

Member

rscottm commented Feb 12, 2013

I say it's time.

donv added a commit that referenced this issue May 6, 2013

* Issue #182 Remove support for Android 2.1, api level android-7
* Issue #364 Remove support for Android 2.2, api level android-8

@ghost ghost assigned donv May 6, 2013

@donv donv closed this May 6, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment