> I have a few scenarios where I guess I am not alone with. There is no
> easy solution but this has to be on top of the list I think...

> 1. Suppose you have an application that is compiled with 1.5 and is
> working fine even if started on a 1.6 device. But you now want to
> support other resolutions, so you need to compile with 1.6.
> Problem:
> If I recompile and publish the new apk, the 1.5 users want see my
> applications. Users already downloaded my application can not
> upgrade... (will there be a "new version" available shown to them in
> the market?)

> 2. Lets say your application works fine on 1.5 and 1.6 and you decided
> to publish your application twice with different package names.
> "MyApplication 1.5" and "MyApplication 1.6" for example.
> Problem:
> The user upgrading from a older version does not know that there is a
> new version, because you published a new Application. You can write it
> into the description and tell the user to download the 1.6 version but
> many users might not read that...
> Settings from the other application are lost...
> Your downloads are split into two applications, so you might not make
> it into the top ranks that easy . You might even need to publish 4
> applications if you have a light and a paid version.

> 3. Now 2.0 SDK is available and you want to add multi touch features
> or any other new stuff for all 2.0 users.
> Problem:
> The above problems are getting even worse. There is no way to easily
> upload multiple apks for the same application.
> Having to rename the package is also not making this better. Every
> time svn freaks out and marks everything as new. Sharing code between
> versions is difficult because of that.

> I don't know if its just "3" (provider in Austria), but I still have
> not received an official update to 1.6. Testing on the real device is
> not possible with a 1.6 image if you don't want to root your phone and
> update the rom manually. 2.0 will be on some devices soon, so there is
> definitely a need to support all 3 versions.

> Conclusion:
> There should be a faster update cycle for the users or a slower update
> of new versions meaning bigger steps.
> or
> We get an easier way to support multiple versions. This also means we
> need a way to know how many actual devices with version 1.5 / 1.6 /
> 2.0 are already sold and/or upgraded. If i know that 1.5 is only on
> about 5% of the devices left, then I can just stop supporting that
> version and upgrade.

> At the moment we can just guess...

> I have a few scenarios where I guess I am not alone with. There is no
> easy solution but this has to be on top of the list I think...

> 1. Suppose you have an application that is compiled with 1.5 and is
> working fine even if started on a 1.6 device. But you now want to
> support other resolutions, so you need to compile with 1.6.
> Problem:
> If I recompile and publish the new apk, the 1.5 users want see my
> applications. Users already downloaded my application can not
> upgrade... (will there be a "new version" available shown to them in
> the market?)

> 2. Lets say your application works fine on 1.5 and 1.6 and you decided
> to publish your application twice with different package names.
> "MyApplication 1.5" and "MyApplication 1.6" for example.
> Problem:
> The user upgrading from a older version does not know that there is a
> new version, because you published a new Application. You can write it
> into the description and tell the user to download the 1.6 version but
> many users might not read that...
> Settings from the other application are lost...
> Your downloads are split into two applications, so you might not make
> it into the top ranks that easy . You might even need to publish 4
> applications if you have a light and a paid version.

> 3. Now 2.0 SDK is available and you want to add multi touch features
> or any other new stuff for all 2.0 users.
> Problem:
> The above problems are getting even worse. There is no way to easily
> upload multiple apks for the same application.
> Having to rename the package is also not making this better. Every
> time svn freaks out and marks everything as new. Sharing code between
> versions is difficult because of that.

> I don't know if its just "3" (provider in Austria), but I still have
> not received an official update to 1.6. Testing on the real device is
> not possible with a 1.6 image if you don't want to root your phone and
> update the rom manually. 2.0 will be on some devices soon, so there is
> definitely a need to support all 3 versions.

> Conclusion:
> There should be a faster update cycle for the users or a slower update
> of new versions meaning bigger steps.
> or
> We get an easier way to support multiple versions. This also means we
> need a way to know how many actual devices with version 1.5 / 1.6 /
> 2.0 are already sold and/or upgraded. If i know that 1.5 is only on
> about 5% of the devices left, then I can just stop supporting that
> version and upgrade.

> At the moment we can just guess...

> If you want to support different resolutions, just change (or add) the
> targetSdkVersion attribute in your Android manifest to 4 (which is1.6).  If you don't change the minSdkVersion, it will still be available
> to users with older versions of Android.

> Things only get tricky if you want to use API's from later versions of
> Android, while still retaining compatibility with previous versions.
> Then you have to isolate the code that uses the new API in a class that
> you reference only dynamically, so you can test if the new API is
> available before trying to use the class.

> Beowolve wrote:
> > Hi all,

> > I have a few scenarios where I guess I am not alone with. There is no
> > easy solution but this has to be on top of the list I think...

> > 1. Suppose you have an application that is compiled with1.5and is
> > working fine even if started on a1.6device. But you now want to
> > support other resolutions, so you need to compile with1.6.
> > Problem:
> > If I recompile and publish the new apk, the1.5users want see my
> > applications. Users already downloaded my application can not
> > upgrade... (will there be a "new version" available shown to them in
> > the market?)

> > 2. Lets say your application works fine on1.5and1.6and you decided
> > to publish your application twice with different package names.
> > "MyApplication1.5" and "MyApplication1.6" for example.
> > Problem:
> > The user upgrading from a older version does not know that there is a
> > new version, because you published a new Application. You can write it
> > into the description and tell the user to download the1.6version but
> > many users might not read that...
> > Settings from the other application are lost...
> > Your downloads are split into two applications, so you might not make
> > it into the top ranks that easy . You might even need to publish 4
> > applications if you have a light and a paid version.

> > 3. Now 2.0 SDK is available and you want to add multi touch features
> > or any other new stuff for all 2.0 users.
> > Problem:
> > The above problems are getting even worse. There is no way to easily
> > upload multiple apks for the same application.
> > Having to rename the package is also not making this better. Every
> > time svn freaks out and marks everything as new. Sharing code between
> > versions is difficult because of that.

> > I don't know if its just "3" (provider in Austria), but I still have
> > not received an official update to1.6. Testing on the real device is
> > not possible with a1.6image if you don't want to root your phone and
> > update the rom manually. 2.0 will be on some devices soon, so there is
> > definitely a need to support all 3 versions.

> > Conclusion:
> > There should be a faster update cycle for the users or a slower update
> > of new versions meaning bigger steps.
> > or
> > We get an easier way to support multiple versions. This also means we
> > need a way to know how many actual devices with version1.5/1.6/
> > 2.0 are already sold and/or upgraded. If i know that1.5is only on
> > about 5% of the devices left, then I can just stop supporting that
> > version and upgrade.

> > At the moment we can just guess...