Java Question How important is support for old versions of Android?

[warwound]

When creating a library i'm finding tasks that are simple to do with newer versions of Android but require workarounds on older versions.
The workarounds can vary in their complexity.

For example i want to include some images in a class, i want to include those images as Base64 encoded strings.
I'm talking about 8 images varying in size from under 1KB to just over 5KBs.
Since Android API level 8, the API has a built in Base64 utility class which i can use:

byte[] decodedBitmapBytes = Base64.decode(encodedBitmapString, Base64.DEFAULT);
return BitmapFactory.decodeByteArray(decodedBitmapBytes, 0, decodedBitmapBytes.length);

Simple and quick - the class works and is complete.

Versions of Android API levels prior to 8 do not have that Base64 class.
The possible workarounds are:

Do not use the API level 8 Base 64 class and either:

• Make it a requirement of my library that the developer includes the B4A StringUtils library in their project - my library would expect StringUtils to be available and not work if it was not included in the project.
• Find a (free) third party Base64 class and include that in my library.
  This can be done but the third party class is a massive class that has many methods and features.
  I require just a 'decode Base64 String to Byte Array' method.
• Do not Base64 encode these images and instead rely upon the developer including them in their project in the project's res/drawable folder and making sure they have their read-only property checked.
  Can my library package access the resources of the B4A application package? The workaround is getting complex and is time consuming.

I know the majority of you will say that it's important for a B4A library to support the same Android versions that B4A itself supports - and i agree.

But what's the point in having new native Android SDK classes to make development more straightforward if you cannot use them because you must support older versions of the API?

Martin.

 

[Jost aus Soest]

I don't think that this is a simple question of "yes" or "no"...

Personaly I could live very well with modern APIs, when at least 90% of the end users can still use our products.

Currrently (at least we arrive there in the next 2 months) this would mean that we have to support Android 2.2 (API 8) - exactly as you want!

Actual stats: Platform Versions | Android Developers

So I choose "No", voting for API 8 - but not newer!

 

[stevel05]

If a new 'function' is only available starting at a particular API, I think it is entirely reasonable that a library built on it does not support earlier versions. If the libraries author has a requirement to create the functionality for earlier versions then that is a bonus.

Your situation may be slightly different in that you are not creating a function based directly on a new feature, but the new feature makes it easier to create your library.

If it were me, and there was a straight forward, easily supportable way to implement the function on earlier API's then I would do it. If it is going to cause more trouble and potentially break the functionality if this or that dependency may not be present, I think I would explain that in the library release.

If someone needs the functionality for an earlier release, then having looked at the possibility of implementing it, you would be in a good position to point them in the right direction and assist them in creating an appropriate alternative.

 

[thedesolatesoul]

If you keep adding and maintaining workarounds for legacy versions, you will spend too much time supporting a far less percentage of devices.
If 80% of your time is spent on 20% of the devices, it up to you to decide whether you have that much time.

 

[warwound]

Thanks for all the replies.

I've left the poll running for a couple of days and the results are:

Should a library support all API levels?

Yes it should support the same API levels as B4A itself does. 2 votes.

No the developer should be free to use newer API level classes. 6 votes.

That along with the usage statistics found in the link posted by Jost aus Soest leads me to think that supporting API level 8 onwards is the best compromise.

Martin.

 

[Erel]

It depends. In some cases it is not possible to support older devices at all. For example NFC is only supported in Android 2.3.3+.

In this case I think that I would have made my library dependent on StringUtils. However your choice is completely reasonable.

 

[warwound]

Well after an interesting chat on the B4A chatroom yesterday i'm now wondering if resources can be included in the library jar file.

The native Android OSMDroid library includes some drawables in it's jar, somehow including them as PNG files.
These are the same images that i have included in my library as Base64 encoded Strings.

The web has a lot of posts from users of the native library complaining that their Android app fails with resource not found errors.

I had the same problem using the native library in a native Android app - hence my Base64 encoded Strings solution.

But after a chat on the chatroom i've decided to research more about including resources (of any type) in a B4A library.
If i can find a way to make it work then my original problem - no Base64 support prior to Froyo - would be solved.
I'd also be able to develop a balloon to display on the MapView showing info on clicked markers and that balloon would be inflated from a layout file included in the B4A library jar.

I shall research and see what i can find out.

Martin.

 

[Erel]

You can also ask the library user to include the images in the Files tab (assets folder).

 

[Jost aus Soest]

You can also ask the library user to include the images in the Files tab (assets folder).

Yes, but these are exactly the things a library user (me!) forgets every time!

 

[warwound]

Yes, but those are exactly the things a library user (me!) forgets every time!

EXACTLY!

A self contained library jar is so much more elegant than requiring that the user copy/paste files into their projects and makes them read only or that they add files to their assets folder.

I've found some code on Stackoverflow that i shall test and hopefully achieve what i want to do.

Martin.

 

[Erel]

I don't think that it will work.

I agree that simpler is better. However I think that this is currently your best option. And it doesn't take too much to copy the file once.

 

[corwin42]

For the AHActionBar and AHQuickAction libraries I had a similar problem. These libraries make use of many resource files.

The solution in these libraries is to let the user put the resource files in the Objects/res folder and make them read only. The libraries themself use reflection to access the resource ids from the R.class file which is generated by B4A on compilation.

This solution works but is not very easy to use and you will get runtime errors if you make something wrong. I myself often forget to make a resource file read only and it gets deleted from B4A the next compile.

I think this problem should be addressed in a future version of B4A with a better mechanism. It seems that library developers want to include resources in their libraries more often now and a simple to use solution (for the B4A developer who just wants to use the library) would be very nice.

@warwound: The solution in the second answer on Stackoverflow is exactly the mechanism what AHActionBar and AHQuickAction libraries use. So it works.

 

[warwound]

I've been experimenting and have managed to get a PNG icon packed into my B4A library.

But so far each time i compile an app that uses my library and then look in the R.java class, there is no sign of my PNG icon being compiled into the B4A app.

I shall keep trying as this is important to me if i can get it working.

Martin.

 

[thedesolatesoul]

Have you seen this post:
http://www.b4x.com/forum/additional...158-mobile-payments-library-10.html#post93481

 

[corwin42]

But so far each time i compile an app that uses my library and then look in the R.java class, there is no sign of my PNG icon being compiled into the B4A app.

I shall keep trying as this is important to me if i can get it working.

I don't think this will work unless the android tools are modified that create the R file.

 

[warwound]

No i hadn't seen that post you linked to.

I searched a bit and found this page: Building and Running | Android Developers.

You can see application resources are compiled into an APK - but 3rd party library resources are not mentioned.

The Stackoverflow post seems to suggest that it's possible though.
(Packaging Android resource files within a distributable Jar file - Stack Overflow).

I shall continue my research!

Martin.

 

[warwound]

Well after much searching i have come to the conclusion that it is NOT possible to compile an application (B4A or native Android) to include resources from an external JAR library.

It's a bit of a FAQ on the Android Developer group: https://groups.google.com/group/and...source+in+external+jar&qt_g=Search+this+group.

You can compile a JAR library with resources and another JAR library can access those resources BUT within the Android build process those resources will not be included.

Back to the drawing board....

Martin.